3 ms·

was about to mention Mithril. solid framework, but not great for large applications.

by holtalanm 6y ago

brlewis 6y ago
What issues have you encountered that make it not great for large apps?
- holtalanm 6y ago
  it has been a few years, so maybe these issues have been addressed at some point since I used it last, but: 1) there were multiple issues with deeply nested object models not being reactive within the UI code that cause me to explicitly call m.refresh (can't remember the exact api, as it has been a while, but the function that was called forced a virtual dom refresh, which was _not_ good for performance). I ended up writing a debounce function that would make sure the m.refresh function only got called once per paint at the most, which helped, but it was just a band-aid over the underlying problem, which was that the framework was not detecting reactive property changes within deeply nested models. At the time I was using it, there was no other remedy according to issues that had been brought up on stack overflow. 2) this is probably personal opinion, but the hyperscript model for structuring html, while it looks good on paper, lends to a really tedious process of writing html-generating javascript. I guess I didn't need a numbered list. Those were my main two gripes.
  - brlewis 6y ago
    For (1), m.redraw() is async; I don't think you have to debounce anymore. The autoredraw system may be more sophisticated than when you used it, too. https://mithril.js.org/autoredraw.html https://mithril.js.org/autoredraw.html For (2), I've been using JSX with Mithril the whole time. My team and I didn't like deeply nested hyperscript either. (At my employment we're in the process of moving away from Mithril, but I'm still using Mithril 2 in a side project)
lhorie 6y ago
Curious why you claim that. It can be used the same way as React is used, and React is largely touted as something that is fitting for large apps.

was about to mention Mithril. solid framework, but not great for large applications.

brlewis 6y ago

What issues have you encountered that make it not great for large apps?

holtalanm 6y ago
it has been a few years, so maybe these issues have been addressed at some point since I used it last, but: 1) there were multiple issues with deeply nested object models not being reactive within the UI code that cause me to explicitly call m.refresh (can't remember the exact api, as it has been a while, but the function that was called forced a virtual dom refresh, which was _not_ good for performance). I ended up writing a debounce function that would make sure the m.refresh function only got called once per paint at the most, which helped, but it was just a band-aid over the underlying problem, which was that the framework was not detecting reactive property changes within deeply nested models. At the time I was using it, there was no other remedy according to issues that had been brought up on stack overflow. 2) this is probably personal opinion, but the hyperscript model for structuring html, while it looks good on paper, lends to a really tedious process of writing html-generating javascript. I guess I didn't need a numbered list. Those were my main two gripes.
- brlewis 6y ago
  For (1), m.redraw() is async; I don't think you have to debounce anymore. The autoredraw system may be more sophisticated than when you used it, too. https://mithril.js.org/autoredraw.html https://mithril.js.org/autoredraw.html For (2), I've been using JSX with Mithril the whole time. My team and I didn't like deeply nested hyperscript either. (At my employment we're in the process of moving away from Mithril, but I'm still using Mithril 2 in a side project)

lhorie 6y ago

Curious why you claim that. It can be used the same way as React is used, and React is largely touted as something that is fitting for large apps.