Faster web
Hajime Yamasaki Vukelic

Generally it’s always good to explore the frontiers of performance as every performance improvement that can be generalized will help everyone forever.

But I disagree with the author on the angle he looks at frameworks: The main purpose of all those well-known frontend frameworks is not developer experience or getting people started quickly. From my experience Vanilla JS is picked up faster by fresh frontend developers than frameworks like react. Less abstraction, less concepts, less implicit rules — all of that lowers the entry bar and let’s newcomers contribute to a project without making their teammates cry during code reviews.

The real argument for using this catagory of big frameworks is complexity.

In the past years we have started to build web and even mobile applications that are just as complex as the most complex desktop applications — adding the extra salt of usually being part of even more complex distributed systems. Frameworks like react and vue are the only way how we can build those kind of applications at scale, sometimes with dozens of developers working on a codebase that later is bundled in one artifact. And in this context, performance is not an absolute criteria. Performance just needs to be good enough. And good enough means that the user can’t tell a difference. As long as performance is good enough in this sense, handling complexity will always have priority when choosing our weapons of choice as long as this is the hardest problem we need to solve. And that’s the case for the majority of web and mobile projects.

And in this bigger picture often the biggest performance gains come from different sources than rendering optimizations. For example by avoiding unnecessary waiting time during client-server communication in use-cases that allow for an optimistic local state. That’s scenarios where react-redux applications really shine.

This perspective on performance is almost ignored in the article even though it could even be in in favor of its argumentation. At a point it shines through that the discussed approach might also contribute to reducing complexity and this might be worth putting out more and explaining why.

Anyways, I definitely give credit that someone did some proof of concept research for compiler based performance optimization and the results might make its way to a broader audience in one form or another. I’m pretty sure that it’s going to come to us in a different form than presented here though: Only enthusiasts like to adopt yet another half-baked programming language that adds yet another layer of abstraction. Which opens the question: Why is it not possible to achieve the same with an extension to JS (like jsx) or similar?