Story of an honest web developer: We use too much JavaScript and that can negatively affect users
Today’s web technologies use large amounts of JavaScript. But has it gone too far? Stefan Judis, a German developer who gave a presentation on the subject at the recent GOTO Copenhagen conference, believes so.
His point is that heavy frameworks with large amounts of JavaScript do not provide a better user experience—on the contrary. They simply provide pages that take longer to load in the browser, which is penalized by both users and Google’s search algorithm.
Back in 2014, Stefan Judis and his colleagues wanted to get with the times, he tells the audience, and that led to them finding the web framework Jekyll. Soon after came the first version of the popular library Angular.
Stefan Judis loves web technology and writing JavaScript. He opened his own business, and was going to make his own blog. He wanted fancy transitions between pages.
“I don’t want to tell you how much time I spent on it,” says Stefan Judis addressing the audience in the hall.
He used a new cutting-edge JavaScript framework. He made many tweaks, and tested the result with Google’s performance tool Lighthouse. He got a score of 90, which usually means being among the top five percent of best-performing websites. Even on a 3G phone, the page rendered in four and a half seconds.
“Honestly, I was proud,” says Stefan Judis.
Ugly website claims the top spot
Stefan Judis had split the code up into chunks that only loaded when needed. But then he compared his website to a website mentioned on developer forums—a personal website that is still updated on a monthly basis, but is using technology (and aesthetics) from the 90s.
It does not look pretty, but that is not Stefan Judis’s point either. The website is incredibly fast. And the code behind it is not something that takes a weekend to maintain. It uses technology that professional developers no longer really use, such as HTML table-based layouts.
Stefan Judis analysed the page with Lighthouse, and compared it with his new and old blog.
Both the Italian website and Stefan Judis’s old blog beat his new advanced JavaScript app with Lighthouse grades of 100 and 97, respectively. In other words, seven and ten points better than the modern app version of the blog.
“It was pretty depressing.”
Why is it so easy to make a mistake
Maybe it comes down to the developer’s competencies:
“Stefan, you messed up!”
That may be true, says Stefan Judis—but asks the audience: Why is it so easy to make a mistake?
His smart JavaScript blog takes up 940 kilobytes, while the Italian website only needs 284. The latter uses two JavaScript resources totalling 6 kilobytes, while Stefan Judis’s blog has 22 scripts comprising 512 kilobytes.
When Google’s search algorithm ranks search results, it looks at, among other things, loading times—a significant factor in many contexts.
Lighthouse weighs a number of factors when calculating its score. And 40 percent of it comes down to JavaScript, which must be downloaded, parsed, and executed before the interface is ready for use, even if you prerender some of the content.
As an example, he shows Netflix’s introductory subscription page, which is focused on getting the potential customers on board as quickly as possible. It uses very few resources and very little JavaScript. An important point is that a 150 kilobyte JavaScript download cannot be compared to an image of the same size when it comes to performance.
Unnecessary JavaScript is bad for the user
He tried a new strategy. For another website, he used a tool for generating static sites, Eleventy, which does not add anything one does not need.
This resulted in a Lighthouse score of 100.
Therefore, it is time to put an end to the idea that “all websites are web apps, and vice versa”. Stefan Judis himself thought so a few years ago, but today, he completely disagrees with that statement.
Is a lot of unnecessary JavaScript the best for the user? He is no longer so sure.
He also points out that mobile data can be expensive in some countries, and heavier pages simply mean more costs for users, without them necessarily getting a better experience—quite the contrary.
Stefan Judis also points out that React, Vue and other frameworks are currently trendy. Measurements show that jQuery is still the most dominant framework, and there is nothing wrong with that.
“Boring is beautiful,” he says.
Accessibility is also problematic with JavaScript frameworks which, for example, create navigation dynamically.
The bottom line is that we are just using too much JavaScript.
JavaScript should be used as an extension
Two new frameworks, Astro and Svelte go against that trend.
“Perhaps JavaScript should not be the starting point for the developer, but should be thought of as an extension.”
A good website is accessible, fast, and secure. Frameworks do not necessarily eliminate errors. For example, React-based sites have about 50 errors on average, according to the Webaim.org service.
Writing complex apps has never been easier than today. But how many websites are really complex apps—asks Stefan Judis.
Some argue that the use of frameworks and libraries means that one does not have to maintain the code. You just download the latest version, and security issues get resolved and coding standards are updated in a snap. But when Version2 later asked Stefan Judis about libraries, he said he does not buy that. One just moves the burden of maintenance to the libraries:
“You spend a day or two figuring out: What do we need to update? What is it that breaks the app? The more complexity you add to your website, the harder it becomes to maintain.”
However, Stefan Judis does not believe that the same applies to web apps:
“My point was that we use a lot of things in the wrong usage scenarios. Large and heavy web apps like Gmail are great—they have a lot of functionality. What I am criticizing is that if you e.g. visit Medium.com and load five megabytes to track the user, and make other wrong technology choices—then we’re heading in the wrong direction.”
The problem can be solved by server-side rendering, but none of the frameworks have fully achieved that yet.
“Right now, React is not ready for that. If you render React on the server side today, you have two choices: either you do not load JavaScript in the browser at all, which means you have no interactivity. Or you load everything, including static files.”
But help is on the way:
“This is what the React team is looking at now, and what they call ‘server components’. The goal is for frameworks to be able to put things into the front-end JavaScript bundle, which is intended for interaction only. You don’t need JavaScript for static navigation—why should you? From the perspective of React, however, we are not quite there yet. The first bid on this was issued a few weeks ago, but it is very cutting-edge technology,” concludes Stefan Judis.
