Skip to main content

Qwik

Why use it?

  • no hydration
    • means far less JS needs to be downloaded before TTI
  • lazy loaded
    • to the extreme
    • major difference with other frameworks is how granular the lazy loading can be (because there is no virtual DOM to reconcile and hydrate)
    • $
      • magic = moves closure to a separate file and replaces it with a dynamic import
      • restriction is function needs to receive everything it needs (not rely on variables outside the closure)
      • any function with a $ will be run asynchronously
  • resumability
    • serializes information known during server build
    • other frameworks don’t rediscover that info on the client until the entire app is downloaded and hydrated
    • qwik can recover that info without downloading the whole framework and loading it
    • avoids the need to execute the whole app to know the app’s state
    • some constraints on what values can be serialized
  • Qwik City
    • single file component
    • loader
    • actions
    • server and client bundles will automatically be kept separate
  • Challenges when adopting Qwik
    • people write non-performant code idiomatic to other frameworks
      • with Qwik, you can offload a lot more to the server
      • eg registering an event listener
      • have unlearn those habits and adopt the new mental model
    • listeners only download their callbacks when event occurs
    • don’t have to register and destroy listeners on the client
      • a huge category of perf issues that has been solved
  • Resources
    • Website
    • Discord
    • REPL
  • Massive user experience difference
    • As app gets larger, loading speed does not increase unless most frameworks
    • Because amount that has to be loaded at first stays constant
    • So in addition to a DX improvement, this framework has a VERY different UX for large apps

Links:

Resumability

Inbox