Hacker News Reader

> - It's still html and css centric - Once built, it doesn't require js by default - You can still opt-into adding js for interactivity here and there

I've never used Astro so forgive my ignorance, but isn't that just creating a .html file, a .css file and then optionally provide a .js file? What does Astro give you in this case? You'd get the same experience with a directory of files + Notepad basically. It's also even more optimized for speed, since there is no overhead/bloat at all, including at dev-time, just pure files, sent over HTTP.

> an example is that the css minifier cleverly inlines some CSS to avoid additional queries

Is that a common performance issue in the web pages you've built? I think across hundreds of websites, and for 20 years, not once have "CSS queries" been a bottleneck in even highly interactive webpages with thousands of elements, it's almost always something else (usually network).

Fair questions.

For the first one, the main benefits of Astro over static html and css (for my use cases) are the ability to include components and enforce the properties that must be passed. A typical example would be [here][0] where I define a layout for the whole website, and then [on each page that uses it](https://github.com/matrix-org/matrix-conf-website/blob/main/...) I have to pass the right properties. Doable by hand, but it's great to have tooling that can yell at me if I forgot to do it.

Content Collections also let me grab content from e.g. markdown or json and build pages automatically from it. The [Content Collections docs][1] are fairly straightforward.

As for performance issues, I've spent quite a bit of time on the countryside where connectivity was an issue and every extra request was definitely noticeable, hence the value of inlining it (you load one html file that has the css embedded, instead of loading an html file that then tells your browser to load an extra css file). The same can be true in some malls where I live.

[0]: https://github.com/matrix-org/matrix-conf-website/blob/main/... [1]: https://docs.astro.build/en/guides/content-collections/

Embedded CSS circumvents proper caching of the CSS. Also, with HTTP/2 your client can download several resources in one transaction. So, it shouldn’t make much of a difference with CSS embedded or separate. Just, that embedded CSS has to be loaded over and over again whereas a separate file can be cached and reused from the local cache.

Caching is only relevant if you think your site is going to be visited by the same person often enough that the cache is worthwhile. If the assets are small that HTTP overhead is non-negligible, and if your CSS would get few enough cache hits, then you're often better off just inlining stuff.

HTTP/2 does not change this equation much. Server Push is dead, and bypasses caching anyway. Early Hints can help if configured correctly, but still require the client to make the request roundtrip to fetch that asset.

> I've never used Astro so forgive my ignorance, but isn't that just creating a .html file, a .css file and then optionally provide a .js file? What does Astro give you in this case? You'd get the same experience with a directory of files + Notepad basically. It's also even more optimized for speed, since there is no overhead/bloat at all, including at dev-time, just pure files, sent over HTTP.

Astro is super for completely static stuff too. Sometimes static stuff can be complex and there a modern framework like Astro shines.

I will share a couple of files to explain.

The site is almost completely static. It serves minimal JS for:

(1) Prefetching (you can block that and nothing will break)

(2) Mobile menu (you cannot make an accessible mobile menu without JS)

The site is for the docs and demos of a JS library. I want many demos on it, to be able to see what patterns the lib can handle and where things break down. I want to be able to add/remove demos quickly to try ideas. Straight HTML written in index.html files would not allow me to do that (but it is fine for the site where I have my CV, so I just use that there).

This is the Astro component I made that makes it super easy for me to try whatever idea I come up with:

https://github.com/demetris/omni-carousel/blob/main/site/com...

Here is one page with demos that use the component:

https://github.com/demetris/omni-carousel/blob/main/site/pag...

Basically, without a setup like this, I would publish the site with 3 or 4 demos, and I would maybe add 1 or 2 more after a few months.

Cheers!

So Astro is basically a (what we used to call) "static site generator" in that case? Something that existed for decades, and is basically just "compiling" templates, which could be in various syntaxes and languages, but in this case it's for JavaScript specifically. I guess the "what's old is new" point continues to stand tall :)

Again I'm failing to see exactly what Astro is "innovating" (as you and others claim they're doing). It's nothing wrong with taking a workflow and making it really stable/solid, or making it really fast, or similar. But for the claim to be "innovative" to be true, they actually have to do something new, or at least put together stuff in a new way :)

I am not saying Astro is innovative and I don’t think I implied that in my reply. I don’t view Astro as innovative and I don’t understand people who view it like that because of, say, its islands. (We knew about islands before Astro.)

As you said, in the example I shared Astro is an SSG. It happens to use server-side JS but this is is irrelevant.

But it is more than that. Astro is an SSG and it is also a *very well made* SSG.

I have used all the usual suspects: Ruby ones, Go ones, Python ones, JS ones. The closest I came to having fun was 11ty, but 11ty is a bit too chaotic for me. Astro is the one that clicked. And the one that was fun to use right from day 1.

I am not a JavaScript person, mind you. JavaScript is not my strongest FE skill. The JS conventions, tricks, and syntaxes of modern FE frameworks, even less so.

So Astro did not click for me because of that. It clicked because of how well it is made and because of how fun it is to use.

Oh! It does this!

Oh! It does that!

Oh! It gives you type safety for your Markdown meta! (What?!)

Oh! It gives you out of the box this optimization I was putting together manually! You just have to say thisOptim: true in the configuration file!

Astro is a very well made tool that improves continually and that aligns with my vision of the platform and of how we should make stuff for the platform.

The best way to do "just html and css with includes" is to run any commonon webserver like nginx and turn on server side includes. It is literally just html and css with includes then. And zero javascript, anywhere, unless you want it.

SSI hasn't changed in 20+ years and it's extremely stable in all webservers. A very tiny attack surface with no maintainence problems. It just does includes of html fragments. The perfect amount of templating power to avoid redundancy but also avoid expoitable backends.

I love Astro so much. After 20 years in data and backend, I got back into frontend for a big project. After banging my head with React, I took a leap of faith and choose Astro with Svelte. That includes an initial try with SvelteKit.

It's worked out so wonderfully. By being HTML/CSS centric, it forces a certain predictable organization with your front end code. I handed the frontend to another developer, with a React background, and because it's so consistently and plainly laid out, the transition happened almost overnight.

My one criticism which is why I ditched it for now is complex routing gets confusing and abstract quickly.

I don't know that there's a serious solution to it because complexity can't come with zero friction but just my gut feeling was to back out and go with something else for now.