Resumability Explained

[@PierreChevallier]

Thanks for explaining, it's the first time since the framework came out that I understand the concept of resumability!

[@awesome-coding]

Glad it was helpful!

[@wolfisraging]

Amazing content bro. Keep it up with these straight forward explainations

[@awesome-coding]

Thank you! Planning to!

[@ryo_5748]

This is the simplest explanation of Qwik in the world! Thank you.

[@awesome-coding]

Glad it was helpful!

[@AlamKhan-yt9wd]

You explained like a 5 year old can understand. You did your best in this video ❤❤

[@awesome-coding]

Glad you think so! Thanks for the feedback!

[@prvtthd401]

Finally, I've been trying to make sense of the whole qwik concept. This video explained it all in a clear format.

[@awesome-coding]

Glad to hear!

[@fin4lgamer]

I think the quick loader only registers events that are actually used instead of all events.

[@julienwickramatunga7338]

You made the concept cristal clear in 6 little minutes, thanks a lot!

[@awesome-coding]

Glad to hear! Thank you!

[@wertin200]

Nice, video. It would be cool if you would a comparision between Qwik city, Svelte kit and Nuxt.

[@awesome-coding]

Great suggestion! I'll add it to the list - thanks!

[@Niksorus]

I'm also very curious about SvelteKit in comparison!

[@ChinyeluLyon]

Really clear explanation, easy to understand!

[@awesome-coding]

Glad it was helpful!

[@Niksorus]

Dude... You're a beast. Thank you sooo much for this content.

[@awesome-coding]

Happy to help!

[@laughingvampire7555]

2:30 that is just a mischaracterization of how that worked, because all those websites were always made to be fast so the user didn't have to wait that much. there was no little interactivity because we use a lot of Javascript with jQuery and Dojo and Extjs and other frameworks.

[@laughingvampire7555]

This idea of resumability is just implementing in a framework and automation of what we did back in the early 2000s even before jQuery & Dojo, but looking at HTMX it looks as an even more compelling idea because for all the interactivity you are getting just one js file that is common to all the pages, is your single entry point and you can reuse all the community effort of something like Rails/Django or a simple CGI scripting language like PHP without any framework. I love the simplicity but I''m terrified of the future web apps that are going to be a mess because people made them with PHP & HTMX

[@awesome-coding]

Honestly this is my main concern as well. How well will an HTMX based app scale in a very large codebase?

[@SR-zi1pw]

Nice explanation

[@awesome-coding]

Glad you liked it!

[@soundrightmusic]

Great to see qwik content. Its really cool tech.

[@ashleyfreebush]

Love this type of video, like the js one

[@Mario-ze3jr]

Although not necessary, it's cool to know how these frameworks work under the hood

[@chibby-k]

Awesome Content. Does the worker thread download all JS chunks into the cache or only the ones interacted with?

[@tomasdohnal]

fabulous video and superb produciton quality! was just wondering, what tools do you use for the animated diagrams and editing in general?

[@awesome-coding]

Thank you for the feedback! I mostly use the Adobe stack: Premiere, Illustrator and Photoshop.

[@stephenkamenar]

so it's the same as hydration, just more granular?

[@awesome-coding]

Hey! In theory it just replaces Hydration, but you could think of Resumability splitting the Hydration process in 2 parts - one running on the server, together with the rendering of the HTML (when that special HTML markup is added in), and one on the frontend, when that special markup is being analysed. The advantage is that because of this change in the architecture, you don't execute / send to the browser the same code twice.

[@omegaomar29]

Do you have resumability using Qwik or you need to use Qwik city?

[@awesome-coding]

This is built directly in Qwik.

[@harshilparmar9076]

Hey nice video, can you please explain more about why there is need of writing code twice while using ajax. You mentioned here 2:55. I am just curious 🧐

[@awesome-coding]

Sure thing. Imagine it's 2008, and you can't run JavaScript on the backend (Node is not yet available). So you would use a language like Java or Ruby for your backend work. You can however use JavaScript on the browser, make async calls to the server and receive an HTML or JSON response back. So, in our scenario, we need to display a list of products in the browser. 1. The user makes a request to the server to see the list of products. 2. On the server, you are getting the products fro the database, and you need to build an HTML page to send as a response to the browser. 3. You are on the server, so you will use your server language to compute the HTML, right? 4. Once the HTML is computed, it is sent to the browser. 5. The user sees the list of products in the browser, and decides to remove a product. 6. Now, as a developer you realise you can send a DELETE async request to the server using AJAX, and avoid refreshing the whole page again. 7. You make the async request to the server, and you get a success response (maybe a boolean, or just a 200 response code). 8. Now you are still on your browser page, but the deleted product is still visible in the list (you only removed it on the backend). 9. Of course you could do a full refresh of the page, and the html will be computed correctly again on the server, but this defeats the purpose. 10. So you need to remove the element programatically with JS from the DOM. 11. You could simply do a dom element remove, but you'll soon realise that people can also modify, or add new products. 12. Considering all these, you realise that the best user experience and dev experience is to create a javascript function on the client that receives a list of products as json, and computes the HTML again. 13. So the next time you are making a DELETE / POST / PUT async request to the server, the server will return an updated list of products as JSON. 14. You pass that JSON to the JS function, and the page is updated without a full page refresh. So you end up with implementing the HTML computing twice - once on the server for the initial response and once on the client to update the page whenever somebody changes the list of products. Hope this helped :)

[@srinivasat5316]

@@awesome-coding thanks, for the explanation. So, the correct term is repeated renders, not "twice" then. I was also confused here

[@PeerReynders]

@@srinivasat5316 The issue is 2x the development work. 1. Develop the server (app) side code to render the HTML. 2. Develop the JS code to support client (app) side interactions and perhaps modify dynamic areas of the DOM. “One App for the price of two” eBays MarkoJS started addressing this problem way back in 2012 (open sourced in 2014) but the rest of the world was too enamoured with developing just one client side rendered (React) app to notice.

[@harshilparmar9076]

@@awesome-coding Ohh my god!! You are the best teacher. Thanks for the explanation.

[@awesome-coding]

@@srinivasat5316 Yep, that's right! Sorry for the confusion!

[@mooza.shorts]

Amazing thanks man

[@awesome-coding]

Thank you!

[@aldogutierrez8240]

I prefer JSP (Java Server Pages) Server Side Rendering

[@awesome-coding]

Heck yea!

[@Kats0unam1]

the frontend framework world should realise we dont need that many tools js frameworks to build websites. Dude already did Angularjs and 2+, why even put more waste outside?

[@Kats0unam1]

I still think Qwik is meh. Doesn't he do more http calls than needed to ?

[@awesome-coding]

It does more requests to fetch the chunks, but this happens only the first time you access the app. Subsequent workflows will use the cached assets. I don't think the http calls ar that big of an issue since hardware is so cheap these days but yes, it is a tradeoff for certain.