Search for a command to run...
Writing about frontend development and other things that sparkle my interest
No comments yet. Be the first to comment.
Why I think that WebAssembly will rise, ignite SSR and tooling (r)evolution, but something will remain the same.
tl;dr:
There will be even more server-side rendering and frontend tools written in other (fast) languages.
WebAssembly will be the next hot thing. It's too cool not to be.
Something will remain the same, so React, Angular and Node.js will continue mostly as they're today.
Some reflections on the last five years.
Around five years ago I posted a silly joke on LinkedIn: "Five years later: angular 15, react 25, babel 17, webpack 20."
It was a time of innovative tools, a hunger to explore the latest trends, and a frontend hype train eagerly embracing the latest advancements. Turns out, I was right only on one point, Angular, and missed all the others. Still, it was fun to find this note five years later and think about what changed since 2018. I'm posting this note to share how I see the near future, and I also hope to amuse myself another 5 years later. And maybe some readers will be amused right now 😄
Curiously, at the beginning of the 2010s, the majority of web applications were server-side rendered with occasional interactive JS add-ons.
And now again, we will see even more server-side rendering! This time it's different, though. We went a long way, browsers offer much better APIs, and we have WASM.
Back in the day, the Ember framework pioneered the idea of CLI that accompanies the frontend framework and helps with bootstrapping, and managing the app components and upgrades. Angular adopted the idea as well and successfully uses it today. Following Create React App, other React-based frameworks offer the same idea.
Given the popularity of Go and the raising popularity of Deno, it looks like we will see more full-fledged solutions that offer you everything: compiler, dependency management, linter, code formatter, language server and so on.
that's what our future looks like, even though it might use some font (and perhaps color) improvements 🧐
During the next 5 years, we might see a rise of WebAssembly. Today, it still has to rely on JS bindings to update the DOM elements. WASM develops fast, and we can see a way to directly update DOM from WASM. Everybody will suddenly discover that they can create full-stack web applications in their language of choice – and all of that will be directly compiled to WASM.
Perhaps it will start another gold rush of front-end or full-stack frameworks. And then we will have an entirely new generation of web developers who are complaining about framework fatigue!
Jokes aside, I see the potential improvements in WASM as a very positive thing. WASI (WebAssembly System Interface) can help on servers, on edge devices and even in blockchains (whaaat?.. well, they also need a compile target for smart contracts and stuff). That's a portable byte code that one day might even eat Docker's lunch and partially replace it. But perhaps 5 years won't be enough for such a futuristic vision.
Plugins for the existing software might become a common practice. Here, let's quickly step back a little. JavaScript's original goal was to modify or extend the behavior of browsers when they open web pages. WASM can do the same for the existing software. And WASM can probably do the same for the existing software if developers integrate support for extensions.
Some quick speculations on this technology in general:
WASM will get direct integration with DOM. Or at least it will be streamlined. WASM will also get direct access to the browser's APIs.
It will lead to a boom of frontend frameworks written in other languages. It's already started, but I'm convinced that the absence of direct DOM integration/APIs is a limiting factor for them.
We will see entirely new languages that compile to WASM. They will attempt to invent a straightforward syntax to operate on the front end. Inspired by Svelte and JSX.
One of the interesting properties of such languages will be feature completeness. Just like Go or Deno, they will offer the entire toolchain to develop and ship the software. In some cases, it will also include hosting/deployment. I hope to see more players like Vercel and Netlify.
Did you ever wish that something simply remains in this crazy world? Well, there is Angular and Node.js!
Even though React cemented itself as the standard, there is still a niche for other approaches, like a more traditional Angular. I will make the most boring prediction: Angular will still be alive in 5 years, and it will still follow the same release cycle. And it will still be relatively popular. So I kinda exercise the naïve weather forecast, "tomorrow the weather will be the same as today". It's often not that far off!
And I think it's even easier to make such a prediction for Node.js. A foundation develops it and given its huge impact on the entire frontend development, I assume that everything will remain the same.
Did it even worth a prediction? Well, I want to hit at least one of them right. I also want to remember a simple idea. There will be new trends, but something will likely remain the same. And yes, of course, React and its hooks will still be with us in 2028, definitely no need to worry here.
it sounds like a lot of time when you put it this way!
Let's play some archaeology and revisit some news from the past. In the frontend community, Angular wasn't the first to adopt a strict release schedule. After IO.js rejoined with Node.js in 2015, the Node.js team committed to following the release schedule and shipping a major release every 6 months. It helped to avoid stagnation, which was the main reason behind the IO.js fork in the first place. Great decision! Because Node.js regained its momentum and continued to be a backbone for most of the frontend innovations.
Well, we don't have version 25, but look at how many things changed in the last 5 years! We had version 16.1 back in the day, and we're sitting on 18.2 now, which was released in June 2022.
Main changes in the last 5 years:
Finalized Context API (at last!)
Function components are mainstream now thanks to hooks. In their turn, function components helped to achieve much better integration with Typescript. Oh, it was such a pain to write class components with Typescript 🤕
We are relieved now!
Gradually shifting focus to server-side rendering.
As it seems to me, React reached its productivity plateau. We still might see more new stuff like signals and perhaps beyond that too. But I personally hope that the React team will stop with the current feature set. I don't want to see any groundbreaking shifts in the core of React again, and I'd rather accept it as-is with all its strengths and weaknesses.
almost a mandatory photo of a code editor from an oblique angle. still looks cool!
In fact, there was only one major release for Babel and two major versions for Webpack. Retrospectively, it makes a lot of sense. With the rise (and fall) of Create React App and other ways to bootstrap applications, the focus of app developers finally shifted away from building tools. Yes, it's still a fascinating and crucial piece of software, but the underlying machinery should be just an abstraction layer for the app developers.
Tools like Vite and Parcel can replace Webpack when we need a somewhat custom build process, but without too many degrees of freedom. It's costly to do the precision control of the build process.
Tools like Esbuild and SWC offer faster ways to compile the code thanks to their implementation languages (Go and Rust respectively).
There is also Turbopack which is inspired by everything else! I can only welcome the new generation of build instruments that don't compromise performance.
Yeap, it's here! Just as the Angular team promised us back in 2016 with the long-awaited release of Angular 2. In fact, the only reason why I got this one right is that the Angular team committed to releasing a major version twice per year. They still follow this rule. Which is great! Sometimes they delay a major release by a month or two, but otherwise, there weren't any significant interruptions in the flow. The predictable release schedule helps to plan development and migrations and also brings confidence that there won't be hard pieces. 6 months isn't enough to build something entirely groundbreaking, but it's still enough to make gradual improvements and deprecate some old patterns. The Angular CLI makes most of the breaking changes easy to manage: you simply run the command, and it automatically replaces old code with the new one or at least gives you a bit of advice on how to update things manually. And I really like the progress of Angular. Since 2018, the team introduced many great features and delivered a very stable framework. Despite many other (very cool) tools being released, Angular remains a solid choice for classic SPA apps.
If you are interested in Angular, please feel free to check out my other article: Clean Architecture in Frontend.
