DEV Community: Aiden Bai

Unleashing Million.js v2.0.0

Aiden Bai — Fri, 10 Mar 2023 20:53:58 +0000

An extremely fast virtual DOM that makes React up to 70% faster!

In the past 5 months, I've been gearing up for Million.js new direction: React, augmented with performance-improving utilities. In v1.0.0, I announced that we would be embarking to replace React with a compiler--an ambitious goal with ambitious results.

However, I've come to realize that replacing React shouldn't have been the goal--you lose the React ecosystem and the architecture is fragile to change.

So today, I'm more than excited to announce a fully, ground-up rewritten version: Million.js v2.0.0!

What's new?

Million.js is up to 70% faster* than React. But that's not all:

⚛️ React.js compatibility
🔼 Next.js compatibility
🛠️ Opt-in optimizing compiler
☑️ Internal Block virtual DOM
💥Custom JSX runtime (for simple use cases)

* Local benchmark of JS Framework benchmark, PR currently pending.

It's now super easy to integrate into any React app. Yep, it's literally just one function:

import { block } from 'million/react';

const BigStatelessComponent = ({ test }) => {
  return <div>{test} {Array(1000).fill(0).map(() => <div></div>}</div>
}

// that's it! you can use it like a normal component now:
const BigButFast = block(BigStatelessComponent)

Why Million?

(and not Preact, Inferno, Solid...)

React "alternatives" like Preact and Inferno are awesome. They are great for building performant yet deeply interactive web apps, and even support some compatibility. Libraries like Solid sport the best performance, and are the top-of-the-line options for building extremely fast web apps.

However, these libraries can sometimes lack the things that make React great (namely the rich ecosystem, concurrent rendering, etc). Plus, most web apps don't need hyper optimized performance for their entire app, meaning migration to these tools is not always possible or necessary.

Million.js takes a different approach. Instead of replacing React, it augments it with performance optimizations when you need it. Million.js works out of the box, alongside your favorite metaframeworks (Next.js, Remix, etc.) and React libraries.

TL;DR: Don't replace React, augment it.

How does this work?

Million.js takes heavy inspiration from the work of blockdom.

Million operates off of the concept of a block virtual DOM. Normally, virtual DOM's diff all of the nodes on a tree, which can become computationally expensive.

Million's block tree requires much less updates, as nodes are grouped together into blocks.

The React integration operates off of the same virtual DOM block core, but does not need its own React reconciler. Rather, it mounts an "island" into the DOM.

<div>
  <million-island><!-- block renders here--></million-island>
</div>

I highly recommend reading over blockdom's performance notes to understand why it's fast.

Acknowledgements

blockdom (Géry Debongnie)
Thank you to Géry pioneering the concept of "blocks" in the virtual DOM. Many parts of the Million.js codebase either directly or indirectly derive from his work.
voby (Fabio Spampinato)
The Million.js "template" concept is derived from Voby's template() API.
bun for their homepage. The Million.js homepage is a remix of what they have currently.
ivi, Preact, and more
Sukka, Tom, and all of the other contributors!

Are you as excited as me? Get started!

I made React with a faster Virtual DOM

Aiden Bai — Wed, 01 Jun 2022 06:04:15 +0000

Plug: I help develop Million: Virtual DOM into the future! 💥🦁✨

Million is a lightweight (<1kb) Virtual DOM. It's really fast and makes it easy to create user interfaces.

Oh man... Another /virtual dom|javascript/gim library? I'm fine with React already, why should I bother switching?

Million makes creating user interfaces as easy as React, but with faster performance and smaller bundle size for the end user. By computing the user interface beforehand with a compiler, Million reduces the overhead of traditional Virtual DOM.

Okay cool... but why should I use Million if I can just use Preact if I need something a bit more lightweight?

While alternative libraries like Preact reduce bundle sizes by efficient code design, Million takes it a step further by leveraging compilation to make a quantum leap in improving bundle size and render speed.

Think of it as if Preact and Svelte had a baby. A baby with super speed! 👶

Using `million/react`

Here is an extremely simple implementation of a Counter app using Million.

import { compat, createRoot, useState } from 'million/react';

function Counter({ init }) {
  const [value, setValue] = useState(init);

  return (
    <div>
      <div>Counter: {value}</div>
      <button onClick={() => setValue(value + 1)}>Increment</button>
      <button onClick={() => setValue(value - 1)}>Decrement</button>
    </div>
  );
}

const root = createRoot(document.querySelector('#app'));

// Million wraps render functions inside a compat function
compat(() => {
  root.render(<Counter init={0} />);
});

Here, you can write React code. Million will automagically optimize it during compile time, allowing for a super speedy Virtual DOM.

Open the project to start tinkering:

Need help on using React? Check out the React documentation.

This is very, VERY early stage, so be prepared for weird bugs / plugin incompatibility / etc. If you have any suggestions, I'd be more than happy if you replied in a comment with it!

Turning MPA to SPA with Virtual DOM

Aiden Bai — Sun, 17 Apr 2022 08:05:03 +0000

Plug: I help develop Million: Virtual DOM into the future! 💥🦁✨

Motivation

Whether you use a static site generator like Eleventy, have a server rendered application with Ruby on Rails, or just have a plain HTML/CSS/JS site, you're probably using some sort of multi-page application.

The main issue with MPA is that each navigation (e.g. clicking a link, form submission) requires a full page reload, meaning more time is wasted.

We could rewrite our entire app as a SPA with React/Vue, but that would be time consuming and unnecessarily complex.

This is why tools like Turbo Drive exist. Turbo Drive "watches for link clicks and form submissions, performs them in the background, and updates the page without doing a full reload."

However, I feel like Turbo Drive is sometimes too overcomplicated -- I just want something small that works without much configuration.

Usage

Using Million, a modern Virtual DOM library, I created a MPA to SPA router.

All you have to do is add this in your HTML files

import { router } from 'https://unpkg.com/million?module';

router();

And it's that easy!

Exploring Blockdom: Fastest Virtual DOM (ever!)

Aiden Bai — Sat, 26 Feb 2022 08:27:31 +0000

If you've been around in the JavaScript UI library development space, you've likely heard about blockdom, which claims to be probably the fastest Virtual DOM that currently exists.

Its even been praised by Ryan Carniato as an example of hyper performant Virtual DOM, even being comparable to Solid.js' performance:

// Detect dark theme var iframe = document.getElementById('tweet-1435721745344831494-360'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1435721745344831494&theme=dark" }

Blockdom is really fast

Compared with other virtual DOMs (see snabbdom, virtual-dom), it's significantly faster. These older methods use node-by-node diffing, or the traversal and comparison of the node tree in order to calculate the optimal DOM modifications to reduce reflow and repaints.

The main way that Blockdom can achieve such high performance is by performing block-by-block diffing. Why are we doing node-by-node diffing when we know most trees will be static? We have a serialized version of the block, and we can do super simple string comparisons O(1) instead of tree traversals O(n).

Old method:

[A, B, C, D] diff() [A, B, C, D]

New Method

'A,B,C,D' === 'A,B,C,D'

Additionally, creating elements is much faster. Instead of individually creating elements and constructing a DOM node tree, we can just used the serialized format of the block and use the cloneNode(true) method to quickly create a DOM tree.

Here's what the syntax looks like:

// create block types
const block = createBlock(`<div class="some-class"><p>hello</p><blockdom-child-0/></div>`);
const subBlock = createBlock(`<span>some value: <blockdom-text-0/></span>`);

// create a blockdom virtual tree
const tree = block([], [subBlock(["blockdom"])]);

// mount the tree
mount(tree, document.body);

// result:
// <div class="some-class"><p>hello</p><span>some value: blockdom</span></div>

As you can see, Blockdom makes some tradeoffs in order to achieve best performance. The blockdom-child syntax is somewhat awkward, but it is necessary in order to create the block tree.

Generalized Blocks

So how can we learn from Blockdom and make existing Virtual DOM implementations better? I've been exploring this concept with Million.js.

aidenybai / million

Optimize React performance and make your React 70% faster in minutes, not months.

Want to automatically find and fix performance issues? Check out Million Lint.

📚 Read the docs

🎦 Watch video

💬 Join our Discord

🌐 Follow on Twitter

What is Million.js?

Million.js is an extremely fast and lightweight optimizing compiler that make components up to 70% faster.

Oh man... Another /virtual dom|javascript/gi framework? I'm fine with React already, why do I need this?

Million.js works with React and makes reconciliation faster. By using a fine-tuned, optimized virtual DOM, Million.js reduces the overhead of diffing (try it out here)

TL;DR: Imagine React components running at the speed of raw JavaScript.

👉 Setup Million.js in seconds! →

Installation

The Million.js CLI will automatically install the package and configure your project for you.

npx million@latest

Once your down, just run your project and information should show up in your command line!

Having issues installing? → View the installation guide

…

View on GitHub

Million.js intends to use the compiler to reduce computational work of diffing, and blocks are a great way to do this. Million.js forgoes the slightly awkward syntax, focusing on two main concepts: the ability to do string comparison and cloneNode(true).

This way, you don't need to construct a block and recall it every time you render. You just construct as you want, and it will handle the rest for you.

This way, it's super simple syntax without much tradeoff.

import { render } from 'million';
import { block } from 'million/block';

render(document.body, block('<div>Hello World</div>'));

You can read up about blocks in Million here.

Conclusions

Blockdom presents exciting new ways to optimize Virtual DOM, making it a viable contender for ways we can optimize rendering in the future.

Other Virtual DOM libraries should take inspiration from Blockdom and conduct research into how block-like structures can help make Virtual DOM rendering a contender in hyper-performant rendering libraries.

ged-odoo / blockdom

A fast virtual dom library

blockdom

Probably the fastest virtual dom library in the world!

IMPORTANT: blockdom is just a proof of concept and a place to experiment some ideas. This is not intended to be used in a real application, no real support will be given! However, it is designed to be the rendering engine of the Owl framework!

blockdom is a very fast virtual dom library. Its main selling point is that it does not represent DOM element by element, but instead block by block, where a block is an element with all its static content and some special tags to indicate dynamic content. This allows blockdom to use cloneNode(true) on blocks and speed up the diff process, since the vdom tree is much smaller.

It features blocks, supports fragments, manage synthetic event handlers and more Note that it is not a framework. It does not even have the concept of components …

View on GitHub

Million.js 1.0.0 Release!

Aiden Bai — Sun, 28 Nov 2021 19:23:23 +0000

<1kb compiler-augmented virtual DOM. It's fast!

I initially started Million.js on a whim. I wanted to tinker around and figure out how to build a simple virtual DOM, and maybe share it with a couple friends. Six months later, Million.js 1.0.0 is completed!

It's been a hot minute, but I've genuinely enjoyed every moment of the process. I'm insanely ecstatic to finally present a stable version of something I'm proud of.

What is Million.js?

It's a Virtual DOM, or the architecture React is built off of. Its goal is to be a compile target for Transitional UI Libraries by providing ways for compilers to optimize diffing.

Essentially, Million.js leverages the declaratively and flexibility of the Virtual DOM and while deferring to the compiler when optimizations can be made.

It also is composable, but sensible by default, allowing you to build scalable, increasingly complex logic, but also enjoy best practices with simple API if need be.

// Composable
const diff = node([children(), props()]);
const data = diff(el, newVNode, oldVNode, []);
flush(data.workStack, schedule);

// Equivalent sensible default API
patch(el, newVNode);

And more complex usage of the default API:

import { m, createElement, patch } from 'million';

// Initialize app
const app = createElement(m('div', { id: 'app' }, ['Hello World']));
document.body.appendChild(app);
// Patch content
patch(app, m('div', { id: 'app' }, ['Goodbye World']));

Why?

🦁 Built for libraries that compile
📦 Lightweight bundle size (<1kb brotli+min)
⚡ Fast runtime operations
🛠️ Composable using drivers, sensible by default

Next Steps

I want to bootstrap a compiler using babel JSX AST plugins and explore the possibilities around automatically applying flags, deltas, and keys at build time to optimize away unnecessary diffing.

Additionally, I want to see what new paradigms and APIs can be built for new UI libraries, and possibility greater adoption of Million.js or tangential ideology.

All in all, I'm excited for the future of Transitional UI Libraries, and I hope Million.js is a step towards that future!

Learn more:

The Million.js Manifesto

Aiden Bai — Wed, 28 Jul 2021 06:52:22 +0000

Past

Back in the days when JavaScript was first manifested, direct DOM manipulation was used to introduce interactivity for static web sites. Eventually, the JavaScript scene moved on to new technologies such as MooTools and jQuery, which helped simplify certain actions into simple, reusable functions. However, there was still one pressing issue.

Even though web development became easier, scaling large web applications that required an extensive amount of interactivity was difficult, as operations were generally imperative and difficult to organize. This led the rise to several frameworks and libraries, notably React. React aimed to allow for declarative development and componentization to compose user interfaces scalably. To achieve this, the team behind React used a Virtual DOM architecture, where computation and logic was deferred to an algorithm to determine changes. This means that the developer just has to figure out how the markup will look.

React helped to pioneer extensive usage of JavaScript to render web applications, leading to the rise of the Virtual DOM architecture in other libraries and usage of new technologies like JSX.

Present

Nowadays, the prevalence of web applications is non-negligible. JavaScript and React are everywhere, and the Virtual DOM architecture is used in many of the popular libraries today (React.js, Vue.js, Preact.js, Elm, etc). "Pure JavaScript rendering" has subsided as development of preprocessors such as Webpack have taken hold as a standard, leading the way to preprocessors, allowing for cross-browser compatibility (e.g. Babel), prerendering, and JAMstack technologies.

JavaScript frameworks and libraries have entire ecosystems around them, with tools like Next.js around React supercharging how web development is done. Library developers are slowly realizing the importance of performance sacrificed in the previous generation of developers for the purpose of developer experience. This is seen with trends towards static analysis with Svelte, which currently leverages the prevalent usage of bundlers in most web applications.

Performance is slowly becoming a priority, but technologies that depend on the Virtual DOM like React are fundamentally outdated, even with incremental improvements with lazy loading and ISR in Next.js.

Future

It is easy to to recite, reinvent, and monkey-patch what exists. With React and the Virtual DOM being such a backbone technology in the JavaScript library space, it is paramount that bleeding-edge libraries like Next.js leverage their position in the ecosystem to pioneer compiler-based optimizations. While the most straightforward solution is to ditch everything and use the browser just as compile target with a series of imperative operations, the Virtual DOM arguably brings many advantages. It helps us write declarative interfaces without templating, meaning conditions are constrained to the limit of JavaScript, as well as many other benefits.

The future of the Virtual DOM is not destruction of the Virtual DOM, rather it is to constrain usage of the Virtual DOM where it is powerful while leveraging static analysis and compilation (This is done through Million.js).

→ Interested in how Million is different?

I recently had the opportunity to chat with @rauchg about Million.js as well as some of my thoughts on the current state of Virtual DOM. He explained to me that optimization of the Virtual DOM was only a facet of the next phase of web frameworks. This includes how we can improve development mode experience, tree-shaking and bundle size, etc.
aggressive tree shaking - reduce bundle size. I highly recommend you to check out his Twitter and blog, as he has so much valuable insight into the industry and how impact can and needs to be made.

Million.js - The Future of Virtual DOM

Aiden Bai — Fri, 16 Jul 2021 01:29:35 +0000

Plug: I work on Million.js: <1kb virtual DOM - it's fast!

TL;DR

Virtual DOM needs to leverage the compiler, so that unnecessary diffing is not incurred.

Introduction

Recently, I published some articles detailing the Virtual DOM paradigm, implementation, and the benefits and flaws using it. These articles received mixed reception, with some developers agreeing with the points in the article, while others disagreed. They argued that compilation based frameworks that do some level of static analysis (notably Svelte) compile to imperative DOM operations and therefore bypass the overhead of a Virtual DOM engine.

You may be wondering: What's the point of using Virtual DOM, if you can just use a compiler-based framework like Svelte? While static analysis and compilation is the future, Virtual DOM should not be completely ruled out as an obselete technology. Svelte only is possible if API conditions are constrained, so that the code is predictive and therefore analyzable. For libraries that need more flexibility, such as React or Vue, conditions cannot be constrained easily and therefore a variant of the Virtual DOM is necessary for those libraries.

This is why Million.js exists—to bring the Virtual DOM into the future by leveraging the compiler for static analysis and optimizations that makes DOM manipulation be performant and flexible.

Virtual DOM Optimizations

Traditionally, Virtual DOM engines do a significant amount of computation during the diffing process. For example, when diffing children, the Virtual DOM engine not only linearly calculates which nodes need to be updated, but also determines the possible swaps/moves that can be done. Although this incurrs the least amount of DOM modifications, the computational cost can be great. Even with extremely efficient list diffing algorithms (like list-diff2), the time complexity is O(n) in the best case (not including the O(n^3 time complexity baseline for diffing). Repeat this for all the children in a vnode tree and you can just imagine how inefficient this can be.

This is why one of the major concepts to create a future oriented Virtual DOM is to be aware and construct the architecture based on the compiler. This not only increases performance by allowing for straight O(1) operations, but also gracefully falls back to normal diffing when necessary. Additionally, bundle sizes decrease significantly, reducing the amount of code that needs to be executed at runtime.

Million.js attempts to implement this with three major "lines of defense":

Keys: Specify the identity of a vnode

Keys are useful when you know that a certain vnode's position, data, and children will not change between two states. Keys can be provided by the user manually, or generated by the compiler. This allows for the vnode to be skipped entirely, avoiding unnecessary diffing (O(1))
Flags: Specify the type of content of a vnode's children.

Flags allow for diffing to skip certain computationally expensive condition branches. For example, if the vnode's children only contains text nodes, then just setting the textContent of the element would be significantly faster than constructing and replacing a text node. Million.js currently only supports 3 flags: NO_CHILDREN (O(1)), ONLY_TEXT_CHILDREN (O(n)), and ANY_CHILDREN (O(n^3)).
Deltas: Specify predictive and consistent modifications of a vnode's children.

Deltas can be utilized when simple, imperative micro-actions can be predicted through static analysis. Deltas by default are a series of imperative operations, but leverage the internal diffing algorithm to reduce DOM manipulations. Million.js currently supports 3 fundemental Delta operations: INSERT (O(1)), UPDATE (O(1) to O(n^3)), DELETE (O(1)).

Compiler Optimizations

First off, most—if not all of the implementation complexity will be with the compiler. This is because static analysis is really hard to pull in a way so that it operates as intended. Below is a list of possible optimizations, and is by no means "real static analysis."

Leveraging Million.js features:

The primary way to optimize for Million.js is just leverage the compiler-focused features that it provides. This is the only way to reduce diffing assuming that the patch scope remains constant.
Prerendering + reducing dynamic content

Another way of making performance better is to not even consider static content by reducing the patching scope—especially if your application is only interactive in certain areas. This is even more efficient than generating imperative DOM operations, as DOM manipulation won't even be needed! Additionally, the initial vnode should be prerendered the page, so that the page doesn't need to be fully initialized at runtime.
```
Bad:
<div></div> inject <button>Click Me!</button>

Good:
<div><button>Click Me!</button></div>
```

Static vnode + props hoisting:

A standard optimization to hoist vnodes and props that are static, allowing them to be cached and incurr no generation computational cost. This is best illustrated with a code sample:

// Without static VNode hoist
const render = () => patch(el, m('div', undefined, [`My favorite number: ${1 + 2 + 3}`]))
render();
render(); // Static VNode needs to be constructed twice

// With static VNode hoist
const _s = <div>Hello World!</div>
const render = () => patch(el, _s)
render();
render(); // Static VNode is used twice and cached

// Without static props hoist
const render = () => patch(el, m('div', { id: `app${1 + 2 + 3}` }))
render();
render(); // Static props need to be constructed twice

// With static props hoist
const _s = { id: `app${1 + 2 + 3}` };
const render = () => patch(el, m('div', _s))
render();
render(); // Static props are used twice and cached

Note: If you feel that this sort of paradigm has a future and are willing to meet those ends—I highly recommend you check out Million.js and try working on an implementation of a compiler yourself.

Conclusion

Million.js is far from being done, and there is a lot of work that needs to be done. I hope that this article has brought about a new perspective to think of the Virtual DOM as it progresses into the future. Feel free to comment any suggestions or lingering questions you may have!

Tips to get Visibility + Feedback to your GitHub project

Aiden Bai — Tue, 06 Jul 2021 07:20:40 +0000

Plug: I help develop million: <1kb virtual DOM - it's fast!

TL;DR

If applicable, post your project on Hacker News with Show HN: in your title, EchoJS, r/opensource, r/javascript, r/sideproject, and ProductHunt.

If you have a following, post to those platforms (i.e. Twitter).

If you have access to communities, post to those communities in sanctioned areas (i.e. Discord, Slack, Telegram)

If you have extra time, post articles related to your project on blogging websites (i.e. Dev.to with #showdev, Hackernoon, Hashnode)

Introduction

You probably stumbled upon this article because you're interested in promoting your project you've been working on. That's great! In this guide you'll learn how to validate your work through gathering an audience, attracting new contributors and stars.

Right off the bat, you should have a reasonably intriguing and useful project. Make sure that your projects are presentable with a clear README, description, and logo. Take for example some projects I've done:

Million.js - 🏳️‍🌈 <1kb virtual DOM - it's fast!
Lucia.js - 🙋‍♀️ 3kb library for tiny web apps

Since my projects are generally JavaScript/TypeScript/Web related, many of the resources provided will be targeted towards those communities, so use as you see fit.

Platforms

Hacker News

Hacker News is probably one of the best way to reach other developers, but hundreds of posts are put on it each day. To ensure you get some exposure, prefix your post title with Show HN: to be listed under the show category. Additionally, include an intriguing and easily understandable title to increase your click through rate.

Examples:

Dev.to

Dev.to is probably one of the most effective ways to get developers to intract with your work. One option is to directly introduce your project. If you do, ensure you add the #showdev tag as well as 3 additional tags related to your project.

The other way of increasing interactions is to write articles related to your project that developers could be interested in. This hooks developers into reading your article, extracting value, while becoming aware of your project. Ensure that you include call to actions at the start and end of your article.

Examples:

Open source communities like r/opensource, r/javascript, r/sideproject are very effective ways to promote your projects if you have a substantial amount (1k+) of Reddit karma. These communities generally discourage advertising, so if you have a new account, try posting to smaller communities to start off instead.

Examples:

ProductHunt

ProductHunt is a great way to pitch your product to "maker-focused communities." This is pretty straightforward, I highly recommend you suppliment using this to advertise to other platforms as well.

Examples:

Other

You can use Twitter, EchoJS, and Discord/Slack/Telegram to help suppliment the other platforms.

Metrics

Github Insights (Under Traffic Tab)
Stars/Contributions to GitHub repo
Dev.to Dashboard stats

Side Effects

GitHub Trending

This is generally the ultimate result of the promotion on other platforms - to float your project to get on trending. This encourages developers on Github who might work on similar projects to see your project. This type of visibility is the most valuable.

Publications

Another way to float your project to gain a "second wind" is to get publications to feature your project. This sort of method is best paired with GitHub trending.

Have any suggestions? Send them in the comment section.

Why Virtual DOM?

Aiden Bai — Fri, 02 Jul 2021 22:23:07 +0000

Plug: I help develop million: <1kb virtual DOM - it's fast!

Introduction

The Virtual DOM was initially pioneered by the React authors on the basis of making delarative JavaScript patterns performant - but how? To understand this, we need to quickly review how traditional DOM manipulation works.

Generally speaking, the easiest way of changing the DOM ("Modifying the HTML") is to mutate the innerHTML property on an element. For example, if I want to add a div element in the document body, I could do something like this:

document.body.innerHTML = '<div>Hello World!</div>';
// <body> now has a <div>Hello World!</div> child.

This seems to be computationally performant, but it really isn't. While the action of reassignment is computationally performant, the DOM repaint ("Updating what the user sees") is not. This is because innerHTML needs to parse DOM nodes from a string, preprocess, and append it, resulting in less-than-optimal performance. The issues with performance are increasingly noticable when there are more children/attributes and when the interval of mutation is shorter.

So, how is this issue fixed? Well, instead, we do pinpoint changes to the DOM. For example, this solution would be almost 10x faster than the innerHTML solution.

const div = document.createElement('div');
div.textContent = 'Hello World!';
document.body.appendChild(div);

While this is simple enough, once you start performing continous mutations, more complexity arises. This is why the virtual DOM was created - to allow you to write declarative content (like the string in the innerHTML example) while harnessing performance by making only pinpoint changes to the DOM.

Virtual DOM

The virtual DOM is a tree of virtual nodes that represents what the DOM looks like. virtual nodes are light, stateless, and are JavaScript objects that only contain necessary fields. virtual nodes can be assembled into trees, and "diffed" to make pinpoint changes to the DOM.

While this is efficient, it has some caveats. Notably, diffing is not computationally free. Traversing the trees have O(n^3) time complexity, meaning the more children, the longer the time it will take to perform the action. To solve this, Million was created.

Read this article if you don't understand what the Virtual DOM is.

Million

Million provides five major improvements: granular patching, fewer iterative passes, fast text interpolation, keyed virtual nodes, compiler flags.

Granular patching: Instead of just replacing the entire element when there is a difference in props or children, only the necessary props are changed.
Fewer iterative passes: Million attempts to reduce the amount of passes during diffing, allowing for better time and space complexity.
Fast text interpolation: Instead of replacing text nodes with DOM methods, Million uses compiler flags to set the textContent of elements to boost performance.
Keyed virtual elements: This allows for the patching algorithm to skip nodes if the new virtual element key is the same as the old one, minimizing the amount of unnecessary work.
Compiler Flags: This allows for the patching algorithm to skip condition branches, meaning less work is done.

Thanks for reading! Drop a star to Million or follow/react to this article for more Virtual DOM content!

How does Virtual DOM work? (Build your own)

Aiden Bai — Thu, 17 Jun 2021 23:09:44 +0000

Plug: I help develop million: <1kb virtual DOM - it's fast!

Introduction

The reasoning behind this is because modification and access of DOM nodes is computationally expensive. A diff between virtual nodes, accessing the DOM only for modification, is the premise of virtual DOM. It avoids the DOM as much as possible, favoring plain JavaScript objects instead, making reading and writing much cheaper.

How does it work?

The Million virtual DOM contains three main functions: m, createElement, patch. To completely understand how virtual DOM works, let's try and create our own rudimentary virtual DOM based off of these functions (~7 minutes read time).

Before we start, we need to define what a virtual node is. A virtual node can either be a JavaScript object (virtual element) or a string (text).

The m function is a helper function that creates virtual elements. A virtual element contains three properties:

tag: which stores the tag name of the element as a string.
props: which stores the properties/attributes of the element as an object.
children: which stores virtual node children of the element as an array.

An example implementation of the m helper function is below:

const m = (tag, props, children) => ({
  tag,
  props,
  children,
});

This way, we can construct virtual nodes easily:

m('div', { id: 'app' }, ['Hello World']);
// Is the same as:
{
  tag: 'div',
  props: { id: 'app' },
  children: ['Hello World']
}

The createElement function turns a virtual node into a real DOM element. This is important because we'll be using this in our patch function and the user may also use it to initialize their application.

We'll need to programmatically create a new detached DOM element, then iterate over the virtual element props while adding them to the DOM element, and finally iterating over the children, initialling them as well. An example implementation of the createElement helper function is below:

const createElement = vnode => {
  if (typeof vnode === 'string') {
    return document.createTextNode(vnode); // Catch if vnode is just text
  }
  const el = document.createElement(vnode.tag);
  if (vnode.props) {
    Object.entries(vnode.props).forEach(([name, value]) => {
      el[name] = value;
    });
  }
  if (vnode.children) {
    vnode.children.forEach(child => {
      el.appendChild(createElement(child));
    });
  }
  return el;
};

This way, we can convert virtual nodes to DOM elements easily:

createElement(m('div', { id: 'app' }, ['Hello World']));
// Is the same as: <div id="app">Hello World</div>

The patch function takes an existing DOM element, old virtual node, and new virtual node. This won't necessarily be the most performant implementation, but this is just for demonstration purposes.

We'll need to diff the two virtual nodes, then replace out the element when needed. We do this by first determining whether one of the virtual nodes is a text, or a string, and replacing it if the old and new virtual nodes do not equate each other. Otherwise, we can safely assume both are virtual elements. After that, we diff the tag and props, and replace the element if the tag has changed. We then iterate over the children and recursively patch if a child is a virtual element. An example implementation of the patch helper function is below:

const patch = (el, oldVNode, newVNode) => {
  const replace = () => el.replaceWith(createElement(newVNode));
  if (!newVNode) return el.remove();
  if (!oldVNode) return el.appendChild(createElement(newVNode));
  // Handle text case
  if (typeof oldVNode === 'string' || typeof newVNode === 'string') {
    if (oldVNode !== newVNode) return replace();
  } else {
    // Diff tag
    if (oldVNode.tag !== newVNode.tag) return replace();
    // Diff props
    if (!oldVNode.props?.some((prop) => oldVNode.props?[prop] === newVNode.props?[prop])) return replace();
    // Diff children
    [...el.childNodes].forEach((child, i) => {
      patch(child, oldVNode.children?[i], newVNode.children?[i]);
    });
  }
}

This way, we can patch DOM elements based on virtual nodes easily:

const oldVNode = m('div', { id: 'app' }, ['Hello World']);
const newVNode = m('div', { id: 'app' }, ['Goodbye World']);
const el = createElement(oldVNode);

patch(el, oldVNode, newVNode);
// el will become: <div id="app">Goodbye World</div>

Notes:

The old virtual node must always model the DOM element until after it is patched.
Generally speaking, applications aren't directly written with these methods, rather they should be abstracted out into components and JSX for simplicity.
This is not the same as Million's implementation, rather it is a demonstration to better allow you to understand how the virtual DOM works.

So... What's unique about Million then?

Million provides five major improvements: granular patching, fewer iterative passes, fast text interpolation, keyed virtual nodes, compiler flags.

Granular patching: Instead of just replacing the entire element when there is a difference in props or children, only the necessary props are changed.
Fewer iterative passes: Million attempts to reduce the amount of passes during diffing, allowing for better time and space complexity.
Fast text interpolation: Instead of replacing text nodes with DOM methods, Million uses compiler flags to set the textContent of elements to boost performance.
Keyed virtual elements: This allows for the patching algorithm to skip nodes if the new virtual element key is the same as the old one, minimizing the amount of unnecessary work.
Compiler Flags: This allows for the patching algorithm to skip condition branches, meaning less work is done.

DEV Community: Aiden Bai

Unleashing Million.js v2.0.0

What's new?

Why Million?

How does this work?

Acknowledgements

I made React with a faster Virtual DOM

Using million/react

Turning MPA to SPA with Virtual DOM

Motivation

Usage

Exploring Blockdom: Fastest Virtual DOM (ever!)

Blockdom is really fast

Generalized Blocks

aidenybai / million

Optimize React performance and make your React 70% faster in minutes, not months.

What is Million.js?

👉 Setup Million.js in seconds! →

Installation

Conclusions

ged-odoo / blockdom

A fast virtual dom library

blockdom

Million.js 1.0.0 Release!

What is Million.js?

Why?

Next Steps

Learn more:

The Million.js Manifesto

Past

Present

Future

Million.js - The Future of Virtual DOM

TL;DR

Introduction

Virtual DOM Optimizations

Compiler Optimizations

Conclusion

Tips to get Visibility + Feedback to your GitHub project

TL;DR

Introduction

Platforms

Hacker News

Dev.to

Reddit

ProductHunt

Other

Metrics

Side Effects

GitHub Trending

Publications

Why Virtual DOM?

Introduction

Virtual DOM

Million

How does Virtual DOM work? (Build your own)

Introduction

How does it work?

So... What's unique about Million then?

Using `million/react`