Live data from Hacker News

Astro is a return to the fundamentals of the web

websmith.studio

201–210 of 268 posts

Re: Astro is a return to the fundamentals of the web

#201
post #10

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

The headline is literally “returns to the fundamentals of the web” so that’s the point.

Re: Astro is a return to the fundamentals of the web

#202
post #10

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

[deleted]

Re: Astro is a return to the fundamentals of the web

#203
post #16

Earlier 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

The problem is that overall decline is generally subjective while personal decline is objective (we all grow old and sick and ultimately die).

People frequently conflate the two.

Re: Astro is a return to the fundamentals of the web

#205

My 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

Your website isn't loading for me.

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…

What about static site generators, in that case?

Re: Astro is a return to the fundamentals of the web

#207
post #10

> 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 didn't read their comment as particularly cynical, and at a high level they're still correct, but so are you.

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

#208
post #186

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

I'm not a frontend developer so I'm ignorant about this stuff so that's the first I've heard of it.

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

#209
post #139
post #133

Earlier 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

Oh okay. While Htmx-the-lib is JS, the standard practice is to make the site progressively enhanced by Htmx such that it still works without JS and improves accessibility for screen readers. While this could be possible with Datastar, I've read that it's generally more work to enable progressive enhancement, but maybe that's not a goal.

Re: Astro is a return to the fundamentals of the web

#210
post #90

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

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.

Post reply on HN