Javascript framework I am actually excited about

If you have read much of my work you know I am a proponent of the JAMstack. I like to utilize CNDs and edge networks as much as possible. A common problem I run into is too much client side javascript. While a framework might feel counterintuitive as a solution, the unique approach of this one might surprise you. Now full disclosure here I have yet to make anything using this framework. I have just been reading the docs and getting my head around how it works. But some of the possibilities are very exciting and this is why I feel it's important to spread the word. So today we are talking about Qwik.

Do we really need another javascript framework?

I used to think there were already too many. I would often avoid using them due to file sizes and load times. This framework solves almost all the problems I previously had with frameworks, speed and scalability being the two most important. Qwik in their documentation states applications can have instant load times that boot with as little as 1kb of javascript regardlessof page complexity. Now that sounds like something I can get behind. So how does qwik achieve all of this. There are a few key differences with the architecture of this framework which allows for all of this functionality.
Let's have a look under the hood.

Resumable with zero Hydration

Hydration refers to client side javascript that converts a static HTML page to a dynamic one by attaching event handlers to specific elements. There will be a period of time between when the HTML is loaded and the javascript has had a chance to execute. This phase is known as the Hydration phase. This phase can slow down load times and can leave a client looking at an unusable site while they wait for javascript to execute.
So how does qwik deal with this issue? Well there are two things they have listed on their website.

1. Delay execution and download of JavaScript for as long as possible

2. Serialize the execution state of the application and the framework on the server and resume it on the client.

Serialization is done in HTML so the browser doesn't have to do anything upon receiving the data. Qwik applications at any point in their lifecycle can be serialized and moved to a different VM instance (server to browser).

Lazy Load everything

If you are not familiar with lazy loading with images it is when an image is only loaded when a client scrolls near it. A great example is your feed on Facebook or Instagram or other social media. You will notice as you scroll the posts will show up before the images. Qwik takes this same approach but for code instead of images. A function triggered by an event handler is only downloaded and run when a client triggers that event. You can find this list on their website.

In Qwik everything is lazy-loadable:

1. Component on-render (initialization block and render block)
2. Component on-watch (side-effects, only downloaded if inputs change)
3. Listeners (only downloaded on interaction)
4. Styles (Only downloaded if the server did not already provide them)

This gives qwik apps infinite scalability regardless of application complexity. Which is very exciting for me as a developer.

Give it a try for yourself

While I have only scratched the surface here I hope I have given you a good outline of what makes this framework unique and let you know why I am so excited about it. I encourage you to check out their documentation and get to know the ins and outs. I can see many future frameworks following qwiks architectural model. Let me know what you think of this new framework in the comments.