RIP React? New Qwik Release Is REALLY Interesting 

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

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.

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!

virtual dom? a dom whithin a dom?

Shout out to human centipede...

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

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.

Completely agree! Not a problem in 2.0 :)

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

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.

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.

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

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 '$'

How will it be a gamechanger?Please Can you tell me more if you can.?

THIS!

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

I worked on the Qwik Astro integration, if Astro allows you to do a rust backend it should be possible. 🤔

That's the point of Qwik. The framework handles this for you, and so you have a good developer experience and a fast app without having to spend time optimizing.

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.