> Traditional frameworks hydrate entire pages with JavaScript. Even if you've got a simple blog post with one interactive widget, the whole page gets the JavaScript treatment. Astro flips this on its head. Your pages are static HTML by default, and only the bits that need interactivity become JavaScript "islands." Back in my days we called this "progressive enhancements" (or even just "web pages"), and was basically…
Astro is a return to the fundamentals of the web
201–210 of 268 posts
Re: Astro is a return to the fundamentals of the web
#202> Traditional frameworks hydrate entire pages with JavaScript. Even if you've got a simple blog post with one interactive widget, the whole page gets the JavaScript treatment. Astro flips this on its head. Your pages are static HTML by default, and only the bits that need interactivity become JavaScript "islands." Back in my days we called this "progressive enhancements" (or even just "web pages"), and was basically…
You're making the opposite mistake: you're seeing someone's description of a tool's feature and confusing it with the way we've already done things without even checking if the tool is transformative just because it kinda sounds similar. Astro's main value prop is that it integrates with JS frameworks, let's them handle subtrees of the HTML, renders their initial state as a string, and then hydrates them on the clien…
Re: Astro is a return to the fundamentals of the web
#203Earlier quoted context omitted.
"Traditional" always been a measure that depends on when we were born. "Traditional" internet for me is 56kbit modems, vbulletin forums, GTA:VC modding and IRC, while for older people "traditional" internet is probably BBS and such, and for the younger crowd things like Discord is part of the "traditional" internet. You see the same thing in political conservative/traditional circles, where basically things were good…
> You see the same thing in political conservative/traditional circles, where basically things were good when they were young, and things today are bad, but it all differs on when the person was born when things decline that's still an accurate represenation, not just an artifact of subjectivity
People frequently conflate the two.
Re: Astro is a return to the fundamentals of the web
#204Re: Astro is a return to the fundamentals of the web
#205My personal website is written with Astro. I love it! Admittedly I'm still a little trigger-happy with my JS usage, but overall the ability to write templated pages and utilize islands that don't require big dependencies is the most friendly web development experience I've had. https://evklein.com
Re: Astro is a return to the fundamentals of the web
#206> When I say Astro sites are fast, I mean properly fast. We're talking 40% faster load times compared to traditional React frameworks. That's a really low bar. Why not static pages? Why even use a framework at all if you're thinking of using Astro?
Per default, Astro generates static pages. So it makes sense to compare it to an approach that doesn't. Using a framework has upsides over writing static pages manually. Most notably, you can decompose your website into reusable components which makes your implementation more DRY. Also, you can fluently upgrade to a very interaction-heavy website without ever changing tech or architecture. But that's just what I valu…
Re: Astro is a return to the fundamentals of the web
#207> Traditional frameworks hydrate entire pages with JavaScript. Even if you've got a simple blog post with one interactive widget, the whole page gets the JavaScript treatment. Astro flips this on its head. Your pages are static HTML by default, and only the bits that need interactivity become JavaScript "islands." Back in my days we called this "progressive enhancements" (or even just "web pages"), and was basically…
You're making the opposite mistake: you're seeing someone's description of a tool's feature and confusing it with the way we've already done things without even checking if the tool is transformative just because it kinda sounds similar. Astro's main value prop is that it integrates with JS frameworks, let's them handle subtrees of the HTML, renders their initial state as a string, and then hydrates them on the clien…
I think your comment gets at a very specific and subtle nuance that is worth mentioning, namely that typically if you were a proghance purist, you'd have a fallback that did work; a form the submitted normally, a raw table that could be turned into an interactive graph, etc..
I don't think these details are mutually exclusive though, and that it was certainly valid in those days to add something that didn't have a non-js default rendering mode, it's just that it was discouraged from being in the critical path. Early fancy "engineered" webapps like Flipboard got roasted for poorly re-implimenting their core text content on top of canvas so they could reach 60fps scrolling, but if JS didn't work their content wasn't there, and they threw out a bunch of accessibility stuff that you'd otherwise get for free.
Now that I'm thinking back, it's hard to recall situations *at that time* where there would be both something you couldn't do without JavaScript and that couldn't also have a more raw/primitive version, but one example that comes to mind and would still be current are long-form explanations of concepts that can be visualized, such as those that make HN front page periodically. You would not tightly couple the raw text content to the visualization, you would enhance the content with an interactive visual, but not necessarily have fallback for it, and this would still be progressive enhancement.
Here's another good example from that time, which is actually only somewhat forward compatible (doesn't render on my Android), but the explanation still renders https://www.ibiblio.org/e-notes/webgl/gpu/fluid.htm
Re: Astro is a return to the fundamentals of the web
#208Earlier quoted context omitted.
> Astro needs to run on a server that can run node etc It needs to run on your computer to generate the HTML, but you can just run npm run build then copy the contents from the dist folder to your apache server, or whether you want to host it. At least, thats how I do it. I haven't used PHP for about 20 years so I'm sure its changed a lot.
But what you're describing could be done for php, or any other backend language/framework... There's nothing unique to Astro in this regard.
Do you know how you can do this in spring? Let's say I used Thymeleaf, is there a maven target I can use to walk over a database and generate every iteration of a html website?
Re: Astro is a return to the fundamentals of the web
#209Earlier quoted context omitted.
Why do you prefer datastar vs htmx? Afaik htmx tends to allow progressive enhancement without JS, while datastar requires JS to work.
Htmx IS JavaScript... Datastar does everything htmx does and much more. And, iirc, is also smaller. Just explore their site, docs, essays etc
Re: Astro is a return to the fundamentals of the web
#210Earlier quoted context omitted.
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. Doa…
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.
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.