Creator of the Solid.js framework Ryan Carniato has a question for frontend developers: “Is 0kb of JavaScript in Your Future?” (meaning zero kilobytes).
“We don’t need to have a crystal ball to predict the future,” Carniato, who works on Solid.js at Netlify, told audiences during the third keynote at International JavaScript last month. “If we look at our past and our present, there’s been this ongoing dialogue about reducing the cost of JavaScript, and it exists for a good reason.“
It’s a bit of a hypothetical question since 0kb isn’t really the goal, Carniato acknowledged in the end. The larger takeaway is that the frontend needs to reduce its JavaScript footprint. Carniato offered eight ways the frontend can reduce JavaScript’s weight.
He spent the first portion of the presentation convincing developers of the problem. First, he pointed out the median page weight by content type showing that, after images, JavaScript is the biggest offender.
Page weights by content type show JavaScript’s role in making pages heavy.
“Primarily, it’s well understood how to optimize images, but JavaScript is a bit trickier, and it happens to be one of most expensive assets provided,” he said.
It’s a bigger problem on mobile, where, depending on the device and network, the cost can be “pretty extreme,” he said.
He showed an example where the JavaScript was 170 kilobytes. “The processing time, the time to parse, execute, run that JavaScript code, is almost three and a half seconds on this low-end device, where the image is like 100 milliseconds or something.”
Multi-Core Scores
A gap that hasn’t been shrinking is the difference between high and low-end devices. The low-end market of devices in 2022 is processing, power-wise, similar to an advanced device back in 2014 — so the iPhone 6s is essentially like having a Moto E 30. He saw the impact at eBay since in e-commerce, page loads are critical.
“It’s no secret that there’s a correlation between those load times and the purchase rates,” he said. “The truth of [the] matter is hydration and large JavaScript payloads are part of our architectural responsibility.”
Carniato outlined eight options to reduce the impact of weighty JavaScript code.
Code splitting and lazy loading can significantly help with weight, Carniato said.
“Almost every meta-framework or tool used today almost does this automatically for you at this point at the route level,” he said. “So you should be doing this already.”
One thing to understand about how frameworks hydrate is that anything the server-rendered will need to hydrate as if it was visible on the page, which is why developers show something else and swap it in. It does take some manual doing to make this work, he added, because if something is actually in the surrender DOM and it’s meant to be interactive, it will hydrate.
“Lazy loading doesn’t prevent it. It’s just the way these frameworks work, because they basically need to run the whole app down,” he added.
Carniato took an interesting approach to comparing frameworks. He looked at their size when starting out and then as more components are added to the framework. The results were surprising, in that fast frameworks don’t necessarily stay fast.
JavaScript framework speeds
“Yes, your baseline […] starts smaller, but people actually have to write code,” he said. “So at a certain point, the components make [a] much larger chunk of it.”
Some frameworks start small but as components are added, the frameworks start to approach each other. He used Svelte as an example.
“Svelte starts as the smallest, for example; by the time you get to 80 unique components, it’s actually larger than React and everyone else,” he said. “So most of the frameworks are actually very similar on scale size, and in fact, you can see the top line hopefully, which is at the beginning, which is React — it’s got the same slope.”
Progressive enhancement is based on the idea that the web was built on anchors and forms; so if the JavaScript isn’t present, developers can fall back on what’s already built into the platform, he explained.
“Progressive enhancement has been getting really a lot of push, especially in frameworks like Remix and SvelteKit,” he said. “As long as you author all your interactions as anchors and forms, then they will work without JavaScript. I think it’s a great thing to do.”
However, it’s not necessarily a replacement for other approaches to reducing code, because it creates a very different experience, he said.
“That poor user that I mentioned before, who’s on that phone that takes three and a half seconds to load in the parse — at let’s say seven seconds in total to get interactive — they click the link that’s been visible for them for three seconds at about the six-second mark,” he said. “And guess what? The JavaScript is not there yet.”
So now instead of doing client-side navigation with some affordances, they have to reload the whole page and wait that seven seconds again, he added.
“It’s good, but it’s also not actually a complete win here, it doesn’t replace the problem,” he said.
The idea behind progressive hydration is that the page hydrates on demand, as it’s needed, he said. Developers can attach some event handlers to the document ahead of the time when someone clicks on it and then do smart stuff with that. Sometimes it’s called selective hydration, he added.
Progressive hydration image by Dan Abramov via Ryan Carniato
Dan Abramov drew the above diagram for Carniato that attempts to show what happens if React hadn’t quite hydrated yet and someone clicks on a different branch (maybe not the one that React is currently loading or hydrated yet), then it would be smart enough to bail out of what it was doing and then prioritize that branch of the tree.
“It still had to go parent to child, but you could hydrate the middle instead of going across; and I think for me, nonblocking is very good in the state,” he said. “Sometimes that can also cause the total time to take longer, maybe you’re not going to notice it, but if you have CPU sitting there, chugging in the background, it can impact the experience somewhat.”
Check-in tomorrow for the remaining four ways Carniato said developers can reduce the weight of JavaScript.
