Qwik is a JavaScript framework that uses a new rendering paradigm called resumability. It can serialize a JavaScript app into HTML, thus eliminating the need for the hydration technique used in meta-frameworks like Next.js. 

#javascript #programming #TheCodeReport

🔗 Resources

- Qwik GitHub https://github.com/BuilderIO/qwik
- Docs https://qwik.builder.io/docs/overview/
- Beta Announcement https://www.builder.io/blog/qwik-and-qwik-city-have-reached-beta
- Lazy Loading Tutorial https://youtu.be/kwUfeWe7DCw

🔥 Get More Content - Upgrade to PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- What is Qwik framework?
- Qwik vs React
- Qwik vs Angular
- Best JS frameworks of 2022
- How to make JS bundle smaller?
2024-02-04T13:31:42.445Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
7ae0b6c8-5e3e-44e2-8927-75bb4cfb817b
dab88e0b5b18f58b5c639cb74c750e34487a7ec1bf99a183f8384aff7eff279d
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
It is September 20, 2022, and you're watching the code report.
It's time to reset the counter yet again.
It's been 0 days since a new JavaScript framework has been released.
The highly anticipated quick framework, built by a dream team of developers, just hit beta yesterday.
Now before you go and change channel.
This isn't just another average 5 inch framework.
It brings an entirely new rendering paradigm to the table called resumability, which totally eliminates the need for hydration, the technique used by almost every meta framework today to make server rendered websites fully interactive.
To understand what makes Quic special, we first need to understand the problem the current generation of frameworks.
The key to a perfect Lighthouse performance score is to use less JavaScript.
Google did some science and found that making a website 20% faster results in 10% more conversions.
If your website makes $1,000 a year, that could be like $10 you're leaving on the table.
The catch 22 of web development is that in order to implement the features your customers want, you need more JavaScript.
But in order to make your site fast, you need less JavaScript.
Like in Next.
Js for example, you start with about 70 kilobytes bytes of JavaScript out of the gate, thanks to React DOM.
You'll then add at least a couple 100 more kilobytes to that with your own application code that will scale o of n based on how much application code you have on the page.
That's because on the initial page load, the framework needs to hydrate the DOM and rebuild or bootstrap the entire component tree from the ground up.
It's kind of like watching a movie that can't be paused.
If you need to restart the application by hitting the refresh button in the browser, it needs to re execute all the JavaScript from the beginning to get back to where it was.
Refresh.
Damn.
Refresh.
Damn.
Frameworks like Astro have recognized this problem, DOM, which uses a technique called partial hydration to selectively hydrate the DOM, but quick cuts out hydration altogether, like it's just not even necessary.
Cherry.
It delivers HTML that's instantly interactive.
That means in theory, you should be able to achieve a perfect Lighthouse performance score no matter how dragon complex your JavaScript code base is.
That sounds too good to be true, so how is it even possible?
The key innovation here is that a quick app can be fully serialized as HTML.
Shell.
In other words, at any moment, you can hit the pause button and capture all the data and closures in the application and represent it all as an HTML string.
That's huge for server side rendering because by the time that HTML gets to the browser, it can just pick up where the server left off without needing to execute any JavaScript at all, and that's why they coined the term resumability.
Now the other thing that makes this magic possible is lazy loading, which is built in as a primitive part of the framework.
To understand it, let's look at some code.
At first glance, it looks like a React app that uses functional components and JSX.
But what's the deal with this dollar sign?
It actually represents a lazy loaded boundary, and what you'll find is that everything is lazy loaded, and that even includes things like event handlers that close over the state of the application.
That's kind of crazy because how does this chunk of JavaScript know the state of the application if it's loaded.
If we look at the HTML, we can see this event handler is serialized directly into the code.
Now, if we open the network tab, we'll find 0 Java script on the initial page load.
You'll notice that that JavaScript is not actually loaded until we click the button.
It contains the code we want to execute, and also has access to the lexical environment to update state that might be shared by other components, which itself comes from another lazy loaded chunk.
The takeaway here is that you don't actually need to load any JavaScript until the user interacts with the UI.
If we go ahead and build the application, which is powered by Vite, you'll notice we get a ton of tiny chunks less than 1 kilobyte each, instead of a single massive bundle.
And because of that, quick can scale infinitely to as much JavaScript as your heart desires.
That's enough.
More.
This has been the code report.
Thanks for watching, and I will see you in the next one.

Speaker 0: It is September 20, 2022, and you're watching the code report. It's time to reset the counter yet again. It's been 0 days since a new JavaScript framework has been released. The highly anticipated quick framework, built by a dream team of developers, just hit beta yesterday. Now before you go and change channel.

This isn't just another average 5 inch framework. It brings an entirely new rendering paradigm to the table called resumability, which totally eliminates the need for hydration, the technique used by almost every meta framework today to make server rendered websites fully interactive. To understand what makes Quic special, we first need to understand the problem the current generation of frameworks. The key to a perfect Lighthouse performance score is to use less JavaScript. Google did some science and found that making a website 20% faster results in 10% more conversions.

If your website makes $1,000 a year, that could be like $10 you're leaving on the table. The catch 22 of web development is that in order to implement the features your customers want, you need more JavaScript. But in order to make your site fast, you need less JavaScript. Like in Next. Js for example, you start with about 70 kilobytes bytes of JavaScript out of the gate, thanks to React DOM.

You'll then add at least a couple 100 more kilobytes to that with your own application code that will scale o of n based on how much application code you have on the page. That's because on the initial page load, the framework needs to hydrate the DOM and rebuild or bootstrap the entire component tree from the ground up. It's kind of like watching a movie that can't be paused. If you need to restart the application by hitting the refresh button in the browser, it needs to re execute all the JavaScript from the beginning to get back to where it was. Refresh.

Damn. Refresh. Damn. Frameworks like Astro have recognized this problem, DOM, which uses a technique called partial hydration to selectively hydrate the DOM, but quick cuts out hydration altogether, like it's just not even necessary. Cherry.

It delivers HTML that's instantly interactive. That means in theory, you should be able to achieve a perfect Lighthouse performance score no matter how dragon complex your JavaScript code base is. That sounds too good to be true, so how is it even possible? The key innovation here is that a quick app can be fully serialized as HTML. Shell.

In other words, at any moment, you can hit the pause button and capture all the data and closures in the application and represent it all as an HTML string. That's huge for server side rendering because by the time that HTML gets to the browser, it can just pick up where the server left off without needing to execute any JavaScript at all, and that's why they coined the term resumability. Now the other thing that makes this magic possible is lazy loading, which is built in as a primitive part of the framework. To understand it, let's look at some code. At first glance, it looks like a React app that uses functional components and JSX.

But what's the deal with this dollar sign? It actually represents a lazy loaded boundary, and what you'll find is that everything is lazy loaded, and that even includes things like event handlers that close over the state of the application. That's kind of crazy because how does this chunk of JavaScript know the state of the application if it's loaded. If we look at the HTML, we can see this event handler is serialized directly into the code. Now, if we open the network tab, we'll find 0 Java script on the initial page load.

You'll notice that that JavaScript is not actually loaded until we click the button. It contains the code we want to execute, and also has access to the lexical environment to update state that might be shared by other components, which itself comes from another lazy loaded chunk. The takeaway here is that you don't actually need to load any JavaScript until the user interacts with the UI. If we go ahead and build the application, which is powered by Vite, you'll notice we get a ton of tiny chunks less than 1 kilobyte each, instead of a single massive bundle. And because of that, quick can scale infinitely to as much JavaScript as your heart desires.

That's enough. More. This has been the code report. Thanks for watching, and I will see you in the next one.
It is September 20, 2022, and you're watching the code report. It's time to reset the counter yet again. It's been 0 days since a new JavaScript framework has been released. The highly anticipated quick framework, built by a dream team of developers, just hit beta yesterday. Now before you go and change channel. This isn't just another average 5 inch framework. It brings an entirely new rendering paradigm to the table called resumability, which totally eliminates the need for hydration, the technique used by almost every meta framework today to make server rendered websites fully interactive. To understand what makes Quic special, we first need to understand the problem the current generation of frameworks. The key to a perfect Lighthouse performance score is to use less JavaScript.
Google did some science and found that making a website 20% faster results in 10% more conversions. If your website makes $1,000 a year, that could be like $10 you're leaving on the table. The catch 22 of web development is that in order to implement the features your customers want, you need more JavaScript.
revenue
google
But in order to make your site fast, you need less JavaScript. Like in Next. Js for example, you start with about 70 kilobytes bytes of JavaScript out of the gate, thanks to React DOM. You'll then add at least a couple 100 more kilobytes to that with your own application code that will scale o of n based on how much application code you have on the page. That's because on the initial page load, the framework needs to hydrate the DOM and rebuild or bootstrap the entire component tree from the ground up. It's kind of like watching a movie that can't be paused. If you need to restart the application by hitting the refresh button in the browser, it needs to re execute all the JavaScript from the beginning to get back to where it was. Refresh. Damn. Refresh. Damn. Frameworks like Astro have recognized this problem, DOM, which uses a technique called partial hydration to selectively hydrate the DOM, but quick cuts out hydration altogether, like it's just not even necessary.
Cherry. It delivers HTML that's instantly interactive. That means in theory, you should be able to achieve a perfect Lighthouse performance score no matter how dragon complex your JavaScript code base is. That sounds too good to be true, so how is it even possible? The key innovation here is that a quick app can be fully serialized as HTML. Shell. In other words, at any moment, you can hit the pause button and capture all the data and closures in the application and represent it all as an HTML string.
software
programming
That's huge for server side rendering because by the time that HTML gets to the browser, it can just pick up where the server left off without needing to execute any JavaScript at all, and that's why they coined the term resumability. Now the other thing that makes this magic possible is lazy loading, which is built in as a primitive part of the framework. To understand it, let's look at some code. At first glance, it looks like a React app that uses functional components and JSX. But what's the deal with this dollar sign? It actually represents a lazy loaded boundary, and what you'll find is that everything is lazy loaded, and that even includes things like event handlers that close over the state of the application. That's kind of crazy because how does this chunk of JavaScript know the state of the application if it's loaded. If we look at the HTML, we can see this event handler is serialized directly into the code. Now, if we open the network tab, we'll find 0 Java script on the initial page load. You'll notice that that JavaScript is not actually loaded until we click the button. It contains the code we want to execute, and also has access to the lexical environment to update state that might be shared by other components, which itself comes from another lazy loaded chunk. The takeaway here is that you don't actually need to load any JavaScript until the user interacts with the UI. If we go ahead and build the application, which is powered by Vite, you'll notice we get a ton of tiny chunks less than 1 kilobyte each, instead of a single massive bundle. And because of that, quick can scale infinitely to as much JavaScript as your heart desires. That's enough. More. This has been the code report. Thanks for watching, and I will see you in the next one.
It is September 20, 2022, and you're watching the code report. It's time to reset the counter yet again. It's been 0 days since a new JavaScript framework has been released. The highly anticipated quick framework, built by a dream team of developers, just hit beta yesterday. Now before you go and change channel. This isn't just another average 5 inch framework. It brings an entirely new rendering paradigm to the table called resumability, which totally eliminates the need for hydration, the technique used by almost every meta framework today to make server rendered websites fully interactive. To understand what makes Quic special, we first need to understand the problem the current generation of frameworks. The key to a perfect Lighthouse performance score is to use less JavaScript. Google did some science and found that making a website 20% faster results in 10% more conversions. If your website makes $1,000 a year, that could be like $10 you're leaving on the table. The catch 22 of web development is that in order to implement the features your customers want, you need more JavaScript. But in order to make your site fast, you need less JavaScript. Like in Next. Js for example, you start with about 70 kilobytes bytes of JavaScript out of the gate, thanks to React DOM. You'll then add at least a couple 100 more kilobytes to that with your own application code that will scale o of n based on how much application code you have on the page. That's because on the initial page load, the framework needs to hydrate the DOM and rebuild or bootstrap the entire component tree from the ground up. It's kind of like watching a movie that can't be paused. If you need to restart the application by hitting the refresh button in the browser, it needs to re execute all the JavaScript from the beginning to get back to where it was. Refresh. Damn. Refresh. Damn. Frameworks like Astro have recognized this problem, DOM, which uses a technique called partial hydration to selectively hydrate the DOM, but quick cuts out hydration altogether, like it's just not even necessary. Cherry. It delivers HTML that's instantly interactive. That means in theory, you should be able to achieve a perfect Lighthouse performance score no matter how dragon complex your JavaScript code base is. That sounds too good to be true, so how is it even possible? The key innovation here is that a quick app can be fully serialized as HTML. Shell. In other words, at any moment, you can hit the pause button and capture all the data and closures in the application and represent it all as an HTML string. That's huge for server side rendering because by the time that HTML gets to the browser, it can just pick up where the server left off without needing to execute any JavaScript at all, and that's why they coined the term resumability. Now the other thing that makes this magic possible is lazy loading, which is built in as a primitive part of the framework. To understand it, let's look at some code. At first glance, it looks like a React app that uses functional components and JSX. But what's the deal with this dollar sign? It actually represents a lazy loaded boundary, and what you'll find is that everything is lazy loaded, and that even includes things like event handlers that close over the state of the application. That's kind of crazy because how does this chunk of JavaScript know the state of the application if it's loaded. If we look at the HTML, we can see this event handler is serialized directly into the code. Now, if we open the network tab, we'll find 0 Java script on the initial page load. You'll notice that that JavaScript is not actually loaded until we click the button. It contains the code we want to execute, and also has access to the lexical environment to update state that might be shared by other components, which itself comes from another lazy loaded chunk. The takeaway here is that you don't actually need to load any JavaScript until the user interacts with the UI. If we go ahead and build the application, which is powered by Vite, you'll notice we get a ton of tiny chunks less than 1 kilobyte each, instead of a single massive bundle. And because of that, quick can scale infinitely to as much JavaScript as your heart desires. That's enough. More. This has been the code report. Thanks for watching, and I will see you in the next one.
It
it
is
is
September
september
20,
20
2022,
2022
and
and
you're
you're
watching
watching
the
the
code
code
report.
report
It's
it's
time
time
to
to
reset
reset
the
the
counter
counter
yet
yet
again.
again
It's
it's
been
been
0
0
days
days
since
since
a
a
new
new
JavaScript
javascript
framework
framework
has
has
been
been
released.
released
The
the
highly
highly
anticipated
anticipated
quick
quick
framework,
framework
built
built
by
by
a
a
dream
dream
team
team
of
of
developers,
developers
just
just
hit
hit
beta
beta
yesterday.
yesterday
Now
now
before
before
you
you
go
go
and
and
change
change
channel.
channel
This
this
isn't
isn't
just
just
another
another
average
average
5
5
inch
inch
framework.
framework
It
it
brings
brings
an
an
entirely
entirely
new
new
rendering
rendering
paradigm
paradigm
to
to
the
the
table
table
called
called
resumability,
resumability
which
which
totally
totally
eliminates
eliminates
the
the
need
need
for
for
hydration,
hydration
the
the
technique
technique
used
used
by
by
almost
almost
every
every
meta
meta
framework
framework
today
today
to
to
make
make
server
server
rendered
rendered
websites
websites
fully
fully
interactive.
interactive
To
to
understand
understand
what
what
makes
makes
Quic
quic
special,
special
we
we
first
first
need
need
to
to
understand
understand
the
the
problem
problem
the
the
current
current
generation
generation
of
of
frameworks.
frameworks
The
the
key
key
to
to
a
a
perfect
perfect
Lighthouse
lighthouse
performance
performance
score
score
is
is
to
to
use
use
less
less
JavaScript.
javascript
Google
google
did
did
some
some
science
science
and
and
found
found
that
that
making
making
a
a
website
website
20%
20%
faster
faster
results
results
in
in
10%
10%
more
more
conversions.
conversions
If
if
your
your
website
website
makes
makes
$1,000
$1,000
a
a
year,
year
that
that
could
could
be
be
like
like
$10
$10
you're
you're
leaving
leaving
on
on
the
the
table.
table
The
the
catch
catch
22
22
of
of
web
web
development
development
is
is
that
that
in
in
order
order
to
to
implement
implement
the
the
features
features
your
your
customers
customers
want,
want
you
you
need
need
more
more
JavaScript.
javascript
But
but
in
in
order
order
to
to
make
make
your
your
site
site
fast,
fast
you
you
need
need
less
less
JavaScript.
javascript
Like
like
in
in
Next.
next
Js
js
for
for
example,
example
you
you
start
start
with
with
about
about
70
70
kilobytes
kilobytes
bytes
bytes
of
of
JavaScript
javascript
out
out
of
of
the
the
gate,
gate
thanks
thanks
to
to
React
react
DOM.
dom
You'll
you'll
then
then
add
add
at
at
least
least
a
a
couple
couple
100
100
more
more
kilobytes
kilobytes
to
to
that
that
with
with
your
your
own
own
application
application
code
code
that
that
will
will
scale
scale
o
o
of
of
n
n
based
based
on
on
how
how
much
much
application
application
code
code
you
you
have
have
on
on
the
the
page.
page
That's
that's
because
because
on
on
the
the
initial
initial
page
page
load,
load
the
the
framework
framework
needs
needs
to
to
hydrate
hydrate
the
the
DOM
dom
and
and
rebuild
rebuild
or
or
bootstrap
bootstrap
the
the
entire
entire
component
component
tree
tree
from
from
the
the
ground
ground
up.
up
It's
it's
kind
kind
of
of
like
like
watching
watching
a
a
movie
movie
that
that
can't
can't
be
be
paused.
paused
If
if
you
you
need
need
to
to
restart
restart
the
the
application
application
by
by
hitting
hitting
the
the
refresh
refresh
button
button
in
in
the
the
browser,
browser
it
it
needs
needs
to
to
re
re
execute
execute
all
all
the
the
JavaScript
javascript
from
from
the
the
beginning
beginning
to
to
get
get
back
back
to
to
where
where
it
it
was.
was
Refresh.
refresh
Damn.
damn
Refresh.
refresh
Damn.
damn
Frameworks
frameworks
like
like
Astro
astro
have
have
recognized
recognized
this
this
problem,
problem
DOM,
dom
which
which
uses
uses
a
a
technique
technique
called
called
partial
partial
hydration
hydration
to
to
selectively
selectively
hydrate
hydrate
the
the
DOM,
dom
but
but
quick
quick
cuts
cuts
out
out
hydration
hydration
altogether,
altogether
like
like
it's
it's
just
just
not
not
even
even
necessary.
necessary
Cherry.
cherry
It
it
delivers
delivers
HTML
html
that's
that's
instantly
instantly
interactive.
interactive
That
that
means
means
in
in
theory,
theory
you
you
should
should
be
be
able
able
to
to
achieve
achieve
a
a
perfect
perfect
Lighthouse
lighthouse
performance
performance
score
score
no
no
matter
matter
how
how
dragon
dragon
complex
complex
your
your
JavaScript
javascript
code
code
base
base
is.
is
That
that
sounds
sounds
too
too
good
good
to
to
be
be
true,
true
so
so
how
how
is
is
it
it
even
even
possible?
possible
The
the
key
key
innovation
innovation
here
here
is
is
that
that
a
a
quick
quick
app
app
can
can
be
be
fully
fully
serialized
serialized
as
as
HTML.
html
Shell.
shell
In
in
other
other
words,
words
at
at
any
any
moment,
moment
you
you
can
can
hit
hit
the
the
pause
pause
button
button
and
and
capture
capture
all
all
the
the
data
data
and
and
closures
closures
in
in
the
the
application
application
and
and
represent
represent
it
it
all
all
as
as
an
an
HTML
html
string.
string
That's
that's
huge
huge
for
for
server
server
side
side
rendering
rendering
because
because
by
by
the
the
time
time
that
that
HTML
html
gets
gets
to
to
the
the
browser,
browser
it
it
can
can
just
just
pick
pick
up
up
where
where
the
the
server
server
left
left
off
off
without
without
needing
needing
to
to
execute
execute
any
any
JavaScript
javascript
at
at
all,
all
and
and
that's
that's
why
why
they
they
coined
coined
the
the
term
term
resumability.
resumability
Now
now
the
the
other
other
thing
thing
that
that
makes
makes
this
this
magic
magic
possible
possible
is
is
lazy
lazy
loading,
loading
which
which
is
is
built
built
in
in
as
as
a
a
primitive
primitive
part
part
of
of
the
the
framework.
framework
To
to
understand
understand
it,
it
let's
let's
look
look
at
at
some
some
code.
code
At
at
first
first
glance,
glance
it
it
looks
looks
like
like
a
a
React
react
app
app
that
that
uses
uses
functional
functional
components
components
and
and
JSX.
jsx
But
but
what's
what's
the
the
deal
deal
with
with
this
this
dollar
dollar
sign?
sign
It
it
actually
actually
represents
represents
a
a
lazy
lazy
loaded
loaded
boundary,
boundary
and
and
what
what
you'll
you'll
find
find
is
is
that
that
everything
everything
is
is
lazy
lazy
loaded,
loaded
and
and
that
that
even
even
includes
includes
things
things
like
like
event
event
handlers
handlers
that
that
close
close
over
over
the
the
state
state
of
of
the
the
application.
application
That's
that's
kind
kind
of
of
crazy
crazy
because
because
how
how
does
does
this
this
chunk
chunk
of
of
JavaScript
javascript
know
know
the
the
state
state
of
of
the
the
application
application
if
if
it's
it's
loaded.
loaded
If
if
we
we
look
look
at
at
the
the
HTML,
html
we
we
can
can
see
see
this
this
event
event
handler
handler
is
is
serialized
serialized
directly
directly
into
into
the
the
code.
code
Now,
now
if
if
we
we
open
open
the
the
network
network
tab,
tab
we'll
we'll
find
find
0
0
Java
java
script
script
on
on
the
the
initial
initial
page
page
load.
load
You'll
you'll
notice
notice
that
that
that
that
JavaScript
javascript
is
is
not
not
actually
actually
loaded
loaded
until
until
we
we
click
click
the
the
button.
button
It
it
contains
contains
the
the
code
code
we
we
want
want
to
to
execute,
execute
and
and
also
also
has
has
access
access
to
to
the
the
lexical
lexical
environment
environment
to
to
update
update
state
state
that
that
might
might
be
be
shared
shared
by
by
other
other
components,
components
which
which
itself
itself
comes
comes
from
from
another
another
lazy
lazy
loaded
loaded
chunk.
chunk
The
the
takeaway
takeaway
here
here
is
is
that
that
you
you
don't
don't
actually
actually
need
need
to
to
load
load
any
any
JavaScript
javascript
until
until
the
the
user
user
interacts
interacts
with
with
the
the
UI.
ui
If
if
we
we
go
go
ahead
ahead
and
and
build
build
the
the
application,
application
which
which
is
is
powered
powered
by
by
Vite,
vite
you'll
you'll
notice
notice
we
we
get
get
a
a
ton
ton
of
of
tiny
tiny
chunks
chunks
less
less
than
than
1
1
kilobyte
kilobyte
each,
each
instead
instead
of
of
a
a
single
single
massive
massive
bundle.
bundle
And
and
because
because
of
of
that,
that
quick
quick
can
can
scale
scale
infinitely
infinitely
to
to
as
as
much
much
JavaScript
javascript
as
as
your
your
heart
heart
desires.
desires
That's
that's
enough.
enough
More.
more
This
this
has
has
been
been
the
the
code
code
report.
report
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speaker explains the benefits of the new quick framework, which is a highly anticipated feature that eliminates the need for hydration and improves page performance. The key to a perfect Lighthouse performance score is less JavaScript, and a lazy loading is built in as a primitive part of the framework. The use of partial hydration is key to achieving a perfect score, and the application of a partial hydration method is designed to represent a lazy loaded page.
Qwik… the world's first O(1) JavaScript framework?
It is September 20, 2022, and you're watching the code report. It's time to reset the counter yet again. It's been 0 days since a new JavaScript framework has been released. The highly anticipated quick framework, built by a dream team of developers, just hit beta yesterday. Now before you go and change channel. This isn't just another average 5 inch framework. It brings an entirely new rendering paradigm to the table called resumability, which totally eliminates the need for hydration, the technique used by almost every meta framework today to make server rendered websites fully interactive. To understand what makes Quic special, we first need to understand the problem the current generation of frameworks. The key to a perfect Lighthouse performance score is to use less JavaScript. Google did some science and found that making a website 20% faster results in 10% more conversions. If your website makes $1,000 a year, that could be like $10 you're leaving on the table. The catch 22 of web development is that in order to implement the features your customers want, you need more JavaScript. But in order to make your site fast, you need less JavaScript. Like in Next. Js for example, you start with about 70 kilobytes bytes of JavaScript out of the gate, thanks to React DOM. You'll then add at least a couple 100 more kilobytes to that with your own application code that will scale o of n based on how much application code you have on the page. That's because on the initial page load, the framework needs to hydrate the DOM and rebuild or bootstrap the entire component tree from the ground up. It's kind of like watching a movie that can't be paused. If you need to restart the application by hitting the refresh button in the browser, it needs to re execute all the JavaScript from the beginning to get back to where it was. Refresh. Damn. Refresh. Damn. Frameworks like Astro have recognized this problem, DOM, which uses a technique called partial hydration to selectively hydrate the DOM, but quick cuts out hydration altogether, like it's just not even necessary. Cherry. It delivers HTML that's instantly interactive. That means in theory, you should be able to achieve a perfect Lighthouse performance score no matter how dragon complex your JavaScript code base is. That sounds too good to be true, so how is it even possible? The key innovation here is that a quick app can be fully serialized as HTML. Shell. In other words, at any moment, you can hit the pause button and capture all the data and closures in the application and represent it all as an HTML string. That's huge for server side rendering because by the time that HTML gets to the browser, it can just pick up where the server left off without needing to execute any JavaScript at all, and that's why they coined the term resumability. Now the other thing that makes this magic possible is lazy loading, which is built in as a primitive part of the framework. To understand it, let's look at some code. At first glance, it looks like a React app that uses functional components and JSX. But what's the deal with this dollar sign? It actually represents a lazy loaded boundary, and what you'll find is that everything is lazy loaded, and that even includes things like event handlers that close over the state of the application. That's kind of crazy because how does this chunk of JavaScript know the state of the application if it's loaded. If we look at the HTML, we can see this event handler is serialized directly into the code. Now, if we open the network tab, we'll find 0 Java script on the initial page load. You'll notice that that JavaScript is not actually loaded until we click the button. It contains the code we want to execute, and also has access to the lexical environment to update state that might be shared by other components, which itself comes from another lazy loaded chunk. The takeaway here is that you don't actually need to load any JavaScript until the user interacts with the UI. If we go ahead and build the application, which is powered by Vite, you'll notice we get a ton of tiny chunks less than 1 kilobyte each, instead of a single massive bundle. And because of that, quick can scale infinitely to as much JavaScript as your heart desires. That's enough. More. This has been the code report. Thanks for watching, and I will see you in the next one.
The speaker explains the benefits of the new quick framework, which is a highly anticipated feature that eliminates the need for hydration and improves page performance. The key to a perfect Lighthouse performance score is less JavaScript, and a lazy loading is built in as a primitive part of the framework. The use of partial hydration is key to achieving a perfect score, and the application of a partial hydration method is designed to represent a lazy loaded page.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Qwik… the world's first O(1) JavaScript framework? 
        and a small summary : The speaker explains the benefits of the new quick framework, which is a highly anticipated feature that eliminates the need for hydration and improves page performance. The key to a perfect Lighthouse performance score is less JavaScript, and a lazy loading is built in as a primitive part of the framework. The use of partial hydration is key to achieving a perfect score, and the application of a partial hydration method is designed to represent a lazy loaded page.
        [/INST]
        
        Generate the video : It is September 20, 2022, and you're watching the code report. It's time to reset the counter yet again. It's been 0 days since a new JavaScript framework has been released. The highly anticipated quick framework, built by a dream team of developers, just hit beta yesterday. Now before you go and change channel. This isn't just another average 5 inch framework. It brings an entirely new rendering paradigm to the table called resumability, which totally eliminates the need for hydration, the technique used by almost every meta framework today to make server rendered websites fully interactive. To understand what makes Quic special, we first need to understand the problem the current generation of frameworks. The key to a perfect Lighthouse performance score is to use less JavaScript. Google did some science and found that making a website 20% faster results in 10% more conversions. If your website makes $1,000 a year, that could be like $10 you're leaving on the table. The catch 22 of web development is that in order to implement the features your customers want, you need more JavaScript. But in order to make your site fast, you need less JavaScript. Like in Next. Js for example, you start with about 70 kilobytes bytes of JavaScript out of the gate, thanks to React DOM. You'll then add at least a couple 100 more kilobytes to that with your own application code that will scale o of n based on how much application code you have on the page. That's because on the initial page load, the framework needs to hydrate the DOM and rebuild or bootstrap the entire component tree from the ground up. It's kind of like watching a movie that can't be paused. If you need to restart the application by hitting the refresh button in the browser, it needs to re execute all the JavaScript from the beginning to get back to where it was. Refresh. Damn. Refresh. Damn. Frameworks like Astro have recognized this problem, DOM, which uses a technique called partial hydration to selectively hydrate the DOM, but quick cuts out hydration altogether, like it's just not even necessary. Cherry. It delivers HTML that's instantly interactive. That means in theory, you should be able to achieve a perfect Lighthouse performance score no matter how dragon complex your JavaScript code base is. That sounds too good to be true, so how is it even possible? The key innovation here is that a quick app can be fully serialized as HTML. Shell. In other words, at any moment, you can hit the pause button and capture all the data and closures in the application and represent it all as an HTML string. That's huge for server side rendering because by the time that HTML gets to the browser, it can just pick up where the server left off without needing to execute any JavaScript at all, and that's why they coined the term resumability. Now the other thing that makes this magic possible is lazy loading, which is built in as a primitive part of the framework. To understand it, let's look at some code. At first glance, it looks like a React app that uses functional components and JSX. But what's the deal with this dollar sign? It actually represents a lazy loaded boundary, and what you'll find is that everything is lazy loaded, and that even includes things like event handlers that close over the state of the application. That's kind of crazy because how does this chunk of JavaScript know the state of the application if it's loaded. If we look at the HTML, we can see this event handler is serialized directly into the code. Now, if we open the network tab, we'll find 0 Java script on the initial page load. You'll notice that that JavaScript is not actually loaded until we click the button. It contains the code we want to execute, and also has access to the lexical environment to update state that might be shared by other components, which itself comes from another lazy loaded chunk. The takeaway here is that you don't actually need to load any JavaScript until the user interacts with the UI. If we go ahead and build the application, which is powered by Vite, you'll notice we get a ton of tiny chunks less than 1 kilobyte each, instead of a single massive bundle. And because of that, quick can scale infinitely to as much JavaScript as your heart desires. That's enough. More. This has been the code report. Thanks for watching, and I will see you in the next one.
        