Do we still need Frontend Web Frameworks? 🤔
If HTML, CSS, JS and the underlying web runtimes are getting more powerful, do we still need to depend on frameworks like React, Vue, Angular, and more?
Hello there!
Our web sites and apps have a come long way from their humble beginnings to be the glitzy and interactivity filled experiences we all love:
Critical to making apps like this work is the rise of frontend web frameworks. These web frameworks reduce the time it takes for us to build great app experiences, and they do so by taking care of the many small and big HTML, CSS, and JavaScript activities that can be quite time consuming. To dive deeper into all of this, Joel Ramos and I start with React and take a broader look at the history and where things with web frameworks are headed:
Now, I want to take expand a bit on the future where things are headed part. Looking ahead, are the same reasons that led to us needing web frameworks in the past still relevant in the future?
Do we still need to use web frameworks?
React was released almost 10 years ago in 2013. Vue followed shortly afterward in 2014. AngularJS was first previewed in 2009, and its successor Angular was released in 2016. If you can even recall what was going on back then, the world of web development was quite different! 🦕
The things about web development that we take for granted today did not exist back then. The web runtimes and the HTML/CSS/JavaScript languages were severely lacking in capabilities and performance. Everybody and their pets used jQuery. Internet Explorer and Flash were still big things. Visual Studio Code was still years away. The rich ecosystem of Node modules, build packs, and bundlers was just starting to gain traction.
This is where web frameworks really shone: they made up for critical shortcomings in the end-to-end web app development experience and capabilities:
React was all about improving UI performance. Vue introduced a lightweight templating mechanism. Angular made it easier for us to efficiently work with data. All of these frameworks simplified the complexity (in their unique way) of taking all of their app code and building a deployable app:
Now, here is where things get interesting. Over the past ten (yes, 10!) years, when we slice and dice each unique improvement the frameworks introduced or enhanced, the underlying web runtimes have natively implemented almost all of these improvements with each new JavaScript (EcmaScript) release and CSS spec revision. Even big gotchas like performance have significantly improved across the board:
Some of the foundational gaps web frameworks had to close were no longer as valid in 2022 as they were in the 2010s. In some ways, web frameworks went from being a net-positive addition to our development experience to a more net-negative one.
To expand on that a bit, a web framework isn’t a lightweight addition to your typical web app. They add hundreds of kilobytes of extra JavaScript that needs to be downloaded. All of this downloaded JavaScript needs to be loaded into memory and processed each time our web app/site is loaded. Let’s take a simple Todo List app:
This app is less than 2kb when built using vanilla HTML, CSS, and JavaScript. This same app created in React requires about 300kb (🛢️!!!) of JavaScript and all the downsides in download and processing time that comes with it. As web frameworks are used for more complicated scenarios, the added baggage they bring often hurts more than it helps.
Where does this leave us?
So, here we are. Web frameworks were designed for a time when the world desperately needed them. Today, the world has gotten better. It is possible to build a really powerful, performant, and maintainable app without using any web frameworks at all. One example of such an app is Visual Studio Code, which is a web-based app built without using any frontend web framework at all:
What is our action item here? Two paths stand out:
If you are building a new app today, really take a strong look at whether you need to use a web framework or whether you can build using HTML, CSS, and JavaScript directly.
If you are working on an existing app that has years of legacy framework code already present, look into optimizing your framework code to ensure you are delivering something to your users that is both performant and accessible.
When using a web framework, you may think that the code you write is following all the best practices by default. Spoiler alert: It isn’t! 🔥
Now, you heard from me on where I stand. I do want to hear from you though. Please vote on my highly scientific Twitter poll and/or post your thoughts in this forum thread to discuss this with me directly.
Till next time!
Cheers,
Kirupa 😀
For any reasonably sized/complex data-driven application (which most UIs are) you're definitely better off using a front-end framework. Sure you can use web components (if you're okay sacrificing FP style code over OOP and classes - I'm not!), or even go vanilla - however, unless it's for a simple TODO app (or hardcore learning purposes), what usually happens is that you start pulling in more and more dependencies, to the point where you kind of end up reinventing the wheel and building your own framework which basically does most of what React etc is doing anyways (but probably not as good). React now, is not the same as back when it launched - if anyone, the React team been at the forefront when it comes to setting new standards for modern webdev and their roadmap continues to impress. Please also take into account that over time, internet coverage has improved a lot, connections has gotten significantly faster, computers are faster too. Long story short, yes there are indeed many many very good reasons to pick a modern frontend-framework today - especially for UI development. They're not making them for fun ;-)
Over the last 20 years, I've worked w. a variety of tech stacks, including RoR, PHP, Flash & Flex, Python and Django, Angular JS, React, etc.
Now that techs like AlpineJS and HTMX are available, it makes less and less sense to use things like React or Vue. We can leverage fewer techs, reduce stack/build complexity and still target about 85% of the UI use-cases out there. Obviously for something like Google Maps, or a much more rich, media-driven experience, it makes sense to use a robust UI framework, but for the standard text & image driven website w. basic forms, why incur the overhead of a SPA framework?