1 of 52

Qwik

Instant-on, resumable WebApps

2 of 52

I am Miško Hevery

CTO at Builder.io

About me

  • Visual CMS�
  • Qwik�
  • AngularJS and Angular�
  • Zone.js�
  • Clean code talks�
  • cocreated Karma�

​

Confidential

3 of 52

  1. JavaScript is THE problem
  2. It is not your fault
  3. There is a solution

4 of 52

5 of 52

But… is this really a problem?

https://web.dev/tags/case-study/

6 of 52

7 of 52

Existing correlation between:

​

  • Sites becoming more interactive
  • Amount of JS

8 of 52

Existing correlation between:

​

  • Sites becoming more interactive
  • Amount of JS

​

And…

​

  • It’s a systemic problem
  • It’s not about going back 10 years ago

​

9 of 52

https://www.builder.io/c/performance-insights

10 of 52

The bottleneck is JS

11 of 52

Big O() notation for frameworks

Resumable

12 of 52

Current trend is linear because

current frameworks are O(n)

​

Amount of JS growing as sites require more functionality

13 of 52

What if frameworks were O(1)?

​

Correlation broken between functionality and amount of JS

14 of 52

Past

Current

Future

Rendering and interactivity separated

Render and interactivity united into a single framework.

Rendering done at the server by:

Interactivity:

Very performant

Slow development, error prone, duplicated logic…

Unified model, fast development, scales in complexity

Uses hydration, to enable interactivity. App runs twice.

Unified model, fast development, scales in complexity

Uses resumability, performance scales well. O(1)

App runs twice in server and client using the same tech:

App runs once, client only executes minimal bites of interactivity.

Render and interactivity united into a single framework.

DX ⬆️⬆️

PERF ⬆️⬆️

15 of 52

Resumable

1

Progressive

2

16 of 52

17 of 52

Virtual Machines�are awesome

18 of 52

Resumability�(just like VMs)

HTML

19 of 52

Hydration = replay app

Rendering runs twice. All logic needs to be downloaded.

Same

20 of 52

Resumability = resume app

Leverage what already ran in the server.

​

No initialization code, rendering, diffing, setting up listeners needs to run in the client.

Server serializes app state then it resumes.

21 of 52

Resumable

1

Progressive

2

22 of 52

Progressiveness

​

23 of 52

Resumable

Replayable

24 of 52

  • JS downloaded
  • Warm JIT
  • DOM update�(vs user latency)
  • Ignore TTI & TBT

Runtime Perf

25 of 52

Startup Perf

Mitosis

26 of 52

27 of 52

Demo time

28 of 52

CAP theorem

​

Consistency

Availability

Partition Tolerance

29 of 52

CAP theorem

​

frontend

​

Capabilities

API

Startup�Performance

f

  • 100/100 lighthouse
  • Instant time to interactive
  • Fast in slow devices
  • Fast in slow networks
  • SEO
  • Functionality
  • Tons of interactivity
  • User customizations
  • A/B testing
  • Metrics
  • Animations

​

  • DX
  • Easy to build
  • Low time to to market
  • Low lock-in
  • Leverage team expertise
  • Fast iteration
  • All-hands: Marketing / designers

30 of 52

Frontend new paradigm

Capabilities

API

f

  • 100/100 lighthouse
  • Instant time to interactive
  • Fast in slow devices
  • Fast in slow networks
  • SEO
  • Functionality
  • Tons of interactivity
  • User customizations
  • A/B testing
  • Metrics
  • Animations

​

  • DX
  • Easy to build
  • Microfrontends
  • Low time to to market
  • Low lock-in
  • Leverage team expertise
  • Fast iteration
  • All-hands: Marketing / designers

Startup�Performance

31 of 52

  • Drag and drop development
  • A/B testing
  • User personalization
  • Using your stack (React / Vue…)
  • Edge optimized
  • First-party code
  • Constant scalability
  • HTML-first, zero JS
  • Highly interactive
  • MPA & SPA
  • Third-party code
  • Analytics and third party code
  • Execute in web worker
  • Write code once generate idoimatic code which runs on any framework
  • Transpiler

32 of 52

Thank you

Follow me

@mhevery

https://qwik.builder.io

npm init qwik@latest

33 of 52

BACKUP�SLIDES

34 of 52

Why the world needs a new solution?

35 of 52

36 of 52

Who is responsible for slow sites?

​

​

​

Developers?

Tools?

Frameworks?

37 of 52

Framework�Mental Model

Tools

Developers

38 of 52

39 of 52

  • Developer should write component based applications�
  • How do we make such code resumable?

Component-based development-model

40 of 52

Resumable Framework

code

  • Don't unnecessarily re-execute code on client.�
  • Compile time transformation.�
  • Sufficient information in HTML to "reason" about application.

41 of 52

42 of 52

43 of 52

Why are we building Qwik?

44 of 52

45 of 52

Web Application

�startup performance

46 of 52

47 of 52

Big O() notation

48 of 52

Let's talk about Frameworks

49 of 52

Replayable�(hydration)��vs��Resumable

50 of 52

O(1) frameworks are not new! but…

​

Wiz is an internal framework at Google:

​

  • Powers Google Search, Gmail, Google Photos…
  • Around for 8 years!
  • Deeply coupled with a backend in Java, business logic may need to be implemented twice, JS and Java
  • Lots of manual DOM modifications
  • Slow development

​

Amazon can not use existing frameworks for its main site

​

  • Too slow, does not scale well
  • Lots of custom code, allows them to deliver fast website that scale in functionality
  • Lots of manual dom modifications
  • Slow development

​

51 of 52

All Frameworks�claim that they are�FAST

Runtime Perf

Startup�Perf

52 of 52

Server-side

cake baking

analogy

​

“baking a cake in a datacenter”

  1. Server bakes a cake
  2. Server sends a picture of the cake + cooking instructions
  3. Client gets the picture + instructions
  4. Client goes buy all ingredients
  5. Client bakes the cake again
  6. User eats the cake