4 ms·

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.h

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 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).

sdegutis 7y ago
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://mithril.js.org/stream.html
- modarts 7y ago
  https://cycle.js.org/ https://cycle.js.org/
  - chrisweekly 7y ago
    +1 for cyclejs! Strange to me that it hasn't caught on more
    - sdegutis 7y ago
      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.
    - pier25 7y ago
      This is probably one reason: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
pier25 7y ago
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.
anonytrary 7y ago
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.
- lhorie 7y ago
  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.
  - anonytrary 7y ago
    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?

sdegutis 7y ago

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://mithril.js.org/stream.html

modarts 7y ago
https://cycle.js.org/ https://cycle.js.org/
- chrisweekly 7y ago
  +1 for cyclejs! Strange to me that it hasn't caught on more
  - sdegutis 7y ago
    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.
  - pier25 7y ago
    This is probably one reason: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...

pier25 7y ago

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.

anonytrary 7y ago

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.

lhorie 7y ago
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.
- anonytrary 7y ago
  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?