How I built super fast JS framework (Faster than React)

综合技术 Medium (源链)

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 diffing algorithm over it, which led to diffing algorithm wars. And I thought that there is a better way of doing this (sneaking around this war), so I created a tiny JS Framework called Radi.js .

How does 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.

How other frameworks operate on each change

Violetare DOM/VDOM nodes, Blue = state, Red = diffing, Green = patching. I should explain what happens in this picture. So most of frameworks that has state and DOM, acts like this when something in 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 comes those diffing algorithms that compete with each other and some does diffing differently) when only state.bg changes?!..

So back to my original question “Why do we need Virtual DOM ?”, 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.

So in this utopia way we changed 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. This would be so cool right ? The thing is that this is how actually Radi.js work .

How does Radi.js work ?

Now that you know why I created another framework, we can talk how it works underneath. We have state and real DOM nodes, built with HyperScript or JSX. Rather than state being separate, I bind every state value to nodes/attributes that it affects. When something in state changes, it triggers event that re-renders corresponding nodes/attributes. And that is it, not much really going on here.

Performance tests

Finally we need to address my claim, that Radi.js is faster than latest React Fiber. For this, let’s use Reacts own performance test that recreates and animates Sierpinski triangle from DOM node.

There are 2 components 1 is Dot that has prop value as text and hoverable action (wraps number with stars and turns background yellow) with JavaScript not CSS, 2. component is triangle that contains 3 of those Dots. Each visible triangle is nested down in multiple DOM levels. Top component counts from 0 to 10 (on repeat) and feeds this number down to every single component. Also top level component is being constantly resized.

Here are tests for React , Stencil and Radi.js filmed on not that powerful machine.

React ~1.8 fps

Stencil ~41 fps

Radi.js ~58.9 fps

All tests are available live! Take a look yourself:

React Fiber (stack) — https://claudiopro.github.io/react-fiber-vs-stack-demo/stack.html

Stencil.js (stack) — https://stencil-fiber-demo.firebaseapp.com/perf.html

Radi.js(stack) — https://radi.js.org/perf-test.html

The future of this

All the things considered, Radi.js is still in development and this means core, router, fetch, devtools and compiler are in progress of being finished. I am actually building 4 production ready projects with this framework already. So no escape for not finishing this project. But main goal in mind is to create very lightweight, super duper fast, memory efficient framework that is developer friendly (this means amazing debugging tools and ease of writing code and/or migrating from other framework).

Thanks for staying till the end and stay tuned for more of this next time.

您可能感兴趣的

So you want to learn React.js? First, make peace with the fact that you need to learn more than just React to work with React. This is a good thing, React is a library that does...
Ext JS to React: Load, Sort and Filter Data with R... This is part of theExt JS to React blog series. You can review the code from this article on the Ext JS to React Git repo . In previous article...
前端每周清单第 27 期:React Patent License 回复,Shopify WebVR... InfoQ.com及所有内容,版权所有 © 2006-2017 C4Media Inc. InfoQ.com 服务器由 Contegix 提供, 我们最信赖的ISP伙伴。 北京创新网媒广告有限公司 京ICP备09022563号-7隐私政策 ...
为什么在 React 的 Render 中使用箭头函数和 bind 会造成问题... 简评:在 render 中使用箭头函数或绑定会导致子组件重新渲染,即使 state 并没有改变。作者推荐使用提取子组件或在 HTML 元素中传递数据的方式来避免绑定。 这个例子中,我在 render 中使用一个箭头函数来绑定每个删除按钮对应的用户 ID。 点击 CodeSand...
有赞的 React 组件库(Zent)开源了 Zent ( ˈzent ) 是有赞 PC 端 WebUI 规范的 React 实现版本,提供了一整套基础的 UI 组件。目前我们有 35+ 组件,这些组件都已经在有赞的各类 PC 业务中使用。我们会在此基础上,持续开发一些新组件。 我们的目标是让 React 开发更快、更简...
Medium责编内容来自:Medium (源链) | 更多关于

阅读提示:酷辣虫无法对本内容的真实性提供任何保证,请自行验证并承担相关的风险与后果!
本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » How I built super fast JS framework (Faster than React)



专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录