Sometimes, we need to sit down and appreciate how much the web platform has evolved.
From a clunky start as static documents with many quirks, to today, a feature-rich platform for heavy apps that rivals native platforms with its efficiency, ease of use, and unmatched evolution.
The web platform has been the leader in innovation in the UI design space, inspiring nearly all UI design technologies, while some adopt it in their stacks.
While the web platform and its technology are easy to use compared to other technologies, it is slightly verbose and low-level as it is a platform, not a framework.
For this reason, frontend frameworks have been created as a high-level declarative thin layer around the advanced web technologies to make developing complex applications and websites easier, faster, and safer.
Where did all of this complexity in today's frameworks come from?
I don't mean simplicity in fundamentals or API surface; I mean simplicity in implementation, the runtime internals, and codegen tooling that powers modern frameworks.
There is no doubt that modern frameworks have become heavy and bulky in their internals. Most of them weigh more than 100kb gzipped, which causes serious performance issues, especially slow load times.
They have also integrated complex and costly technologies into their runtimes just to be a little more declarative. Look at the entire spectrum of VDOM implementations.
They have also relied more and more on compilers and codegen in their tooling to add functionality not possible with normal JavaScript. Some use compilers to allow reactivity with normal JavaScript expressions, like Svelte.
Additionally, frameworks have integrated custom domain-specific syntax into JavaScript, like JSX, which requires additional work in code viewers and parsers to support it.
The quest for less verbosity has taken us to the realm of complex techniques and implementations, not because the web is verbose, but because the benefits started to require a lot for less.
If you have noticed, over the years, frontend frameworks have depended more on complex technologies just to be a little more declarative.
I am not against declarative programming, especially in places with a solid structure, like UI design. But I am here to highlight the existence of many solid and lightweight techniques that can be incorporated into frameworks.
They are a little bit more verbose, but they are on par with and may exceed the heavier ones in flexibility and functionality.
These techniques will not take anything from us; they are just the features you expect but coexist seamlessly with the rest of the application code as they use only native ways.
The web natives are good enough and surprisingly powerful and flexible if implemented correctly, but a little less expressive than the framework's own techniques. But do we really need to reinvent the wheel just for a little more?
In this series of articles, I will discuss the current trend of complex implementations and how we can solve them through the power of simplicity and remaining close to the natives.
For that, I have developed NeoComp.js, a proof-of-concept framework to show how simple lightweight techniques can deliver amazing results while having excellent performance.
Do not increment the new frameworks counter; this is not, and will not be, at the current time, a well-maintained and production-ready framework.
It is just a collection of ideas to support an argument done in free time and created for personal use. If you liked a feature, feel free to implement it in your framework.
Now, before diving into how we can fix the complexity with simplicity, let's just discuss.
The major roles of frameworks in the webdev world are logic encapsulation and composition, and DOM building and binding.
All frameworks have settled on a general markup of components and agreed on the core fundamentals, with slight dialect differences.
What is not agreed upon is the shape of the bindings to the DOM, and this is the main reason for divergence in modern frameworks and their paradigms.
Some use VDOM, others use fine-grained DOM bindings, others use compilers to convert normal JavaScript expressions into reactive ones, others stream JavaScript based on user interactions, and there are still those who use JQuery and support IE7, and countless other technologies invented just to bind some state to and with the DOM. Why all of this diversity?
The web platform was relatively low in verbosity from the beginning, and evolving means less complexity, and when React came, it erased the word "imperative" from the dictionary.
We loved React's declarativity, but it caused serious performance problems. The solutions that kept the declarativity relied on transpilers/compilers, while ones that favored performance over declarativity were not sold well, while React became restrained by legacy code, restricting it from fixing itself.
In the next article, we will dive into the problems associated with the render function paradigm and the alternative solution for it.