4 ms·
Actually a clean library .Github has more details on why it is faster than React >Monkberry is 10 times faster, sometimes 100 times faster. It's because Monkbe
by hitr 10y ago
Actually a clean library .Github has more details on why it is faster than React
>Monkberry is 10 times faster, sometimes 100 times faster.
It's because Monkberry will do only necessary dom updates, and does it in a completely different way than React does.
Monkberry compiles template to plain JavaScript to gain an advantage by using v8 hidden classes and reduce call stack. There is no virtual dom (in general, an react app have to keep 3 virtual doms), for example next template will be generated to JavaScript code which will do only necessary dom updates on state changes.
and also some benchmarks comparing against it.
http://monkberry.js.org/benchmark/ http://monkberry.js.org/benchmark/
I always enjoy reading why someone developed new library or tool because they wanted to improve something about a library they were using.It may not be a big thing but it surely gives one or two flaws about your favorite library you are so fond of .
- lhorie 10y agoI asked the author if he could put together a dbmon so we could compare apples to apples. Unfortunately, React is not a good representative of modern virtual dom overhead/performance. On dbmon, React is somewhere between one and two order of magnitudes slower than many virtual dom libraries (e.g. mithril rewrite, inferno, kivi), with render times in the 60-100ms range (vs 2-10ms range for the other libs), and proportionally similar results in vdom benchmark. As far as I could see, Monkberry doesn't implement the search space reduction algorithm that the libraries above do, and uses only mapped reordering, so I'm curious if its compilation+mapped reordering combo can outperform search space reduction w/ a virtual dom overhead. Anyways, regardless of how well it does against vdom libs that do take advantage of hidden classes etc, I really like the execution of this project.