I actually think that mithril's redraw algorithm is less intuitive to use than react, but it is way simpler, which has its own advantages.
[edit] No time tonight to make it pretty and publish it, but here it is[1]. Usage is identical to my parenscriptx[2] (a React tool I wrote that I based this off of).
Also, thank you for the mithril blog. It is amazing.
Everybody else, if you haven't read the mithril blog[1], YOU SHOULD BE READING THE MITHRIL BLOG. Even if you never plan to use mithril, you'll probably learn something interesting.
I personally despise Lisp syntax.
Typically, Mithril uses raw JS lists, function calls, and objects to create its vdom, which you have to directly manipulate. Like using react without JSX. With a lisp syntax, you might write the end of an expression as )))))), as opposed to in JS, where you might write )])]}); or something similar.
But it's not strictly parenthesis that bother me. You're right in that )]}) is actually far more annoying. I try not to nest that deep in JS if I can help it.
Arrow functions reduce the pain. Not passing array literals in function calls helps as well. Angular seems like the big culprit that injects [] into the middle of an argument list, for me anyway, and using that syntax is optional.
I've actually considered the idea of hacking a JSX compiler to spit out Mithril output.
If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.
It did seem like an obvious thing to do. I probably would have searched for and found this before doing any actual work on JSX, but I'm glad to know it exists already. :)
It took me a long time to figure that was the point and it still kind of seems you could write in good old plain javascript:
x = "some state"
if (you want to change it) { x = "some other state"
DrawThingOneThatDependsOnx()
DrawThingTwoThatDependsOnx()}
(Plus with vanilla js running up to 40x faster than React https://news.ycombinator.com/item?id=9824884 apparently)
That particular link is a strawman argument. React isn't magically fast. Writing a 5 line shouldComponentUpdate would normalize the performance.
If you think you can do better with something else, feel free to ignore the React hype. For my part, I've been doing frontend full time more or less exclusively since 2005 and have tried dozens of libraries/frameworks in earnest. I don't know of a better way to write client side code.
State control is not simple when you have many moving parts. A very good solution (which both Angular and React bring to the table without destroying performance most of the time) is to remove all the moving aspects to the parts. This doesn't matter in microbenchmarks, but in real apps, having something be slightly slower but bug-free is better than fast but wrong.
function constructor(spec) {
let {member} = spec,
{other} = other_constructor(spec),
method = function () {
// accesses member, other, method, spec
};
return Object.freeze({
method,
other
});
}
All application state can be stored in a single "Atom" (i.e immutable data) and all message passing can be achieved through CSP channels.
When dealing with the DOM, 'incremental-dom' is a nice option.
Of course, separating pure functions from side-effects inducing code is key to maintaining control.
This is my approach when going "framework-less".
https://developers.google.com/closure/compiler/docs/api-tuto...
Not an excuse for baroque frameworks though.
The end result is very React-like in behavior, but completely interoperable with other web components, and not require a framework at all.
Web Components hasn't been supported by all browsers (and probably still isn't) and has had some problems with grouping components and loading them. I can use React today but Web Components is something I might want to use in 2-3 years.
State control. The most important thing about a React app is that you can write your code to have every bit of application state inside a single variable. It gets you hot code loading, trivial testability, and session recording/replay. I can actually test the app without having to use selenium (which I hate). These aren't really benefits from React per se but from the vdom approach. My apps are in Clojurescript and don't use the majority of React's features so replacing it with an alternative vdom implementation is on my todo list for this year.
I haven't used it in anger, but Polymer is at the top of my list if I needed to write an app to integrate with a third party or something where I didn't have app state control.