9 ms·

Qwik: No hydration, auto lazy-loading, edge-optimized, and fun

141 points by lobo_tuerto 4y ago

suprfsat 4y ago
it's a modern version of asp.net web forms.
- skyde 4y ago
  this is my understanding as well! but i might be wrong. Asp.net webform where not really interactive. Any change to the UI require reloading the page.
  - mpeg 4y ago
    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.
    - serbrech 4y ago
      ASPnet webforms kept the state serialized in a hidden field in on the page
      - mpeg 4y ago
        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.
- christophilus 4y ago
  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.
ipsum2 4y ago
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.
- dvrp 4y ago
  Did you see this? https://qwik.builder.io/docs/faq/#can-i-enjoy-the-rich-react-ecosystem https://qwik.builder.io/docs/faq/#can-i-enjoy-the-rich-react...
  - ipsum2 4y ago
    No, that's good news! The documentation is a little sparse though.. will it still do lazy loading with the react components?
fny 4y ago
Has anyone found a link to a therapist working app that showcases the performance in the docs? I looked around but haven't found anything.
dvrp 4y ago
here we go again
nextaccountic 4y ago
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?
- simonhorlick 4y ago
  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.
  - kaleidawave 4y ago
    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...
    - meenie 4y ago
      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.
      - kaleidawave 4y ago
yodon 4y ago
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. [0]https://qwik.builder.io/docs/overview/ https://qwik.builder.io/docs/overview/
- azangru 4y ago
  > 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".
  - yodon 4y ago
    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.
danbulant 4y ago
This seems to work the same svelte kit does? Except it's react and not svelte.
- kevinak 4y ago
  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.
  - akvadrako 4y ago
    I can't get it from that explaination. Does it work like elder.js?
    - mpeg 4y ago
      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.
      - aatd86 4y ago
        What I do not understand is why is hydration claimed to be such a concern if it only happens on initial page load and then the client-side takes over? In Amazon famous case, the 100ms delay was because it was an MPA: each page change was a page load. In that case I'd understand.
azangru 4y ago
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.
omniscient_oce 4y ago
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?
- satvikchoudhary 4y ago
  I think your understanding of hydration is correct. The 100ms -> 1% line comes from amazon. https://dexter.agency/blog/100ms-faster-1-more-revenue-how-speed-affects-your-revenue/ https://dexter.agency/blog/100ms-faster-1-more-revenue-how-s... I feel time-to-interactive is more important than just the page load as a user, so I can see why it would matter. There is a trick in remix which improves user experience somewhat. https://twitter.com/ryanflorence/status/1547959632663961602?s=20&t=PKJPaA6NDfxnWar4W5Crig https://twitter.com/ryanflorence/status/1547959632663961602?... Qwik also saves on network bandwidth. The benfits of qwik will be felt most on slow network connections and old mobile devices. Feel free to correct me if I got something wrong.
- christophilus 4y ago
  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.
  - aatd86 4y ago
    That might not be hydration but third party script delaying the main js file perhaps? Hydration shouldn't take that long depending on the frameworks. Frameworks that rerender such as react are probably more problematic.
Lt_Riza_Hawkeye 4y ago
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).
- mpeg 4y ago
  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.
manucorporat 4y ago
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 https://www.youtube.com/watch?v=BxGbnLb5i9Q A lot good content here too: https://qwik.builder.io/media/ https://qwik.builder.io/media/
- kolme 4y ago
  ¡Hola, tocayo! Mind if I ask you a Question? I've seen a talk of yours about Stencil and how it was compatible with other things because of Web-Components. How is the compatibility of qwik with Web-Components? Cheers.
  - dogoku 4y ago
    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?
Existenceblinks 4y ago
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).
- christophilus 4y ago
  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.
  - Existenceblinks 4y ago
    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.
    - throwaway234229 4y ago
      They mean React à la functional components, hooks, and JSX. The point is qwik enables this style of development without the runtime punishment.
      - Existenceblinks 4y ago
        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.
serbrech 4y ago
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.
- christophilus 4y ago
  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.
  - austinjp 4y ago
    If I'm in a meeting where someone suggests using opaque technical language to deliberately reduce reach... I'm voting that down :) Use simple language that everyone understands. You might gain some converts.
woile 4y ago
I recently learned about qwik thanks to fireship's 3 min video: https://www.youtube.com/watch?v=x2eF3YLiNhY https://www.youtube.com/watch?v=x2eF3YLiNhY 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.
- kanwisher 4y ago
  Love this guy, saves so much time. Gives you a quick intro to a framework so you know why I should care about this new framework
amelius 4y ago
What is hydration in this context?
- creamyhorror 4y ago
  Attaching JS (hooks) to DOM nodes, making those nodes interactive instead of static elements.
- Existenceblinks 4y ago
  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.
RamblingCTO 4y ago
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?
bricss 4y ago
Server-side rendering aka SSR is back bae
yoyohello13 4y ago
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?
dirkg 4y ago
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.
garyrob 4y ago
For me, the examples simply don't work in Safari, such as at https://qwik.builder.io/examples/introduction/hello-world/ https://qwik.builder.io/examples/introduction/hello-world/. All I get is the spinner spinning forever.

141 points by lobo_tuerto 4y ago

suprfsat 4y ago

it's a modern version of asp.net web forms.

skyde 4y ago
this is my understanding as well! but i might be wrong. Asp.net webform where not really interactive. Any change to the UI require reloading the page.
- mpeg 4y ago
  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.
  - serbrech 4y ago
    ASPnet webforms kept the state serialized in a hidden field in on the page
    - mpeg 4y ago
      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.
christophilus 4y ago
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.

ipsum2 4y ago

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.

dvrp 4y ago
Did you see this? https://qwik.builder.io/docs/faq/#can-i-enjoy-the-rich-react-ecosystem https://qwik.builder.io/docs/faq/#can-i-enjoy-the-rich-react...
- ipsum2 4y ago
  No, that's good news! The documentation is a little sparse though.. will it still do lazy loading with the react components?

fny 4y ago

Has anyone found a link to a therapist working app that showcases the performance in the docs? I looked around but haven't found anything.

dvrp 4y ago

here we go again

nextaccountic 4y ago

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?

simonhorlick 4y ago
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.
- kaleidawave 4y ago
  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...
  - meenie 4y ago
    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.
    - kaleidawave 4y ago

yodon 4y ago

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. [0]https://qwik.builder.io/docs/overview/ https://qwik.builder.io/docs/overview/

azangru 4y ago
> 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".
- yodon 4y ago
  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.

danbulant 4y ago

This seems to work the same svelte kit does? Except it's react and not svelte.

kevinak 4y ago
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.
- akvadrako 4y ago
  I can't get it from that explaination. Does it work like elder.js?
  - mpeg 4y ago
    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.
    - aatd86 4y ago
      What I do not understand is why is hydration claimed to be such a concern if it only happens on initial page load and then the client-side takes over? In Amazon famous case, the 100ms delay was because it was an MPA: each page change was a page load. In that case I'd understand.

azangru 4y ago

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.

omniscient_oce 4y ago

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?

satvikchoudhary 4y ago
I think your understanding of hydration is correct. The 100ms -> 1% line comes from amazon. https://dexter.agency/blog/100ms-faster-1-more-revenue-how-speed-affects-your-revenue/ https://dexter.agency/blog/100ms-faster-1-more-revenue-how-s... I feel time-to-interactive is more important than just the page load as a user, so I can see why it would matter. There is a trick in remix which improves user experience somewhat. https://twitter.com/ryanflorence/status/1547959632663961602?s=20&t=PKJPaA6NDfxnWar4W5Crig https://twitter.com/ryanflorence/status/1547959632663961602?... Qwik also saves on network bandwidth. The benfits of qwik will be felt most on slow network connections and old mobile devices. Feel free to correct me if I got something wrong.
christophilus 4y ago
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.
- aatd86 4y ago
  That might not be hydration but third party script delaying the main js file perhaps? Hydration shouldn't take that long depending on the frameworks. Frameworks that rerender such as react are probably more problematic.

Lt_Riza_Hawkeye 4y ago

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).

mpeg 4y ago
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.

manucorporat 4y ago

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 https://www.youtube.com/watch?v=BxGbnLb5i9Q A lot good content here too: https://qwik.builder.io/media/ https://qwik.builder.io/media/

kolme 4y ago
¡Hola, tocayo! Mind if I ask you a Question? I've seen a talk of yours about Stencil and how it was compatible with other things because of Web-Components. How is the compatibility of qwik with Web-Components? Cheers.
- dogoku 4y ago
  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?

Existenceblinks 4y ago

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).

christophilus 4y ago
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.
- Existenceblinks 4y ago
  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.
  - throwaway234229 4y ago
    They mean React à la functional components, hooks, and JSX. The point is qwik enables this style of development without the runtime punishment.
    - Existenceblinks 4y ago
      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.

serbrech 4y ago

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.

christophilus 4y ago
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.
- austinjp 4y ago
  If I'm in a meeting where someone suggests using opaque technical language to deliberately reduce reach... I'm voting that down :) Use simple language that everyone understands. You might gain some converts.

woile 4y ago

I recently learned about qwik thanks to fireship's 3 min video: https://www.youtube.com/watch?v=x2eF3YLiNhY https://www.youtube.com/watch?v=x2eF3YLiNhY 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.

kanwisher 4y ago
Love this guy, saves so much time. Gives you a quick intro to a framework so you know why I should care about this new framework

amelius 4y ago

What is hydration in this context?

creamyhorror 4y ago
Attaching JS (hooks) to DOM nodes, making those nodes interactive instead of static elements.
Existenceblinks 4y ago
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.

RamblingCTO 4y ago

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?

bricss 4y ago

Server-side rendering aka SSR is back bae

yoyohello13 4y ago

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?

dirkg 4y ago

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.

garyrob 4y ago

For me, the examples simply don't work in Safari, such as at https://qwik.builder.io/examples/introduction/hello-world/ https://qwik.builder.io/examples/introduction/hello-world/. All I get is the spinner spinning forever.