You might be familiar (or not) with some of my previous posts where I had discussed my fondness at using Snowpack as my build tool. Over the death of several builder analogies, even calling them sherpas at one point! I had tried to explain a bit about Snowpack, how to use it and why you should.
But there is an article that I have been wanting to write for a while, and it all starts with one of the founders of Snowpack, and how it all came about. But the best way to tell this story is to reframe the story into one of rebellion and revolution, one of renascence and recreativity.
Snowpack, brought about a new dawn in web development. However, before the emergence of unbundled development, build tools such as Webpack, Parcel, Rollup to name but a few, were the dominant players in this field. Their idiosyncrasies were widely accepted and begrudgingly adopted. Eventually becoming the de facto industry behemoths of their day.
When it came to utilising them, there was something that was, from this writers point of view, something sorely wrong with this forced marriage type of relationship that was being placed upon the developers.
I always found them to be more obstructionists than anything else; obtrusive and unnecessarily complex from some of the endless unverified documentation that exists around each one. Overall they come across as a tad bit ostentatious, but that's just the opinion of one.
This period in web development's history was one that was ripe for a revolution. Silently crying out from under the weight of the aforementioned build tools for something, simpler, faster and config free.
Step in our main protagonist Fred K. Shott.This enigmatic individual from California, had by all accounts an epiphany that would fundamentally change the way we all would work with the web.
For those who dont know of Fred. Fred's a highly skilled developer who had previously worked as part of the now infamous 'Polymer' Team at Google, who were looking to build on top of Web Components paradigm and introduce yet another Google insipid web framework.
I don't want to talk about Polymer or about our protagonists time there, for I don't have any context to safely discuss this with you. For sake of this narrative, let's assume that there was something early on that inspired him to start his wonderings into Open Source Software.
Now we meet Fred at Pika, where his ambition to make the web faster started to become slightly more than a glint off reality. How he sought to achieve this can be read in more detail here.
Summarizing the article, he speaks of a new(ish) technology that was emerging at the time of 2015 called ESM, or ECMAScript Modules, a standardised way to send more compact, reliable, optimised, smaller and faster payloads of JavaScript to run anywhere on the web.
At a time where most of the 'old' web was built off of a single bundled file, which got really huge and messy very quickly. There was inherent difficulties adopting the newer ESM standards. The Pika mantra was to make modern ESM focused tooling, to make JS more accessible to package authors and application developers at the same time.
Working as as part of a very small team, Fred began working on Skypack. A content delivery network, built to distribute ESM specific node modules and packages throughout the web. With no installation required, package managers nor build tools, just the ability to load and consume optimised NPM packages. Packages that were designed to run not only on Node, but in the browser as well.
Skypack in preceding years has became a rocketing success, having served over 491 Million packages to date. For a first step, our protagonist along with this project was definitely heading in the right direction. But I would like to share with you the following, found on the Skypack's About Page
Here it eludes to their DNA, their raison d'etre:
- Make the web faster for internet users
- Easier to build on for frontend developers of all skill levels
- Everything [...] is either open source (reusable by anyone) or freely hosted for anyone
- Keep the internet open and accessible for everyone.
Such aspirational ideals, when applied can give rise to a space where all sorts of radical and fantastic innovation can arise from. Having someone like Fred as an advocate and practitioner for such ideologies helped power the momentum to drive forward the coming revolution.
Personally, these are principles that I also share, and so it's quite evident why you could consider me a 'fan-boy' but I would push back. Im at heart an anarchist, a rebel, most importantly a Scot. As result of my own predisposition, I am especially supportive those who are similar in vain. Any act of rebellion will always find me a supporter to their lost cause.
Via La Revolution
Let me ask you a question, "What is the difference between a movement and a revolution?"
This kinda question is often kindling for a wider more nuanced debate, for the sake of brevity lets just say that the difference is; A movement naturally runs out of momentum, and come to a rest, where as a Revolution is a complete turn of the wheel.
The initial momentum in Web development came when asynchronous behaviours slowly started becoming part of the Web standard. This addition of non-blocking behaviour opened up a whole new avenue of development and engineering. A whole new approach to deriving solutions.
If we were to frame concurrency within Web development to only this, we would still be in a situation where albeit actions can work in parallel we would of been encumbered by the development experience.
Still oppressed under the weight of the Big Build Tools. The heaviest of all the taxation penalties was that of the Build time, a cost that was becoming increasingly expensive with larger and larger sites and applications.
For there to be a real revolution, there has to be a heightened level of tension within the system, a palpable feeling of frustration, a stifling sense of stress.
Predictably there was also notable displeasure coming from the 'elites' - I use this political term very lightly, in this case I'll be referring to the senior most developers, those in the highest, most vaulted positions, those whom make the larger architectural design decisions, the CTO, COO, CEO's, whichever C you can think off.
Again steps in our protagonist, this time with Snowpack. The plucky ESM build tool that leveraged new and exciting technologies to implement a faster than lightning experience to Web Development.
Enhancing the table stakes for all parties involved. While augmenting the JS Ecosystem with its fresh new approach to un-bundled development.
Snowpack in this sense was like a massive crack appearing on a glacial plate. It was deep and seismic. By creating a chasm where none of the same size and scale had existed before, Snowpack had provided enough momentum to break free from the tyranny of the majority.
And in doing so, the proverbial wheel had turned around. The cycle was complete, there was a new age in web development. The revolution was alas here,
I would be remised if I didn't mention a few of the others that were involved in shaping this new age. Having found out that they had indeed collaborated at times over the early development of Snowpack and in other related projects. Open Source powerhouses such as Rich Hall from SvelteKit and Evan Yue from Vue and Vitejs, along with the SAS-like team that had assembled around Fred; Nate Moore, Matthew Phillips and Drew Powers.....Rebel scum each and every one of them.
The Framework Wars
Running throughout the narrative was this secondary thread to the story of revolution in web development.
This is the hitherto untold story of the the frameworks wars. I will try and make it short.
Frameworks arose around the time when Javascript was starting to become more ubiquitous on the web. Given that in JS there is more than a dozen ways to skin the same cat. There is unsurprisingly, more than a hundred ways to create and generate elements to work with the DOM.
At the start the frequency of new frameworks that would be created was often sparse and sporadic, compared to today's rate of one every second day. This new industry of Developer Frameworks and Tooling, more holistically described as DevX, is vicious.
This very quickly became a big money industry. With Big money comes Bigger expectations, more competition and less co-operation. An effective arms-race between competing ideas and visions began to surface.
The development experience working with these frameworks had all came with the similar structural flaws, very much akin to the big build tools of old, this legacy baggage was being reflected within frameworks, slow development times, setup configurations etc.
The largest most critical flaw came with the closed-garden effect of frameworks. You used only one and never another, you couldn't fluidly choose which UI framework would better suit that particular need. It was only one and never another.
This has lead to large communities, isolated closed gardens became walled cities. Opinionated driven design and development became the norm. Opinions from one framework,was nothing more than a mere altered reflection in another.
Some designed and embroidered their own opinions on top of others, some did it to their own frameworks. Hunkering down, reinforcing their own norms, their own standards, and in effect their own will.
Just like with the Build tools, and the tyranny of masses that had formed from around it, we now had achieved in the ecosystem another form of oppression, the Tyranny of Frameworks.
Its probably hasn't escaped your notice but we have been forced to send vast amounts of moronic data in either; large or small, chucked or bundled, minified and uglified, compressed and encoded, files down the wire.
As with everything in our world, there is a cost to all of this, mostly its never really felt for prolonged periods of time by the developer, but it is always felt by the end user.
And sad truth is, end-users the run of the mill folk who go to your site, don't raise Pull Requests to tell you something was wrong, they just wont come back.... the money, clicks away.
The Space Race
Okay, for I was already unhappy with the prospect of a lifetime of creating websites solely in JavaScript. Building some sham site, using modules and plugins from the ecosystem to just put a site together. Build tools, UI Frameworks, yada yada yada.... it was becoming tedious and very tiresome.
The problem with innovation is that when the practical and theoretical limits are hit, unless the consumer demands shift, innovation would just be idle, only to come back alive when a new idea emerges or a slight-shift to the norm happens or when new tools are created.
In a nutshell that could best describe the Space Race from Cold War to now. As Sputnik was to satellites, so is the Souyez to SpaceX.
Was the ecosystem constantly Innovating? ... a better description would be - " idle awaiting next process tick."
Forgive my cynicism but I profusely believe that you do not need to use NextJS and its ilk, to build your atypical, run of the mill websites, you know those static site where the content doesn't really change much.
If you do feel the urge to, then it's for most probably due to one or two reasons, either it's stockholm syndrome whereby your cognitive reasoning has been so abused by the frameworks and ways of the past, that you are now an unwavering sycophant, or your a masochist.
Either way it's an awfully perverse practice to be as prevalent in the industry as it is, we should be actively avoiding this form of depraved behaviour.
Let's reintroduced our protagonists, and his merry band of rebel developers. Earlier in the year, Fred had posted an announcement that they were working on a brand new project.
Build faster websites with less client-side JavaScript.
If that doesn't get you, let me quote some more from the Astro homepage.
"For a technology built on top of three different languages, the modern web seems to focus an awful lot on JavaScript."[...yup I would say that...]"it’s time to accept that the framework wars won’t have a winner",....really it was a fruitless war of attrition, leaving behind a trail of worn out developers and over-engineered applications.
"That’s why Astro lets you use any framework you want (or none at all)"....🤯
Pardon?
"Use any framework you want, or none at all"
Another seismic shockwave had erupted somewhere. This felt more like something more on the magnitude of a volcano erupting than an earthquake tremor or an aftershock. Since the tweet in April, the ecosystem has slowly been self adjusting to the news of this new space kid on the scene.
The best analogy I can create to describe Astro, is think of each UI Framework, whether it be; React, Preact, Solid, Svelte, Vue etc, each as a sandbox, inside of them you can build out your fabulous sandcastles (App's).
Now In a component driven UI model you would have many components, all of them built within that single sandbox.
Now Imagine your sandbox being on a beach, this beach being a larger sandbox for you to now build in, but on this beach you can jump between any sandbox you like.
So your components can start to take on different roles, each now using a framework that best suits the components needs, instead of the reverse approach where everything is a nail.
This conceptually is a major paradigm shift, closed gardens are now open sandboxes. Developers can play and build in whichever framework they choose, without prostrating to one particular tech-stack.
Liberation for the Nation!
We can now develop in more wonderous and creative ways, Astro literally came in and redrew the boundaries between the frameworks, showing that their is scope to collaborate between two or more competing methods.
This is real liberation, instead of competing ideals, after all dust has settled and the respite between battles gets longer, the focus can now be on collaborating and creating a better internet.
Now Astro is still in Beta, v0.20 at the time of this writing and its well down its roadmap towards a strong v1. This is important to consider when reading the next section.
The Jammies
Roll on October, and its the conference season. This is where a lot of projects are showcased and discussed to us the adoring public. In 2021, the JAMStack conference was definitely one to watch out for.
The keynote speech given by Matt Biilmann from Netlify. Where he best described the ecosystem over the past year. Discussing with other keynote speakers such as Evan Yue, Rich Harris, about the progression of the JAMStack.
It is a very illuminating keynote speech that he gives, but around the 35 minute mark, he begins mentioning Astro, and their unique approach to the whole issue of rendering the content.
This is a separate article, which would seek to discuss the unique take Astro took to provide their Partial Hydration. So unique that it has caused others to take notice. Its very rare to find new projects being mentioned in another's keynote, but when Astro landed, it sent a massive shockwave and a lot of people have noticed.
Consider the others who were involved in this category, 11ty, Cloudcannon, Hugo, & SecondState WASMEdge. CloudCannon and SecondState are two really innovative projects, worth taking a look at. 11ty and Hugo are Astro's direct competitors within this space. Both of them are already well established within the ecosystem, having operated in this space of Static Site Generation for longer, and can easily be assumed to be the dominant players within this field.
So it was beyond surprising and not without merit for Astro to be crowned winners of a very prestigious accolade "Innovators of the Year"...
Astro makes Astronauts
I can say, being a supporter and member of the Astro community on Discord, has been a revelation. Learning and watching the process of this project unfold has been eye-opening.
There is presently a monumental effort being under took to get Astro to v1 status within a expectable timeframe.
And Astro is changing, with the new developers coming into the community and they manner in which this project is ran. Embracing the rebellious spirit of making a free and better internet. Astro is undergoing rapid development, with input coming directly from the community to the developers, and vice versa, the communication between the Core team, and the community is second to none.
There is great ambitions behind Astro, and its safe to say those who have tried it love it. And there is a term for those who come to Astro, we call them 'Astronauts'.
If you want to try Astro you can do simply by going into your terminal and entering:
npm init astro
To read up on Astro and how to use it, you can find out more through their Official documentation. If you have a question or wish to chat to other Astronauts you can find them all on Discord hanging out in the Astro Lounge
Ill leave you with this video from Matthew Philips, who is a legend in his own right, giving those at the JamStack conference a sneak preview of what is too come in v0.21.
See you soon 🖖👩🚀