What is the value in first sending dysfunctional HTML and then fixing it with later executed JS? If you do that, you might as well do 100% JS. Probably would simplify things in the framework.

Sending functional HTML, and then only doing dynamic things dynamically, that's where the value is for web _apps_. So if what you point out is the value proposition for Astro, then I am not getting it, and don't see its value.

Dysfunctional HTML in the sense that interactivity is disabled, but visually it is rendered and therefore you can see the proper webpage immediately.

Just compare the two cases, assuming 100ms for the initial HTML loading and 200ms for JS loading and processing.

With full JS, you don't see anything for 300ms, the form does not exists (300ms is a noticeable delay for the human eye).

With frameworks such as Astro, after 100ms you already see the form. By the time you move the mouse and/or start interacting with it, the JS will probably be ready (because 200ms is almost instant in the context of starting an interaction).

This is not new at all, old school server side processing always did this. The advantage is writing the component only once, in one framework (React/vue/whatev). The server-client passage is transparent for the developer, and that wasn't the case at all in old school frameworks.

Note that I'm not seeing this is good! but this is the value proposition of Astro and similar frameworks: transparent server-client context switching, with better performance perceived by the user.

Usually I write my HTML and CSS also in a way that I write it once and can then reuse it elsewhere. I do that by employing traditional template engines like Jinja2 (in Python) or using SXML in Lisps.

You don't have any complex interactivity than, and therefore this solutions does not apply to your use cases

> you're chomping at the bit to be cynical instead of curious.

Nicely sums up a lot of interactions these days

>e.g. The <form> probably doesn't work at all without the JS that takes it over.

What a value!

I guess I may be chomping at the bit to be cynical, but I have quite a bit of experience in these fields, and I don't think Astro sounds especially transformative.

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

I'm sorry to go off-topic, but since when hydrating web pages with JavaScript became a thing? First time I've heard the term.

Edit: according to WP history, around December 2020

https://en.wikipedia.org/w/index.php?title=Hydration_(web_de...

Second edit: "Streaming server rendering", "Progressive rehydration", "Partial rehydration", "Trisomorphic rendering"... Seems I woke up in a different universe today.

the concept is not new in an sense (duh), I mean, send HTML first send the important CSS first so the browser can show something - and with the correct dimensions hopefully to avoid reflows (and flash of white and so on), and therefore JS interaction "always" got enabled on some kind of trigger (onload, DOMContentLoaded, or simply it the script tag was added after the closing body tag, which as far as I know led to all of the event handlers registering by the time the DOM tree was there)

then chunking was the next step, and basically then logical endpoint is this mix-and-match strategy that NextJS is "leading" (?), by allowing things to be streamed in while sending and caching as much of the static parts up front as possible.

Its definitely older. I remember hearing about it around a job I had in 2017-2020, but it was already an established term by that time.

Quote:

2013-2015: The concept of SSR in JavaScript frameworks emerged with React (released in 2013). Initially, it was referred to as "reconciliation" or "bootstrapping" — React would match the DOM with the virtual DOM.

2015: Around the release of React 0.14 and React 15 (2016), the term "hydration" began appearing in the React ecosystem to describe the process of attaching event listeners to server-rendered markup.

    The first known mention in React documentation and community discussions around 2015-2016 clarified that React would "hydrate" the HTML.

    This distinguished it from full re-rendering, which would discard the server-rendered DOM.

Oh no, go read about AJAX. You may be too young, there's no revolution here. I celebrate your curiosity, it's still a wheel. Changing the name it's still reinventing it.