I experimented with React a bit but I was a bit bugged by how large it was. The basic idea of rendering to a virtual DOM and having unidirectional data flow is really simple but I had trouble actually diving in to React's source code and seeing things under the hood (for example, I had to find a blog to see how the diffing algorithm worked).
What are the other libraries out there that we can use for this virtual DOM pattern right now? I only found mithril[1] that similarly does the template rendering with Javascript but I still don't know how different to React it is in the end? Is the diffing algorithm similar? Do they handle corner cases the same (many attributes need to be treated specially when writing them to DOM)?
Simplifying it a bit: other than the virtual DOM, is the rest of React also the best way to structure apps? What would the ideal "barebones" virtual DOM library look like?
While the basic idea of rendering to a virtual DOM is simple, making it work well for large applications require a lot more than a toy implementation as described in the article.
In order to get adopted, React needs to coexist with existing applications/third party libraries that do manual DOM mutations. The life cycle methods are there to deal with this.
React implements its own class system that supports mixins and type annotations. The plan is to change the API to use ES6 classes (we're working to improve the standard to support all React use cases).
React re-implements its own event system in order to make it fast, memory efficient and abstract away browser differences.
Making composable components is not as straightforward as it first seems. There are a lot of edge cases like refs, owner/parent to be handled.
Then, as you mentioned, there's the diff algorithm and batching strategies which need to be implemented in a performant and memory efficient way. And provide hooks for the user to be able to give it hints via shouldComponentUpdate.
I'm not familiar w/ React's implementation, so I can't speak for them. With Mithril, the diffing algorithm is basically a recursive tree diff. In addition to diffing at the attribute level (and taking care of some broken edge cases), it can do things like detect parent changes and reattach unmodified trees to new parents, if needed. I generally don't like corner-case-specific optimizations because I believe there are better directions to explore in order to improve performance (Mithril has a concept called SubtreeDirectives that I'm planning to expand on, for example). At the end of the day, one has to ask themselves if loading and parsing code to handle a bazillion rare corner cases is really significantly better than just doing the naive thing. The benchmark on the Mithril homepage seems to suggest that being minimalist performs better at the worst and arguably most important case (the first render).
Mithril in its entirety (with router, promises, ajax, etc) is ~500 lines of code (vs Bloop's 250) and the diff implementation has gotten more and more robust over the course of v0.1.* thanks to the Mithril community. I'd love to be proven wrong, but I'm seriously doubtful you can get a better balance between leanness and robustness elsewhere.
Re: best way to structure apps: I just posted an article ( http://lhorie.github.io/mithril-blog/an-exercise-in-awesomen... ) that ports some of the examples in this article over to Mithril to see how the two compared. My conclusion was that it's definitely possible to structure apps in a React-like style with Mithril. There a lot of benefits that this structure brings to the table, and using well understood design patterns effectively can go a long way to complement the componentization paradigm.
I don't force any particular implementation of the MVC pattern with Mithril, but I try to always organize code following the classic MVC pattern in my own code. My blog is partly an effort to document the techniques that can be used to support a liberal MVC pattern without necessarily committing to React's OOP paradigm or whatever.
I have a similar frustration with React. The source code is very hard to read our follow.
An ideal "barebones" virtual dom library looks like https://github.com/Matt-Esch/virtual-dom . The `virtual-dom` module was build out of frustration with the readability of react source code and is the minimal modular subset.
I've also built a small framework on top `virtual-dom` to add in essentials like immutable state and event handling ( https://github.com/Raynos/mercury ). Whilst mercury might not be the best way to structure apps, it's an approach that is getting me far and I'm drawing strong inspiration from FRP and FP systems like Elm and om.
Is there a single-file version of virtual dom available for download? I am not finding any instructions in the repo on how to build it. Also, why does it have so many files in the first place?
It has many folders because the `vtree`, `vdom` and `h` are fundamentally seperate concepts.
Again each one is seperated into it's own files, this allows you to just require the `is-x` functions or the `diff` function alone without having to depend on the entire implementation.
It's also easier to maintain code if it's not one big file.
What are the other libraries out there that we can use for this virtual DOM pattern right now? I only found mithril[1] that similarly does the template rendering with Javascript but I still don't know how different to React it is in the end? Is the diffing algorithm similar? Do they handle corner cases the same (many attributes need to be treated specially when writing them to DOM)?
Simplifying it a bit: other than the virtual DOM, is the rest of React also the best way to structure apps? What would the ideal "barebones" virtual DOM library look like?
[1] http://lhorie.github.io/mithril/