DEV Community: Miško Hevery

How To Embed Tweets Without a Performance Penalty

Miško Hevery — Thu, 02 Mar 2023 15:36:17 +0000

Why embed Twitter on your website

You have a great product, and your users are raving about it on Twitter. You want to use the social proof on your page to tell new users how awesome you are. Let's embed some tweets into your site! Twitter makes this easy! Click the tree dots context menu and select Embed Tweet, then follow the instructions. Twitter gives you a code snipped, which you embed into your page and success! You have a tweet embedded on your page.

Miško Hevery (Builder.io/Qwik)

@mhevery

Blank page with an embedded tweet. How bad can it be?

JS: 1.5MB 🤯
PageSpeed score: 61/100 🤯
Time to Interactive: 9 sec 🤯
TBT: 1.7 sec 🤯

What hope does an average site have if a simple tweet requires MegaBytes of JS and seconds to interactivity?

mhevery.github.io/perf-tests/twi…

23:55 PM - 23 Dec 2022

Embedding a tweet is expensive

We don't give embedding a tweet onto our site much thought, but it turns out that that tweet is quite expensive from a performance perspective. To show you just how expensive that embed is, we have embedded a single tweet and then four tweets into a blank page and asked Google PageSpeed to rank the quality of our site. To make sure that we are measuring just the cost of the embedded tweet, the page we are testing is otherwise blank.

To our surprise, the results are not great!

Here are some highlights of the bad experience people will get on low-powered mobile devices:

The users have to wait almost 18 seconds before the page becomes interactive.
The tweet rendering freezes the UI (not responsive) for 4 seconds.
Each additional tweet costs the visitor a little over 3 seconds of waiting.
To render a tweet, the embed script makes about 27 requests and downloads 600 Kb over the wire, which results in 1.6 Mb of JavaScript, out of which only about 50% gets executed.

Keep in mind this is on the blank page. The situation will get worse as the page becomes more complex with more third-party scripts.

The thing to observe is that the Tweet Embed solution is JavaScript-heavy and requires a lot of JavaScript execution to render the tweet. The more JavaScript on startup, the slower your site.

Why so expensive

The natural question is to ask, why is this so expensive? Why does Twitter not care about its users and the end-user experience? Well, it is easy to blame Twitter engineers but let's have some empathy for the engineer that designed this system. They were probably under time pressure to deliver, and so they chose the path of least resistance to deliver the Tweet embed feature.

The Tweet embed is a standard stand-alone application that gets loaded in an iframe. (One iframe per tweet) The application is CSR (client-side rendered) SPA (single page application) written in React. React is a well-tested and loved technology by developers, so the fact that the Twitter engineer chose it for the tweet implementation is unsurprising.

The Twitter engineers could have chosen other rendering technologies, but it would not have significantly impacted the outcome. We have compared a movie app written in seven different frameworks, and the result was mostly the same for all CSR applications. The main winners were the HTML-first frameworks such as Astro and Qwik because those deliver primarily HTML rather than JavaScript — more on that later.

23 third-party scripts

At this point, stepping back and seeing the big picture is important. A single tweet has lowered our site score to 69. Four tweets to 39! But this is but one third-party script. Google reports that an average site has 23 different third-party scripts! So this is but one of many more scripts to be embedded into your site. If one third-party script fares so badly, what do you think a site with 23 different third-party scripts will do? There is just no hope that the site will perform well. The site will have a bad user experience, and people will leave.

It is paramount that we, as site developers, pay attention to third-party scripts and do a better job shielding ourselves from their consequences.

It's just another CSR app

The big realization is that each third-party script is yet another application on your site besides your application. We do things to optimize our application, such as SSR (server-side render)/SSG(static site generation), so why don't third-party scripts do that as well?

Third-party scripts are primarily concerned with the ease of embedding. The primary goal for the Twitter embed is easy embedding for the site developer. When the site developer recognizes that the embed has destroyed the site’s performance, it is too late, and they are unlikely to do much about that. See [3 people problem] later in this article. Because ease of embedding is a priority, the most straightforward thing to do is to cut and paste a JavaScript tag into your site. The CSR (Client Side Rendering) approach will work with any existing solution you use for the site because all the work is done on the client rather than on the server. But precisely, this do-all-work-on-the-client shortcut makes embedding easy. However, the performance of the third-party scripts is poor.

What we need is a way to embed third-party applications in a cut-and-paste way that actually renders using SSR/SSG (rather than CSR). The problem is that most of our frameworks/libraries are CSR-centric, with SSR as an add-on using meta-frameworks. Notable exceptions are Astro and Qwik, which focus on SSR/SSG as a primary delivery mechanism.

It all comes down to JavaScript

Once you dig into site performance for long enough, you realize it all comes down to JavaScript. Actually, it is three things, but two of them have a well-understood solution, so we are left with JavaScript.

To make your site fast, it needs three things:

To send HTML to the client
To optimize images and CSS
To minimize the amount of JavaScript on the startup

Most meta-frameworks can do SSR/SSG, so they can send HTML to the client. Meta-frameworks also have good support for Image and CSS optimization. It is not an automatically solved problem, but with a little bit of work on the developer's side, the HTML, Image, and CSS are well-understood problems with well-understood solutions. So if a site fails to deliver on these, it really comes down to the site developer not doing their job or not being aware of how to do it.

The remaining problem is executing less JavaScript on startup. We don't have good solutions for sending less JavaScript to the client. That is because most meta-frameworks and frameworks use hydration to recover their state, which results in too much JavaScript execution on the client. That is why solutions such as Astro, Eleventy, and Qwik are becoming more popular because they are focusing on addressing the JavaScript problem.

So the Twitter engineer implementing the Twitter embed fell into the JavaScript problem because most of our solutions are JavaScript-centric.

HTML-first embedding

To get good performance, third-party scripts need to send HTML and delay the execution of JavaScript for as long as possible. When the site starts up, there is always some amount of JavaScript that needs to run on the main thread, which is the bottleneck. Unfortunately, third-party scripts' current status quo is that each adds even more JavaScript to the startup cost. Some tools such as Partytown try to help with this, but overall this is not a solved problem. Third-party script providers should strive to improve.

But remember that third-party providers are really just packaging their applications into an easily embeddable script tag. They themselves usually use existing frameworks/libraries. These frameworks/libraries are CSR-centric with limited ability to do SSR and delay hydration. So while it is easy to blame third parties for slow site startup performance, in the end, the third parties rely on the same frameworks/libraries as we all do, and most of these frameworks are not focused on minimizing the amount of JavaScript at startup.

In the end, third-party providers don't provide HTML-first solutions because, as an industry, we don't have good HTML-first frameworks to use to deliver those solutions. Sure we have Astro and Eleventy, but these frameworks are more meant for static site generation rather than interactive application delivery.

Our proof of concept for tweet embeds

Let's build the same solution with an HTML-first approach.

What we are trying to do is to do a client-side include of HTML.

Ideally, we want this:

<html>
 <body>
   Your content
   <include src="<https://qwik-twitter.builder.io/tweet/1606438382561026049.html>"></include>
  </body>
</html>

Unfortunately, HTML does not have an <include> tag, so we are cheating with a bit of JavaScript.


<html>
<body>
Your content
<script type="module" src="https://qwik-twitter.builder.io/tweet/1606438382561026049.js"></script>
</body>
</html>

Where the https://qwik-twitter.builder.io/tweet/1606438382561026049.js returns:

(function(html) {
   const script = window.currentScript;
   const div = document.createElement('div');
   div.innerHTML = html;
   while(div.firstChild) {
     script.parentNode.insertBefore(div.firstChild, script);
   });
 })(`
   <!-- HTML we want to insert -->
   <div>my tweet</div>
`)

The above is HTML wrapped as JavaScript, with very little actual JavaScript.

The above code allows us to achieve two things:

It is still easy to embed the tweet into your website as it is a simple cut and paste.
The embedding code delivers HTML, not JavaScript (Even though it is wrapped in JavaScript to work around the browser limitations.) The fact that we are delivering HTML (instead of JavaScript) has a huge impact on the site startup performance.

Generating HTML first content

So there are many frameworks that can do SSR/SSG and hence generate HTML for the client. But most of them come with hydration costs. So for our example, we have chosen Qwik because it uses resumability instead of hydration to make the application interactive. Astro would have also been a good choice because it delays the hydration cost until the island is ready. Anything which does not add JavaScript on startup and produces HTML would have been a great choice.

The nice thing about Qwik is that you get to write your application in a familiar React-like style, but Qwik automatically generates HTML and delays the loading of JavaScript until it is needed (the same application written with React, as we see in Twitter embedded in the example above, results in a lot of JavaScript on startup).

Why it performs so much better

Let's examine the performance improvements with the new approach.

WOW! That’s quite a difference! As you can tell from the above, embedding HTML (even if wrapped in JavaScript) has almost no impact on the startup performance of your site! Even adding multiple tweets does not negatively impact the startup's performance. The only minor negative impact is from CLS (Commutative Layout Shift), which is due to serving images without size information, something that should be a straightforward fix.

The key thing to notice is that all of this is driven by the amount of JavaScript which needs to execute. By reducing the amount of JavaScript, the page became performant. The hard part is not knowing that JavaScript needs to be reduced but knowing how to use existing tools to deliver a minimal amount of JavaScript. This requires a paradigm shift.

Try it for yourself

If your site uses Twitter Embed and you would like to try this approach, you can do so here: https://qwik-twitter.builder.io/.

Find a tweet that you would like to embed
Paste it into the Tweet URL and submit.
Copy the appropriate level of the script to your site.

What the differences are

JS only is by far the smallest amount of code to paste, but it means that the end user will first see a page without a tweet, and a fraction of a second later, the tweet will show up. This has several shortcomings. The small delay will negatively impact the CLS, and the lack of content will prevent the search engine from indexing the tweet content.
HTML + JS includes HTML in addition to JavaScript. While this tweet will still have a flash of unstyled content, it does have the content, which means the search engine will correctly index it.
HTML + JS + CSS is the best way to inline the content so that there is no flash of unstyled content and the search engine can index it. The JS on end can update the tweet reply, retweets, and favorite stats once it executes.

The three people problem

Any system which is not a closed loop will go out of sync. The best systems are such that there is a feedback loop that self-corrects. In the case of a third-party ecosystem, there are three separate people involved and very little feedback between them.

Third-party developer: in our case, the Twitter engineer that created the Twitter embed code.
First-party developer: this is you creating a site for your users and deciding to embed the third-party code because it provides value.
End user: the person using the site.

The problem is that the person feeling the slowness is the end user. The person who can do something about it is the third-party developer, but they are not feeling the problem. The first-party developer is aware of the problem but needs the value of the third-party script, so they keep using it as there are few alternatives.

The above creates very little incentive for the problem to get fixed. Add to it the realization that the third-party developer needs better tools for creating the third-party code in an HTML-first manner, and we have a bit of a stalemate in the industry.

What the industry can do to aim higher

So what can we do to improve this?

We need to empathize with the end user and care more about performance as an industry.
We need examples (like this one) showing that it is possible to do better. This is a mental model shift where we need to understand that it is about leaning more toward HTML and less toward JavaScript.
We need tooling that allows developers to create HTML-first sites without sacrificing development speed. The easy path needs to be the performant path; otherwise, corners will be cut in the name of deadlines.

Conclusion

Average sites have 23 third-party scripts. We add these scripts because they provide value for our sites, whether as social proof or insights into user behavior. To make the scripts easy to embed, they are usually written as CSR (client-side rendered) applications. CSRs come with high startup cost, which is often hidden from the site developer. Most of these third-party scripts are written as CSR applications, meaning they are JavaScript-heavy and need to execute on startup, negatively impacting our site. Multiply this by 23 scripts per page, and the site has little hope of being fast, let alone “blazingly™ fast”.

There is an alternative way to provide value. Instead of CSR, we need HTML-first third-party scripts that delay JavaScript for as long as possible. Such third-party scripts are possible, but they require different kinds of approaches to the problem. This requires support from tools and educating developers. We need to make sure that the easy way to build a site or third-party scripts is also the performant way to build it.

Visually build with your components

Builder.io is a headless CMS that lets you drag and drop with your components right within your existing site.

Try it out

Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

The Challenges of Lazy Loading in JavaScript

Miško Hevery — Thu, 02 Mar 2023 15:26:52 +0000

So your site has too much JavaScript. No problem, say the experts, just lazy load your application! Well, I am here to tell you that lazy-loading is harder than you think!

Let's start with building a simple app to demonstrate the problem. We will have three components:

A component for state
A component for the interaction
And a component for displaying user data.

For this simple example, we are about to show you the breakdown is overkill, but we designed the simple application in this way to demonstrate the problem of real-world applications better.

Note: We use React in these examples because of its concise syntax and popularity. But the issues described here are in no way specific to React. All Hydration based frameworks face these issues. So please don't take this as a negative reflection on React specifically.

File: main.tsx

export function MyApp() {
  const [count, setCount] = useState(0);
  return <>
    <Display count={count} />
    {count > 10 ? <OverSize /> : null}
    <Incrementor count={count} setCount={setCount} />
  </>;
}

function Display({count}) {
  return <div>{count}</count>
}

function OverSize() {
  return <span>Count is too big!</span>
}

function Incrementor({count, setCount}) {
  return <button onClick={() => setCount(count+1)}>+1</button>
}

render(<MyApp/>, document.getElementyById('my-app'));

For brevity, the application is small. But let's imagine that there are many sub-components behind each of our components and those sub-components have a lot of JavaScript. So our application is large and therefore slow to start. We consulted PageSpeed, and their primary recommendation was to reduce the amount of JavaScript.

Lazy loading a component

File: main.tsx

import { useState, lazy, Suspense } from 'react';

const Display = lazy(async () =>
   await (import('./display')).Display);

const Incrementor = lazy(async () =>
   await (import('./incrementor')).Incrementor);

const OverSize = lazy(async () =>
   await (import('./oversize')).OverSize);

export function MyApp() {
  const [count, setCount] = useState(0);
  return <>
    <Suspense><Display count={count} /></Suspense>
    {count > 10 ? <Suspense><OverSize /></Suspense> : null}
    <Suspense><Incrementor count={count} setCount={setCount} /></Suspense>
  </>;
}

createRoot(document.getElementyById('my-app')).render(<MyApp/>);

File: display.tsx

export function Display({count}) {
  return <div>{count}</count>
}

File: oversize.tsx

export function OverSize() {
  return <span>Count is too big!</span>
}

File: incrementor.tsx

export function Incrementor({count, setCount}) {
  return <button onClick={() => setCount(count+1)}>+1</button>
}

The result is straightforward, even though it is quite wordy. We had to create multiple files and give them names. And as we all know, naming is one of the hardest problems in computer science. And this is where the problems start. Our hard work of breaking up the application into separate files will be undermined by Hydration, coalescing, and prefetching problems.

Hydration

On application, startup Hydration requires that the framework descends into each component to rebuild the component state (useState) and check to see if the component has any listeners that need to be attached for interactivity. The fact that we descend into each component completely undoes the lazy-loading work we put in. Both Display and Incrementor will be fetched eagerly as part of the application startup. Here lazy-loading made the situation arguably worse since the browser will have to make multiple HTTP trips to the server.

The only component where lazy-loading helped is the OverSized component. This is the only component not needed as part of Hydration, so lazy-loading it made sense. The problem is that as a developer, you don't know which set of components your application will need because that is oftentimes dependent on the application state and may change as the application adds new features. So while in the above example, it is easy to reason about which components will be needed eagerly, in a large-scale application, the problem quickly goes beyond what developers can keep track of and requires some sort of automation, which needs to be custom-built.

From the above example, it should be apparent that lazy-loading is only useful for components not currently part of the render tree. That is because the components part of the render tree require Hydration to become interactive, and Hydration requires the eager walking of the component tree. So lazy loading is great for route changes (new components not part of the current render tree) but not so much for lowering the amount of JS which is required for Hydration.

Merging components

It may very well be that the Display and Incrementor components need to be loaded together. In that case, they should be placed in the same lazy-loaded chunk. Not all bundlers will know how to merge display.tsx and incrementor.tsx into the same file because they are accessed through a separate dynamic import. And even if they know how to merge dynamic imports, it is not immediately clear to the bundler which dynamic imports should be merged and which should not. This is a problem because now the developer needs to make bundling choices about which chunk each symbol should be placed in. Such information may not be apparent at the time of writing the application or may change as the application adds new functionality.

A corollary to the above is that bundling is not an implementation detail of the application but a configuration detail of the bundler. Our bundler systems are not set up for this.

Prefetching

We want to ensure that the user has a smooth experience. That means that we don't want to start fetching a JS chunk on user interaction. Instead, the chunk should be prefetched eagerly. But prefetching is outside of the scope of frameworks, as well as bundlers. Prefetching now falls onto the developer's responsibility. This is tricky because the developer now needs to determine all of the potential entry points chunks, in which order they should be prefetched, and when in the application lifecycle is a good time to do the prefetching. For example, is chunk A needed now or only on route change? How does the developer communicate that information to the pre-fetcher? What mechanisms should be used for prefetching? And many more questions which now fall on the developer's responsibility.

Lazy-loading on interactions

As written, our code can only lazy-load components. Components include event handlers, but because components are often loaded eagerly due to Hydration, we often lazy-load behavior before it is needed. Loading the component behavior eagerly can be seen on PageSpeed as “Reduce unused JavaScript” code coverage (event handlers are downloaded but not executed as part of hydration.). It is the code which downloaded but was not executed as part of Hydration. The not-executed code is mostly event handlers. So let's try to lazy load the event handler.

We start by breaking up the incrementor.tsx into even smaller files by pulling out the event handler like so:

File: incrementor.tsx

export default function Incrementor({count, setCount}) {
  return <button onClick={async () => {
    (await import('./incrementor-on-click')).default(setCount, count);
  }}>+1</button>
}

File: incrementor-on-click.tsx

export default function incrementorOnClick(setCount, count) {
  setCount(count+1)};
}

But here we run into more issues regarding hydration trampoline closure; async nature of lazy-loading; prefetching; its a lot of work; (And we have not even gotten into the issue of flowing types across lazy loading boundaries)

Hydration trampoline closure

The issue is that when Hydration collects all of the listeners, it expects a closure to invoke when the listener fires on user interaction. In our example, the listener-closure closes over setCount and count, and that code for creating the closure needs to be executed eagerly, as shown here for the onClick case.

File: incrementor.tsx

export default function Incrementor({count, setCount}) {
  return <button onClick={async () => {
    (await import('./incrementor-on-click')).default(setCount, count);
  }}>+1</button>
}

Another way to look at it is from the handler file.

File: incrementor-on-click.tsx

The above function needs to get a hold of setCount and count to perform its job. Without setCount and count the IncrementorOnClick can't do anything useful. So how does it get a hold of it? Well, it expects that data to be passed in when it is invoked.

This is the reason why the <button onClick={...}/> has an eager closure that captures the setCount and count on Hydration and then makes it available to the lazy-loaded function on invocation.

Another way to think about it is that lazy-loading listeners do not help with startup performance, as we still need to allocate the event handlers (It may help with the amount of JS we download, but not in this case, as the ceremony of lazy loading contains more code than the actual lazy-loaded chunk.).

Async nature of lazy-loading

Lazy-loading is asynchronous by its nature. The issue is that the event handler oftentimes has to synchronously call preventDefault or call other APIs which are only available synchronously. This complicates the writing of code as the developer now needs to take that into account. It may not be possible to just refactor the code for lazy-loading and assume it will work, as doing so introduces lazy-loading boundaries, which may break the application.

Prefetching

Again prefetching is an issue with lazy-loading on interactivity, and all of the issues we discussed above apply here as well. But in the case of interactivity, prefetching is a lot more important because while Hydration causes eager loading of components, interactivity will not eagerly load until the user interacts, and by that point, it may be too late (user will experience slow network delay on the first interaction.) So prefetching of interactivity code is a must!

It is a lot of work

The amount of work to create lazy interactions is astounding!

create a new file
insert dynamic import()
ensure that the code is prefetched
repeat for each component/function

Most of the time, the developer will not do all of this extra work for a relatively small win. The issue with event handlers is not that any one event handler adds a lot of code. It is that applications usually have a lot of event handlers, and so it adds up. It’s like death by a thousand cuts.

Conclusion

Application startup performance is tied to the amount of JS that the browser needs to download and execute. Lazy-loading code is often suggested as the solution to improve startup performance. While this may sound straightforward at first, it is much harder than you think.

Lazy-loading adds extra ceremonies to your code and workflow. It requires the developer to think about how the application should be broken up. It creates new problems around prefetching of code, which is not solved out of the box and requires more engineering.

And finally, a lot of benefits of lazy-loading is destroyed by the eager nature of Hydration, and so most benefits of lazy-loading can only be achieved with components that are not currently in the render tree (components that need to be loaded on route-change.) It’s easy to say that lazy loading will solve your performance problems, but the actual engineering part of the developer is a lot more than it may seem. For this reason, it rarely gets done. When an application grows too large and lazy-loading becomes necessary, the refactoring process may be extremely difficult.

About Qwik

Qwik is a framework that eliminates the need for developers to manually handle lazy-loading, bundling, and prefetching. It functions seamlessly out of the box. Furthermore, Qwik does not undo the advantages of Hydration for components in the render tree, as it does not perform Hydration.

Visually build with your components

Builder.io is a headless CMS that lets you drag and drop with your components right within your existing site.

Try it out

Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

Our current frameworks are O(n); we need O(1)

Miško Hevery — Wed, 18 May 2022 18:56:56 +0000

Miško HeveryFollow

CTO at Builder.io, empower anyone to create blazing fast sites. Previously at Google, where he created Angular, AngularJS and was co-creator of Karma.

Original: https://www.builder.io/blog/our-current-frameworks-are-on-we-need-o1

Today, websites are more interactive and useful than ever, which also means they’re more complex than ever. Users have come to expect the new interactivity and usefulness, and they’re not going to want to give it up. All of this means more JavaScript is being sent to the browser on page load than ever, which isn’t likely to slow down anytime soon. We can expect that sites will continue to keep getting better and more complex, but what should we do about JavaScript?

How did we get here?

It’s well understood that the amount of JavaScript being sent to browsers is steadily increasing, as shown in this graph from httparchive.org.

Some people like to argue that the site we served ten years ago and the one we serve today are the same. But it’s not a fair comparison. The sites of today are way more complex.

And while some of the complexity comes from better interactions and functionality for the end-users, a lot of it comes from helping us gain insight into our users' behavior, which helps us build even better sites. Our sites ultimately get bigger because they do more stuff not only for our end-users, but for us as well.

CPUs have stalled.

Every year, the CPUs are getting faster, but most of the speedup comes from improved parallelism. And in recent years the performance improvements per core have been slowing down. We’re approaching the limits of how fast CPU clocks can run and how much cleverness the CPUs can do per clock cycle. As a result, we see more multi-core CPUs pop up (It is not uncommon for your phone to have 4 CPU cores and 4 GPU cores). So the main driver of CPU performance improvement these days comes from parallelism of multiple cores, not from improvements in a single core.

So, why are we talking about CPU speed and cores? As our sites get bigger and download more JavaScript, the CPU has more work to do. And because JavaScript is single-threaded, all of the additional work falls onto a single core. Therefore, this is not a problem that will get better by waiting a few years and expecting the hardware to catch up.

Ultimately, our current JS load is increasing faster than the rate of single CPU core performance. This is not sustainable.

Frameworks were not designed for this.

Frameworks for desktop applications have existed way before the web. So when the web came, we just took our desktop framework philosophy of what the framework is and applied it to the web. Desktop frameworks can safely assume that all of the code is already available and that there is no server. The problem is that those two key points are not true for the web. We can't assume that the code is already available, and server pre-rendering has become an important part of our vocabulary.

We’re at a stage where the frameworks we have are pretending they’re desktop frameworks. They have not embraced SSR and lazy-loading to the core.

y=mx+b

An application needs to boot up on the client. The bootup consists of a fixed cost of the framework and a variable cost of the application itself (the complexity of the application). So really, we are talking about a linear relationship which can be expressed as “y=mx+b”.

When frameworks argue who is smaller, they can really only compete on two points: the fixed cost of the framework or the variable cost of the application. So either a smaller “m” or a smaller “b”.

Ryan Carniato did a nice comparison of different frameworks in his post JavaScript Framework TodoMVC Size Comparison (table replicated below).

For the sake of my argument, the exact numbers aren’t important, but the table does a good job of illustrating how, as the application size increases, different frameworks have different slopes (“m”) and different initial values (“b”).

Even the smallest “m” is not enough.

The problem is that all frameworks have approximately the same slope. And even if the framework completely compiles away so its “b” becomes zero, the application dominates the download and execution size. The “b” kind of doesn’t matter for sufficiently large applications.

All of the above lines are “O(n)”. As the application gets bigger, so does the initial bundle size. Applications will continue to get bigger as we continue to build better end-user experiences.

New goal “O(1)

What we need is a new paradigm. We need a framework with a constant load time no matter the application complexity. At first glance, this may sound impossible—surely, the initial bundle is proportional to the application complexity. But what if we lazyload code rather than doing it eagerly? I covered why existing frameworks need to eagerly download code in my post, Hydration is pure overhead. Here’s what we’re looking for instead:

The current status quo is to download and execute all of the code at once. What’s needed is a way to sip on the JavaScript as the user is interacting with the site. No interaction, no JavaScript; little interaction, little JavaScript. If there’s a lot of interaction, we approach the classical frameworks and download most of the code. But the big deal is that we need to shift our mental model from eagerly downloading code at the beginning to lazily downloading code as the user interacts.

Current frameworks already know how to do this to some extent, as they all know how to download more code on route change. What’s needed is to extend that paradigm to the interaction level.

In the above image the site is delivered as HTML to the client. Notice that none of the components have the coresponded code loaded. The next image shows which components need to be downloaded and executed on user interectaion. The result is that a lot less code needs to be downloaded and the code which is downloaded is executed later. This offloads the amount of work the CPU has to do on site startup.

Summary

The amount of JavaScript we download to the browser is going up every year. The problem is that our site's complexity increases as we deliver more complex end-user experiences that require more code. We have already reached a point where we have too much code in the initial download, and our site’s startup performance suffers. This is because the frameworks we use are O(n). This is not scalable.

While different frameworks have different slopes in the end, any slope is too much. Instead, we need to lazy load on interaction rather than on initial load. Frameworks already know how to lazy load on route change, we just need to go deeper and do it on interaction as well. This is needed so that our initial load size can be O(1) and we can lazy load code on as needed basis. It’s the only way we can continue to build even more complex web applications in the future.

Don't blame the developer for what the frameworks did!

Miško Hevery — Wed, 04 May 2022 17:59:17 +0000

Miško HeveryFollow

CTO at Builder.io, empower anyone to create blazing fast sites. Previously at Google, where he created Angular, AngularJS and was co-creator of Karma.

Original: https://www.builder.io/blog/dont-blame-the-developer-for-what-the-frameworks-did

Let's talk about the tools we have to build web apps and how those tools deceive us.

Common story

You’re starting a new greenfield project, and this time, you’ll make sure that the site will be fast and slick! The starting line looks good, but soon your application gets big, and the startup performance starts to suffer. Before you know it, you have a huge app on your hands, and you are feeling powerless to fix it. Where did you go wrong?

Every tool/framework promises a better, faster result, yet we have the whole internet to tell us that the result is anything but a better, faster web. And who else is there to blame for this but the developers?

They messed up, cut corners, etc., which is why they ended up with a slow site. Or so we’re told.

It's not your fault

If a few sites are slower, then sure, blaming the developer may make sense. “Look, the other sites are fast; clearly, the rest of the world knows how to do it right.” Something like that. Except that is not the world we live in. All sites are slow! How can you blame the developer when no one is succeeding? The problem is systemic. Perhaps it’s not the developer's fault.

This is a story of how we build apps, the tools we use, the promises the tools make, and the world of slowness we end up with. There’s only one conclusion. The tools have over promised, and this is a systemic problem in the industry. It’s not just a few bad apples, but the whole world wide web.

Too much code

We all know what the problem is: too much code! We got so good at creating code that browsers can't keep up with us. No matter where you look, everyone tells you your site has too much JavaScript, yet no one knows how to shrink it down.

It's like a YouTube fitness channel telling you that all you need to do to lose weight is eat fewer calories. Easy advice, and yet the success rate is dismal. The reason is that the advice ignores appetite hormones. How can you keep your will to eat fewer calories when you are hungry, weak and all you can think about is food? The situation is stacked against you. The secret to losing weight may not be cutting calories after all, but controlling your appetite. But when was the last time you heard anyone talk about appetite control?

That’s what it’s like with JavaScript bloat. We know we need less JavaScript, but all of the tools just keep bundling more and more code into your app.

Evolution of bundling

Let's take a look at how we got into this situation first, and then let's discuss a path forward.

Gen 0: Concatenation

Before ECMAScript modules, there was nothing. Just files. Bundling was simple. The files were concatenated together and wrapped in IIF. It was as simple as we could get.

The upside was that it was hard to add more code to your application, so the bundles stayed small. Code reuse just was not a thing with this model. Everyone concatenated code slightly differently.

Gen 1: Bundlers

Enter ECMAScript modules, a proper syntax for importing and exporting your code. This was awesome, but delivering thousands of files to the browser was a problem. And so, a whole cottage industry of bundlers arose: WebPack, Rollup, CommonJS, etc.

Now, code reuse has become possible. However, it was a bit too easy to npm install a dependency and bundle it in. Quickly size became a problem.

To their credit, the bundlers know how to do tree-shaking and dead code elimination. These features make sure that only reachable code gets bundled.

Gen 2: Lazy loading

Recognizing the issue of large bundles, the bundlers started to offer lazy loading. Lazy loading is great as it allows code to be broken up into chunks and delivered to the browser on an as-needed basis. This is great because it allows the application to be delivered in parts, starting with the most needed part. It also allows the paralyzation of download, parsing, and execution.

The problem is that in practice, we build apps using frameworks, and the frameworks have a lot of influence on how bundlers break up our code into lazy loaded chunks. The trouble is that lazy loading a chunk introduces an asynchronous API call—a PROMISE. And if the framework expects a synchronous reference to your code, the bundler can’t introduce a lazy loaded chunk.

We are in a bit of a fallacy. Bundlers truthfully claim that they can lazy load code, but unless the framework can accommodate a PROMISE as a developer, you may not have much of a choice.

Gen 3: Lazy loading components not in the render tree

Frameworks quickly scrambled to take advantage of the lazy loading capability of the bundlers, and today almost all know how to do lazy loading. But there is a BIG caveat! Frameworks can only lazy load components that are not in the current render tree.

What is the render tree? It’s a set of components that make up the current page. An application usually has many more components than are on the current page. A portion of the render tree is the view. It’s what you currently see in the browser viewport. But a render tree encompasses the whole DOM, even the components outside of the current view.

Suppose a component is in the render tree. In that case, the framework must download the component because the framework needs to rebuild the render tree of components as part of Hydration or update. Frameworks can only lazy load components that are currently NOT in the render tree.

Another point is that the frameworks can lazy load components but that always includes behavior. The component unit is too large because it encompasses the behavior. It would be better if the lazy loading unit were smaller. Rendering a component should not require the download of the component's event handlers. The framework should only download the event handlers on user interaction and not as part of the component render method. Depending on the kind of application you are building, the event handlers may represent the bulk of your code. So coupling the download of component's render and behavior is suboptimal.

The core of the problem

It would be great to lazy load the component render function only when the component needs to be rerendered and lazy load the event handlers only if the user is interacting with them. The default should be that everything is lazy loaded.

But there is a big problem with that approach. The issue is that the frameworks need to reconcile their internal state with the DOM. And that means that at least once on application Hydration, they need to be able to do a full render to rebuild the framework's internal state. After the first render, the frameworks can be more surgical about their updates, but the damage has been done, the code has been downloaded. So we have two issues:

Frameworks need to download and execute components to rebuild the render tree on startup. (See Hydration) This forces eager download and execution of all components in the render tree.
The event handlers come with the components even though they are not needed at the time of rendering. The inclusion of event handlers forces the download of unnecessary code.

So the status quo of frameworks today is that every component (and their handlers) in the SSR/SSG render tree must be eagerly downloaded and executed. Lazy loading with today's frameworks is a bit of a lie because you can't do lazy loading on the initial page render.

It’s worth pointing out that even if a developer introduces lazy loaded boundaries into the SSR/SSG initial page, it does not help. The framework will still have to download and execute all of the components in the SSR/SSG response; therefore, as long as the component is in the render tree, the framework will have to eagerly load the components that the developer tried to lazy load.

The eager download of the components in the render tree is the core of the problem, and there is nothing the developer can do about it. Still, that doesn’t stop the developer from getting blamed for how slow the site is. Fun!

Next-Gen: Fine-grained lazy loading

So, where do we go from here? The obvious answer is that we need to go more fine-grained. The solution is both obvious and difficult to implement. We would need to:

Change the frameworks so they don't eagerly load the render tree on hydration.
Allow the component render function to be loaded independently from the component event handlers.

If your framework can do the two parts above, the user would see huge benefits. The application would have lite startup requirements because no rendering would need to happen on startup (the content is already rendered at SSR/SSG). Less code is downloaded. And when the framework determines that a particular component needs to be rerendered, the framework can do so by downloading the render function without downloading all of the event handlers.

Fine-grained lazy loading would be a huge win for site startup performance. It’s much faster because the amount of code downloaded would be proportional to the user interactivity instead of being proportional to the initial render tree complexity. Your sites would become faster, not because we got better at making the code small, but we got better at only downloading what we need rather than downloading everything up front.

Entry points

It’s not enough to have a framework that can do fine-grained lazy loading. Because, to take advantage of fine-grained lazy loading, you must first have bundles to lazy load.

For bundlers to create lazy loadable chunks, bundlers need an entry point for each chunk. If all you have is a single entry point to your application, bundlers can't create chunks. And if that’s true, even if your framework could do fine-grained lazy loading, it would have nothing to lazy load.

Creating entry points is cumbersome today because it requires that the developer writes extra code. When developing the application, we can really only think about one thing, which is the feature. It’s simply unfair to developers to make them think about the feature they’re building and lazy loading at the same time. So in practice, creating entry points for bundlers is not a thing.

What’s needed is a framework that creates the entry points without the developer thinking about it. Creating entry points for the bundlers is a framework’s responsibility, NOT the developer’s responsibility. The developer's responsibility is to build features. The framework's responsibility is to think about the low-level implications of how the feature should be accomplished. If the framework doesn’t do that, then it’s not fully serving the developer's needs.

Overproduction of entry points

The goal should be to create as many entry points as possible. But, some might ask, wouldn’t that cause the download of lots of small chunks rather than a few big ones? The answer is a resounding “no”.

Without an entry point, a bundler can’t create a new chunk. But nothing stops the bundler from putting several entry points into a single chunk. The more entry points you have, the more freedom you have to assemble the bundles in the most optimal way. The entry points give you the freedom to optimize your bundles. The more of them, the better.

The framework of the future

The next-gen frameworks will need to solve these problems:

Have a DX that people love (existing frameworks are there today).
Do fine-grain lazy loading of code.
Automatically generate lots of entry points to support the fine-grained lazy loading.

The developers will build their sites, just as they do today, but the sites will not overwhelm the browser with huge bundles and execution on application startup.

Qwik is a framework that is designed with these principles in mind. Qwik fine-grained lazy loading is per event handler, render function and effect.

Conclusion

Our sites are getting bigger, with no end in sight. They are big because the sites do more today than before—more functionality, animation, etc. We can assume that the trend will continue.

The solution to the above problem is to do fine-grained lazy loading of code so that the browser doesn’t get overwhelmed on the initial page load.

Our bundling tools support fine-grained lazy loading, but our frameworks don’t. Framework hydration forces all components in the render tree to be loaded on hydration. (The only kind of lazy loading framework support today is for components that are currently not in the render tree.) Frameworks also download event handlers with the component even though event handlers can be the bulk of the code and will not be needed for initial hydration.

Because bundlers can fine-grain lazyload, but our frameworks don’t, we fail to recognize the subtlety in this. The result is that we blame the slow site startup on developers because we mistakenly believe that they could have done something to prevent the situation, even though the reality is that they had very little say in this matter.

We need new kinds of frameworks that are designed with fine-grained lazy loading as a core feature of the frameworks (such as Qwik). We can't expect the developers to take on this responsibility; they’re already overwhelmed with features. The frameworks need to think about both lazy loading runtimes as well as creating the entry points so that the bundlers can create the chunks to lazy load. The benefits of the next-gen frameworks would outweigh the cost of switching to them.

Hydration is Pure Overhead

Miško Hevery — Wed, 20 Apr 2022 22:51:30 +0000

Miško HeveryFollow

CTO at Builder.io, empower anyone to create blazing fast sites. Previously at Google, where he created Angular, AngularJS and was co-creator of Karma.

Original: https://www.builder.io/blog/hydration-is-pure-overhead

Hydration is a solution to add interactivity to server-rendered HTML. This is how Wikipedia defines hydration:

In web development, hydration or rehydration is a technique in which client-side JavaScript converts a static HTML web page, delivered either through static hosting or server-side rendering, into a dynamic web page by attaching event handlers to the HTML elements.

The above definition talks about hydration in terms of attaching event handlers to the static HTML. However, attaching event handlers to the DOM is not the challenging or expensive part of the hydration, and so it misses the point of why anyone would call hydration an overhead. For this article, overhead is work that can be avoided and still leads to the same end result. If it can be removed and the result is the same, it is an overhead.

Digging deeper into hydration

The hard part of hydration is knowing WHAT event handlers we need and WHERE they need to be attached.

WHAT: The event handler is a closure that contains the behavior of the event handler. It is what should happen if a user triggers this event.
WHERE: The location of the DOM element where the WHAT needs to be attached to (includes the event type.)

The added complication is that WHAT is a closure that closes over APP_STATE and FRAMEWORK_STATE:

APP_STATE: the state of the application. APP_STATE is what most people think of as the state. Without APP_STATE, your application has nothing dynamic to show to the user.
FRAMEWORK_STATE: the internal state of the framework. Without FRAMEWORK_STATE, the framework does not know which DOM nodes to update or when the framework should update them. Examples are component-tree, and references to render functions.

So how do we recover WHAT (APP_STATE + FRAMEWORK_STATE) and WHERE? By downloading and executing the components currently in the HTML. The download and execution of rendered components in HTML is the expensive part.

In other words, hydration is a hack to recover the APP_STATE and FRAMEWORK_STATE by eagerly executing the app code in the browser and involves:

downloading component code
executing component code
recovering the WHAT(APP_STATE and FRAMEWORK_STATE) and WHERE to get event handler closure
attaching WHAT (the event handler closure) to WHERE (a DOM element)

Let's call the first three steps the RECOVERY phase. RECOVERY is when the framework is trying to rebuild the application. The rebuild is expensive because it requires downloading and executing the application code.

RECOVERY is directly proportional to the complexity of the page being hydrated and can easily take 10 seconds on a mobile device. Since RECOVERY is the expensive part, most applications have a sub-optimal startup performance, especially on mobile.

RECOVERY is also pure overhead. Overhead is work done that does not directly provide value. In the context of hydration, RECOVERY is overhead because it rebuilds information that the server already gathered as part of SSR/SSG. Instead of sending the information to the client, the information was discarded. As a result, the client must perform expensive RECOVERY to rebuild what the server already had. If only the server had serialized the information and sent it to the client along with HTML, the RECOVERY could have been avoided. The serialized information would save the client from eagerly downloading and executing all of the components in the HTML.

The re-execution of code on the client that the server already executed as part of SSR/SSG is what makes hydration pure overhead: that is, a duplication of work by the client that the server already did. The framework could have avoided the cost by transferring information from the server to the client, but instead, it threw the information away.

In summary, hydration is recovering event handlers by downloading and re-executing all components in the SSR/SSG-rendered HTML. The site is sent to the client twice, once as HTML, and again as JavaScript. Additionally, the framework must eagerly execute the JavaScript to recover WHAT, WHERE, APP_STATE, and FRAMEWORK_STATE. All this work just to retrieve something the server already had but discarded!!

To appreciate why hydration forces duplication of work on the client, let's look at an example with a few simple components.

We'll use a popular syntax understood by many people, but keep in mind that this is a general problem not specific to any one framework.

    export const Main = () => <>
       <Greeter />
       <Counter value={10}/>
    </>

    export const Greeter = () => {
      return (
        <button onClick={() => alert('Hello World!'))}>
          Greet
        </button>
      )
    }

    export const Counter = (props: { value: number }) => {
      const store = useStore({ count: props.number || 0 });
      return (
        <button onClick={() => store.count++)}>
          {count}
        </button>
      )
    }

The above will result in this HTML after the SSR/SSG:

    <button>Greet</button>
    <button>10</button>

The HTML carries no indication of where event handlers or component boundaries are. The resulting HTML does not contain WHAT(APP_STATE, FRAMEWORK_STATE) or WHERE. The information existed when the server generated the HTML, but the server did not serialize it. The only thing the client can do to make the application interactive is to recover the information by downloading and executing the code. We do this to recover the event handler closures that close over the state.

The point here is that the code must be downloaded and executed before any event handler can be attached and events processed. The code execution instantiates the components and recreates the state (WHAT(APP_STATE, FRAMEWORK_STATE) and WHERE).

Once hydration completes, the application can run. Clicking on the buttons will update the UI as expected.

Resumability: a no-overhead alternative to hydration

So how do you design a system without hydration and therefore, without the overhead?

To remove overhead, the framework must not only avoid RECOVERY but also step four from above. Step four is attaching the WHAT to WHERE, and it's a cost that can be avoided.

To avoid this cost, you need three things:

Serialize all of the required information as part of the HTML. The serialized information needs to include WHAT, WHERE,APP_STATE, and FRAMEWORK_STATE.
A global event handler that relies on event bubbling to intercept all events. The event handler needs to be global so that we are not forced to eagerly register all events individually on specific DOM elements.
A factory function that can lazily recover the event handler (the WHAT).

A factory function is the key! Hydration creates the WHAT eagerly because it needs the WHAT to attach it to WHERE. Instead, we can avoid doing unnecessary work by creating the WHAT lazily as a response to a user event.

The above setup is resumable because it can resume the execution where the server left off without redoing any work that the server already did. More importantly, the setup has no overhead because all of the work is necessary and none of the work is redoing what the server already did.

A good way to think about the difference is by looking at push and pull systems.

Push (hydration): Eagerly download and execute code to eagerly register the event handlers, just in case of user interaction.
Pull (resumability): Do nothing, wait for a user to trigger an event, then lazily create the handler to process the event.

In hydration, the event handler creation happens before the event is triggered and is therefore eager. Hydration also requires that all possible event handlers be created and registered, just in case the user triggers the event (potentially unnecessary work). So event handler creation is speculative. It is extra work that may not be needed. (The event handler is also created by redoing the same work that the server has already done; hence it is overhead)

In a resumable system, the event handler creation is lazy. Therefore, the creation happens after the event is triggered and is strictly on an as-needed basis. The framework creates the event handler by deserializing it, and thus the client does not redo any work that the server already did.

The lazy creation of event handlers is how Qwik works, which allows it to create speedy application startup times.

Resumability requires that we serialize WHAT(APP_STATE, FRAMEWORK_STATE) and WHERE. A resumable system may generate the following HTML as a possible solution to store WHAT(APP_STATE, FRAMEWORK_STATE) and WHERE. The exact details are not important, only that all of the information is present.

<div q:host>
    <div q:host>
        <button on:click="./chunk-a.js#greet">Greet</button>
    </div>
    <div q:host>
        <button q:obj="1" on:click="./chunk-b.js#count[0]">10</button>
    </div>
</div>
<script>/* code that sets up global listeners */</script>
<script type="text/qwik">/* JSON representing APP_STATE, FRAMEWORK_STATE */</script>

When the above HTML loads in the browser, it will immediately execute the inlined script that sets up the global listener. The application is ready to accept events, but the browser has not executed any application code. This is as close to zero-JS as you can get.

The HTML contains the WHERE encoded as attributes on the element. When the user triggers an event, the framework can use the information in the DOM to lazily create the event handler. The creation involves the lazy deserializing ofAPP_STATE and FRAMEWORK_STATE to complete the WHAT. Once the framework lazily creates the event handler, the event handler can process the event. Notice that the client is not redoing any work that the server has already done.

A note on memory usage

The DOM elements retain the event handlers for the lifetime of the element. Hydration eagerly creates all of the listeners. Therefore hydration requires allocating a memory on startup.

Resumable frameworks do not create the event handlers until after the event is triggered. Therefore, resumable frameworks will consume less memory than hydration. Furthermore, the resumable approach does not retain the event handler after execution. The event handler is released after its execution, returning the memory.

In a way releasing the memory is the opposite of hydration. It is as if the framework lazily hydrates a specific WHAT, executes it, and then dehydrates it. There is not much difference between the first and nth execution of the handler. Event handlers' lazy creation and release does not fit the hydration mental model.

Conclusion

Hydration is overhead because it duplicates work. The server builds up the WHERE and WHAT (APP_STATE and FRAMEWORK_STATE), but the information is discarded instead of being serialized for the client. The client then receives HTML that does not have sufficient information to rebuild the application. The lack of information forces the client to eagerly download the application and execute it to recover the WHERE and WHAT (APP_STATE and FRAMEWORK_STATE).

An alternative approach is resumability. Resumability focuses on transferring all of the information from the server to the client. The information contains WHERE and WHAT (APP_STATE and FRAMEWORK_STATE). The additional information allows the client to reason about the application without downloading the application code eagerly. Only a user interaction forces the client to download code to handle that specific interaction. The client is not duplicating any work from the server; therefore, there is no overhead.

To put this idea into practice, we built Qwik, a framework that is designed around resumabilty and achieves excellent startup performance. We're also excited to hear from you! Let's keep the conversations going and get better as a community at building faster web applications for our users.

— Love from the Builder.io team.

PS: Many thanks to Ryan Carniato, Rich Harris, Alex Patterson, Dylan Piercey, Alex Russell, Steve Sewell who provided constructive feedback for the article. ❤️

We know you have a few burning questions. That's why we've put together an FAQ to address them all.

Why coin a new term?

Resumability does not have a clear line indicating that component X is or is not hydrated. If you insist on saying that Qwik hydrates, then you have two choices:

Qwik apps are hydrated when the global event handler is registered. It does not feel right because no app code has been downloaded, and no work has been performed.
Qwik apps are hydrated when the first interaction parses the serialized state. Hydration is attaching event listeners for interactivity. Deserializing state is there to recover the application's state and has nothing to do with registering event handlers. There are situations where the deserialization does not need to happen, and when it does, it happens after the event has been triggered. The other problem is that deserialization of state restores state even for components that have not been or will never be downloaded. So while it's tempting to assume that this is the point of hydration, we think of it as just lazy deserialization of app state as it does not directly relate to event processing.

Neither of these options feels satisfactory, and so we're coining a new term. You could define hydration as making the app interactive, but such a definition is so broad that it will apply to everyone, which will make it less valuable. So while it may sound like we're splitting hairs, we like to talk about hydration vs. resumability as we believe it better captures the massive difference in the amount of work required to make the application interactive.

Is resumability just hydration after the event?

It's certainly a valid way to look at it. However, there's one big difference. Resumability does not require that the framework download and execute the components to learn about the component hierarchy. Resumability requires that all of the framework's information be serialized in the HTML, including:

Location of the event listeners and event types.
Where to download the event
Component boundaries
Component props
Projection/children
Where to download the component re-render functions if needed

Since the framework deserializes all of this information and continues the execution where the server left off, resumable is a much better word.

What are real world results like? Where can I see a site that uses a resumable strategy?

Builder.io used the resumable strategy (and Qwik) to redo our website. We’ve removed 99% of JavaScript from startup and the resulting app feels super snappy even on mobile. Using Qwik and Partytown, we were able to cut down 99% of the JavaScript in our site and get a PageSpeed score of 100/100. (You can still visit the old page using hydration [PageSpeed 50/100] and compare it to the new page using resumability [PageSpeed 100/100] to experience the performance difference for yourself.)

Qwik's documentation is running on Qwik. You can look under the hood by opening up the dev tools (incognito) in your browser and notice the lack of Javascript on startup. (The page also uses Partytown to move third-party analytics to web workers.)

Finally, check out a to-do app demo running on Cloudflare edge. This page is ready for interaction in about 50 ms!

My framework knows how to do progressive and/or lazy hydration. Is that the same thing?

No, because progressive/lazy hydration still can't continue where the server left off. All component code needs to be downloaded and executed to recover and install the event handlers.

With resumability, many components will never download because they never change. But these components can pass props to child components or create content that the child component projects. So even if not interactive, the components' state needs to be recovered by re-execution. Recovering props is why islands that enable progressive/lazy hydration can't be arbitrarily small.

Simply put, resumability requires significantly less code to download and execute to handle a user interaction than hydration.

My framework knows how to create islands. Is that the same thing?

The island architecture breaks up the application into islands. Each island can then be hydrated independently. Instead of one big hydration, the total amount of work is now spread over many smaller hydration events. Typically, a trigger causes the island to hydrate lazily instead of eagerly on startup.

This means island-based hydration is an improvement as it can break the work down into smaller chunks and delay its execution, but it's still hydration and not the same as resumability.

My framework knows how to serialize the state. Does it have overhead?

The issue here is that the word state is overloaded. Yes, there are some meta frameworks that can serialize the state. But here, "state" means APP_STATE, not FRAMEWORK_STATE. I'm unaware of any popular framework (or meta-framework) that can serialize FRAMEWORK_STATE. Additionally, even if FRAMEWORK_STATE was serialized, the WHAT and WHERE are not.

Yes, serialization of state (APP_STATE) is useful and avoids a lot of work on the client. But it still results in hydration.

Is a component hydrated on first interaction?

If you look at the internal state of a resumable framework, you'll find no difference between the first interaction of the component and subsequent interactions. The only difference is that the framework has parsed the serialized state. And once the state is parsed, it applies to all components, not just the one the user has interacted with. At any point, the framework can serialize the state back to the HTML. Does that mean that the application is no longer hydrated? From that point of view, deserialization of state hydrates all components, even if their code has not been downloaded.

How can I take advantage of resumability today?

The framework controls the kind of recovery strategies it uses to make the application interactive. Therefore, to take advantage of resumability, your application needs to be using one of the frameworks which support it. Currently, we are only aware of Qwik which aims explicitly for resumability. The benefits of resumability are too great to be ignored, so I'm sure that other frameworks will start using this strategy in the future, whether they're new frameworks or existing frameworks that choose to migrate to resumability.

Is there a delay on first interaction?

Not when you use prefetching. Qwik is unopinionated about prefetching - we have used a variety of strategies for prefetching (eager, on visible, analytics-driven) to great results. In most cases, we find prefetching in a Web Worker, such as with Partytown, leads to the best balance of 0 cost and high speed. We will bake best practices into the framework and provide examples with recommended patterns over time.

Can I use my React/Angular/Vue/Svelte components with Qwik?

Rewriting an application is a huge undertaking. To lower the barrier to entry, we are looking into creating interoperability with some of today's more popular frameworks. Qwik will be your orchestrator delivering instant applications startup, but it will still work with most of the existing code investment. Think of Qwik can as the orchestrator for your current application. This way, you don't have to rewrite the whole application but still get some benefits. This is a work in progress, so stay tuned.

And if you are curious what is coming up next for Qwik:

If you made it this far, thanks for reading! Learn more about Qwik here, or follow us on Twitter to get updates as we have them

From Static to Interactive: Why Resumability is the Best Alternative to Hydration

Miško Hevery — Thu, 31 Mar 2022 01:01:14 +0000

Miško HeveryFollow

CTO at Builder.io, empower anyone to create blazing fast sites. Previously at Google, where he created Angular, AngularJS and was co-creator of Karma.

Original: https://www.builder.io/blog/from-static-to-interactive-why-resumability-is-the-best-alternative-to-hydration

No one wants a slow, unresponsive website. Prerendering your site is one of your most powerful tools as a web developer when it comes to website performance optimization.

Almost all front-end JavaScript (JS) frameworks have a way to prerender content as HTML through server side rendering (SSR) or static site generation (SSG). The result is that the site displays almost instantly as the HTML is streamed into your user’s browser.

However, there’s a problem. HTML is static whereas websites are usually dynamic and interactive. How do frameworks make pre-rendered HTML interactive on the browser?

The current generation of frameworks solves this through a client-side process called hydration, a resource-intensive process that adds significant overhead to the page’s startup cost.

Here’s my controversial opinion: hydration is what happens when you add SSR/SSG as an afterthought to a front-end framework.

A framework designed from the ground up for prerendering can avoid hydration and its performance penalty by serializing state on the server and resuming it on the client.

Before diving into serialization and resumability, let’s talk about the problem that hydration solves.

How does a framework make a page interactive?

Any front-end framework needs three things to be able to respond to interactivity:

Associating event handlers: The framework must have a way to associate DOM elements with their corresponding event handlers, which are the functions that respond to user input and enable interaction with your website.
Recovering application state: Once a user event triggers an event handler, the function updates application state.
Recreating the component hierarchy: Once the application state updates, the framework needs to re-render the application view to reflect the state to the user. The framework must understand the relationship between the state and the components to complete rendering.
Let's look deeper into how hydration handles these tasks and why it’s an expensive approach.

Associating event handlers

Frameworks associate event handlers with specific DOM elements by executing a component template. For example, in React, a button component written in JSX might have an onClick prop with an event handler. Hydration requires that the browser downloads and executes all components’ templates before associating event handlers.

Unfortunately, the JS bundle’s download size and code execution time is proportional to the complexity of the page. A small demo page will download a small amount of JS and execute quickly, but the bootstrap cost becomes prohibitively expensive when it comes to real-world pages, often leading to multi second times to interactive (TTI).

Some frameworks mitigate this performance penalty by attempting to delay when certain parts of a page are rendered. This strategy works reasonably well for content-centric pages such as marketing pages. For sites like web apps where components share state in complex ways, however, frameworks still need to download every component in the DOM tree and execute its template.

Recovering application state

Event handlers need an application state to update, which is present on the server during prerendering. Frameworks must reconstruct this state on the client for the DOM to update properly.

Hydration’s basic approach is to execute the same code that generated the application state on the server again within the browser, which adds to execution time and delays interactivity.

That’s why many meta-frameworks serialize the application state on the server and include it in the HTML so that state can be restored using JSON.parse(). Deserialization is significantly faster than reconstructing state by executing application code on the browser, and it works well for simple and complex pages.

Even when application state is serialized, however, hydration still reconstructs internal framework state by slowly executing code.

Recreating the component hierarchy

For the final piece, frameworks need to recreate the component hierarchy, which is part of a framework’s internal state. It keeps track of which components need to be rerendered when your application state changes.

Similar to how it associates event handlers with DOM elements, hydration must download all of a page’s components and execute their templates to rebuild a component hierarchy, adding still more overhead.

The alternative to hydration

Front-end frameworks perform hydration to recover event handlers, application state, and the component hierarchy in order to make the page interactive.

Each step requires downloading and executing code, which is expensive. Code execution time in particular is proportional to your page’s complexity when using hydration. We could roughly model this limitation with an equation:

Time to interactive = hydration execution cost * page complexity + payload size

No matter how small your payload, hydration will always be a bottleneck.

One solution to this problem is to eliminate the need to execute any code to restore a page’s interactivity, which we can do through serialization. As mentioned above, many meta-frameworks already serialize application state. Why not serialize event handler associations and component hierarchies, as well?

Because it’s really hard!

Function closures, promises, and resource references, among other structures, are all difficult to serialize. So a framework needs to be designed with serializability and resumability in mind. These aren’t features that can easily be added to existing frameworks without large-scale breaking changes.

The biggest win of serializing page state into HTML is that making the page interactive doesn’t require downloading or executing any template code. The framework simply resumes the page.

The bottom line? Resumable frameworks would reduce execution cost to zero and incur a constant overhead regardless of page complexity.

Resumability in Qwik

We at Builder.io have created a resumable front-end framework, Qwik. Our goal is to bring every web page’s time to interactive to its absolute minimum.

While we got the ball rolling, Qwik is open to the community. Everyone who’s as passionate about web performance as we are is invited to try it out and contribute and comment.

Head over to Qwik’s repository to learn more, or try our starter: npm init qwik@latest.

If you have any questions, ask away on our discussions forum and join our Discord server.

Introducing Qwik starters - get up and running with Qwik now

Miško Hevery — Tue, 14 Dec 2021 22:25:03 +0000

Nothing is more satisfying than playing with code and discovering new things! Yes, it is finally here, npm init qwik for you to try and discover a different way to build web apps that stay lean and performant no matter their size. It is the same technology that is powering builder.io and gets 100/100 PageSpeed.

Qwik starter CLI is a simple starter for you to try experimenting with Qwik first hand and to get a better understanding of just how different it is.

The CLI consist of these four examples, that will be expanded in the near future:

starter: A basic hello world.
starter-builder: A basic hello world integrated with Builder's Qwik API.
starter-partytown: A basic hello world showing how expensive tasks can be run on web-worker with Partytown
todo: A classic TodoMVC application.

Basic starter

> npm init qwik
💫 Let's create a Qwik project 💫

✔ Project name … qwik-starter
✔ Select a starter › Starter
✔ Select a server › Express

⭐️ Success! Project saved in qwik-starter directory

📟 Next steps:
   cd qwik-starter
   npm install
   npm start

> (cd qwik-starter; npm install; npm start)

Try it in StackBlitz.

Starter with Builder Qwik API

> npm init qwik
💫 Let's create a Qwik project 💫

✔ Project name … qwik-builder
✔ Select a starter › Starter Builder
✔ Select a server › Express

⭐️ Success! Project saved in qwik-builder directory

📟 Next steps:
   cd qwik-builder
   npm install
   npm start

> (cd qwik-builder; npm install; npm start)

Try it in StackBlitz.

Starter with Partytown

> npm init qwik
💫 Let's create a Qwik project 💫

✔ Project name … qwik-partytown
✔ Select a starter › Starter Partytown
✔ Select a server › Express

⭐️ Success! Project saved in qwik-partytown directory

📟 Next steps:
   cd qwik-partytown
   npm install
   npm start

> (cd qwik-partytown; npm install; npm start)

Classic TodoMVC

> npm init qwik
💫 Let's create a Qwik project 💫

✔ Project name … qwik-todo
✔ Select a starter › Todo
✔ Select a server › Express

⭐️ Success! Project saved in qwik-todo directory

📟 Next steps:
   cd qwik-todo
   npm install
   npm start

> (cd qwik-todo; npm install; npm start)

Try it now in StackBlitz.

Profile away

We encourage you to open the dev tools and put all of the examples through the profiler to see how little time is spent on the main thread.

Happy coding and please provide feedback:

Star us on github.com/builderio/qwik
Follow us on @QwikDev and @builderio
Chat us on Discord
Join builder.io

How we cut 99% of our JavaScript with Qwik + Partytown

Miško Hevery — Mon, 06 Dec 2021 15:32:07 +0000

We’re excited to announce that the builder.io homepage now achieves a 100/100 score on PageSpeed Insights, even on mobile, since we adopted Qwik.

Qwik can achieve this performance no matter how large your application gets. The above numbers were achieved with some cool technology including:

Pages served with Qwik have less than 1kb of JavaScript to boot.
Our homepage only sends HTML for above-the-fold content.
Partytown is used to move all third-party scripts to web-worker.
This site is created using builder.io’s visual no-code editor

Qwik scales to massive sites, with hundreds of components, and MBs of content and continues to be fast. And it provides interactive server-side components that can transition to client components.

Where were we before

Our story starts here:

Notice that the performance of the site is average. On mobile, Google PageSpeed estimated that it will take 7.6 seconds before a user can click on a link and expect a response. This is not a great user experience. Additionally, Google is using PageSpeed scores to affect SEO ranking.

The reason for this is that the site has to execute a lot of Javascript on startup. Today, even a static site is full of JavaScript to add menus, interactivity, and third-party analytics scripts such as Google Tag Manager, Intercom, and CRM services.

The JavaScript site consists of two sources of slow down, the site itself and third-party scripts.

The first source of slow down comes from frameworks. When used in conjunction with modern frameworks, sites have a great developer experience and are highly interactive. But this comes at a cost of large JS download and slow startup times as frameworks reconcile the HTML generated on the server with the DOM the frameworks expect. This is known as reconciliation/rehydration, and all frameworks (with exception of Qwik) suffer this fate. The key part of reconciliation/rehydration is when the frameworks attach the listeners to the DOM, making the site interactive. This is the reason why reconciliation/rehydration has to happen as soon as possible. Without this, your site does not work (think menus, chat widgets, etc...)

The second source of slow down comes from third-party scripts. Yes, there are a lot of demo sites and “new builds” that show good PageSpeed scores, but this is in large part because third-party scripts are not yet included. Here is an example of some of the third-party scripts which are on our site:

Google Tag Manager: is a must for any live site to collect usage statistics so that the marketing can gain insight as to how the site is used and how it can be improved. GTM executes at the beginning and it alone can take up all of the CPU time allotted for the site in PageSpeed before it starts being penalized.
Intercom: Allows the customers to chat with builders in real-time on the site to ask questions and to find out more information.
Twitter: Testimonials about our product are shown in twitter widgets, which requires that we load Twitter javascript.

All of the above third-party scripts run immediately on-site load and compete for CPU with the reconciliation/rehydration step above, resulting in poor user experience.

The issue is that as developers we have very little control over the above situation. We must use third-party scripts to add analytics and user service features that marketing teams need, and we must use existing frameworks which require expensive reconciliation on-site startup. There just are not a lot of levers under our control. This is the state of our industry and it is why no one can get much better results with the standard approach.

Qwik and Partytown aim to solve that!

Where are we now

Metric	Before	After	Unit	%
Performance Score	52	100	s	92%
First Contentfull Paint	3.4	1.1	s	309%
Speed Index	3.4	1.1	s	309%
Largest Contentful Paint	3.8	1.2	s	316%
Time to Interactive	7.6	1.4	s	543%
TTI - LCP (difference)	3.8	0.3	s	1,266%
Total Blocking Time	1,300	40	ms	3,250%
Cumulative Layout Shift	0	0		-

First, a reminder that these numbers are for mobile, a much harder bar to reach than desktop performance.

The above table shows where we are now with Qwik and Partytown. The improvements are massive. Time to interactive dropped from 7.6 seconds down to 1.2 seconds. And total blocking time dropped from 1.3 seconds down to 40 milliseconds. The drop in JS execution can directly be attributed to Qwik for framework time and Partytown for third-party time.

Above is the performance profile before Qwik/Partytown. (This is emulating mobile)

Page took 1.8 seconds to load.
The main thread is very busy most of the time with "reconciliation" work (Figuring out where the DOM listeners should be placed.)
The above results in many dropped frames.
There is a cascade of JS code loading before the main thread gets busy with "reconciliation".

Compare the previous expensive startup with the Qwik/Partytown combination?

No JS download
Page took 0.5 seconds to load.
Main thread is mostly idle.
Very few dropped frames.
Party town loads later
3rd party scripts execute in web worker (rather than main thread)

The comparison between the previous and current performance is night and day.

The main thing to take away is not that Qwik/Partytown have some clever algorithm. Instead, Qwik/Partytown offloads the main thread from almost all JS, which is why the page loads so fast. But with Qwik, the page remains fully interactive, even with almost no JS. Qwik lets you have your cake and eat it too. Let's look at JavaScript usage.

Metric	minified	compressed
Baseline (Main Thread JS)	1,800kB	326kB

Qwik + Partytown (Main Thread JS)*	3.5kB	2.5kB
--> part: Qwikloader	.5kB	1kB
--> part: Partytown confg	.5kB	1kB
--> part: Partytown	2.5kB	1.5kB
=== Size Improvement ===	51,429%	13,000%


WebWorker 3rd Party JS	219kB	82kB
--> part: Zoominfo	1.5kB	1.3kB
--> part: Google Tag Manager	167kB	60kB
--> part: Google Analytics	50kB	21kB
--> part: site-tracking	217kB	64kB

We went from 1.8MB of JavaScript on the Main thread down to 3.5kB. WOW!

The original site had 1.8MB of JavaScript, out of that 219kB was a third-party scripts which as developers we have no control over. That leaves 1.6MB of JavaScript for the site itself. The 1.6Mb contains the framework, templates, and styling needed to rehydrate the site back to full interactivity. When using standard frameworks your site will download the content twice. Once as HTML and again as JavaScript. The double download is what accounts for 1.6MB of code. (You know it is site templates because it compresses really well down to 244kB.)

Contrast the baseline with Qwik + Partytown which comes in at 3.5kB (2.5kB compressed.) Let me repeat that to make it clear. With Qwik + Partytown the only JavaScript which needs to execute on the main thread comes to 3.5kB! This is the reason why the site is so fast to load because there is nothing for the MainThread to do. The other thing to point out is that the 3.5kB will stay no matter how complicated your site gets, it is a fixed cost.

We still have the issue of executing third-party code, but that has been relocated to the WebWorkerThread which runs at a lower priority than MainThred. There all 220kB of third-party code can do its thing without affecting the MainThread performance.

But there is one more thing to point out. Above we mentioned that existing frameworks need to download the site twice. Once as HTML and again as JavaScript which comes to 1.6MB. Here is where Qwik gets to shine. Qwik takes that 1.6MB and breaks it up into multiple separate chunks. Qwik can then download only a small portion of that whole JavaScript and only on user interaction. Qwik can rehydrate components lazily and out of order. This means there is no JavaScript needed until the user interacts with something on the page. And because the hydration is independent for each component only a small piece of JavaScript needs to be downloaded and executed on user interaction to hydrate only that component that the user interacted with. So there are two benefits:

We don't have to do anything on page startup, and
when we do have to rehydrate, it is scoped to a single component only (rather than to the whole page).

The last thing to point out is that the vast majority of the page is static, which means those components will never hydrate and thus the JavaScript for those components will never download.

What is Qwik?

Qwik is a new kind of web framework that focuses on time-to-interactive. Resumability means that Qwik can start executing on the server, can be serialized into HTML, and sent to the client. On the client, qwikloader.js (less than 1kb JS on the client) sits idly waiting for user interaction. When a user interacts, Qwik can resume execution where the server left off. Resumability means that Qwik does not have to do reconciliation on startup and only the component you interact with needs to be hydrated. Qwik can create components on the server and then move them to the client in a seamless way. All of the above results in instant-on applications as is demonstrated above.

Lazy loading of content below the fold

Qwik keeps all of its state in DOM, which means that Qwik itself is stateless. The stateless property allows for the lazy loading of content below the fold.

The above is very difficult to do with existing frameworks but is trivial with Qwik.

What is Partytown?

Partytown allows you to relocate third-party scripts into web-worker. Third-party scripts are often the biggest culprit for making the site how slow time-to-interactive.

What is next?

We are hard at work on getting Qwik into your hands soon so you can see for yourself what kind of amazing things you can build.

Your bundler is doing it wrong

Miško Hevery — Mon, 30 Aug 2021 15:40:16 +0000

Today's bundlers rely on developers to decide where and when the application code should be lazy loaded. This is done by developers inserting dynamic imports into their codebase like so:

async function doSomething() {
  const chunk = await import('./my-chunk');
  console.log(chunk.someSymbol);
}

Developer needs to:

Decide where in code a good place for lazy loading would be.
Lazy load in a way that is compatible with the existing application workflow. (Lazy loading is inherently asynchronous, and the ideal function to do perform the lazy loading may be synchronous, limiting where the lazy loading code can be placed.)
Assign a chunk name ./my-chunk which will influence what the bundler can name its chunks, and how it can put chunks together into an application.
Determine what will go into the chunk (e.g. should symbolA and symbolB go into the same chunk, or should they go to separate chunks?).

The issue with the above is that when a developer is writing source code, they have no idea if the location they chose is a good place to have a lazy loaded boundary, or if the chunks have the right symbols. This information is not available until the application is deployed and the results of real-world usage are observed. For example, maybe the settings page is rarely visited and so it should be pulled out of the main bundle. Alternatively, maybe the notification section is lazy loaded but it is the most frequented page by users, so the lazy loading is only making the experience worse.

To make matters worse, once a developer makes these choices there is very little the bundler can do to compensate for them. The bundler pretty much MUST do what the developer asked for. To give the bundler more freedom, we need to look at the problem in a fresh new way.

My point is that when we write code we have no idea what the final bundles should look like and, therefore, don't have sufficient information to decide where to put the dynamic imports. On the other hand, by the time we collect sufficient data on what ideal chunks should look like the source code is already written. Inserting dynamically imports retroactively may be a huge undertaking. (Or alternatively, we over lazy loaded and broke the app into far too many small pieces.)

What we want is the ability to decide what the ideal number of chunks should be and move the code between those chunks based on how real users use our application. We also want to do that without having to go back and refactor our source code. Chunk layout should be configuration information we pass into the bundler, rather than code we embed into our codebase.

To add even more complexity, all of the current generation of frameworks have synchronous rendering pipelines. This makes it very difficult to insert asynchronous dynamic imports into the application.

If we want an optimal lazy loading strategy we need to solve the problems above.

Enter Qwik

Components are the basic building blocks of Qwik applications. Qwik asks you to breaks up the component into three parts:

view: Contains the JSX code which renders the visual portion of the component.
state factory: Contains code that creates a new component state.
event handlers: Contains code used for component behavior/user interactions.

Why break up components into three parts?

Most frameworks keep view, state, and handler code together. Here is an example of how a pseudo framework might achieve this:

export function Counter(props: {step?:number}) {
 const [count, setCount] = useState({count: 50});
 const step = props.step || 1;
 return (
   <div>
     <button onclick={() => setCount(count - step)}>-</botton>
     <span>{count}</span>
     <button onclick={() => setCount(count + step)}>+</botton>
   </div>
 )
}

Note that the components view, state, and handler are all inlined together. The implication is that all of these parts (view, state, and handler) have to be downloaded, parsed, and executed together. This severely limits our lazy loading capability.

The example above might be trivial, but imagine a more complex version of the above, which requires many KB worth of code to be downloaded, parsed, and executed together. In such a case, requiring the view, state, and handler to be eagerly loaded together might be a problem. Let's look at some common user usage patterns to get a better idea as to why this is an issue:

User interacts with a component by clicking on it:

some of the handlers are needed: Only the specific handler which is triggered needs to be downloaded. All other handlers are not needed.
view is not needed: View may not be needed because the handler may not cause a re-render on may cause a re-render of a different component.
state factory is not needed: The component is being rehydrated and so no state initialization code is needed.

Component state is mutated:

handlers are not needed: No handlers need to execute.
view is needed: View is needed because the component needs to be rerendered.
state factory is not needed: The component is being rehydrated and so no state initialization code is needed.

New component is created by the parent:

handlers are not needed: No handlers need to execute.
view is needed: View is needed because the component needs to be rendered.
state factory is needed: The component is being created and so state initialization code is needed.

What the above demonstrates is that in each use-case only part of the view, state, handler information is required. The problem is that we have three distinct pieces of information which are all inlined together, but we only need to use them at different times of the component lifecycle. To achieve the optimal performance we need a way to download and execute the component in parts, based on what the component needs to do. The above code, as it is written, is permanently bound together.

Breaking up is easy to do

Qwik solves this by only downloading and executing the code that is needed for the task at hand. Keep in mind that while the example above is simple, the complexity of the code is significantly larger in real-world scenarios. Furthermore, more complex code oftentimes contains more imports (which in turn have imports of their own), that adds even more code to the component.

It is not possible to "tool" our way out of this. It isn’t possible to write a statically analyzable tool that can separate these pieces into parts that can then be lazy loaded as needed. The developer must break up the component into the corresponding parts to allow fine-grain lazy loading.

Qwik has qrlView, qrlState and qrlHandler marker functions for this purpose.

file: my-counter.tsx

import {
 QComponent,
 qComponent,
 qrlView,
 qrlHandler,
 qrlState
} from '@builder.io/qwik';

// Declare the component type, defining prop and state shape.
export type Counter = QComponent<{ step?: number }, 
                                   { count: number }>;

// Declare the component's state factory. This will be used 
// when new component is being created to initialize the state. 
// (It will not be used on rehydration.)
export const CounterState = qrlState<Counter>(() => {
  return { count: 0 };
});

// Define the component's view used for rendering the component.
export const CounterView = qrlView<Counter>((props, state) => {
 return (
   <div>
     <button on:click={Counter_update.with({ direction: -1 })}>
       -
     </button>
     <span>{state.count}</span>
     <button on:click={Counter_update.with({ direction: 1 })}>
       +
     </button>
   </div>
 );
});

// Component view may need handlers describing behavior.
export const Counter_update
   = qrlHandler<Counter, {direction: number }>(
       (props, state, params) => {
         state.count += params.direction * (props.step || 1);
       }
     );

// Finally tie it all together into a component.
export const Counter = qComponent<Counter>({
 state: CounterState,
 view: CounterView,
});

Compared to other frameworks, the above is wordier. However, the cost of the explicit break up of components into their parts gives us the benefit of fine-grained lazy loading.

Keep in mind that this is a relatively fixed DevExp overhead per component. As the component complexity increases, the added overhead becomes less of an issue.
The benefit of this is that tooling now has the freedom to package up the component in multiple chunks which can be lazy loaded as needed.

What happens behind the scenes

qrlState, qrlHandler, qrlView are all markers for Qwik Optimizer, which tell the tooling that it needs to transform any reference to it into a QRL. The resulting files can be seen here:

File: my-counter.js

import {qComponent, qrlView, qrlHandler, qrlState} from '@builder.io/qwik';

export const CounterState = qrlState(() => ({
 count: 0,
}));

export const CounterView = qrlView((props) => {
 const state = getState(props);
 return (
   <div>
     <button on:click="/chunk-pqr#Counter_update?direction=-1">
       //              ^^^^^^^^^^^^^^^^^ LOOK ^^^^^^^^^^^^^^^^
       -
     </button>
     <span>{state.count}</span>
     <button on:click="/chunk-pqr#Counter_update?direction=1">
       //              ^^^^^^^^^^^^^^^^^ LOOK ^^^^^^^^^^^^^^^^
       +
     </button>
   </div>
 );
});

export const Counter_update = qrlHandler(
  (props, state, params) => {
         state.count += params.direction * (props.step || 1);
);


export const Counter = qComponent({
 state: '/chunk-abc#CounterState', // <<=== LOOK
 view: '/chunk-cde#CounterView',   // <<=== LOOK
});

In addition to the source file transformation, the optimizer removed any static references between the view, state, and handlers. Qwik also generates entry point files for the rollup. These entry points match the QRLs above.

File: chunk-abc.js

export { CounterState } from './my-counter';

File: chunk-pqr.js

export { Counter_update } from './my-counter';

File: chunk-cde.js

export { CounterView } from './my-counter';

The important thing to note is that Qwik has great freedom on how many entry files should be generated, as well as which export goes into which entry file. This is because the developer never specified where the lazy loading boundaries are. Instead, the framework guided the developer to write code in a way that introduced many lazy loading boundaries in the codebase. This gives Qwik the power to generate optimal file distribution based on actual application usage. For small applications, Qwik can generate a single file. As the application size grows, more entry files can be generated. If a particular feature is rarely used, it can be placed in its own bundle.

Once Rollup processes the entry files, the resulting files are as seen below:

File: chunk-abc.js

import { qrlState } from '@builder.io/qwik';

export const CounterState = qrlState(() => ({
 count: 0,
}));

File: chunk-pqr.js

import { qrlHandler} from '@builder.io/qwik';

export const Counter_update = qrlHandler(
  (props, state, params) => {
         state.count += params.direction * (props.step || 1);
);

File: chunk-cde.js

import { qrlView} from '@builder.io/qwik';

export const CounterView = qrlView((props, state) => {
 return (
   <div>
     <button on:click="/chunk-pqr#Counter_update?direction=-1">
       -
     </button>
     <span>{state.count}</span>
     <button on:click="/chunk-pqr#Counter_update?direction=1">
       +
     </button>
   </div>
 );
});

Notice that Rollup flattened the contents of files into the entry files and removed any unneeded code, resulting in ideally sized bundles.

Constraints

In order for the tooling to be able to move qComponent, qrlState, qrlHandler around the usage of these methods is restricted. (Not every valid JS program is a valid Qwik program.) The constraint is that all of the marker functions must be a top-level function that is exported.

Examples of invalid code:

import { someFn } from './some-place';

function main() {
 const MyStateFactory = qrlState(() => ({})); // INVALID not top level
}

const MyStateFactory = qrlState(() => someFn({ data: 123 })); // VALID imports OK

Tooling has choices

It is possible (and all too common) to break up an application into too many small files, which negatively impacts download performance. For this reason, the tooling may choose to merge files together and over-bundle. This is desirable behavior. If your entire application is relatively small (less than 50KB) then breaking it up into hundreds of files would be counterproductive.

If your code structure is fine-grained, the tooling can always choose to create larger (and fewer) bundles. The opposite is not true. If your code structure is coarse, there is nothing the tooling can do to break it up. Qwik guides the developer to break up the application into the smallest possible chunks, and then rely on tooling to find the optimal bundle chunks. This way Qwik can provide optimal performance for applications of all sizes.

Do you find the above exciting? Then join our team and help us make the web fast!

Try it on StackBlitz
Star us on github.com/builderio/qwik
Follow us on @QwikDev and @builderio
Chat us on Discord
Join builder.io

How to score 100 on Google PageSpeed Insights on Mobile

Miško Hevery — Mon, 23 Aug 2021 15:08:55 +0000

Google PageSpeed Insights is a tool you can use to measure the perceived latency of your website. Getting a good score here is vital because Google has announced that it will use these scores as an input into its search ranking algorithm.

We set out to see what it would take to score 100 on PageSpeed Insights on mobile. When we embarked on this effort, we already scored 100 on desktop, but modern commerce is mobile commerce, and there we only scored in the mid-60s. In this blog post, we share ways to get your site scoring 100 on mobile as well. Many companies claim 100 on desktop, but 100 on mobile is a bit of a unicorn. So let's dive in.

Builder.io is a standard Next.js site. Because the site itself is running on the Builder content platform, the content already adheres to all of the best practices for image sizes, preloading, etc. Yet, it still only scored in the 60s. Why?

It helps to look at the breakdown which makes up the score.

The problem can be broken down to:

TBT/TTI: The JavaScript is causing too much blocking time on the page.
FCP/LCP: The page has too much content to render for mobile browsers.

So we should aim to:

Decrease the amount of JavaScript.
Decrease the amount of content for the initial render.

Why so much JavaScript?

Our homepage is essentially a static page. Why does it need JavaScript? Well, the homepage is a Next.js site, which means it is a React application (We use Mitosis to convert the output of our drag and drop editor into React). While the vast majority of the site is static, there are three things that require JavaScript:

Navigation system: Menus require interactivity and hence JavaScript. Also, different menus are used for desktop and mobile devices.
We need to load a chat widget
We need Google analytics.

Let's dive into each one separately.

Application bootstrap

Even though this is primarily a static site, it is still an application. To make the menus work, the application needs to be bootstrapped. Specifically, it needs to run rehydration where the framework compares the templates against the DOM and installs all of the DOM listeners. This process makes existing frameworks replayable. In other words, even though 95% of the page is static, the framework must download all of the templates and re-execute them to determine listeners' presence. The implication is that the site is downloaded twice, once as HTML and then again in the form of JSX in JavaScript.

To make matters worse, the rehydration process is slow. The framework must visit each DOM node and reconcile it against the VDOM, which takes time. And the rehydration process can't be delayed, as it is the same process that installs DOM listeners. Delaying rehydration would mean that the menus would not work.

What we are describing above is a fundamental limitation of every existing framework. You see, they are all replayable. This also means that no existing framework will allow you to score 100 on mobile on a real-world site. The amount of HTML and JavaScript is simply too great to fit into the tiny sliver that PageSpeed allots for it on mobile.

We need to fundamentally rethink the problem. Since most of the site is static, we should not have to re-download that portion in JavaScript, or pay for rehydration of something we don't need. This is where Qwik truly shines. Qwik is resumable not replayable, and that makes all the difference. As a result, Qwik does not need to:

Be bootstrapped on page load
Walk the DOM to determine where the listeners are
Eagerly download and execute JavaScript to make the menus work

All of the above means that there is practically no JavaScript to execute a site load, and yet we can retain all of the interactivity of the site.

Intercom

Intercom is a third-party widget running on our site which allows us to interact with our customers. The standard way of installing it is to drop a piece of JavaScript into your HTML, like so:



<script type="text/javascript" async="" src="https://widget.intercom.io/widget/abcd1234"></script>
<script async defer>
Intercom('boot', {app_id: 'abcd1234'}
</script>

However, there are two issues with the above:

It adds JavaScript that needs to be downloaded and executed. This will count against our TBT/TTI.
It may cause layout shifts, which counts against CLS. This is because the UI is first rendered without the widget and then again with it as the JavaScript is downloaded and executed.

Qwik solves both issues at the same time.

First, it grabs the DOM that Intercom uses to render the widget. Next, the DOM is inserted into the actual page, like so:



<div class="intercom-lightweight-app" aria-live="polite">
  <div
    class="intercom-lightweight-app-launcher intercom-launcher"
    role="button"
    tabIndex={0}
    arial-abel="Open Intercom Messenger"
    on:click='ui:boot_intercom'
  >
    ...
 </div>
 <style id="intercom-lightweight-app-style" type="text/css">...</style>
</div>

The benefit of this is that the widget renders instantly with the rest of the application. There is no delay or flicker while the browser downloads the Intercom JavaScript and executes the creation of the widget. The result is a better user experience and a faster bootstrap of the website. (It also saves bandwidth on mobile devices.)

However, we still need a way to detect a click on the widget and some code to replace the mock widget with the actual Intercom widget when the user interacts with it. This is achieved with the on:click="ui:boot_intercom" attribute. The attribute tells Qwik to download boot_intercom.js if the user clicks on the mock widget.

Content of: boot_intercom.js



export default async function(element) {
 await import('https://widget.intercom.io/widget/abcd1234');
 const container = element.parentElement;
 const body = container.parentElement;
 body.removeChild(container);
 Intercom('boot', { app_id: 'abcd1234' });
 Intercom('show');
}

The file above downloads the real Intercom widget, removes the mock, and bootstraps Intercom. All of this happens naturally, without the user ever noticing the switcheroo.

Google Analytics

So far, we have fought a good fight in delaying JavaScript and hence improving the website’s performance. Analytics is different, as we can't delay it and must bootstrap it immediately. Bootstrapping analytics alone would prevent us from scoring a 100 on PageSpeed Insights for mobile. To fix this, we will be running GoogleAnalytics in a Web Worker using PartyTown. More about this in a later post

JavaScript delayed

The work described above lowers the amount of JavaScript the website has to download and execute to about 1KB, which takes a mere 1ms to execute. Essentially, no time. Such a minimal amount of JavaScript is what allows us to score a perfect score on TBT/TTI.

HTML delayed

However, even with essentially no JavaScript we still can't score 100 for mobile if we don't fix the amount of HTML sentto the client for the above fold rendering. To improve FCP/LCP we simply must shrink that to a minimum. This is done by only sending the above the fold HTML.

This is not a new idea, but it is tough to execute. Theexisting frameworks make this difficult, as there is no easy way to break up your application into pieces that are above and below the fold. VDOM does not help here because the application generates a whole VDOM, even if only a portion of it is projected. The framework would re-create the whole site on rehydration if part of it was missing,would resulting in even more work on the initial bootstrap.

Ideally, we’d like to not ship the HTML that is below the fold, while maintaining a fully interactive menu system above the fold. In practice, this is hard to do, as can be seen by the lack of such best practices in the wild. It’s too hard to do, so no one does it.

Qwik is DOM-centric, which makes all the difference. The entire page is rendered on the server. Then, the portion of the page that does not need to be shipped is located and removed. As the user scrolls, the missing portion is lazy downloaded and inserted. Qwik doesn’t mind these kind of DOM manipulations, because it is stateless and DOM-centric.

Here is the actual code on our server that enables lazy loading of the site below the fold:



  async render(): Promise<void> {
    await (this.vmSandbox.require('./server-index') as ServerIndexModule).serverIndex(this);
    const lazyNode = this.document.querySelector('section[lazyload=true]');
    if (lazyNode) {
      const lazyHTML = lazyNode.innerHTML;
      lazyNode.innerHTML = '';
      (lazyNode as HTMLElement).style.height = '999em';
      lazyNode.setAttribute('on:document:scroll', 'ui:/lazy');
      this.transpiledEsmFiles['lazy.js'] = `
        export default (element) => {
          element.removeAttribute('on:document:scroll');
          element.style.height = null;
          element.innerHTML = ${JSON.stringify(lazyHTML)};
        };`;
    }
  }

The code is simple and to the point, yet it would be difficult to achieve with any of the existing frameworks.

Check out the below fold lazy loading in action:

Notice that the page first loads without content below the fold; as soon as the user scrolls, the content is populated. This populationis near-instant since there is no complex code to execute. Just a fast and straightforward innerHTML.

Try it out

Experience the page for yourself here: https://www.builder.io/?render=qwik. (And see the score on PageSpeed) We are still missing analytics, but that is coming soon.

Like what you see? Our plan is to make Qwik available for every Builder.io customer, so that their sites are supercharged for speed out of the box. You have never seen a platform that is this fast before.

Do you find the above exciting? Then join our team and help us make the web fast!

Try it on StackBlitz
Star us on github.com/builderio/qwik
Follow us on @QwikDev and @builderio
Chat us on Discord
Join builder.io

Qwik: the answer to optimal fine-grained lazy loading

Miško Hevery — Mon, 02 Aug 2021 16:50:10 +0000

Qwik aims to delay the loading and executing of JavaScript for as long as possible and to only do so upon user action, to deliver the fastest loads. This is done during the initial load, as well as during the whole application lifetime. Put differently, Qwik wants to have fine-grained lazy-loading. By "fine-grained," we mean that only the code that is directly required to process user action will be downloaded. In this post, we’ll explore the technical challenges that need to be solved to achieve fine-grained lazy loading.

Serialize listeners

The most obvious challenge to solve is the initial page load. We’ve already covered how to do this in HTML first, JavaScript last. The trick is to serialize event name and event action as URL into the DOM attribute. A top-level global event handler can then listen to events and download the code associated with the event.

<button on:click="./MyComponent_onClick">click me</button>

The above code achieves that with no JavaScript (outside of a 1kb loader) loaded on the initial page load. This solves the initial time-to-interactive goal, but creates a new issue. We don't want to cause full application download and bootstrap on the first user interaction. Doing so would only move the problem from initial load to initial interaction. (If anything, this would worsen the situation, because it would introduce significant latency to first user interaction.)

The solution is to ensure that no single user interaction causes a full application download or bootstrap. Instead, we only want to download and bootstrap/rehydrate the code/component which is directly needed to process the interactions. We want fine-grained lazy loading.

Serializing events into HTML/DOM is what makes this all possible. Without it, it would be impossible to delay the template from loading, because the framework would need to download the template to identify where the events are.

Asynchronous, out-of-order component hydration

To ensure that the first interaction does not cause a full application download and bootstrap, it is necessary to rehydrate the components asynchronously and out of order.

Here asynchronously means that the rendering system can pause rendering to asynchronously download a template for a component, and then continue the rendering process. This is in stark contrast to all of the existing frameworks, which have fully synchronous rendering pipelines. And because the rendering is synchronous, there is no place to insert asynchronous lazy-loading. The consequence is that all of the templates need to be present ahead of call to render.

Another issue with existing rehydration strategies is that they start at the root component and synchronously rehydrate all of the components below. The consequence is that all the components must be rehydrated at the same time, forcing the download of every component. This would cause an extended processing time for the first interaction. Out-of-order hydration means that each component can be rehydrated independently from any other component and in any order. This allows Qwik to only rehydrate the minimum number of components that are needed to process the request.

<div decl:template="./path/MyComponent_template">
  ... some content ...
</div>

In the above case, <div> represents a component associated with MyComponent_template.ts. Qwik will only download the template if it determines that the component needs to be rerendered, thus further delaying its download.

Without out-of-order rehydration, the framework is forced to download all the templates and rehydrate them all at once. This would create large download and execution pressure on the first interaction.

Separation of rendering from event handlers

An essential consideration for Qwik is that all of the existing rendering systems inline event listeners into the template. The consequence of the above is that when a component needs to be rerendered (or rehydrated) the browser must also download all of the listeners, regardless of if they are required. The listeners often close over complex code, which further increases the amount of code that is downloaded.

import {complexFunction} from './large-dependency';

export function MyComponent() {
  return (
    <button onclick={() => complexFunction()}>
      rarely clicked => click handler downloaded eagerly
    </button>
  );
}

Qwik separates the event handles from the template code. This means that either the listeners or template can be downloaded independently, and on an as-needed basis.

MyComponent_template.ts

export MyComponent_template() {
  return (
    <button on:click="./MyComponent_onClick">
      rarely clicked => click handler downloaded lazily
    </button>
  );
}

MyComponent_onClick.ts

import {complexFunction} from './large-dependency';

export default function() {
  complexFunction();
}

Without the separation of event handlers from the templates, the framework would have to download a lot more code than required to rerender the component. Plus event handlers are often complex and have other dependencies, which adds to the amount of code that needs to be downloaded.

Serialization of component state

When a component gets rehydrated, an essential part of the process is to restore the component's state. Existing frameworks don't have a way to serialize the state, as there is no standard way to demarcate where the component's state is.

Qwik breaks components up into several pieces.

props: These are just properties of the components that are reflected in the DOM. For example: <counter min="0" max="100"/> the props are {min: 0, max: 100}.
state: Internal state of the component, which can be serialized into the DOM.
transient state: Any additional state that component may cache, but which cannot be serialized. This information needs to be recomputed (e.g. temporary promises while the component is talking to the server).

<div decl:template="./Conter_template"
     :.='{count: 42}'
     min="0" max="100">
  <button on:click="./Counter_incremente">+</button>
  42
  <button on:click="./Counter_decrement">+</button>
</div>

If the component can’t serialize its state, it won’t be possible to rehydrate the specific component in isolation. (Where would the component get its state?) As a result, the framework would have to download extra code to compute or download the state from the server. Qwik avoids all of this by serializing state in the DOM.

Serialization of app/shared state

In addition to the component state, which is private to the component, the application state is also shared between components. It, too, needs to be serialized into the DOM. The shared state is broken down to:

key: An ID that uniquely identifies a piece of state. The ID is then used as a reference it in the components.
state: Shared state between the components which can be serialized into the DOM.
transient state: Any additional state that applications may cache, but can't be serialized. This information needs to be able to be recomputed.

<div :cart:="./Cart"
     cart:432="{items: ['item:789', 'item:987']}"
     :item:="./Item"
     item:789="{name: 'Shoe' price: '43.21'}"
     item:987="{name: 'Sock' price: '12.34'}">
  ...
</div>

Serializing the application’s state allows the components to render the same information in multiple locations, and communicate with other components. Without the framework understanding and managing the shared state, it would not be possible to hydrate components independently because the framework would not know when the state changes. (For example, Angular and React don't have explicit state management tied to the render function. As a result, the only sensible thing to do when the application state changes is to rerender the entire application, which prevents fine-grained lazy-loading.)

Reactive connections between app state and components

The real benefit of having a framework that understands the state is that the framework knows the relationship between state and components. This is important because it tells the framework which component needs to be rehydrated when a given state changes. Or more importantly, it tells the framework which components don't need to be rehydrated when a state changes. For example, adding an item to a shopping cart should only rerender the component that displays the shopping cart count, which is only a tiny portion of the overall page.

<div :cart:="./Cart"
     cart:432="{items: ['item:789', 'item:987']}">
  <div decl:template="./Unrelated">...</div>
  <div decl:template="./ShoppingCart"
       bind:cart:432="$cart">
   2 items
  </div>
  <button on:click="./AddItem">buy</button>
</div>

The goal of Qwik is to rehyrate the minimum number of components. When the user clicks on the <button> Qwik will download ./AddItem, updating the cart:432 application state. Qwik will then determine that a component with bind:cart:432 is the only component that uses the state, and therefore the only component which needs to be rehydrated and rerendered. Qwik can prune most of the components on the page, allowing it to keep the lazy-loading fine-grained. Knowing which components are connected to which state is a critical property that is not present in other frameworks. It is the property that allows for fine-grained lazy loading during application startup, as well as throughout its lifetime.

Component isolation

So far, we have discussed how Qwik supports fine-grained lazy loading of code. All of the above works because Qwik understands the data flow in the application. Qwik uses this information to prune the components that do not need to be rehydrated and only rehydrate the necessary components. The implication is that the components must not talk to other components without Qwik's knowledge. Components can't have secret conversations with other components.

If the components get a hold of state without Qwik's knowledge, Qwik would not know that the component needs to be rehydrated/rerendered when the state changes. This is why components need to list their dependencies in the component's properties explicitly.

Without explicit listing, the framework would have no choice but to rerender everything once the state changes. This would cause the whole application to be downloaded and boottraped.

Conclusion

There are many ways in which the approach to building web applications needs to change to structure it for lazy loading. The issue is that the current frameworks do not help with this problem, and sometimes they even make it worse (for example, forcing full-page rehydration, synchronous rendering, etc.). Qwik makes fine-grained lazy loading a reality, so that developers can build sites/apps that load in sub-seconds, no matter how large and complex they become.

Try it on StackBlitz
Star us on github.com/builderio/qwik
Follow us on @QwikDev and @builderio
Chat us on Discord
Join builder.io

HTML-first, JavaScript last: the secret to web speed!

Miško Hevery — Wed, 14 Jul 2021 22:17:40 +0000

All frameworks need to keep state. Frameworks build up the state by executing the templates. Most frameworks keep this state in the JavaScript heap in the form of references and closures. What is unique about Qwik is that the state is kept in the DOM in the form of attributes. (Note that neither references nor closures are wire serializable, but DOM attributes, which are strings, are. This is key for resumability!)

The consequences of keeping state in the DOM have many unique benefits, including:

DOM has HTML as its serialization format. By keeping state in the DOM in the form of string attributes, the application can be serialized into HTML at any point. The HTML can be sent over the wire and deserialized to DOM on a different client. The deserialized DOM can then be resumed.
Each component can be resumed independently from any other component. This out-of-order rehydration allows only a subset of the whole application to be rehydrated and limits the amount of code that needs to be downloaded as a response to user action. This is quite different from traditional frameworks.
Qwik is a stateless framework (all application states are in DOM in the form of strings). Stateless code is easy to serialize, ship over the wire, and resume. It is also what allows components to be rehydrated independently from each other.
The application can be serialized at any point in time (not just on initial render), and many times over.

Let's look at a simple Counter component example, and how state serialization works. (Note that this is the output of the server-side rendered HTML, not necessarily specific code developers would be hand-coding.)

<div ::app-state="./AppState" 
     app-state:1234="{count: 321}">
  <div decl:template="./Counter_template"
       on:q-render="./Counter_template"
       ::.="{countStep: 5}"
       bind:app-state="state:1234">
    <button on:click="./MyComponent_increment">+5</button>
    321.
    <button on:click="./MyComponent_decrrement">-5</button>
  </div>
</div>

::app-state (application state code): Points to a URL where the application state mutation code can be downloaded. The state update code is only downloaded if a state needs to be mutated.
app-state:1234 (application state instance): A pointer to a specific application instance. By serializing the state, the application can resume where it left off, rather than replaying the rebuilding of the state.
decl:template (declare template): Points to a URL where the component template can be downloaded. The component template is not downloaded until Qwik determines that the component's state has changed, and needs to be rerendered.
on:q-render (component is scheduled for rendering): Frameworks need to keep track of which components need to be rerendered. This is usually done by storing an internal list of invalidated components. With Qwik, the list of invalidated components is stored in the DOM in the form of attributes. The components are then waiting for the q-render event to broadcast.
::.="{countStep: 5}" (Internal state of component instance): A component may need to keep its internal state after rehydration. It can keep the state in the DOM. When the component is rehydrated it has all of the state it needs to continue. It does not need to rebuild its state.
bind:app-state="state:1234" (a reference to shared application state): This allows multiple components to refer to the same shared application state.

`querySelectorAll` is our friend

A common thing that a framework needs to do is to identify which components need to be rerendered when the state of the application changes. This can happen as a result of several reasons, such as a component has been invalidated explicitly (markDirty()), or because a component is invalidated implicitly because the application shared state has changed.

In the example above, the count is kept in the application state under the key app-state:1234. If the state is updated it is necessary to invalidate (queue for rerender) the components that depend on that application state. How should the framework know which components to update?

In most frameworks the answer is to just rerender the whole application, starting from the root component. This strategy has the unfortunate consequence that all the component templates need to be downloaded, which negatively affects latency on user interaction.

Some frameworks are reactive and keep track of the component that should be rerendered when a given state changes. However, this book-keeping is in the form of closures (see Death By Closure) which close over the templates. The consequence is that all the templates need to be downloaded at the application bootstrap when the reactive connections are initialized.

Qwik is component-level reactive. Because it is reactive, it does not need to render starting at the root. However, instead of keeping the reactive listeners in the form of closures, it keeps them in the DOM in the form of attributes, which allows Qwik to be resumable.

If count gets updated, Qwik can internally determine which components need to be invalidated by executing this querySelectorAll.

querySelectorAll('bind\\:app-state\\:1234').forEach(markDirty);

The above query allows Qwik to determine which components depend on the state, and for each component it invokes markDirty() on it. markDirty() invalidates the component and adds it to a queue of components which need to be rerendered. This is done to coalesce multiple markDirity invocations into a single rendering pass. The rendering pass is scheduled using requestAnimationFrame. But, unlike most frameworks, Qwik keeps this queue in the DOM in the form of the attribute as well.

  <div on:q-render="./Counter_template" ... >

requestAnimationFrame is used to schedule rendering. Logically, this means that requestAnimationFrame broadcasts the q-render event which the component is waiting on. Again querySelectorAll comes to the rescue.

querySelectorAll('on\\:q-render').forEach(jsxRender);

Browsers do not have broadcast events (reverse of event bubbling), but querySelectorAll can be used to identify all the components which should receive the event broadcast. jsxRender function is then used to rerender the UI.

Notice that at no point does Qwik need to keep state outside of what is in the DOM. Any state is stored in the DOM in the form of attributes, which are automatically serialized into HTML. In other words, at any time the application can be snapshot into HTML, sent over the wire, and deserialized. The application will automatically resume where it left off.

Qwik is stateless, and it is this that makes Qwik applications resumable.

Benefits

Resumability of applications is the obvious benefit of storing all framework state in DOM elements. However, there are other benefits which may not be obvious at first glance.

Skipping rendering for components which are outside of the visible viewport. When a q-render event is broadcast to determine if the component needs to be rendered, it is easy to determine if the component is visible and simply skip the rendering for that component. Skipping the rendering also means that no template, or any other code, is required to be downloaded.

Another benefit of statelessness is that HTML can be lazy loaded as the application is already running. For example, the server can send the HTML for rendering the initial view, but skip the HTML for the view which is not visible. The user can start interacting with the initial view and use the application. As soon as the user starts scrolling the application can fetch more HTML and innerHTML it at the end of the DOM. Because Qwik is stateless, the additional HTML can be just inserted without causing any issues to the already running application. Qwik does not know about the new HTML until someone interacts with it, and only then it gets lazy hydrated. The use case described above is very difficult to do with the current generation of frameworks.

We are very excited about the future of Qwik, and the kind of use cases that it opens up.

Try it on StackBlitz
Star us on github.com/builderio/qwik
Follow us on @QwikDev and @builderio
Chat us on Discord
Join builder.io

That’s it for now, but stay tuned as we continue to write about Qwik and the future of frontend frameworks in the coming weeks!

DEV Community: Miško Hevery

How To Embed Tweets Without a Performance Penalty

Why embed Twitter on your website

Embedding a tweet is expensive

Why so expensive

23 third-party scripts

It's just another CSR app

It all comes down to JavaScript

HTML-first embedding

Our proof of concept for tweet embeds

Generating HTML first content

Why it performs so much better

Try it for yourself

What the differences are

The three people problem

What the industry can do to aim higher

Conclusion

Visually build with your components

The Challenges of Lazy Loading in JavaScript

Lazy loading a component

Hydration

Merging components

Prefetching

Lazy-loading on interactions

Hydration trampoline closure

Async nature of lazy-loading

Prefetching

It is a lot of work

Conclusion

About Qwik

Visually build with your components

Our current frameworks are O(n); we need O(1)

Miško HeveryFollow

How did we get here?

CPUs have stalled.

Frameworks were not designed for this.

y=mx+b

Even the smallest “m” is not enough.

New goal “O(1)

Summary

Don't blame the developer for what the frameworks did!

Miško HeveryFollow

Common story

It's not your fault

Too much code

Evolution of bundling

Gen 0: Concatenation

Gen 1: Bundlers

Gen 2: Lazy loading

Gen 3: Lazy loading components not in the render tree

The core of the problem

Next-Gen: Fine-grained lazy loading

Entry points

Overproduction of entry points

The framework of the future

Conclusion

Hydration is Pure Overhead

Miško HeveryFollow

Digging deeper into hydration

Resumability: a no-overhead alternative to hydration

A note on memory usage

Conclusion

Why coin a new term?

Is resumability just hydration after the event?

What are real world results like?** **Where can I see a site that uses a resumable strategy?

My framework knows how to do progressive and/or lazy hydration. Is that the same thing?

My framework knows how to create islands. Is that the same thing?

My framework knows how to serialize the state. Does it have overhead?

Is a component hydrated on first interaction?

How can I take advantage of resumability today?

Is there a delay on first interaction?

Can I use my React/Angular/Vue/Svelte components with Qwik?

From Static to Interactive: Why Resumability is the Best Alternative to Hydration

Miško HeveryFollow

How does a framework make a page interactive?

Associating event handlers

Recovering application state

Recreating the component hierarchy

The alternative to hydration

Resumability in Qwik

What are real world results like? Where can I see a site that uses a resumable strategy?

`querySelectorAll` is our friend