#qwik
#Development #Reviews
Things you forgot (or never knew) because of React · “The world which crowned React king no longer exists.” https://ilo.im/14uklm
_____
#WebDev #Frontend #Frameworks #Libraries #React #Astro #Fresh #Qwik #Preact #Solid #Svelte #Vue
#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!
https://tech.sparkfabrik.com/en/blog/qwik-and-the-power-of-loaders-and-actions/
#Qwik è probabilmente la cosa migliore capitata ai framework javascript dai tempi di Angular.
@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
#Qwik could really be the next big thing.

Been hearing about #qwik for JS. Let’s give the site a look…
Immediately mad:
• 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
• Can’t click the other ‘tabs’ to see the other benefits (doesn’t work without JavaScript even though it’s a) a pitch site whose sole purpose is to maximize delivering content to users, not be some interactive web application b) you are not showcasing the actual use case for the framework if it can’t render without JS but you’re using it to deliver that content… further in the case of web apps, the extra loading time isn’t as much an issue as users expect a load time & expect to stick around a while so this hydration may be a premature optimization that adds a _lot_ of complexity)
• 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?
• Why Qwik has an entire section dedicated to the ‘numbers’ on how a fast site leads to good things, but you can build static sites that are way faster without all of this complicated tooling. The focus of these numbers is on web pages / multi-page app candidates, not SPAs or PWAs which is where a heavy framework like this should be preferred to just using a static site generator or a allow refreshes with a multi-page app. A lot of these sites eliminating all of their analytics and JavaScript would probably see better numbers and responsiveness as well.
Kinda neat
• The ‘resumability’ problem
• Ship less JavaScript is a pretty good motto, especially for a framework to admit
🐳 #Docker + #QWIK Boilerplate + #Nginx + #NodeJS 18.16 / #ExpressJS + #PostgreSQL 15 🐳
A complete stack for running a builded QWIK App into Docker containers using docker compose tool.
👇👇👇👇👇👇👇👇👇
https://github.com/Inushin/dockerQwikNginxNodePostgreSQL
🚀 Reading tip for German-speaking JavaScript developers: With Qwik 1.0, a new open-source full-stack web framework from Builder.io is available that enables fast interactivity through JavaScript streaming.
Qwik’s goal is to keep initial JS costs constant. It also offers built-in features such as lazy execution and data fetching.
Read more here: https://www.heise.de/news/Full-Stack-Framework-Qwik-1-0-bringt-neuen-Ansatz-fuer-schnellere-Interaktivitaet-8985672.html
#Qwik #WebFramework #JavaScript #JavaScriptStreaming #OpenSource
Translated with www.DeepL.com/Translator (free version)
#qwik 1.0 is here! https://www.builder.io/blog/qwik-v1 you can listen to The Web Platform Podcast chat with Misko about this new approach. https://thewebplatformpodcast.com/207-qwik
☕️ 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
#Qwik looks pretty cool 👌👌
#qwik has made it to RC! huge congrats to the team. https://www.builder.io/blog/qwik-rc-milestone
Juho came to Turku today to share with us what #Qwik is and what it's bringing to the frontend development.

Miško Hevery tells @kball about a pretty bonkers Qwik demo he built 👇
😭 je craque, je ne supporte plus l'écosystème javascript, où on peut perdre une après midi à se débattre dans des problématiques de tooling (bundlers, rollup, cjs, ejs, modules, gnagnagnagna...) au lieu d'être productif dans son code..😭
au cas où, si quelqu'un sait comment utiliser #postgresql avec pour un endpoint #Qwik (ça marche avec mysql2, mais pas node-postgres because of rollup..)
@ro Good question.
#qwik & #solidjs & #svelte are able to do the stuff that they do, including resumeablilty and fine grained reactivity because they take the code and compile it into an optimised format.
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...
#Development #Trends
The evolution of Signals in JavaScript · What’s behind the recent frontend buzz around the term “Signals”? https://ilo.im/11dpft
_____
#Development #Trends
#WebDevelopment #WebDev #Frontend #Framework #Library #JavaScript #Signals #Angular #Qwik #React #Solid #Svelte #Vue
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
In Qwik you can create server functions anywhere in your code.
Probably because they are doing module extractions.
https://twitter.com/manucorporat/status/1628758078572175360
@jlarky this is interesting.
🚀 I published v0.1.1 of https://npm.im/qwik-emoji this morning!
This was my first experience working with #Qwik, and it was pretty nice. Looking forward to what the team builds.
https://www.seanmcp.com/articles/publishing-a-qwik-component/
@nathansmith yes I have looked into it, however I am really liking #qwik it has a similar paradigm, most of the same hooks as react.js, technically it should have the fastest rendering due to resumability.
Yo, there are so many modern #JavaScript frameworks and workflows!! 😅
I'm extremely fond of @preact, which makes me really excited to use #Fresh and @deno_land (especially now that #Deno supports NPM).
I'm trying my best to keep-up with all the ongoings, but I just learned about #Qwik today and I finally grokked what #Vite and #PartyTown do. 🤪
How does anyone keep all this JavaScript stuff straight? What's current, legacy, upcoming? 😅
@brad_frost What's your opinion on #Qwik?
@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.
@joelhooks I agree with you, new tech like #qwik & #solidjs stand on #reactjs shoulders, partly they are attractive as one does not need to re-learn them as most of the #syntax is same.
However reactjs was built on top of shoulders of a giant like #angular that I was working with before I started using #react.
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.
2022 JavaScript Rising Stars · Trending projects in the JavaScript eco-system over the last 12 months https://ilo.im/1089pg
_____
#development #trends
#webdevelopment #webdev #JavaScript #JS #ecosystem #framework #library #frontend #backend #BuildTool #CSSinJavascript #StaticSite #StateManagement #Testing #GraphQL #Angular #Qwik #React #Solid #Svelte #Vue
@jlarky what are your impressions of #svelteKit .
I know you are a fan of #astro however #sveltekit hit version 1, so it is more production ready than all the other frameworks.
#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 guess I have been spoiled by reactjs in the sense it does allow all javascript vanilla patterns; developer productivity comes at the price of app performance.
I understand the newer frameworks do provide alot of benefits but some patterns have to be avoided.
@ro my early impressions are if you stick to #qwik conventions it will be easier then other frameworks.
For example it has its own meta framework like #nextjs called #qwikCity .
Also it encourages smaller units of work style functions, as all functions marked are imported via lazy loading after first render.
Also if you know #reactjs & #nextjs you already know around 70% of qwik.
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.
@trevdev I think #qwik is the most feasible from a developer productivity point of view.
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.
:nodejs: :typescript:
#primeagen has a live #twich session about #qwik with its creator.
There is comparison with #nextjs & a bit about #solidjs as well.
Its a long but very informative video as primeagen asks all the right questions.
:nodejs: :typescript:
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.
@brandont @benjaminhollon if I do it I would probably do it in a new front-end framework like #qwik although it is early days while I am learning it.
What are your thoughts? 😀
@lexLohr totally agree with you.
both #qwik & #solidjs build on top of jsx, hooks, but simplifying where other frameworks have #footguns with #reactivity & reducing initial js loads.
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.