How I built a super fast JS/TS framework
Tags: javascript, vue, react, showdev
Published: 2019-04-26 14:52:46

---
title: How I built a super fast JS/TS framework
published: true
description: First of all I want to address elephant in the room that is one question you might be having: “Why the heck another JavaScript framework ?”. Well, my answer is that I noticed a pattern in all of the frameworks I recently went through and all of them have the same problem. They are stuck in creating Virtual DOM and then running the diffing algorithm over it, which led to diffing algorithm wars.
tags: js, vuejs, react, showdev
cover_image: https://thepracticaldev.s3.amazonaws.com/i/cz8bvziftuaqnvji8c3e.png
---

# How do other frameworks operate?

What if we didn't use Virtual DOM at all, instead work with real DOM instead? To answer this, we first need to understand how most frameworks work, to better illustrate this I drew a small example.

![img](https://thepracticaldev.s3.amazonaws.com/i/g25b38qhbuf2se3ultxp.png)

Violet are DOM/VDOM nodes, Blue = state, Red = diffing, Green = patching. I should explain what happens in this picture. So most of the frameworks that have state and DOM, act like this when something in the state is modified. In this example, state.bg has changed. So now we iterate through all of the nodes (those 5 steps) and renders them. If something is changed, then patching happens where rendered stuff goes to actual DOM (green action). Ok, that's cool, but why do we need to iterate every single node (note that here come those diffing algorithms that compete with each other and some does diff differently) when only state.bg changes?!..

So back to my original question “Why do we need Virtual DOM ?”, the answer is to iterate through all of DOM more quickly. Ok, so what if we didn't iterate?

# Utopia way of doing this

But I want to show you the way that in my head it should work without diffing nor iterating, nor Vnodes for that matter as well.

![img](https://thepracticaldev.s3.amazonaws.com/i/dqb4xxm4q2w1w4oemihe.png)

So in this utopia way we changed the same state.bg and there is no iteration (so no need for Virtual DOM), only one render (that single red dot), only one single parameter/attribute/node modifies which is affected by state.bg changes. Much less unnecessary iteration, unnecessary memory usage for virtual nodes, much less rendering = much faster.

# Motivation

*1. Small bundle size*
Many of the modern frameworks are very large. I honestly do not believe that the application “Hello World” should weigh more than 10kb. 
To solve this problem, I decided to use a declarative way to describe the components. This has a positive effect on the final size of the application and allows you to use the tree-shaking directly in the component template.
[Playground](https://stackblitz.com/edit/typescript-cuat9d)

*2. Truly reactive*
I really wanted to implement reactivity as it was done in VueJS. If you change the entity of something, then the data on the page also changes, and if you change the data, the entity changes.
[Playground](https://stackblitz.com/edit/typescript-ddsu5c)

*3. Pure reusable components*
Any framework should be able to create life-cycle-aware components. This removes duplication of code and allows the component to be reused in several places.
[Playground](https://stackblitz.com/edit/typescript-cf54fk)

*4. Conditional render and list render directives*
I really like the ReactJS, very straight, the first acquaintance, it was just wonderful. However, if you need nested conditional rendering, you will have to either use component wrappers or make ternary expressions that are difficult to read.
[Playground](https://stackblitz.com/edit/typescript-gssmle)

# Benchmark application
[Playground](https://stackblitz.com/edit/typescript-p35cgr)
## Another frameworks
React (Stack) — https://claudiopro.github.io/react-fiber-vs-stack-demo/stack.html
React (Fiber) — https://radi.js.org/fiber/Fiber%20Example.htm
Stencil.js — https://stencil-fiber-demo.firebaseapp.com/perf.html

# Performance test

1. https://pxyup.github.io/Revact/ - try with throttling x6 times.
2. https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html (old name faster-dom)

# Link

1. https://github.com/PxyUp/Revact - source
2. https://pxyup.github.io/Revact/ - DEMO
3. https://github.com/RyuuGan/html2FastDom - Html transpiller