Qwik maintainer here, lots of good feedback for our landing page! we already updating much of the content there. Please check this 20min if you wanna understand of the fundamental building block that makes this framework so different: https://www.youtube.com/watch?v=BxGbnLb5i9Q
I am also interested in hearing your opinion on this, especially since you are one of the creators of Stencil.
We jumped into stencil with the idea that web components are the future and that we'd be able to build once and use across multiple frameworks. The latter has been true, but challenging (mainly due to react's quirks) but the former is what worries me.
I can see this trend of moving away of SPA and into highly optimized SSR techniques, like Qwik's resumability, but they contradict the "cross-framework", "use the platform" nature of web components.
For example, is there any way for the Qwik compiler to know if a 3rd party custom-element is interactive and determine when or if it needs to send down the custom element definition?
The tech looks great but the landing page is a poster child for reminding engineers that you are not your customer, even when your product is designed to be used by other engineers.
The first full sentence of the first full paragraph on the landing page is "Qwik does not do hydration because it is resumable."
The fraction of people looking for a "zero hydration resumable web framework" is at best minuscule compared to the number of people looking to make their website load faster or looking for ways to convert a higher fraction of visitors into customers.
Even on HN, people adopt products because of the benefits, not because of the hard things you did. Zero hydration is not a benefit - it's a hard thing you did that makes the real benefits possible. Start with the benefits. Understanding the benefits makes people want to know more, including the secret sauce, like zero hydration, that makes the benefits possible.
This page [0] would make a better landing page - it makes a much more readable case for what Qwik is and why it's important.
> The fraction of people looking for a "zero hydration front end web framework" is at best minuscule compared to the number of people looking to make their website load faster or looking for ways to convert a higher fraction of visitors into customers.
It probably means that their target audience is people who understand these words. Probably web developers disenchanted with the state of today's web frontend, and looking for informed decisions in assessing different options.
As for ways to make their website faster, almost every web framework will boast of that. Gatsby (for crying out loud) will say it's "the fastest".
This announcement is a big deal. It's an extremely disruptive new project from an extremely experienced team. It's also an announcement that has driven a tiny fraction of the discussion one would expect a project of this importance built by a team of this experience to drive on HN.
Hopefully things pick up, but the past six hour's minimal response to this posting (and mostly similar or weaker responses to previous postings about Qwik here) is arguably a powerful measure of the landing page and the tag line for the landing page failing to do their job.
Bear in mind this is a beta product, it's being actively developed (e.g. signals like in solidjs are coming soon, which is a pretty major feature) and the API is probably going to change quite a bit in the following months.
The people that want to "speed up their site" are not the target audience at this point, it's developers who know what hydration and resumability are.
Very few web developers are "keeping up-to-date" that quickly. I've been aware of it for a while, but the vast majority of devs are not aware of tools until they hit mass adoption.
This feels like a good hook to me. Imagine how many executives and team leaders have heard “hydration” as an excuse for why a particular feature is difficult/late/complicated.
Bypass hydration, problems go away. It doesn’t matter what the solution is.
Plus, giving the usually-non-techy manager a good buzzword (which, let’s be fair, “resumable” is because it is a real programming term that is not well-defined and could somehow play a role in the design of an alternative to hydration) gives… uh, what was I talking about?
Plus, giving the manager a good buzzword that they can drop in meetings and catch the others participants unaware makes them feel powerful, and they will mention Qwik as part of that buzzword-droppage.
Is this a joke? I’m a senior PM at one of the “bigger” modern software companies they everyone loves to hate and I’ve literally never heard anyone talk about issues with “hydration”.
I’ve heard plenty about inefficient rendering of SSR react components, but literally never heard anyone say “we have an issue because of hydration speed etc”.
I don’t entirely agree with the original comment too but hydration has always been an issue when TTI is discussed.
Aside from the inefficient rendering of SSR due to data aggregating data, another inefficiency here is the need to re-render them again client side all that same JavaScript and json server side.
React tries to solve this issue with its concurrent mode, and streaming ssr, and server components.
I argue hydration is near to the core problem that many of today’s popular tools like graphql relay and react’s concurrent mode are trying to solve. Or Remix, Marko, Nextjs’s layout RFC. Each tool solves the problem slightly differently. Some try to make sure all data are loaded in parallel as much as possible so that hydration doesn’t cause a waterfall of requests. Others lazy load islands of JavaScript.
I had to scroll down to the bottom to understand what Qwik was, because it suddenly compares it with react, and I know what react is.
“Framework reimagined for the edge”
that does not tell me anything about what Qwik is. It’s not even a proper sentence, is it? A framework for what? Is it software? A methodology? Some device? No clue.
I understand the sentence. My guess is this page is targeting people who understand and need what it is selling. It’s probably not ready for mainstream, so maybe that’s why they use that language? Just a bunch.
I don't quite understand the "Every 100ms faster → 1% more conversions" tag line (in the context of how Qwik improves over competitors)
AFAIK Qwik would have a similar initial load time to other server-side rendered frameworks where all you send across the wire first is the HTML and CSS to render that particular page. That's the initial page load.
From there it loads the JS which then hydrates data and turns it into a functioning React app. So what Qwik claims to improve over other solutions is the time-to-interactive metric, rather than the initial page load. Is this a correct assessment?
If so, then the "100ms -> 1% more conversions" buy line does not seem to really follow on from the actual improvements of Qwik over other methods. Anyone understand this more than me?
I’ll never use Citi Bank intentionally due to what appears to be hydration. Every. Single. Time. I log in to pay my Costco card, I click the login form to start autofill, and when I’m almost ready to submit, the entire page redraws and I have to start over.
Time to interactive matters. At least in this sample size of 1, I will choose a competitor, all else being equal.
Reading through the docs. It's amusing and a bit disorienting to see a combination of React syntactic idioms (JSX, things starting with "use") and RxJS idioms (the Finnish notation, in which reactive things end in a dollar sign) — but without either React or RxJS.
This looks really good, it checks all the requirements I need for a project. Previously I looked into NextJS and Remix, but found them lacking. The only pet peeve, is that it looks like its 99% react, (JSX, functional components, hooks, etc) but isn't, making the entire ecosystem built around React incompatible. Really wish they could've made React work for them instead.
It summarizes quite well the capabilities of this framework. The landing didn't tell me much even after watching the video. I think it's promising spite of some angular slang leaking, looking at you `$`!
I'm considering Qwik for a personal project but I'm also waiting for nextjs conf to see if there's something interesting there, the positive of nextjs is that it works good enough and it's well established already.
I wish there was a mode that gave me everything except lazy load.
I like the idea, though I do fear the level of complexity (while necessary for the problems it's trying to solve) will further push away non-web developers from the web space.
But my concern is that if I'm on spotty wifi, and I click a button or scroll the page, the actual behaviors of that button or the components scrolling into view may not function for a solid 5-10 seconds while my phone attempts to establish a connection. I love that the framework's demos make it really easy to see what's going on - for example, under the "Simple useWatch()" demo, you can see that the JS file that actually updates the page when the "+" button is clicked, does not get loaded from the server until the first time you click the button. Similarly with the "Below the fold Clock" button, that clock will be rendered correctly for some specific time (default to 10:20:30 in the example code) when you initially scroll down, but won't actually update to the current time until a network connection has been established, javascript downloaded, parsed, and executed - none of which kicks off until you scroll the clock into view, meaning you may be staring at a non-functional clock for 1-5 seconds until it snaps into reality.
It seems to me that there would be no downside to having these JS files preloaded in the background after the initial page load finishes. Curious why they went with the completely lazy loading strategy.
As an aside, it seems these JS files are loaded from a service worker. I have no idea why that would be remotely necessary, but it prevents me from playing around with this idea using the chrome devtools, as the service worker doesn't seem to be subjected to the network tab's "ignore cache" or internet throttling simulation (for example, returning the .js file in 2ms despite throttling being set to simulate a network latency of 300ms).
You can actually customise the prefetching strategy, and in fact the default qwik strategy on the latest version will prefetch visible listeners. You could change it to prefetch every listener on the page.
I think this landing page could use more "why" instead of "what". Why do I need no hydration? Why do I want to remove 99% of javascript from the main thread? I only rarely use frontend stuff, but when I do, I like to use sveltekit. Why would I want to use qwik?
What do you mean by no hydration? How does the client-side code picks up state from the initial render? (does Qwik apps load faster due to not needing hydration?)
Also, it talks about reactivity. Does it means it has no vdom? Is it related for no need for hydration?
Resumability is still a kind of hydration, I suppose, but it's so much more efficient that it makes sense to separate it from hydration and just say it's "no hydration" same as some frameworks advertise "0kb js" when what they mean is just a kind of progressive enhancement that still includes js.
There is no vdom on Qwik, it is kind of a requirement for fast hydration / resumability to not have a vdom – otherwise there is only so much optimisation you can do when you need to convert all your server-rendered markup into a vdom representation.
My bad, you’re right it seems they’re currently using a vdom; I suppose this is something they’re looking to get rid of before 1.0 since I’ve seen they’re implementing signals for reactive updates (like solid does)
Relationships between components and the app state are serialised along with the html. A small (~1kb) library is used to lazy load javascript as the user starts interacting. The key is that it's immediately usable, you don't require a client side re-render before any of the buttons work, for example. This means you can get great PageSpeed scores really easily and the apps feel super responsive.
I have no affiliation with Qwik, but I did try it out on a small project yesterday to see how it works. I'm really impressed so far.
It is true that a button's click event can fire before a client re-render. *However* if that event changes state it does have to do a initial VDOM render to make a first frame before a second one to work how to change the actual DOM and the UI. and although that click event does run it needs to be redirected to the actual event handler. That redirect needs to do downloading, parsing and hydration. So "immediately usable" and "super responsive" are a stretch here...
There is a service worker that will prefetch all of the event handlers currently in view. So when the person clicks on the button, the browser will fetch the JS, but the service work short circuits that request and returns the JS instantly. They have plans to make the prefetching even smarter by gathering information on which chunks are most used and prefetch those first.
Ah I didn't realise it did that? The homepage still makes several references to lazily downloading JS?
Eagerly downloading JS is something every framework does though and many only download for the current view through code splitting for the current page. It doesn't fix the later two problems..., struggling to find any benefits above existing techniques here :/
How much work needs to be done to make other frameworks/components/toolsets/React libs ect compatible with Qwik? What is the extra work involved in converting a medium size project written using e.g. NextJs to Qwik? vs starting from scratch?
I think a few concrete examples like this would help. Qwik looks like it solves a big problem but I'm not sure about barrier to entry.
Also this may sound biased but I hope this is not in any way influence by Angular, given its lead dev. I find Angular has a very opinionated 'enterprisy' mindset thats very different from the React/Next/webpack approach common in JS.
As someone who is only minimally familiar with the front end space, when would it be worth while using a framework like this?
I almost always go the MPA route with a backend framework like Django and bundle my frontend stuff with Webpack. Am I missing out on anything important by not learning React/jsx?
Trying to understand what's different between this and approach non-js backend langs have been doing for 10 years. Server side rendering and resume by rendering different <head> on demands of different resource (url).
It looks like you can build an app using the convenience and rich interactions of React-like abstraction while gaining the benefits of a traditional backend approach. If so, I’m sold. I love React, but hate the SPA pitfalls and bloat.
React (react-dom) is also bloat, though. The only selling point of React is being popular which brings some benefit. I'd say we are "stuck" like having to use a legacy machine just because parts for maintenance is widely available.
JSX is fair, though ugly. Every programming language has function and they can compose even better in nicer way. Also other ways of doing state rather Hook hack which is yet another external-tool coupling dependencies.
Alternative .. way of doing `$(selector).on` which was already modular per <head> or dynamic-import in today, to achieve on-demand js.
They say the selling point is actually React style programming which is a regression IMO since it's throwing out wide range of tools available in many programming languages. Only to be able to write one language, and the language is also not great.
It does not, Qwik’s claim to fame is that it doesn’t need to hydrate the page with JavaScript, it does this not only by serialising data sent from the server but also by doing it with the “component code”. The explanation is a bit simplified but hopefully it makes sense.
The key difference is that Svelte, like React/Vue and most other frameworks is not resumable. Resumability essentially means that the client is able to take server-rendered markup and state and resume execution – this greatly reduces the overhead associated with hydration (it's kind of like a very, very efficient hydration)
The only resumable frameworks currently are Qwik and Marko6 (not released yet, beta coming Q1 2023)
Elder.js does partial hydration, which is similar to what Marko5, Astro or Fresh do. It basically means the server marks certain components (or component trees) as static, and tells the client to not hydrate them at all.
This works in reducing the amount of work the hydration has to do, and therefore making it quicker, but it doesn't do much for web applications with lots of interactivity.
I don't disagree, plus the Amazon metric has been quoted everywhere with very little context, so I wouldn't be surprised if it was not fully accurate.
However, there are teams that have a lot of insight into the needs of ecommerce that are investing heavily in reducing the hydration overhead – I imagine the reason for it is that in very dynamic sites it feels clunky that the user can't interact with the page until it has hydrated.
It is no coincidence that the only other framework besides Qwik that is being built around resumability is eBay's Marko 6
I'm not sure why you think MPA is somehow inherently slower than a SPA
For a complex application, data has to load in from the server on every page load – it can't simply be all bundled into the js.
In eBay's case, a MPA using their own custom framework makes sense, as they do async rendering (e.g. you can load and show the most important data in the page quickly, while ancilliary stuff can load afterwards) and partial hydration (so if a component doesn't require js, no js loads/runs)
The point is that hydration is more of an issue for MPAs since each time the page loads (on navigation), the html must be parsed and DOM objects need their javascript listeners attached.
For SPA, this is not the case after the initial page load event. Hydration needs to happen only once at startup.
eBay develop Marko and use it for their pages.
This talk between a Qwik team member and a Marco team member explains the differences a lot better than what i can https://www.youtube.com/watch?v=7XR5-qDhqGY
No. The serialization of state from the server to the client is the only parallel. The serialization is simpler and more efficient and doesn’t round-trip. And you get rich interactivity and a first class component model and (presumably) TypeScript.
It is nothing like ASP.NET web forms... the server is not keeping any state here between requests, it simply renders the page and serialises the state, event handlers and such in a way that the client can pick them up and resume execution.
When the client either lazy loads (on interaction) or prefetches these serialised event handlers, there is no server work at all, it's simply static js files.
Right, but the reason it was kept in a hidden field was that it would then go to the server on form submission and the server would persist it across requests, if I recall correctly – haven't done ASP.NET in more than a decade.
Either way, that was a form of hydration itself I suppose, the server would send this state value to the client and the client would hydrate its view to match the state.
A lot good content here too: https://qwik.builder.io/media/