Beyond React: Exploring Solidjs and Qwik for next-level web development

Beyond React: Exploring Solidjs and Qwik for next-level web development

Introduction

React is very familiar to almost everyone who is into web development. It is the most popular library for building user interfaces and has a very huge ecosystem. It is widely used in enterprise software applications and has a great amount of resources and tutorials helping people to build applications with react.

Software development has always been the most innovative field and every new technology or stack comes up resolving the issues of the existing technology. While react has been trending and among the most widely used frontend frameworks, newer frameworks are emerging with the ability to overcome the issues with react.

Solidjs and Qwik are two new frameworks gaining popularity these days due to the way they make the application performant.

In this post let us go through the issues in react projects and then we will look at how these newer technologies are solving the issues.

Please note that this post in no way conveys that react is going away or we should start migrating to solidjs or qwik. The intention is just to make ourselves aware of the newer frameworks becoming popular due to their features. React has reached very far and the react team is continuously working to further enhance react and thus it cannot be replaced so easily.

Issues with React

  • Re-rendering - The components in react re-renders on state changes. Re-rendering is a computationally expensive process and it can impact the performance of the application where it happens too often.

  • Virtual DOM - In react there is a concept of Virtual DOM which you might be aware of. The concept of Virtual DOM was actually introduced to increase the performance of the app considering the process of updating the actual DOM as a costly operation. Although there are multiple benefits of the Virtual DOM it can be a costly operation for complex applications since the Virtual DOM consumes memory to preserve the DOM tree with the actual DOM. Sometimes it is more efficient to directly update the DOM and using the Virtual DOM.

  • State Management - With the increased complexity of the react application the state management can be tricky as it will lead to re-rendering the component which in turn causes performance issues.

Solidjs

Solidjs is a UI library developed by Ryan Carniato and first released in March ,2020. It is developer friendly as it is syntactically similar to react but there are differences in the underlying implementation that we will look further in this post.

Just like react has a meta framework called nextjs , solidjs also has its meta framework with the name SolidStart

Solidjs has a very fast performance and the initial load time.

Some of the salient features of Solidjs are as follows -

  • Fine Grained Reactivity - This is one of the key features of solidjs because of the changes are tracked to a granular level and the updates to the state are directly done on the real DOM without re-rendering the component.

  • Lightweight and small APIs - The bundle size of solidjs is less as compared to other frameworks and it has a very simple set of APIs.

  • Developer friendly - It is developer friendly of its simple syntax very similar to that of react. Like other frontend frameworks solidjs also has a component based UI development approach.

  • Declarative programming - Solidjs also uses a declarative programming approach towards building the UI.

  • No Re-Rendering - There is no rendering of the components in solidjs when the state changes. The components in solidjs is rendered only once and the state changes are done without re-rendering the DOM tree.

  • No Virtual DOM - Solidjs does not uses Virtual DOM unlike React , Vue and other frameworks. This is because the state changes are directly updated to the real DOM in a fine grained way without re-rendering.

Qwik

Qwik is yet another frontend framework that is still in a very nascent phase but it slowly attracting the developers because of its blazing fast performance. It was created by Misko Hevery. Qwik is also having a meta framework just like react and solidjs called Qwik City.

Almost all the frontend frameworks that we are aware of has an intial javascript bundle size that helps the browsers to add interactivity to the application. In complex applications the initial bundle size starts to increase even if we implement lazy loading.

The existing frontend libraries or framework works on the concept of hydration.

Hydration referers to the process of adding client side javascript to the server rendered HTML to add interactivity to the application rebuilding the UI on client side. This is used in Angular, React ,Vue ,Solidjs etc... Hydration can be understood as a rebranding of Client Side Rendering (CSR)

In react we have hydration together with rerendering of the components but in solid there is hydration but no rerendering. In qwik neither have hydration nor re-rendering.

Qwik brings up a new technique in which the initial bundle size is heavily reduced and the javascript is loaded on demand as the user interacts with the application. This technique is called resumability. Resumability is a technique for a framework to recover its state without re-executing the application components on the client. This is done by serializing not just the application state but also the framework state during HTML pre-rendering. By serializing the component boundaries, event listeners, and reactivity graph, a resumable framework can continue executing where the server left off.

This simply means that in Qwik the bundle size would be very less as the javascript for interactivity is not downloaded to client with the initial load. The UI is interactive the moment user clicks a button etc...

Conclusion

In this post we saw how newer frontend technologies are emerging up with innovative techniques to improvise the performance of the application by Hydration, Resumability. React initally had only CSR and later added SSR (Server Side Rendering) but the SSR does not help much, it just gives the user the illusion that the application has loaded and ready for interaction. However behind the scenes Hydration is underway and the client side javascript is downloaded for the app to be interactive.

Resumability solves this problem by adding instant interactivity to the application with minimum intial bundle size.

With that being said the concepts would be much clearer when we actually create sample apps and see whats happening in the console and network to undertsand hydration and resumability in a better way.

Thank you for reading the post and see you in the next post.