React made me sad, so I switched to Mithril[1]. Not only is it significantly smaller in size, but it's way faster and includes a router and AJAX methods out of the box. I wish more people would give it a shot.
That said, I do still love React Native, and use React on a daily basis to take advantage of the "write once, run anywhere" paradigm.
We're currently using Mithril and one of the biggest issues was getting started in it. It's adoption is lacking, making finding people who've had similar issues difficult. Solving every problem yourself is much harder than finding an existing answer on SO.
That said, we still use it, but we're considering moving to React in the future, mostly since its learning curve is a lot less steep and we would be able to iterate faster.
Have you tried the mithril.js gitter channel[1]? It's sort of the de-facto go-to-place for mithril questions; there are lots of active users there who are willing to help you out
You can also drop me a line via email, and I'd be happy to help too.
While domvm [1] is young and doesn't have the adoption of Mithril (not even within an order of magnitude), it does solve many issues that people frequently have with Mithril's architecture and magic. Check it out if you'd like. Disclaimer: I'm the author and 1.0 (stable) target is April 1st.
It's a half-joke date. I'm the only dev and there's still a crapload of docs and tests to write. If I can't hit it, then at least I have a good April Fools joke prepared :)
Truthfully, my knowledge is second hand. I haven't spent a ton of time with it, my coworker is the one who had issues learning it. I've spent a little time with it, and haven't had the same issues he ran into.
I think the issue comes from the learning curve between jQuery and Mithril. Coming to Mithril from React I'd imagine would be relatively easy, where coming to it from JS spaghetti would be rough due to the lack of adoption and step-by-step tutorials that exist compared to React.
In practice you'll learn React Native once (1), learn some of each platform's intricacies (N), and sometimes need to debug (at most for each platform, so 0...N.
I've recently started playing with Mithril as well and I quite like it.
I haven't used React or Mithril enough to speak confidently about the differences, but it seems Mithril offers everything React does and more with better performance and documentation.
I'm planning to keep the basic, most used APIs the same, but yes, there will be some breaking changes. Promises will follow ES6 API and advanced redraw control APIs will likely be changed to improve ergonomics and leverage good ideas from other vdom libraries.
Other correct comments about a quite active 'next' branch aside... The latest commit on master is Nov 12, 2015. That's not even half a year ago. The stable shelf life of software worth mentioning is longer than that, don't you think?
> That's not even half a year ago. The stable shelf life of software worth mentioning is longer than that, don't you think?
I can see that you haven't spent much time in the JavaScript ecosystem. And forget latest commit, if a JS project wasn't started in the last half year, it's already getting long in the tooth. After a half year, trendy devs will already start moving on to the next great framework and package manager.
Yes, that is my point, with so many options in JS frameworks, libs, etc, I normaly study Github activity before jumping in. Learning a new tool takes time and we cannot afford to waste it on dead-end projects.
Yes of course, but I would expect many commits between stable releases (patching issues). I guess this is just a different pattern where a solo-dev goes quitely working for a few months and then emerges with the next release.
To give some context, even though the version is at 0.2.x, it's been fairly stable for months, and there have been very few bug reports (despite it being used fairly extensively in relatively big codebases - see lichess.org, for example).
Most of the "bugs" (or rather, limitations) in the issue tracker are either discussions or things that are difficult to address w/ the current codebase - e.g. design/ergonomics issues, as opposed to implementation issues - Those are part of the reason for the rewrite.
Another thing that is worth mentioning is that Mithril's general philosophy is to avoid adding features for features' sake, so it can look less "active" than it actually is.
That said, I do still love React Native, and use React on a daily basis to take advantage of the "write once, run anywhere" paradigm.
[1] https://lhorie.github.io/mithril/