As of now, it is pretty damn good described in docs, man. There is a plethora of useful information that you could gain going through tutorial, including the stuff described here. If you are interested in Qwik I recommend you its docs and tutorial, it took me about 1 and half a day including qwik city docs. Nevertheless, Tony is indeed cool and he has a talent to teach!
This is the best explanation of QWIK framework yet, thank you @TonyAlicea. The best feature of QWIK is no hydration, which I think is the current challenge with other frameworks. Also since more HTML and less JavaScript is the way forward with SEO that is another major win.
Nice to see you around Tony! I have been wondering for years where you have been. It's thank to you that I understood JavaScript. Your course "JavaScript: Understanding the Weird Parts" is still the best out there. You might think about updating. 🙂
Thanks! You may not know but I've released multiple new courses over the past couple of years, including an ES6 course companion to The Weird Parts, an HTML/CSS course, and newly a React course. All are listed on my site: anthonyalicea.com/courses/
Thank you, Tony, for a fabulous first peek under-the-hood of Qwik and for taking the time and trouble to clearly illustrate what is going on. I have learnt a lot from your javascript, css and html courses over the past year and can't recommend them highly enough! 😎🙏
So basically, you wouldn't even strictly need to write your application in JS, if there was some kind of intermediate language then people could essentially write parsers into that which could then ultimately wind up as HTML+JS code when rendered to the browser. What they appear to have built then is a JS parser into the Qwik system, which could serve as a reference implementation.
Great explanation, it's very impressive that you understand all of this just by looking at the code, you have 200IQ or something, and i think the same about Qwick, or maybe not Qwick but "resumability" is the real future for frontend web dev. The creator of Qwick crafted something fantastic that will change web development for ever i'm pretty sure, it just need to get the API a little bit more user friendly, and it's an excellent thing that he decided to make it look like React even tho he is ALSO the creator of Angular, haha the man is just a genius at this point
Tony, if you have the time, how about a "best practice" tutorial video on Qwik + PWA? It's still not clear whether or not the two can work together well, or if at all, considering the well-defined requirements of PWA vis-a-vis Qwik's "resumable" feature. Your ideas will certainly provide more clarity to it.
Yes, the question of PWAs have been asked a few times. From what I understand it involves using the existing service worker that Qwik already sets up, and setting up the pre-fetcher to download all of the app's code.
What will determine adoption, I think, will be the API and the ecosystem. Devs tend to lean more towards their experience than the user's (unfortunately). I think Qwik has the UX part down, if they also get the DX then yes I think it will be big. Of course, if that happens it means other frameworks will try and provide resumability in some way.
For me as a freelancer I can see this being (initially before resumability is wide spread) a pretty big competitive advantage. Being able to confidently tell a potential client that their site will be generally much faster if they choose you, to build it, is a big deal.
@@caw5v Agreed. Qwik also has the ability to have different apps using different versions of Qwik run on the same web page. Could be major points for a business with lots of apps in a portal.
Thanks Murali! If you mean Qwik releases, I would follow their twitter: twitter.com/QwikDev. If you mean course releases, the new React course is in production (preorders available), and I anticipate early release content with the next couple of months: understandingreact.com
A good example! I like the metaphor of video streaming. Qwik is like streaming a video, while other frameworks work like downloading a video. Qwik does prefetching, which is like buffering. The difference with a streaming video and Qwik, is that the portion of the app that is streamed is controlled by the user.
Web components are really a separate topic from JS frameworks like Qwik, React, etc., though they can work together. Qwik, however, is focused on server-side rendering as much as possible for start up, so server-side rendering your web components is a consideration.
Using the backend and API of your choice, I think. Qwik City does let you retrieve data, for example, for a particular route: qwik.builder.io/qwikcity/routing/data/
what if u trying to render a huge list with a huge payload.... would it remember those old aspnet client side serialized state (webforms) that could grow to MBs?
It depends. With Qwik you can render on the server or the client. But for huge lists, even from a DOM perspective, I think you should not be rendering the entire list at once but paginating and retrieving as-needed, either via a paging interface or a "load more" at the bottom of the page.
One question: will this whole system/or concept eventually be built in to the browsers? I haven't tried it yet, but from what you are saying, it seems like it should just be part of the browser. Is that a dumb question?
hey man. this looks very promising. i have watched the whole video of you and Misko and i think this will change the frontend world. do you think you can make more videos on qwik? and also do you think it is worth learning qwik as a framework and using it for production?
More Qwik videos are definitely coming. And Qwik is fast approaching production release, so I think it's worth learning if you have projects that are appropriate for it. At the very least understanding resumability will be important in the future of JS frameworks, I think.
Serialization means taking information stored in the computer's memory and converting it into something that can be stored, passed around, and restored later.
Amazing analysis and tutorial 🙏🏻 But what I find interesting or questionable is, would a website using qwik not perhaps be more vulnerable due to the ability to reverse engineer it with ease? 🤔
Thanks! I don't think a website using Qwik would be more vulnerable to reverse engineering. Other frameworks download the entire app code, while Qwik is only downloading what you're using, and does a lot of work on the server. In that sense, it's a bit less vulnerable really.
So qwik is just loading chunks of js as needed instead of loading everything at one go. If that's the case wouldn't that make things worse for real websites since there would too many network latency/requests? If so I qwik would be better used to build solutions on local networks? Am I missing anything cause this seems confusing and counterproductive
You missed the prefetching and bundling. Possible paths are prefetched (but not executed) while on a page and possible paths can also be smartly bundled. Prefetching only happens in production though.
Great video, but Qwik looks like a disaster waiting to happen. Hopefully I'm wrong, but with so many moving parts I suspect this will lead to some very hard to understand errors in the wild. And if I understand correctly, all of this is to save on the initial parsing of the JS?
Not just parsing, but downloading, execution, etc. Qwik is like streaming a video instead of downloading it, but where you get the JS only for the interactions you are actually doing. So you could have a massive app, and only end up downloading/parsing/executing a tiny fraction if that's all you're doing in the app that time through. I'm not sure about hard-to-understand errors. I do think you need to have a good understanding of how browsers and client/server relationships work, which has been obfuscated by bundling these days. But for large apps I think this is a big deal.
@@TonyAlicea if you use all or most of the JS, then the downloading of several chunks would be less efficient than the downloading of one file, wouldn't it? I believe the issue is that parsing all of the JS at the beginning impacta that initial load, but once all JS was parsed the performance should be about the same, no?
Downloading JS is one piece of the puzzle. But the massive piece is resumability. Not having to hydrate, and avoiding a large amount of execution for startup speed. There's lots of potential there. Regarding if you use all or most of the JS, I'm not sure it's less efficient, maybe equal (Qwik prefetches JS as you go), however you sacrifice startup speed which is important for certain types of apps/user bases.
I was excited about Qwik, but when I tried to use it, the limitations of everything needing to be serializable got in the way. Maybe it's worth it for the benefits, but it's definitely some extra burden on the developer.
@@TonyAlicea I was trying to get the tanstack table working with qwik (really jumping in on the deep end). The table is basically a function that keeps track of the state of a table (sort order, filter values, etc.). The table object that's returned by the library includes many helper functions that can be used to mutate the state, but because of how Qwik works, those functions can't be passed around everywhere (such as a click handler). I posted more details in the Qwik GitHub discussions.
I've made good progress since I originally posted about this. As long as you keep track of all of the state that's needed to generate the table object (You probably need to do this anyway), you can pass that state around wherever you want (it's all serializable so far for me). This means you can pass the state into a callback function and generate the table object again inside that function's context. Again, I have more details and a link to a stackblitz in the GitHub discussion I started about this.
I just can't get past the idea of bloating html doc with these new script types and element attributes.. just a bad code smell to me. I don't really have much faith in the direction and ideas presented by qwik but hope to be proven wrong. I also just don't know what I would actually need qwik for, I feel like it's over-optimizing the client side. Just in the last couple years we've seen a shift away from SPAs and client-side driven apps and back towards the old traditional server side apps and I tend to agree that is the way of the future - not these client side optimizations that inheritely just bloat the client to do things that ultimately the server should just be better at.
A few thoughts: 1) What you're calling 'bloating html doc' is metadata about the app. Metadata is what HTML is for! While the extra info is visible in the HTML, it is *far less* than the bloat being added both to JS and to the DOM (invisibly) in other frameworks. 2) The idea of 'over-optimization' I think only makes sense if the dev has to do optimization work that doesn't have sufficient return on time investment. If the framework is doing the work for you, thus the optimization is *free*, what would be wrong with maximum optimization? 3) Qwik lets you do both SPA and MPA. It's server-first, so is part of the shift away from SPAs. You can use either for MPA or for SPA, mix and match as you like per interaction.
Fantastic explanation, love your calm voice and tempo. 1000x better than reading 10 articles or the documentation to understand a new framework.
Thanks!
As of now, it is pretty damn good described in docs, man. There is a plethora of useful information that you could gain going through tutorial, including the stuff described here. If you are interested in Qwik I recommend you its docs and tutorial, it took me about 1 and half a day including qwik city docs.
Nevertheless, Tony is indeed cool and he has a talent to teach!
Absolutely this is my first video of him, and I put him no 1 place because of calm and focused on target of the video.
thanks again
Amazing explanation, I didn't know qwik used rust under the hood. Thank you.
This is a masterclass of unpacking a deep, complex topic into bite-sized, understandable chunks (ha!).
Ha! Thanks Edo!
This is the best explanation of QWIK framework yet, thank you @TonyAlicea. The best feature of QWIK is no hydration, which I think is the current challenge with other frameworks. Also since more HTML and less JavaScript is the way forward with SEO that is another major win.
Thanks Nosherwan, and agreed!
This is f great. Thank you!
This should be added to the qwick media section
Thanks it’s already there!
Just excellent! Now I understand the power behind Qwik. You rock!
Nice to see you around Tony! I have been wondering for years where you have been.
It's thank to you that I understood JavaScript. Your course "JavaScript: Understanding the Weird Parts" is still the best out there. You might think about updating. 🙂
Thanks! You may not know but I've released multiple new courses over the past couple of years, including an ES6 course companion to The Weird Parts, an HTML/CSS course, and newly a React course. All are listed on my site: anthonyalicea.com/courses/
Thank you, Tony, for a fabulous first peek under-the-hood of Qwik and for taking the time and trouble to clearly illustrate what is going on. I have learnt a lot from your javascript, css and html courses over the past year and can't recommend them highly enough! 😎🙏
Great explanation! Very helpful for my paper
Its so simple and such a good idea. Loved it!
Awesome stuff, i'm a beginner in frontend development, confused a lot, but this explanation is pristine🚀
we're very thankful for your great work Tony. this is something that mean a lot to us.
Tony thank you so much, your videos are so informative, you ask a lot of relevant questions and answer them really well. Really helpful!
This is by far the best explanation of a framework I have seen, thank you Tony 🫡
Thanks David!
Amazing explanation. Thanks a lot.
Thanks for this one, please create more under the hood videos like this.
That was such a good explanation.and yes, this is a whole different mindset of how JS frameworks should work. U just won a subscriber.
Thanks Michael!
It really clicked for me after this explanation, thanks a lot man.
Thank you!
So basically, you wouldn't even strictly need to write your application in JS, if there was some kind of intermediate language then people could essentially write parsers into that which could then ultimately wind up as HTML+JS code when rendered to the browser. What they appear to have built then is a JS parser into the Qwik system, which could serve as a reference implementation.
The best explanation I ever seen for a framework
Thanks Adnan!
Amazing way to explain 🔥🔥
Excellent throughout !
holy shit, love seeing rust in places i didn't expect
Maann,, amazing detailed explanations. Thanks 🙏
This was great. Watched it twice
Thanks!
Excellent explanation. Thank you.
Thanks!
Gr8 video!
The big question is the community adoption, cause currently react is rule at industry.
Indeed. I think Qwik's many advantages will attract community builders though.
Dude, this video is awesome, subbed.
Thanks!
Great explanation, it's very impressive that you understand all of this just by looking at the code, you have 200IQ or something, and i think the same about Qwick, or maybe not Qwick but "resumability" is the real future for frontend web dev. The creator of Qwick crafted something fantastic that will change web development for ever i'm pretty sure, it just need to get the API a little bit more user friendly, and it's an excellent thing that he decided to make it look like React even tho he is ALSO the creator of Angular, haha the man is just a genius at this point
I think it's syntax similarity to react is to help drive it's adoption.
really great explanation, especially for the source code tracing was fantastic! Easy to understand what's going on from the root of code! thanks!
Thanks, glad it helped!
Fantastic video, extraordinary explanation! Thank you
Thanks!
Awesome video
Thanks Kelvin!
Absolutely phenomenal. Unparalleled job 🙏👏
Thanks so much!
Tony, if you have the time, how about a "best practice" tutorial video on Qwik + PWA? It's still not clear whether or not the two can work together well, or if at all, considering the well-defined requirements of PWA vis-a-vis Qwik's "resumable" feature. Your ideas will certainly provide more clarity to it.
Yes, the question of PWAs have been asked a few times. From what I understand it involves using the existing service worker that Qwik already sets up, and setting up the pre-fetcher to download all of the app's code.
Explained very nicely
Thanks!
Beautiful presentation 👌 thank you
Thanks!
You're a great teacher Tony. Thx again
Thanks Chris!
Great video! The idea sounds great!
Fan of Tony from AngularJs days !
Thanks! :)
Awesome video! Thank you!
Thanks Benjamin!
This has to takeover at some point. It delivers fast load times and a performant run time environment. Oh and it scales too lol. Is it perfect?
What will determine adoption, I think, will be the API and the ecosystem. Devs tend to lean more towards their experience than the user's (unfortunately). I think Qwik has the UX part down, if they also get the DX then yes I think it will be big. Of course, if that happens it means other frameworks will try and provide resumability in some way.
For me as a freelancer I can see this being (initially before resumability is wide spread) a pretty big competitive advantage. Being able to confidently tell a potential client that their site will be generally much faster if they choose you, to build it, is a big deal.
@@caw5v Agreed. Qwik also has the ability to have different apps using different versions of Qwik run on the same web page. Could be major points for a business with lots of apps in a portal.
Thank you so much, please make playlist about how to use Qwik in development.
Any info on release updates?
Great explanation, thank you
Thanks Murali! If you mean Qwik releases, I would follow their twitter: twitter.com/QwikDev. If you mean course releases, the new React course is in production (preorders available), and I anticipate early release content with the next couple of months: understandingreact.com
Stunning!!!
Thanks Yinon!
Great video. The only issue now is that angular or sveltekit are not resumable
Qwik basically brings to the web what games have always been doing.
A good example! I like the metaphor of video streaming. Qwik is like streaming a video, while other frameworks work like downloading a video. Qwik does prefetching, which is like buffering. The difference with a streaming video and Qwik, is that the portion of the app that is streamed is controlled by the user.
@@TonyAlicea video streaming is a great analogy !
super awsome video. love the video. you are the best.
Thank you!
Great explanation :D
Thanks Victor!
Thanks for the detailed explanation. Is there a way to create reusable Web Components library using QWIK?
Web components are really a separate topic from JS frameworks like Qwik, React, etc., though they can work together. Qwik, however, is focused on server-side rendering as much as possible for start up, so server-side rendering your web components is a consideration.
Tony what about the backend? How do we integrate a database?
Using the backend and API of your choice, I think. Qwik City does let you retrieve data, for example, for a particular route: qwik.builder.io/qwikcity/routing/data/
I think qwik will replace react in future . Do you guys think that too ?
Hard to say. But I believe it will become very popular because of the performance improvements it enables.
what if u trying to render a huge list with a huge payload.... would it remember those old aspnet client side serialized state (webforms) that could grow to MBs?
It depends. With Qwik you can render on the server or the client. But for huge lists, even from a DOM perspective, I think you should not be rendering the entire list at once but paginating and retrieving as-needed, either via a paging interface or a "load more" at the bottom of the page.
can you make a under the hood video for vue js? and svelte maybe?
One question: will this whole system/or concept eventually be built in to the browsers? I haven't tried it yet, but from what you are saying, it seems like it should just be part of the browser. Is that a dumb question?
hey man. this looks very promising. i have watched the whole video of you and Misko and i think this will change the frontend world. do you think you can make more videos on qwik? and also do you think it is worth learning qwik as a framework and using it for production?
More Qwik videos are definitely coming. And Qwik is fast approaching production release, so I think it's worth learning if you have projects that are appropriate for it. At the very least understanding resumability will be important in the future of JS frameworks, I think.
I watched misko demo it and noticed any interaction caused the core lib of 1.1mb to download.... 1.1mb???
What about mithril js framework
Why is more fast than react or vue
wait for another undesr-the-hood video for the remix framework.
also i wanted to ask you: what exactly is meant by serialization?
Serialization means taking information stored in the computer's memory and converting it into something that can be stored, passed around, and restored later.
it still blows my mind how it's possible to pass around closure-related information just like qwik does.
if qwik serializes data into the HTML, if that data contains sensitive information, wouldnt it then be a huge security issue?
It wouldn’t be serializing any data that isn’t already intended to be sent to the browser and is visible in the HTTP requests anyway.
Amazing analysis and tutorial 🙏🏻
But what I find interesting or questionable is, would a website using qwik not perhaps be more vulnerable due to the ability to reverse engineer it with ease? 🤔
Thanks! I don't think a website using Qwik would be more vulnerable to reverse engineering. Other frameworks download the entire app code, while Qwik is only downloading what you're using, and does a lot of work on the server. In that sense, it's a bit less vulnerable really.
So qwik is just loading chunks of js as needed instead of loading everything at one go. If that's the case wouldn't that make things worse for real websites since there would too many network latency/requests? If so I qwik would be better used to build solutions on local networks? Am I missing anything cause this seems confusing and counterproductive
You missed the prefetching and bundling. Possible paths are prefetched (but not executed) while on a page and possible paths can also be smartly bundled. Prefetching only happens in production though.
I just wonder how people come up with such creative ideas
30yrs of coding experience
Great video, but Qwik looks like a disaster waiting to happen. Hopefully I'm wrong, but with so many moving parts I suspect this will lead to some very hard to understand errors in the wild. And if I understand correctly, all of this is to save on the initial parsing of the JS?
Not just parsing, but downloading, execution, etc. Qwik is like streaming a video instead of downloading it, but where you get the JS only for the interactions you are actually doing. So you could have a massive app, and only end up downloading/parsing/executing a tiny fraction if that's all you're doing in the app that time through.
I'm not sure about hard-to-understand errors. I do think you need to have a good understanding of how browsers and client/server relationships work, which has been obfuscated by bundling these days. But for large apps I think this is a big deal.
@@TonyAlicea if you use all or most of the JS, then the downloading of several chunks would be less efficient than the downloading of one file, wouldn't it? I believe the issue is that parsing all of the JS at the beginning impacta that initial load, but once all JS was parsed the performance should be about the same, no?
Downloading JS is one piece of the puzzle. But the massive piece is resumability. Not having to hydrate, and avoiding a large amount of execution for startup speed. There's lots of potential there.
Regarding if you use all or most of the JS, I'm not sure it's less efficient, maybe equal (Qwik prefetches JS as you go), however you sacrifice startup speed which is important for certain types of apps/user bases.
I was excited about Qwik, but when I tried to use it, the limitations of everything needing to be serializable got in the way. Maybe it's worth it for the benefits, but it's definitely some extra burden on the developer.
I’m curious, what were you trying to do that serialization got in the way?
@@TonyAlicea I was trying to get the tanstack table working with qwik (really jumping in on the deep end). The table is basically a function that keeps track of the state of a table (sort order, filter values, etc.). The table object that's returned by the library includes many helper functions that can be used to mutate the state, but because of how Qwik works, those functions can't be passed around everywhere (such as a click handler).
I posted more details in the Qwik GitHub discussions.
I've made good progress since I originally posted about this. As long as you keep track of all of the state that's needed to generate the table object (You probably need to do this anyway), you can pass that state around wherever you want (it's all serializable so far for me). This means you can pass the state into a callback function and generate the table object again inside that function's context.
Again, I have more details and a link to a stackblitz in the GitHub discussion I started about this.
I just can't get past the idea of bloating html doc with these new script types and element attributes.. just a bad code smell to me. I don't really have much faith in the direction and ideas presented by qwik but hope to be proven wrong. I also just don't know what I would actually need qwik for, I feel like it's over-optimizing the client side. Just in the last couple years we've seen a shift away from SPAs and client-side driven apps and back towards the old traditional server side apps and I tend to agree that is the way of the future - not these client side optimizations that inheritely just bloat the client to do things that ultimately the server should just be better at.
A few thoughts:
1) What you're calling 'bloating html doc' is metadata about the app. Metadata is what HTML is for! While the extra info is visible in the HTML, it is *far less* than the bloat being added both to JS and to the DOM (invisibly) in other frameworks.
2) The idea of 'over-optimization' I think only makes sense if the dev has to do optimization work that doesn't have sufficient return on time investment. If the framework is doing the work for you, thus the optimization is *free*, what would be wrong with maximum optimization?
3) Qwik lets you do both SPA and MPA. It's server-first, so is part of the shift away from SPAs. You can use either for MPA or for SPA, mix and match as you like per interaction.
Not using template strings in 2023, jeez.
Template strings were used throughout (not that it matters), so not sure what you're talking about.