Why am I so excited about Astro?
In a field that tends toward absolutes, I’ve really loved that Astro has identified a specific set of use cases, embraced that there’s no one-size-fits-all approach to building for the web, and given us smart defaults to start with, plus full control of how far we can choose to go with our apps.
And no matter which approach you choose, you get to keep the modern, component-based workflow that makes the developer experience so pleasant in all our favorite frameworks.
There is a big push right now to recenter on simplicity.
More and more people seem to be questioning why we’re spending so much time on complex solutions to problems that most of don’t have, and I’m extremely here for it.
Web standards have made massive leaps forward since the last wave of JS frameworks rose to popularity. Many things that made something like React necessary in the first place have been implemented natively, and if you keep an eye on the spec discussions, it’s pretty clear that these working groups have no intention of slowing down.
The web is ready to evolve to its next, simpler iteration.
We moved to tools like React because they simplified the mental model of building web apps.
The cost of success is complexity: more use cases, more edge cases, backward compatibility, a Cambrian explosion of ecosystem tools, and devs using these frameworks to do things they were never intended for.
All of this has led to commentary like Andrew Clark saying, “If you use React, you should be using a meta-framework.” This makes me wonder if we’ve reached the apex of React’s dominance (and maybe the all-in JS framework approach?), and the coming years will see a new approach move in as the “default modern approach” to building for the web.
If you use React, you should be using a React framework. If your existing app doesn’t use a framework, you should incrementally migrate to one. If you’re creating a new React project, you should use a framework from the beginning.
— Andrew Clark (@acdlite)
January 23, 2023
We’ve started applying some very high-complexity app approaches to very low-complexity websites.
When I’m lucky enough to get into a deeper conversation about how we build for the web with people who have been doing it for a long time, one of the more common pain points we talk about is how easy it is to go overboard with our projects “just in case” (or worse, “because it’s fun”).
React was built to power Facebook, arguably the most complex app on the internet at the time.
It excels at building highly complex applications. And if we find ourselves building one of those, we should absolutely choose the right tool for the job. But if we’re *not***** building something monstrously complex, well… we should still choose the right tool for the job, which might just be shipping only HTML and CSS.
There are no “sides” in building for the web.
This all brings me back to why I think what Astro is doing is so smart.
They’re telling us to rely on the platform as a default, then giving us a clear, flexible API to add any frameworks and abstractions we need on top of it as part of the Astro authoring experience.
They’re giving us a bridge where other frameworks appear to draw lines in the sand.
The guidance is, effectively: “We can’t stop you from using JS, but we won’t help you either.”
Both sides have strong arguments for why their approach is correct (and, in many cases, it starts to sound like there’s an argument for which side is more “morally correct” which worries me quite a bit). Depending on the project, where I land in the argument will change.
What if the “JS vs. no-JS” argument didn’t have to exist?
Astro takes a completely different approach. “There’s nothing to argue about,” they seem to be saying. “If you don’t need JS, don’t ship it. (We’ll help.) And if you need JS, use whatever you need. (We’ll help with that, too.)”
In many ways, we get to have our cake and eat it, too.
Rather than accepting the false premise that everyone needs to “choose a side” in the JS wars, Astro just… builds websites. And I love that.