#Qwik ha le potenzialità per diventare la prima scelta per molti progetti frontend, e se non lo avete ancora scoperto vi consiglio di dargli un'occhiata perché ha dei vantaggi competitivi niente male.
Ho pensato di condividere il mio "primo contatto" in questo post sul tech blog di @sparkfabrik, se vi va dategli un occhio e fatemi sapere che ne pensate!
@fogoplayer This is a more nuanced look at reactivity in different frameworks 🔗 https://www.builder.io/blog/reactivity-across-frameworks
I’ve been looking for this link for ages! I saw Miško Hevery give this blogpost as a talk live a few months ago and I think it’s very well put together
Been hearing about #qwik for JS. Let’s give the site a look…
• I’m still skeptical about “the edge” for most web apps as this usually
• Social media in header options are _all_ proprietary
• Theming is treated as binary (light | dark)
• JSX is awful & base example shows it
• Scroll down to get a “Loading...” because it doesn’t work without JS (and can’t even be bothered to give the correct ellipsis symbol in “…”) & it’s a _massive_ white block to get to the footer.
• Delivers useless element class names that will make it difficult for scraping, or providing users with the tools they need to make a site better or more accessible (think userScripts & userStyles).
• Community page doesn’t expand to any open source, decentralized, or private options: just expanded to more horrible social media. No self-hosted forums (like Discourse), no decentralized chat (like IRC, XMPP MUC, Matrix Space).
Temporarily enable JS for the domain…
• Batteries included talks about the big cabal of edge compute options it is “optimized” for which explains some things but it’s presupposing that you want or need “the edge”
• The marketing with YouTube-thumbnail-inspired images is so heavy-handed it hurts.
• Seems one of the main things it’s trying to sell is Builder.io
• Oddity: docs page uses giant emoji, but from different sets … why?
• The ‘resumability’ problem
Qwik’s goal is to keep initial JS costs constant. It also offers built-in features such as lazy execution and data fetching.
☕️ Wake up and smell the coffee because the next episode of The Code and Coffee Show is just around the corner!
Get ready to dive into the enchanting realm of #Qwik with Giorgio Boa and yours truly.
Discover the ins and outs of Qwik and learn how to kickstart your journey with it. Don't forget to mark your calendars and join us: https://www.youtube.com/watch?v=-jkfp8zf9OM
@ro Good question.
React.js does everything at runtime, they say they are working on a compiler but it is atleast a year away.
I think next.js is the same...
Is useSignal() the Future of Web Frameworks? It sure is the current trend, but I think this should be a compiler optimization. #React #Solid #Qwik https://www.builder.io/blog/usesignal-is-the-future-of-web-frameworks
@jankaifer @brianleroux I understand that but that is exactly what I am not a fan of, I dont want to be restricted by differentiating between server and client components & what can be done in one and not the other.
I also dont like the way next.js does hydration, I prefer #qwik frameworks approach of resumeability.
I like #reactjs I make money professionally because of it.
So I mean no disrespect & hopefully for future if we learn new tech it should be an exciting experience not a religious one.
#qwik is good but latest version has alot of changes; even though for the better, this just shows its not ready yet.
They have dropped 4 hooks for 1, which is a good decision & qwikCity will have server functions, I am assuming they took inspiration from #nextJs 13, lol 😄
@lexLohr thank you for the feedback.
Vanilla closures are also a challenge in #qwik
If using closures, one has to make sure qwik's own tracked state variables are in closure, otherwise it doesnt work.
I understand the newer frameworks do provide alot of benefits but some patterns have to be avoided.
Also it encourages smaller units of work style functions, as all functions marked are imported via lazy loading after first render.
May I ask what framework or library you are most used to for front-end?
@ro I am also evaluating #qwik .
Even though technically it is not production ready if you look at its #showcase alot of well developed ideas are there.
I think one can still use it for small to medium projects.
#astro is impressive as it is versitile & allows one to bring their own framework / library.
So if you already like one of the popular frameworks, lets say #react you can still use it inside #astro and get better performance than #nextjs .
I am leaning more towards #qwik though.
It essentially sends the same minimal js for a smaller app vs bigger; essentially loader/optimiser with symbols.
Everything else is lazy loaded via web workers in the background.
Also people like react, so essentially they can write same style code with SEO optimisations.
Its a long but very informative video as primeagen asks all the right questions.
After constructive discussions here & my own research it seems like the people (most of my fellow technologists here 😀) think #svelte #astro & #solidjs are better candidates then #qwik .
So what is the next logical step, I learn more about #astro & #solidjs before moving forward.
I ❤️ that the current progress in the frontend world is achieved by evolution rather than revolution, even though the marketing claims might suggest otherwise.
Solutions like #Qwik, #SolidStart, #Fresh, #Marko6 are based on seemingly iterative small improvements of previous concepts – to great effect. Still, these established concepts served as a blueprint for immense improvements.
I have been working with #react since it was new.
I however feel it is time to move on due to #footguns #hydration & the divide between server & client components.
Also two major players are steering it in their direction namely #remix & #nextjs (vercel).
Which framework would you choose, please provide reasons in response.