Comment by embedding-shape
2 days ago
> In 2021, Astro was born out of frustration. The trend at the time was that every website should be architected as an application, and then shipped to the user’s browser to render.
Was it? Hot damn, I knew it'll eventually happen, but we truly are just running around in circles. Eventually these same people will do the same loop around, creating new frameworks because the current "server<>client" model suddenly doesn't make any sense anymore, and of course this should be rendered server-side.
Why are we doomed to repeat this, and why does it happen so quickly particularly in web development? We have each other's histories and knowledge right in front of us, what's missing for us to not continue just running around in circles like this?
IMO it's because the web has a huge diversity of behaviors (in a way that, say, native apps do not) but a monoculture on the development side.
React makes sense if you're making Gmail. It doesn't really make sense if you're making a mostly static blog. But because there are more job opportunities in the former (when you consider the wealth of internal web apps out there in the world) all the training courses folks take emphasize React and an app-centric way of thinking about the web.
And perhaps most importantly, it's good enough. It works. Users get by with it. And the developer experience is better than it was in the days of Backbone etc. So few push for change.
> React makes sense if you're making Gmail.
Except the old Gmail used to be so much faster…
Also the old Gmail never used react...
Many technical directions in the past 15 years have been a thinly veiled attempt to actually get paid for doing work.
> Users get by with it.
They would not if they had choice.
And they don't. Web development practices are largely driven by what developers want, not what users want. Which is why Google started doing things like measuring Core Web Vitals and having it affect SEO rankings, to force developers to care.
2 replies →
Whenever you think that everything old is new again and we're just retracing our steps from the past, you risk missing the lessons learned in the meantime.
It gets worse, some teams would get x real estate on a website, and one team would use React, another Vue, another would use Angular because they owned that real estate on your site and that's what the team was best with. Astro lets you still do that, but turns it all into static content. Think of orgs the size of Google or YouTube, there are different teams responsible for what looks like a small thing but different pieces of a giant pie.
> The trend at the time was that every website should be architected as an application, and then shipped to the user’s browser to render.
This is wrong. Some websites are better mostly (mostly) rendered on the client (we call them "apps", like a map application) and some are better mostly rendered on the server (like blogs).
It was and will be.
What is the preffered way to do the opposite now? Not every webapp should be architected as an website.
Vite + React is the go-to recipe.
Yeah, I'm not sure I understand why "islands" isn't just "bits of JavaScript on a static page".
It feels like the "JavaScript as a Server Side Language" folk are just repeatedly re-inventing stuff that has been done a million times by other systems with a different back-end only with a new fancy name.
The key difference between islands and what we used to do back in the day (js on a static page) is that with an islands approach you architect your site with a components-driven approach where everything encapsulates the js/css/html it needs, then you mark it as an "interactive" island if you actually need client-side js to run – the code is the same, but it either runs only in the server (default) or in both server and client.
I know this sounds similar, but, compared to the more traditional approach, there is a certain simplicity to having everything just be javascript. You can often run the same libraries on both server and client depending on your needs, plus it fulfills the promise of web components in a way that is easier to work with (though WCs have also come a long way!)
I will also say encapsulating everything you just said in a single term, "islands," is a lot simpler and prettier to discuss. At least from my perspective, the naming also makes a lot of sense. Literal islands of interactivity surrounded by an ocean of static.
4 replies →
You can do this with just about any programming language or scripting language that can render HTML on the server + plain HTML and JS. You could do this with PHP 30 years ago.
2 replies →
It has been funny seeing the tide come in and out now a few times. Though I will admit that each time, the ergonomics get better. AJAX as a pattern was pretty gnarly if you wanted to do a bit more than update a notification badge or comment box.
There's a really nice pattern of using Custom Elements [0] for that sort of JS interactivity sprinkling. You can make your web application however you want, and when you want the client to run some JS, you just drop in `<my-component x="..." y="...">...</my-component>` with whatever flavour of HTML templating you have available to you. (also possibly with the is= attribute in the future [1], which will let you keep more of the HTML template out of JS)
It saves you the hassle of element targeting and lets you structure that part of your app a bit more without going overboard on "everything is a react component, even the server bits".
Want something "server side generated" in that JS? Just render it in attributes/body/a slot element/a template element, and expect to pick it up in the JS side of things. Feels like how it's supposed to be... and there's no framework required!
[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Custom Elements do start to feel like the dream of the Knockout-era web of "Progressive Enhancement" is finally almost entirely out of the box in the browser. Especially ignoring the Shadow DOM and using Light DOM to style your unpopulated or static rendered fallback states as close to your "live" JS-driven state can lead to some very good experiences, including and especially when JS is disabled (or erroring).
Here's a trivial example: https://supremecommander.ai. A raw CSS implementation of my blog's logo would have been a pain to build and maintain, but with Astro the code is relatively straightforward JS that becomes pure HTML/CSS at build-time.
The other nice thing is that you can throw all kinds of preexisting components from React/whatever into your site, and it will ship zero JS to the client until you explicitly flag a specific JS resource as an "island".
The only special thing about "islands" is that they're an escape hatch from the default behavior of JS being strictly build-time-evaluated. I found the terminology and description a little confusing at first too, because it makes it sound more special than it is. But the concept makes sense when you understand the context of Astro's intentional default behavior.
Your website also reloads itself every 4 seconds for me on mobile Firefox
4 replies →
The have Rust now so the entire tooling layer can justifiably be rewritten a few more times
[flagged]