Over the past two decades or so, the front-end ecosystem has changed drastically. We’ve seen the rise and (relative) fall of giants such as jQuery, Angular, and React which have elevated webpages from simple, static sites to massive, robust applications. Due to the high pace at which new developments are coming to light, existing frameworks are being forced to continue to innovate at record pace.
At this point, unless you have a specific use case for non-standard functionality, you can’t really go wrong in your choice in one of the major front-end frameworks. The feature set and tooling offered is similar enough that it mostly comes down to what your team knows, or personal preference. Things weren’t always like this however, let’s take a trip down memory lane.
The creation of JavaScript
I won’t get into specifics here, but just know that JavaScript was initially released towards the tail end of 1995 with the intention of bringing interactivity to the web. Its’ adoption was quick, and by the early 2000’s as Internet Explorer’s market share reached 95%, it was the de facto standard for client-side scripting on the web.
Enough about plain, boring (colloquially known as “vanilla” JavaScript). We’re here to learn more about modern front-end! And the first big step towards that came with the release of jQuery in 2006. A library that attempts to fix many of the often repetitive pain points surrounding updating the DOM.
As a quick example, let’s create a quick counter which can be incremented by a button. See below the difference in code between vanilla JavaScript and jQuery.
As we can see above, jQuery offers a layer of abstraction which makes it much less verbose to update the counter. Compared to modern frameworks however, there’s still a distinct disconnect between the ‘state‘ (the number that the counter is incrementing) and the ‘view‘ (that same number being shown. In our small counter example above it’s still perfectly manageable, but as you can imagine, this’ll become nightmarish to maintain for large applications.
The next major steps towards modernity
When React released in 2013, and other frameworks such as Angular in 2016, we saw a cumulative shift towards the single concept that essentially all of modern UI frameworks are built around: reactivity. Differing implementations aside, this simply means that you no longer have to worry about updating your view. You simply manipulate the state (your counter variable) and the UI is magically updated by your framework of choice.
The view and state here are part of a component; A reusable piece of code which encapsulates a view and state, and thus ensures a clear connection. When the value changes, the UI and the components dependents (other components or state relying on the value) are updated.
Let’s quickly take a look at our counter example from above in React (very aptly named), which is currently the most popular UI framework (or technically, a library) for new projects.
In this example, the connection is much clearer. We simply create a variable ‘counter‘ and pass it into the view. Instead of having to manipulate HTML ourselves, the component manages its own state. Developers are relieved of yet another repetitive task and simply have to think about updating the state.
One small downside is that developers have to learn a new ‘dialect’ for each front-end framework. While it’s all using JavaScript under the hood and the functionality and concepts are virtually the same, the syntax can differ quite drastically between for example React, Angular and Svelte.
To drive home this example, let’s also look at how this counter would look in Svelte (version 4.)
Svelte takes the abstraction a step further while, ironically, looking the most look similar to vanilla JavaScript. This provides the least amount of overhead (and one could argue, the best developer experience), but it does add a bit of “magic”. It’s not immediately clear that the counter variable is reactive. To address this, Svelte 5 is adding something called runes, with which you’ll have to wrap the 0 to make it a reactive value, rather than a static one.
What about the future?
Who knows, really? Personally I think we’re headed for an era where the current most popular tech stack will obtain near monopoly status. That being: React, Nextjs & shadcn/ui. The reason I think this is because GenAI for UI (GenUI?) like StackBlitz’ Bolt and Vercels v0 are reinforcing themselves.
Both of these tools allow developers to build and ship much, much more quickly. Due to the availability of tooling in this tech stack, more project will use them, and due to more projects using them it’ll be trained on these new projects and become even more prevalent. Like an infinite loop somewhat.
