JavaScript Frontend Speed is the Next Big Thing
The two paths of reengineering frontend solutions for speed.
Faster and lighter web experiences are the next big things and teams of developers are reengineering their solutions to make them faster not only because speed metrics are being taken into consideration by search engines but because of the value of time for customers. Time is money is an adage that every one of us knows well and for the context of web development, more time for building and loading a web application is money spent by the web application owner and the customers.
Most of the optimization rooms are on the user side, the browser, where manipulating the DOM and rendering it faster has become a top-level priority that puts frontend engineering teams on a challenging time after they have built and chipped amazing user interface.
A large part of the slowness of web applications comes now from the loading of web pages due to the ever-growing number of third-party JavaScript externals scripts that make the UI interactive and easy to develop and that the browsers have to load and compile and execute. With minified, bundlers, code splitters, etc. we have significantly reduced the loading time of JavaScript and its execution by the browser but there are remaining rooms for improvement, and reimagining the design and architecture of frontend frameworks is one of these rooms.
Aware of this important need for improvement of loading speed, javascript frontend frameworks builders have retaken their source code and worked on it to make their solution faster and new frontend frameworks are specifically built around this promise. If we take the example of React, the team behind this framework has come with a faster and lighter version of this framework called Preact purposefully built for speed and competing solutions like Svelte have positioned themselves to compete with this optimized version of React. Then the solution for faster web applications and experiences is a two-way path, improving the already adopted frontend framework (Preact) or adopting a new one (Svelte or another one like Inferno or one that I don't know).
I am aware that many frontend engineers like you are aware of this situation and what is required to be done and many of you are exploring ways to optimize web applications for reducing loading time. For example, people like Nilanth have been rebuilding their whole applications using new declared faster js frontend frameworks like Preact and benchmarking them with the old ones that they were using and if you read the benchmark reporting of Nilanth here in Javascript in plain English you will see that the difference is important at least in my point of view and this difference is way more important than this difference that I was trying to highlight with my poor benchmarking article about React, Vue about core vitals metrics.
As a final thought, I would say that developer productivity and user experience efficiency are two competing strengths that we should use to judge frameworks. Some make the developer more productive but how about the result in terms of user experience. Some are difficult to implement and less productive but maybe they are more efficient in terms of user experience.
Let’s recall that my opinion is that the user experience has more weight and priority than the productivity of the software engineering team or the alone software engineer like me. But my product management and design skill instinctively spoke cognitively out loud to tell me why I have not said product manager and designer instead of software engineer because what I am going about with you with these words is also about the design and management of a tech product that deals with web applications development productivity and performance testing and benchmarking for not only tech decision making but also for shipping better experience to end-users.
Tech people ground their decisions on science, knowledge, data, and tech then why just decide to choose a framework without having clear performance and user experience data and why not use all the available framework to build our solutions and ship to each user the one that is most efficient given the user’s environment.
PS: Happy new year to all Javascript in plain English readers and to everyone who cares. I wish that 2020 will be better than this troubling year that we left behind. I wish and hope that this year will be for you a year of fulfillment, joy, happiness, and success in your personal and professional life. HAPPY NEW YEAR.
More content at plainenglish.io. Sign up for our free weekly newsletter. Get exclusive access to writing opportunities and advice in our community Discord.
