Hacker News Reader

Comment by arianvanp | Hacker News Reader

To explain why this is nicer than react:

virtual-dom makes zero to non assumptions about your architecture. which I like. It's just dumbly a diffing algorithm and that's it.

Mercury[0] is a "framework" (A collection of opinionated modules) that builds on top of this to give a more complete app stack. And it's really fast[1].

Because it's so dead simple and takes so little assumption, it's really easy to mold to your needs. For example, we've chosen to use it for our Haskell virtual-dom implementation[2]. Also Elm has chosen to use this library for their `elm-html` library [3] and PureScript is using it too [4].

So it's also nicer (in my opinion) from a technical perspective. Not just a licensing perspective.

[0] - https://github.com/Raynos/mercury [1] - http://elm-lang.org/blog/Blazing-Fast-Html.elm [2] - https://github.com/ghcjs/ghcjs-vdom [3] - https://github.com/evancz/elm-html [4] - https://github.com/purescript-contrib/purescript-virtual-dom

View on HN

Yes, the flexibility of virutal dom is really nice. I started to use it with rxjs (Reactive Extensions) only to discover that someone else is already doing so: https://github.com/staltz/cycle

If you really want a functional, stream based frontend in Javascript (vs Elm/purescript/etc), this is well worth looking into. Cycle's author sums up his criticisms of React here: http://staltz.com/dont-react/

Mercury looks like an compelling alternative to React, if only because by comparison React is so unopinionated.

A default stack with the modularity to swap-out as needed should make life easier for someone coming from a Rails Omakasa[1] background, and struggling to choose and learn all the layers needed behind React to make it functional.

[1] http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...

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.

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

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

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)

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

Yeah, all of the Raynos libraries are really nice and modular. Each one is useful on its own (I think with one exception) without the need for the other Mercury components. It's actually quite a feat.

Yep but some could use a bit more documentation love. I should make myself useful...

Reply on news.ycombinator.com