25 ms·

How about Mithril? In any case, I think it's cool to use the Virtual DOM when you need, but React and Mithril forcing you to re-render EVERYTHING every time is

How about Mithril? In any case, I think it's cool to use the Virtual DOM when you need, but React and Mithril forcing you to re-render EVERYTHING every time is a bit too heavy-handed.

masklinn 12y ago
Not sure about Mithril but React certainly does not force you to re-render everything every time. Bypassing re-rendering when unnecessary is what `shouldComponentUpdate` is for, and while React can't switch it on by default because that would require making lots of unwarranted assumptions about the applications it's used for, nothing stops you from setting up a default `shouldComponentUpdate` based on your own system's invariants. That's why Om is faster than React out of the box even though it's implemented on top of React: it can makes assumptions the generic React can't (namely that all component state is immutable and provided through the component's cursor) and can thus set up a fast and generic `shouldComponentUpdate`.
ArthurClemens 12y ago
Mithril already uses a diffing algorithm: "diffs the new tree against the existing one and intelligently modifies only the portions that have changed": http://lhorie.github.io/mithril/mithril.render.html http://lhorie.github.io/mithril/mithril.render.html
lhorie 12y ago
Hi, Mithril author here All three libraries have similar virtual dom implementations. In all of them, rendering to the DOM itself only happens on nodes that need it, otherwise nodes aren't touched at all. Diffing is what runs on the entire template on every redraw, but all 3 libraries provide APIs to skip diffing of certain areas of the template based on some condition (i.e. React has shoudComponentUpdate, Mithril has subtree directives, Mercury has thunks). Diffing everything on a redraw might sound expensive, but it's actually a pretty good strategy performance-wise, and more importantly, it makes it easier to reason about and fix performance bottlenecks, compared the alternatives used by older frameworks (dirty checking, observables) Between Mithril and Mercury, honestly, they are fairly similar in terms of what they offer. Mercury's modularity makes its parts popular among projects that aren't strictly web applications themselves, whereas Mithril has a very strong focus on powering web apps (e.g. docs-are-a-must policy, small footprint and API surface, no build system required, etc)
- FractalNerve 12y ago
  Hi, I've thought a classroom with master students in computer science Mithril and we've found that the tutorials on your Homepage aren't easy to follow. A girl for example wanted to follow the tutorial 1:1 but found herself stuck, we know that the code at the bottom of the page worked, however I would heartly support you and your framework more, if there were easier to follow tutorials, more examples, integrations into build systems etc. The topic of my talk and excercises was building & scaling modern web apps. That's we used: React, Yeoman, Mimosa.io, Swagger, Strongloop, Redhat OpenShift, Microsoft Azure and VisualOps.io to quickly build a build framework, deployment targets and a workflow for a 'large' sample application and develop modules for the web app that consumes other APIs. We've also used Mimosa.io and Yeoman and have followed the tutorials on their websites and were very pleasantly surprised. Especially the tutorial on Yeoman's site was stellar. I think integrating Mithril with both of these frameworks with one empty and one opiniated boilerplate to quickstart into coding without having to create the js/css/html files by hand would be more practical to follow by total newcomers. It would also fit the keyword "modern" in my talk more than having to do it by hand. Thank you for taking the time to read this far! You're invited to a cool and chilled beer (or coffe), when you have the pleasure to visit Germany :)

How about Mithril? In any case, I think it's cool to use the Virtual DOM when you need, but React and Mithril forcing you to re-render EVERYTHING every time is a bit too heavy-handed.

masklinn 12y ago

Not sure about Mithril but React certainly does not force you to re-render everything every time. Bypassing re-rendering when unnecessary is what `shouldComponentUpdate` is for, and while React can't switch it on by default because that would require making lots of unwarranted assumptions about the applications it's used for, nothing stops you from setting up a default `shouldComponentUpdate` based on your own system's invariants. That's why Om is faster than React out of the box even though it's implemented on top of React: it can makes assumptions the generic React can't (namely that all component state is immutable and provided through the component's cursor) and can thus set up a fast and generic `shouldComponentUpdate`.

ArthurClemens 12y ago

Mithril already uses a diffing algorithm: "diffs the new tree against the existing one and intelligently modifies only the portions that have changed": http://lhorie.github.io/mithril/mithril.render.html http://lhorie.github.io/mithril/mithril.render.html

lhorie 12y ago

Hi, Mithril author here All three libraries have similar virtual dom implementations. In all of them, rendering to the DOM itself only happens on nodes that need it, otherwise nodes aren't touched at all. Diffing is what runs on the entire template on every redraw, but all 3 libraries provide APIs to skip diffing of certain areas of the template based on some condition (i.e. React has shoudComponentUpdate, Mithril has subtree directives, Mercury has thunks). Diffing everything on a redraw might sound expensive, but it's actually a pretty good strategy performance-wise, and more importantly, it makes it easier to reason about and fix performance bottlenecks, compared the alternatives used by older frameworks (dirty checking, observables) Between Mithril and Mercury, honestly, they are fairly similar in terms of what they offer. Mercury's modularity makes its parts popular among projects that aren't strictly web applications themselves, whereas Mithril has a very strong focus on powering web apps (e.g. docs-are-a-must policy, small footprint and API surface, no build system required, etc)

FractalNerve 12y ago
Hi, I've thought a classroom with master students in computer science Mithril and we've found that the tutorials on your Homepage aren't easy to follow. A girl for example wanted to follow the tutorial 1:1 but found herself stuck, we know that the code at the bottom of the page worked, however I would heartly support you and your framework more, if there were easier to follow tutorials, more examples, integrations into build systems etc. The topic of my talk and excercises was building & scaling modern web apps. That's we used: React, Yeoman, Mimosa.io, Swagger, Strongloop, Redhat OpenShift, Microsoft Azure and VisualOps.io to quickly build a build framework, deployment targets and a workflow for a 'large' sample application and develop modules for the web app that consumes other APIs. We've also used Mimosa.io and Yeoman and have followed the tutorials on their websites and were very pleasantly surprised. Especially the tutorial on Yeoman's site was stellar. I think integrating Mithril with both of these frameworks with one empty and one opiniated boilerplate to quickstart into coding without having to create the js/css/html files by hand would be more practical to follow by total newcomers. It would also fit the keyword "modern" in my talk more than having to do it by hand. Thank you for taking the time to read this far! You're invited to a cool and chilled beer (or coffe), when you have the pleasure to visit Germany :)