RIP React? New Qwik Release Is REALLY Interesting
ฝัง
- เผยแพร่เมื่อ 28 ก.ย. 2024
- I've never been the biggest fan of Qwik. Resumability just didn't seem worth the costs, and the hacks to enable it were...chaos, to say the least.
That said, honestly? Very impressed with what they're cooking here. Excited to try out 2.0 when it drops.
POST: www.builder.io...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
I just replaced react with Qwik. I've never been happier.
My homepage is just 8kb, using tailwind, with a complex layout, and loads in 96ms.
This is a great breakdown of Quik. I’m impressed with their obsession with performance.
Qwik also did a great work on eliminating the boundaries between frontend and backend. So much better than Server Actions!
You can define a server only function by wrapping the definition in server$(), then it will only be executed on server side when being called.
And you can define this thing anywhere and call it anywhere. You don't need to use it with an action attribute on form element. And you don't need to worry about 'use client' or 'use server'. The only thing you need is wrapping it inside server$(). And this is just magic!
How's the server side rendering / data fetching story look?
@@MattSalsa Fetching data is easy. As I mentioned, you just need to wrap it inside server$() and then the code will be executed on server side. So, same as server action, you can query the data from your db directly. Only difference is server$() can be defined anywhere and called anywhere.
It is capable of SSR, but tbh, Qwik doesn't talk much about it in the doc. I am thinking one reason about this is that Qwik already skips hydration and send HTML back to client, so SSR doesn't benefit Qwik a lot. So, overall, it's probably not Qwik's high priority atm.
Was a fun stream! Qwik has changed a LOT since your last stream with Misko, and really exciting to see a project where a great user experience matches the developer experience out of the box.
big ups, mention of jack :P
misko is really great at creating great DX i remember when i use angularjs it is much simpler than jquery imo, and now with qwik ive tried it and its much more simpler than react i really hope people start using it some of the function that are hard now become easy like server$ its kinda like react server component and then worker$ for web worker which is very useful for long process running on client, and many more
Not EVERY framework needs binding packages for stuff like popper. All you need is a framework that is friendly towards web components. For example, Angular is (not my favorite framework). I would love a future where every component library supports web components.
web components suck, i hope people stop using them or they get a huge rework(which is unlikely, so there is only 1 option left)
Can web components easily bind their internal state to framework-specific state? If not the result is gonna be rather unflexible.
Also can web components talk to each other? It's more and more common for UI libraries to provide composable primitives - a dropdown component is not just one component but a family of components(or hooks) like Dropdown.Root, Dropdown.Viewport, Dropdown.Option etc. If web components can't communicate you're gonna have a hard time implementing this level of composability.
@@upsxace I respectfully disagree 😉. But improvements to ergonomics are underway. Currently I would advise using a library to create them (and keep your sanity)
@@zwanz0r using any frontend framework will make you 10 times more productive than building web components, plus their API is horrendous and counter-intuitive(which sometimes leads into bugs on complex use-cases), and the idea that web-components are fully portable to any framework/setup is a myth. You mentioned "web-components friendly frameworks", but all of those either still do things WAY better without web components(example: svelte), or they are just inferior frameworks that aren't good for complex use-cases anyways.
TLDR: Web components don't scale well in my opinion
Does every video have to be RIP now?
The first time someone has explained hydration in a way I understand. Now all those hydration errors make sense
The way he says attributes is pretty funny
Qwik is awesome but there (for me) is many abstractions... Like I can't just access created element and call native JS functions, for making custom player. I love where Qwik framework is going, but they need to add more air.
The virtual node comments thing seems like a weird hack to me. Why can't resumable nodes just be identified with a unique address stored in a class or a data attribute?
I want to build a multi static page site, all static content only not application. Is qwik or astro good for me
Astro shines in those instances
Yep! Both are server first (including Qwik core itself). Qwik is kinda like a .astro file, with the added resumability part, where there is a server to client handoff when the user interacts with something.
You can even use Qwik's resumability inside of Astro if you choose. With the @qwikdev/astro integration.
The other choice being Qwik's meta-framework Qwik City. Which can be more useful for a large web app.
@@omomer3506 🙏 thank you
Maybe I'm misunderstanding, but aren't static site generators the correct tool for that? Like Hugo
@@kangalio with server first frameworks like Qwik and Astro it's just as good with SSG, and you can have interactivity and javascript.
21:01 There is Nuxt UI :)
idk how I should feel about the 1000th js cool framework out there that I should learn to build a stupid website
RIP this, RIP that, this killer that killer, I am tired of this shit
@@marh122 It's just content creators making noise for clicks
@@cassideybennet9256 no it's because once you are in the business for a while and have come accross more complex application you know that this stuff matters
You cannot learn everything at once, focus on fundamentals first and be patient. That applies to anything you want to learn/know, don't hate on JS/Web
You don't need to learn it. Just because tech influencers talk about it, doesn't mean you need to learn it. If you want, just be aware that it exists and then in the future you can remember "Oh I know a perfect tool for the job" just because you are aware it exists. No need to even write a single line of code in it before that or let alone be a master in it.
The fact that the HTML semantics were all over the place and the inspector was completely cluttered with comments was a deal breaker for me. Was it just me, or does anyone else feel this way? The old Qwik results felt chaotic, at least from my front-end-oriented point of view.
Completely agree! Not a problem in 2.0 :)
The point you made about component ecosystem is only partially true, imho.
The real reason Svelte doesn't really need wrappers for vanilla libraries is "actions", one of its best features.
Runes will help, for sure, but I don't think library authoring is hindered by missing features as of now, just a smaller ecosystem, compared to the giant React user base.
Let’s freaking go (as in Go lang)
not game changer, just another js framework
You don’t know what you are talking about, just use it and you will tell me.
dont speak facts to me, i wanna believe again 🙏
Sounds like heresy
Yes you need a ecosystem to build a product which React has.
Nah, I just built a project with it, and it was a mind blowing experience. I used to work with Next.js 14 and the next in general is not a developer friendly, I had a terrible experience with it because I need to define what runs on the client and what runs on the server … etc, but with Qwik.js I just wrote the components like I’m writing a plain react project and it all runs on server, thanks to resumability, I don’t really need to worry about what component runs on server and what is not.. Just write and run!
separately - awesome shirt (not even meaning this ironically)
21:00 Angular has Material
More Qwik content please! I think it is really interesting framework that solves problems in great way
hes looking at the output of the html you dont have to write, comparing that to the input of tailwinds you do have to write...
The disrespect on Angular 😑
Theo isnt into carrot farming
Angular deserves it tbh
There can never be enough angular disrespect
Still, React and Angular (and perhaps other big names like Vue) will still be here in 20 years and the developers will at least be thankful that the docs are good, that the code is standardized, and that an ecosystem exists/existed. These other random frameworks can't say the same - all they do is push the status quo for the fun of it.
@@bullettime2808u just dont @defer signal enough bro
Using HTML comments for actual functionality feels like the creative tech videos with titles like "I used my 30 smart refrigerators' free cloud storage account to store terabytes of data for free". Kinda fun to see something like that work, but obviously a bad and hacky idea for production.
how is it bad and hacky for production if it doesnt produce anything that effects security or user experience in a bad way? i mean if the price of running an app once is bad looking production html is it not worth it?
@@ayoubkrt5018 because HTML comments aren't a reliable source of data or functionality. A random browser update in the future might remove the ability for JS to read HTML comments because technically they aren't part of the DOM, and some browsers might already not parse HTML comments at all.
@@okie9025 the HTML ur talking about tells the browser to parse those comments if im not wrong, also i dont see why browsers would suddenly decide to drop comments support? that sounds like a far fetched fear out of nowhere, qwik is supported in every browser that supports service workers, aka every browser except some very old iphones, like i said i much rather comments then downloading javascript, there doesnt seem to be any browser movement to disable comments parsing from what i see either, infact it seems odd to do, ur telling me a mobile browser is gonna use the device limited resources to decide not to parse html just because of spite?
@@ayoubkrt5018 I'm not saying that we should remove HTML comments, I'm saying that it's an unreliable whack way to make your framework work. I'm saying that comments aren't an integral part of browsers and are more of an auxiliary/niche feature that anyone rarely ever uses. I'm also not saying that there is an active effort to remove HTML comments, but that doesn't mean that they are a stable and standardized way to store your data. It's a cool idea, but it's not sustainable. That's why my original comment compared it to a specific type of tech video, for example using Discord messages as a cloud storage solution - it technically works perfectly, but it's obviously unreliable.
@@okie9025 yes and im asking in what way is it not reliable ? just because it's not orthodox way we should avoid it? even tho its a much better solution? comments are part of html, browsers are required by the html that qwik make to parse what it tells it to, if suddenly browsers started deciding for themselves to parse whatever they want it would be a problem, also i dont like the discord msgs as storage comparison, in that road, yeah thats risky and not a plausible way to hold ur data, however html comments are always present, always sent to the client, always existed with the browser, comments help dev understand what they wrote, well now they help a framework understand what it needs to do, i dont get how this seems problematic to you? what other option would u suggest one to use to fix the hydration issue?
i mean when angularJs came out it was a hack compared to the present technologies, yet here we are
Initial page load is fast but runtime performance on DOM operations is unfortunately slow if you compare Quik to Svelte or React and Angular in the js web frameworks benchmark.
The problem with tailwind isn't the output html it's the dev environment html, this is not an issue with Qwik. Why would we give a shit about the production environment level code it's not supposed to be human readable its whole purpose is perfromance optimization...
Resumability is what hydration should have been.
Astro with Solid. Why should I use something else 🤷🏻♂️
Well I like the new paradigm of adding comments in the markup, but I think React could move towards this as well.
Resumability would require a significant architectural change from the ground up for React. Very unlikely.
Would definitely be some breaking changes.
It’d be awesome if they could though.
this new encoding makes me think a lot of the encoding in source maps
I don't complain about Tailwind because of its verbosity. That's annoying for sure, but it's not the main reason for me. I don't understand the purpose of Tailwind at all. I don't understand the point of learning all the utility classes when they are just a single line of CSS anyway. I'll just use the CSS that I already know instead of taking on another dependency and having to learn their language. Makes zero sense to me.
Well written blog and well made video.
looks like something that depends on browser quirks over specification. I am sure the browser is allowed to ignore the comments alt other when forming the nodes
It's not. The way browsers should parse HTML to the DOM is explicitly defined in the HTML spec
why would you trigger me with datetime hydration errors out of nowhere like this!! Those are especially funny honestly, because it *should* be easy to have some attribute for react to compare instead of the text content, the time tag literally has one called datetime. Then again, I once had a very weird bug where I had an array of data objects that would get filtered in the client days after deployment (page using SSG in next) and after filtering it would mix data from the objects with data that was there in the HTML seemingly at random, causing very weird states. This would not happen if navigated to the page from elsewhere on the site, only due to hydration. Since that day I had a custom hook wrapping a nanostores atom to have a synced isClient state across my app to reference all over the place...
The hate on Angular is funny but version 17 is out soon so it must be doing something right
Thank you!
After using QWIK in my side project that had a very VERY simple website i have one thing to say - QWIK is not ready for production. The documentation is garbage at best and missing some key aspects at worst, the aproach with $ scoping is quite good, but sometimes really pain in the ass, but most importantly, community around QWIK is pretty much non exsistant. I might be biased because i'm in love with React, but after migrating my project from QWIK to React(Next 14), the site became just tiny bit slower to load, but the DX improvements went through the roof.
i dont quite understand your take here with the docs being garbage, i had spent my time reading react docs, svelte docs, solid docs and out of all of them qwik was the nicest and most interesting reads, it covers most of anything that you need to know with hold my hands examples even, maybe you can be more clear which part of the docs suck?
the approach with the $ is made to stop u from making a gun that shoots u in the foot pretty sure, yeah can be annoying but i rather deal with that than a foot gun tbh
and for the community, depends how u look at it, if ur comparing it to react community then yeah how could it compare, but for a new framework with a whole new take into the market the community is rising, in understand that sometimes u might not get the answer u want but mostly 8/10 times i ask questions in the discord there is someone to help, sometimes even misko helps, idk about the migration part cause that highly depends how big ur app is, if its a static app that has little to no interactivity then yeah u wont feel a huge difference out of the box, its when you start loading javascript is the big guns that qwik has, also about the DX it could also be that you're more used to react DX? cause i tried both react and qwik and next 13, and after trying qwik react and next DX felt extremely horrible in comparison
Re-write in Go
almost every second day something new keeps on coming out that claims to be faster, lighter, and better and killer of a particular technology
Can someone point me to some proper benchmarks that accurately measure hydration on an average app? I think I've seen hydration take like 30-50ms so not sure why Qwik maintainers always focus so much on hydration being the single source of bad user experience in apps. Including a single 3rd party integration like Google Analytics will probably impact your site more compared to just hydration in a modern framework.
Yeah of course if there was no hydration so it was 0ms it would be better, but there are probably many more things you do in code that impact app usability compared to hydration.
Although I do agree dealing with hydration mismatch errors sucks.
Depends how big ur website is, I mean if ur website is a small portfolio with minimal to no interactivity then yeah it won't really suffer too much, but then if u have an e-commerce with lots of JavaScript, lots of listeners a lot of everything, running it twice is a big cost
@@ayoubkrt5018 but I want actual numbers, not theoretical stuff. I know how hydration works and that bigger app could mean hydration takes longer. Just saying "hydration is bad" doesn't mean anything to me unless I see some actual data from some real world mid/big size applications.
But to your point about a big app...You probably don't ship that whole app as a single JS file and all screens in a single screen that you need to hydrate the whole app at once and parse all app JS at once. Code splitting is a thing and it's done out of the box in these meta frameworks like Next.js so it doesn't necessarily mean that a bigger app will just automatically make hydration worse.
The problem with this, is you have two separate systems that don't understand each other. The **client** and the **server**. As a result, you're effectively running the same code twice to "sync it up".
This means you're effectively re-executing the application and rebuilding the tree from code.
The game changer here, is the what an alternative to hydration enables, you can delay the execution of components until the user opts-in to it. Why should I as a user care about the 1 MB of carousel JS, if I haven't touched the carousel?
That is what Qwik handles for you automatically.
@@thejackshelton I do understand roughly how all of this works, but fetching such a big payload after page load would potentially result in carousel interactions not being registered, right? People are used to first page load taking a bit longer and then things being smooth. If you delay that 1MB carousel to be lazy loaded later, people might be frustrated because they are used to things working smooth after page load.
I'd say both approaches have their pros and cons, but Qwik focusing on hydration being the "only reason modern apps are bad" feels so weird. They are obsessed with hydration and you can see that in their docs and multiple blog posts they released in last two years.
I'm not against Qwik and it's cool to see people coming up with different approaches, but that extreme focus on hydration as only bad thing just feels weird to me.
@@rand0mtv660 I agree that the focus should not be on hydration, it's again what the **alternative** to hydration enables, that other frameworks cannot do without completely breaking their ecosystems.
As for things not being registered, this isn't the case. To explain from a high level:
Qwik is exactly like video streaming but with javascript. We take large pieces of code, and break them down into these things called q-chunks.
When we click on a 10 hour video from youtube, it starts playing the video, it does not bother loading the entire video before you play.
Qwik prefetches these chunks from a service worker in a separate thread, you can think of this like a buffer. As a result interactions are instant.
Delaying the execution of javascript and only executing what the user actually interacts with is key, and solves a major problem in the web space.
Please also do an Elm video
Gonzalez Charles Perez Jose Martin Maria
White Edward White Dorothy Garcia Jeffrey
Certainly looks developer friendly.
Allen Kimberly White Steven Thompson Daniel
bruh now i have to rewrtie prod again 🤦♂️
This is so clever
react wrappers to me is an L. i just cant deal with learning how to interface another layer just to do what i want. Whats worse if it doesnt do what you want it to do and have to learn how the wrapper actually calls the actual library. Id rather learn to use the library itself instead of jumping all those hoops.
Sometimes these wrappers are not even maintained by the same creator of the library so youre at their mercy.
Thomas Lisa Martinez John Rodriguez Laura
noice
Lopez Laura White Timothy Martin Joseph
Jones Scott Garcia Matthew Allen Sandra
Martinez Angela Robinson Robert Anderson Ronald
5:10 or so - "I'm going to watch the rest of this because I like you, but this seems wholly undebuggable and ultimately undoable"
Taylor Jose Williams Charles Robinson David
I really avoid this channel because this sort of thing is neither fun nor digestible but somehow the quality of presentation makes it watchable and readable. It's not smart content and feels like a regurgitation of the text and concepts floating around in the domain. There is real hardcore web technologies out there that tie heavily on telecom aspect and this frontend stuff is purely overengineering to get motion designed brochures, landing pages and consistent design. It's not supposed to be a headbreaker or require a great amount of skill to conquer.
THIS!
Okay, RIP react.
Martin Amy Walker Gary Jackson Laura
Young Brenda Moore Ruth Robinson Christopher
Harris Charles Smith Amy Walker Kenneth
Another bad news for React.
Oh no! Anyway...
Johnson Shirley Rodriguez Sandra Thomas Robert
Anderson Dorothy Lewis Jeffrey Jones Shirley
Just another random street framework who wants to get some income donations :)
Thompson Barbara Rodriguez Thomas Miller Jeffrey
Super annoying to chase one new thing after the other. It is all about more and newer. Nothing of substance
oooh early
I used to watch when you were smaller, been a while but youve gotten a lot larger since I last saw a video... and just like most brands of chips, over time you've slowly replaced the same bag with more air than chips.
Shouldnt you be working on getting more concise/informative? Efficient videos that don't waste a second, respecting your viewers time?
Stop hyping things up so much Theo, beginners look up to you.
White Barbara Hernandez Jeffrey Perez Ruth
By god do I hate React 👍👍
Another day another JS framework that changes everything
It’s fun to see what people are working on but do we really need another framework? I’d rather see the features in existing frameworks. Maybe this will inspire them to look into adding these.
We can say the same thing each time.
- Having C, do we need C++?
- Having C++ do we need Java?
- Having Javascript do we need JQuery?
- Having JQuery do we need Angular?
- Having Angular do we need React?
- Having React do we need Qwik?
Each solution solve a different problem, and you don't need a new solution either and can stay in what you use. There is people already working on those frameworks but not everyone agree on how X framework/tool solve a problem.
@@neociber24 all great points and I’m not saying not to try new things and the examples while not really relevant to each other your point still stands.
@@jollyJedi but then you're missing the point, because they are indeed trying new stuff, and they consider it to be relevant
First?
The last will be first, and the first will be last.
I'm sorry I had to drop this bomb here. I don't even know what it means 😂
first is the last second
That’s worse then angular, 🤢🤮
best ecommoerce javscrpit framework
svelte 5 for the win, in terms of syntax is a winner compared to this.
I'm noticing a recurring pattern in all GUI code: You have one state tree, and another GUI element tree. They're both highly complex, and mostly identical, but different in a some crucial ways. And you're trying to manage a two-way binding between them, which stays reliably in sync at a high frame rate, but without unnecessary re-renders.
so what you’re telling me is…Qwik needs another virtual node for that 😅
virtual dom? a dom whithin a dom?
Shout out to human centipede...
Theo, thanks for keeping us in the loop.
Looking at theos shirt gives the same satisfaction levels to my eyes as seeing someone beat the Turkish ice cream man
Click baiting on YT tech is as bad if not worse than Twitter tech.
So many tech TH-camrs doing the “Mom, read me a bedtime story” format. Find an article and read it
Regarding the tailwind 'vs' qwik complaints: There is two groups, those that care about the semantics of the output (who will dislike qwik and tailwind equally) and those who care about the semantics of the source code.
Agreed. Which is why classless PicoCSS paired with UnoCSS is just so good 🤌at least for the second group
The output of Qwik v2 is pretty clean. There's some metadata attributes on the qwik container (root), to tell if it's ssr rendered, etc. the rest looks like html and a script tag.
I feel like I’m one of like, three people, that actually likes Angular lol
Sorry to be that guy, but when "attribute" is used as a noun (like an HTML attribute), it's pronounced with the stress on the first syllable (ATT - rib - ute), not the second syllable (a - TTRIB - ute). Placing the stress on the second syllable is for when it's used as a verb.
Going from React or Angular to this might be easier, but having started on Svelte, this just seem verbose
i mean, u dont have to understand much of any of this as the framework handles everything for u, u would find that svelte upcoming runes also are similar to qwik's '$'
The purpose of semantic HTML is to provide correct and precise information to assistive technologies. It's not to make the website source more readable. Tailwind and Quick are just fine in this regard.
yeah. I both am not very interested in quick as a framework but am very interested with how you cover it here as a tech demo to better understand how code runs. great article by the qwik team!
Anyone remember XPath? A lot of this feels a bit like a re-invention of it ...
Miller Barbara Robinson Gary Rodriguez Eric
I’m most interested in qwik because it’s choosing a new path which should in theory be better. In your opinion it may not be something that needs to be changed (hydration) I believe it’s more than a syntactic sugar like svelte vs react.
Especially when it comes to distributed computing and decentralized data storage, Qwik could be a game changer
How will it be a gamechanger?Please Can you tell me more if you can.?
Robinson Deborah Jones Betty Robinson Susan
Rodriguez Elizabeth Hall Ronald Thomas Kimberly
Jackson John Brown Jose Wilson Sandra
Lewis Laura White Donald Jackson Anthony
Gonzalez Elizabeth Anderson Dorothy Hall Matthew
Garcia Thomas Young Carol Anderson Deborah
Lopez Deborah Young Matthew Martin Eric
Wilson Gary Allen Eric Thomas Deborah
angular > [...rest of the frameworks]