Live data from Hacker News

Astro 1.0 – a web framework for building fast, content-focused websites

astro.build

151–160 of 256 posts

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#151
post #146

Earlier quoted context omitted.

You have to be joking, surely? React/Vue as a mere static template languages? Dedicated static site frameworks such as Jekyll and Middleman are a much better experience. My favourite is still Perl's Template::Toolkit.

TypeScript, that's the differentiator. Having fully typed variables in the templates cannot be replicated in templating languages (well technically they might be able to but that's not as ergonomic as fact).

Talk about sledgehammer to crack a nut - honestly, why does anyone need type safety in a simple templating operation? Dynamic languages have their uses, you know. Type safety is a tool, not an ideology.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#152

Earlier quoted context omitted.

Have you used React before? It's miles above HTML templating. I honestly don't use frameworks that have regular templating anymore, like Vue or Svelte.

What are you referring to? I am unaware of what “regular” templating you’re referring to or what react is achieving that is not available or cumbersome under react or svelte. I mean if JSX is considered as something particularly powerful (not saying it does) doesn’t Vue actually do that https://vuejs.org/guide/extras/render-function.html ?

Think of JSX as a macro, rather than "regular" templating, which is typically string substitution.

For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.

You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#153
post #114
post #111

Earlier quoted context omitted.

Also out of the box: - Tailwind support - Optional choice of UI framework (React, SolidJS, Svelte etc...) - Partial hydration. Generates _actual HTML_ on the server-side rather than JS blobs (which is what some other frameworks call SSR). It really does work nicely. It's very fast, minimal config required.

As someone who started building web pages in the 90s, the "islands architecture" (generating HTML server-side) of Astro and others makes me laugh because it's literally what we used to do with XMLHttpRequest in IE 5/6 20+ years ago. We generated page partials (or used static ones) and pulled them in with "Ajax" (for the oldies out there) and then inserted them in the right place on the page using innerHTML. There's n…

Sure, and I was also around when XMLHttpRequest was new and innovative. And development then was awful compared to where webdev is today - I've been in the industry that entire time.

And it's not quite the same thing - we're not talking about injecting server-side HTML snippets into other HTML pages (which never actually went away). This is more like optional, self-contained but fully-featured web applications that load after the full HTML renders. You could use that to fetch static HTML, or you could use it to provide an interactive client-side experience that only operates on a portion of the page, up to whatever complexity you like. And if the user has JS disabled the rest of the site still renders correctly.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#154
post #151

Earlier quoted context omitted.

TypeScript, that's the differentiator. Having fully typed variables in the templates cannot be replicated in templating languages (well technically they might be able to but that's not as ergonomic as fact).

Talk about sledgehammer to crack a nut - honestly, why does anyone need type safety in a simple templating operation? Dynamic languages have their uses, you know. Type safety is a tool, not an ideology.

I basically never use dynamic languages anymore. If there aren't algebraic data types in a language I simply don't use it. Sometimes people think I'm exaggerating but it's truly great to use a language with ADTs that you get spoiled.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#155

I'm looking at https://docs.astro.build/en/concepts/why-astro/ and I still can't tell what's interesting and unique about this as compared to other options in this space. I acknowledge that this might be a PEBKAC situation, but I'd love to hear thoughts from people who used Next.js, Remix, or whatever and found Astro to be a revelation. It seems like Astro's creators believe "content-focused" is a differentiator, but…

I think it makes the tradeoffs that are ideal for content-oriented sites rather than web apps.

> Next.js uses React to render your website. Astro is more flexible: you are free to build UI with any popular component library (React, Preact, Vue, Svelte, Solid and others) or Astro’s HTML-like component syntax which is similar to HTML + JSX.

> Both Next.js and Astro are frameworks for building websites. Next.js does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites).

https://docs.astro.build/en/comparing-astro-vs-other-tools/#...

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#156

Sometimes all the frameworks that re-invent MVC (but in a detached fashion) and tout "server side rendering" just feel like we've come full circle where we're just serving a static view cache that was generated from models and data using a controller. The big difference here (as with other JavaScript-based renderers) is of course the "use one tool/language for everything" aspect which to me is a bit of a 'meh'-benefi…

I think edge computing and CDNs might be what is making this all more interesting. It is not just where you render (Server vs. Client), it is where you render (Dallas vs. Rio). If you can get your app to re render small sections and have the framework figure out that these sections are static and can chuck them in a CDN (or they are not and need an edge server, or a central server) then you can get lots of optimizations that way.

That said, for most side projects and commercial projects the complexity may not be worth it. It probably makes the most difference to very high traffic sites where money is lost for each millisecond delay in giving you the page (or the ads). And in this sense it may be premature optimization.

I like using Next.js, but I often wonder if it is "too much" and adds complexity I wouldn't have otherwise. An old fashioned rails app, and some caching / CDN done in front of it as a separate concern is probably more than enough performance for most people.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#157
There are a lot of open source projects similar to astro. Here is a comparison of the popularity and product iteration trend of them. https://ossinsight.io/collections/static-site-generator You can see that astro's popularity is on the rise. I think it's worth keeping an eye on.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#158
post #72

Earlier quoted context omitted.

So they have moved all the previously frontend stuff to backend and output Hot-wired / Liveview / Livewire instead?

I wish. AFAIK it's just classic server-side rendering with full-page navigation. Mind you, that's the optimal solution in many cases. But a full-stack JavaScript web framework with something like Phoenix's channels and LiveView built in would be a killer combination.

I just started working on something like this. It's a VDOM implemented in Ruby and it streams updates to the browser via Server-Sent Events which are then applied by a tiny bit of JavaScript.

A basic counter component would look something like this:

    initial_state do |props|
      { count: 0 }
    end

    handler(:increment) do |e|
      update do |count:|
        { count: count + 1 }
      end
    end

    render do
      
        

Count: {state[:count]}

Increment end
There are some things I'm used to in the JavaScript world that I'm trying to introduce here. I got hot reloading which is pretty cool. And CSS modules... and static typing with Sorbet.

Events are handled on the server, so there's no need for an API... You could just talk to your database directly in your onsubmit-handler. I think that might be the largest benefit from using something like this.

If the app is deployed in a region close to you, you won't barely notice the latency.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#159
post #99
post #80

Earlier quoted context omitted.

> As long as you have npm installed it'll work. Exactly proving my original point.

If you don't have npm installed, just stay as far as you can from this :D Seriously, JS static website generators are the worst... use something written in any compiled language so you just download and run a single binary, no messing around with npm and millions of dependencies. Take your pick here: https://jamstack.org/generators/

PHP is pretty great. No NPM needed

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#160
post #134

Publishing with a SSG is so complex (and for many good reasons, as other comments mention). When anything gets this this complex, I pine for an end to end optimization targeting simplicity. And I don't think the static site generator is the driving force for complexity here. The web ecosystem really seems nuts when you step back. When it comes to publishing on the web, I would really like to see something simpler gai…

That same thinking is what led me to build [Primo]( https://github.com/primodotso/primo ) - a SSG in a desktop/server CMS. It’s the only thing me or anyone I know who’s uses it uses to build normal websites anymore bc it’s so much faster to get a site up and easier to write code/content.

Looks cool, but I think you missed a big opportunity to charge money for this.
Post reply on HN