Hacker News Reader

Comment by anonytrary | Hacker News Reader

This library isn't meant to have full parity with React, but it's a great example that illustrates how simple a naive VDOM diff/patch is to implement.

That said, this is missing a lot of essential optimizations that libraries like React make. For example, key and type matching, batching updates, scheduling updates, and other stuff that isn't immediately apparent without reading the code.

View on HN

I'm not sure if any of their content is still relevant, but mithril makes some bold claims for >React performance: https://mithril.js.org/framework-comparison.html#react

"Generally speaking, React's approach to performance is to engineer relatively complex solutions.

Mithril follows the less-is-more school of thought. It has a substantially smaller, aggressively optimized codebase. The rationale is that a small codebase is easier to audit and optimize, and ultimately results in less code being run."

(Obviously, I'm not claiming the same for this toy example - just that batching updates etc, may not be necessary for performance).

I wondered what happened to .prop() which looked like it had a lot of potential. Looks like that potential was (at least partially?) realized as it evolved into a "stream" library [1], which basically acts like cells in a spreadsheet. This seems like a really useful concept which could be used to create more kinds of UI frameworks than just declarative React style ones.

[1]: https://mithril.js.org/stream.html

https://cycle.js.org/

+1 for cyclejs! Strange to me that it hasn't caught on more

I just looked over their website for 10 minutes and still can't figure out how it handles more complex nested components with complex state. Is it like Elm and Redux where it has a giant tree and you have to update the root with a bunch of events, creating intermediate adaptor events from the deepest nodes all the way to the top? Does it have anything like React's Contexts? I really like the examples I saw on the landing page, but I would rather like some comparisons of how to do the exact real-world things React can do. Mithril's website did this pretty well. Maybe this is hurting adoption? Or maybe it's just me.

This is probably one reason:

https://krausest.github.io/js-framework-benchmark/current.ht...

I used Mithril recently in a small project and it's quite awesome.

I didn't miss any of React's features plus it includes a router and an http client in less than 10kB gzipped. Heck, my whole application weighted something like 38kB. Not the JS bundle, everything.

The other greatest thing about Mithril is that there is no reactive state per se. Your state are just vanilla objects and vars and then you tell Mithril to redraw the whole thing. It sounds wasteful but it's quite fast and the developer experience becomes a joy.

Mithril is like a sharp sushi chef knife. Since it leaves all the application architecture to you you better know what you're doing otherwise you will cut yourself pretty badly.

It depends on the use case. For applications that experience a high frequency updates near the top of the tree, a naive solution would typically block user input.

Mithril's solution is very simple but using a setInterval(render, 16.6667) has its drawbacks that can lead to jankiness in the UX. React 16 from what I understand is almost a complete rewrite of React and does some smart stuff with animation frames to ensure an optimal UX.

Mithril does use requestAnimationFrame unless you're in some version of IE. But Mithril rendering was never intended to run as the inner loop of an animation. Lifecycle hooks and CSS animations are preferable instead.

React Fiber basically breaks down large animation payloads so each "chunk" can fit within one frame budget, but at the cost of a lot of untreeshakeable internal and peripheral complexity in React core.

Agreed; all of complex scheduling solutions using RIC/RAF and priority queueing are probably not needed for 95% of webapps. The primary need is good state management and a good side-effect framework (e.g. hooks, lifecycle methods).

Do you intend for Mithril to support this sort of "incremental" priority work handling?

Snabbdom[0] might be a better one there, it's not quite 33 lines (the core is about 200), but it is intended to be usable and used in production systems, either on its own or underlying a components system or whatnot.

[0] https://github.com/snabbdom/snabbdom

(sidenote: “snabb” is Swedish for “fast”)

Seems to be, via the verb snappa which is the Swedish version of the Germanic snappen.

I made a similar implementation as the article describes in 60 LOC which also includes a lite versions redux and hooks. (Uses Snabbdom for diff and update of real dom)

https://github.com/irony/pureact

Demo: https://mandatkollen.se which is built in Pureact.

I wonder how well the event binding works. For me this is the main reason to use React because it avoids all the mess that can come from that. Apart from that, React performance is much better than any naive re-rendering solution, on the other hand it's worse than programmatic diffing with native APIs or jQuery...

In what way would you say the event binding here differs from React's? (Genuinely interested).

The main difference from where I'm sitting is that React has a concept of "Component state" - updates to which trigger local redraws. Here you have to manually call:

  renderNoughts()

any time you change state, this rerenders the whole mount point.

If I'm honest, React's state stuff has always seemed a little strange to me Would love people to try explain the point to me, is it just a performance related enhancement?

React's state stuff is just a really basic, batteries-included solution that works for basic things but doesn't really scale. There's nothing special about it in terms of performance. Once you get beyond a certain level of complexity in your app, and need to bring in richer state management, React's mechanisms become dead weight.

The one exception being contexts. Contexts allow you to hook into react's virtual DOM and "talk about" a subtree of it instead of just the very next layer down. This is something that an external library can't replicate, so it's more of a fundamental primitive than setState and hooks are.

I've never deep-dived into that but it's possible to declare components as pure. In that case, as least in theory, React is able to only perform the absolute minimum amount of operations. [1] On the other hand, about binding, the worst-case scenario is that after an update onclick handlers stop working or memory leaks start emerging. It's easy to run into these problems when working for instance with older Frameworks like Backbone.js, which register click handlers procedurally but don't manage the bindings - automatically - during the whole life cycle. Also I've observed such problems with one of the minimalistic React clones, I think it was Preact or Inferno.

[1] https://medium.com/@esamatti/react-js-pure-render-performanc...

Reply on news.ycombinator.com