3 ms·

> - 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 nev

by diggan 1y ago

> - 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).

thibaultamartin 1y ago
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/src/pages/index.astro#L21-L24 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/src/layouts/BaseLayout.astro#L7-L11BaseLayout.astro#L95 https://github.com/matrix-org/matrix-conf-website/blob/main/... [1]: https://docs.astro.build/en/guides/content-collections/ https://docs.astro.build/en/guides/content-collections/
- mbirth 1y ago
  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.
  - MrJohz 1y ago
    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.
demetris 1y ago
> 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/components/carousel/Carousel.astro 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/pages/demos/no-js.astro 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!
- diggan 1y ago
  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 :)
  - 1y ago

by diggan 1y ago

thibaultamartin 1y ago

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/src/pages/index.astro#L21-L24 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/src/layouts/BaseLayout.astro#L7-L11BaseLayout.astro#L95 https://github.com/matrix-org/matrix-conf-website/blob/main/... [1]: https://docs.astro.build/en/guides/content-collections/ https://docs.astro.build/en/guides/content-collections/

mbirth 1y ago
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.
- MrJohz 1y ago
  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.

demetris 1y ago

> 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/components/carousel/Carousel.astro 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/pages/demos/no-js.astro 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!

diggan 1y ago
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 :)
- 1y ago