3 ms·

Noted. Meanwhile, this is 12.3kB (uncompressed) while React's core (minus addons or anything) is 121.7kB. For something as young as this, and to do fairly well

Noted. Meanwhile, this is 12.3kB (uncompressed) while React's core (minus addons or anything) is 121.7kB. For something as young as this, and to do fairly well in a number of benchmarks compared to the highly engineered piece of work that is React is pretty great. This library can only get better. It's great to see someone trying to make a more lightweight React. Also, you can see exactly how the benchmarks are run through the /test folder. My test using PhantomJS gave me the same results as the recorded statistics against Safari. And because it uses the browser's built in DOM toolkit rather than a virtual one, (in theory) it should become faster whenever browser DOMs become faster.

blablabla123 11y ago
> It's great to see someone trying to make a more lightweight React. For sure, also I must say how amazed I am about React's great ecosystem. In only a year a lot of high quality plugins have been created.
psteeleidem 11y ago
On the following note: > it should become faster whenever browser DOMs become faster The killer feature of React is that it made it possible to efficiently rerender the entire UI and for developers to not have to write code to manually manipulate the DOM. I hope browser vendors take note of this and do more to support this use case. Ideally, morphdom should not even exist and we could instead have the browser natively do the job of diffing/patching the DOM. Admittedly, there would have to be a lot of details to work out, but React, virtual-dom and morphdom are working in the right direction. Behind the scenes, the implementation might change and any good UI framework should make this a non-breaking change.
explorigin 11y ago
Allow me to introduce you to Mithril (http://mithril.js.org/ http://mithril.js.org/), the 18kB (uncompressed) virtual-dom implementation that beats React in many benchmarks. > And because it uses the browser's built in DOM toolkit rather than a virtual one, (in theory) it should become faster whenever browser DOMs become faster. ...as will all virtual-dom implementations get faster as JS becomes faster. I would argue that there is more attention paid to JS-speed than DOM-speed because there is a server-side (among other things).

blablabla123 11y ago

> It's great to see someone trying to make a more lightweight React. For sure, also I must say how amazed I am about React's great ecosystem. In only a year a lot of high quality plugins have been created.

psteeleidem 11y ago

On the following note: > it should become faster whenever browser DOMs become faster The killer feature of React is that it made it possible to efficiently rerender the entire UI and for developers to not have to write code to manually manipulate the DOM. I hope browser vendors take note of this and do more to support this use case. Ideally, morphdom should not even exist and we could instead have the browser natively do the job of diffing/patching the DOM. Admittedly, there would have to be a lot of details to work out, but React, virtual-dom and morphdom are working in the right direction. Behind the scenes, the implementation might change and any good UI framework should make this a non-breaking change.

explorigin 11y ago

Allow me to introduce you to Mithril (http://mithril.js.org/ http://mithril.js.org/), the 18kB (uncompressed) virtual-dom implementation that beats React in many benchmarks. > And because it uses the browser's built in DOM toolkit rather than a virtual one, (in theory) it should become faster whenever browser DOMs become faster. ...as will all virtual-dom implementations get faster as JS becomes faster. I would argue that there is more attention paid to JS-speed than DOM-speed because there is a server-side (among other things).