Lazy-loading is like exercise. Everyone says they are doing it, few are, and those that are rarely know what they are doing.

Frameworks were not designed with lazy loading in mind. It was a late addition to their development life cycle.

We now pay the price of bloated apps.

/1 Granularity: What is the minimum piece of code that you can lazy-load?

In theory, anything can be lazy-loaded in practice, most FWs only support the lazy-loading of components.

Lazy-loading, events, or behavior is out of scope for most FWs. (No primitives are provided.)

/2

I have been doing a lot of tweets on how VMs work, like the one below.

What surprised me are all of the negative comments that can be summarized as "JS sucks!"

I want to dispel this.

https://twitter.com/mhevery/status/1635492705315999744?s=20

1/5 First, these tweets are not meant to make fun of JS but rather to share the understanding that there is no "magic" in the VM and that VM needs to solve problems where it has "insufficient" information.

2/5

How can `a+b` be almost 4x faster than `b+a`?

🤯

1/6 Here is a test to prove it!!!

stackblitz.com/edit/web-platf…

2/6

What is a hashing function, and how does it relate to HashMaps? CPUs only understand array access.

HashMap is a data structure that converts non-numeric KEY access into numeric index access on an array.

Colocating client/server code in a single file is the next battleground for better DX between meta frameworks.

Let's zoom into what it is!

🧵🪡🧶 Module extraction is the way it is done today.
1) Well-known top-level function invoked by the server but tree-shaken by the bundler for the client.
2) Some form of manual type safety.

(no special code transformation needed)

React’s upcoming compiler will not solve prop-drilling, but Signals solve it well.

🧵🪡🧶 Example: an application where the state is stored at a common ancestor of two child components that render and mutate the state.

Make your code faster with Bloom filters. They are like HashMaps but smaller and allow you to short-circuit more expensive operations.

🧵🪡🧶 Imagine you have to do an expensive search operation for a KEY. You also know the most likely outcome is that the KEY will not be found. Such operations can’t be skipped on the off chance that the KEY is found.

A bloom filter allows you to skip such work

JSX could have been 2x faster if it was designed more optimally for JS VMs!

Let's see what design decisions make JSX slow and how we could speed it up.

🧵🪡🧶 There are two issues with tcurrent JSX transpilation:

1. The use of object-literal for properties causes megamorphic access on read.
2. Using variable args requires conversion to an array in `h()` function.

CORRECTION: The explanation and conclusion are correct, but the benchmark had an honest mistake so the slowdown is only 20-50%.

Thank you, @mraleph, for catching it.

But let's turn this into a lesson and understand the mistake and why it caused such a drastic slowdown.

🧵

https://twitter.com/mhevery/status/1626002464469323777

The mistake is that my array contained `[-0, -1]` when it should have contained `[-0, 1]`.

`a = 0-x` is about 3-10x faster than `a = -x` 🤯

Let's jump into JavaScript VM details to see why and how to guard against this VM de-opt:

🧵🪡🧶 The first thing to understand is that JavaScript has two representations for numbers:
- Integers: Fast path
- Floats (IEEE 754): Slower path

Integers are stored as “Two's complement” and can't have `-0`, but Floats can!

Lazy loading in frameworks is a lie!

(And then we blame the developer for slow sites.)

🧵🪡🧶 Let's start with a simple app. Let's assume it is slow because of too much JavaScript.

Experts say there is an easy solution. Just lazy-load it!

I want to show you how much the frameworks will fight you every step of the way and how little benefit you will get.

Words are hard! And sometimes, they don't come out the way they were intended.

I feel this is such an example, so let me expand on what I believe:

https://twitter.com/mhevery/status/1566818498294083584?s=20&t=4a2koPrAfAyc2qCWdtcg8g

Ideas are created when you talk to others/study existing solutions. We all stand on the shoulder of "others".

It is rare that we have genuinely original ideas. Most of the time, they are repackaging incremental improvements to what already exists.

https://twitter.com/Rich_Harris/status/1624444013322305537?s=20&t=4a2koPrAfAyc2qCWdtcg8g

useSignal() is the future of web frameworks and is a better abstraction than useState(), which is showing its age.

🧵🪡🧶 useState() returns the value "in time" rather than the state "over time" it represents. This can lead to problems when value is captured in closures such as useEffect().

useEffect is a bad abstraction

There is a better way: 🧵🪡🧶 useEffect() only runs on the client.

Sometimes I want to run code as part of SSR/SSG on the server.

Get faster startup performance by running effects as part of SSR/SSG instead of client side.

🧵🪡🧶 In React, everything that is not rendering is an effect. Effects only run on the client (Not part of SSR/SSG.)

This means that anything in effect will not render as part of SSR/SSG.

We all know that micro-benchmarks lie!

But do you know how much?
Through what mechanism?
How can you safeguard against it?

🧵🪡🧶 Let’s say you want to benchmark a common operation of creating and setting an attribute on a DOM node.

You may write something like this.

Understanding monomorphism can improve your JavaScript performance 60x.

Curios to find out more, read this thread. First things to understand is that CPUs only understand arrays, so your object/classes need to get translated into arrays which CPUs can work with.

As developers, we know how to serialize:
- Data => JSON
- Code => file.js

But how do you serialize closure (Code + Data)?

Qwik's key innovation, which enables all other magic, is that it knows how to serialize closures on servers and invoke them on clients, key to Resumability! For example, the server can register a DOM listener closure as part of SSR, and then only materialize (download and resume) the closure if the user actually triggers that event.