Collaborate with mithril

[Raynos]

https://github.com/lhorie/mithril.js

@lhorie We seem to also have an interface very similar to yours, h vs m. We are also implementing a diff and patch system to allow efficient updates.

Would be cool to see if we can collaborate or share ideas.

[Matt-Esch]

We have broken the current code base into highly reusable components, and I don't think there is anything left to action on this. These packages will end up as standalone modules once we have agreed on everything. Closing this issue now, but feel free to leave comments.

[Raynos]

This is is more communicating with @lhorie about whether we can collaborate in some fashion.

[lhorie]

In terms of actual code, I'm going to agree w/ @Matt-Esch, I don't see anything really actionable here. Mithril's virtual DOM API is less comprehensive than this project's because I don't see the need for things like a public patch method within the context of Mithril. That kind of method has implications both in terms of code size and API complexity, and in order for Mithril to keep both low, it consciously makes an API orthogonality trade-off, unlike virtual-dom. I'm not saying virtual-dom is wrong, I think virtual-dom is taking the correct approach given it's focused exclusively on, well, the virtual dom. I'm just saying that idiomatic Mithril doesn't need certain aspects, so I don't include them.

I don't think either project would be interested in breaking its APIs to conform with the other either, and personally I don't care for API standardization bureaucracy a la Promises/A+.

In terms of discussion, though, I'm more than happy to trade ideas.

One of the lingering concerns I have right now is performance in the "developer-shot-own-foot" scenario, i.e. someone who made a gigantic template and is running into slowness because they're trying to push a million DOM elements into the document. I thought about implementing a mechanism similar to 3D games, where it skips rendering of things that are off-screen. Conceptually, it's an algorithm that could exist without the need to expose a dedicated API, but in practice I'm not sure how feasible that is (given the need for browser repaints to calculate screen offsets, complexity related to scrolling, etc)

virtual-dom provides the concept of components to deal with this. From my Angular experience, I found that this optimization can backfire: comparing data to determine whether a component needs to update is essentially Angular's dirty checking and can be even more expensive than just doing the diff of the template subtree, especially once your page is complex enough to start running into performance problems. In my case, I had half a dozen relational entities and there was a lot of "noise" data (e.g. every field in a "user" object when you only use the name on the template), so it was hard to reason about the performance differences between dev and prod, as well as the impact of incremental additions to the web service entities (and yes, the web service design was suboptimal and largely out of my control, as is often the case in the real world).

Another problem is that if the data does change a single field, the subtree does need to be evaluated (on top of the cost of dirty checking), and this is a scenario that was happening a lot for me.

As I mentioned here, I'm open to implementing a mechanism that is similar to virtual-dom's component concept, but given the high potential for shooting yourself in the foot (given that the scenario implies having already shot yourself in the foot once), I'm only considering it as a plugin, not as a public API in Mithril core.

[Raynos]

I don't think either project would be interested in breaking its APIs to conform with the other either, and personally I don't care for API standardization bureaucracy a la Promises/A+.

I would not recommend for that. The only thing I can recommend is that both mercury and mithril have their own h and m function respectively that both returns instances of vnode. This way both mercury and mithril can re-use diff.js from virtual-dom.

Also if both mercury and mithril use vnode instances then the solution that does server-side rendering will work for both mercury and mithril templates.

I do NOT want to standardize API. I want to share and re-use internal implementation details.

[Raynos]

comparing data to determine whether a component needs to update is essentially Angular's dirty checking

My usage of components solves this with immutable data structures. In theory I do < 5 equality checks ( https://github.com/Raynos/vdom-thunk/blob/master/index.js#L23-L28 ) which should always be cheaper then calling the function which creates a bunch of objects & arrays.

I'm not actually optimizing for avoiding to diff the virtual tree. The optimization is to avoid creating a virtual tree in the first place which should significantly reduce GC churn for large virtual trees.

[lhorie]

@Raynos Mithril's vnode signature is public and documented here. so changing it would be a break in API - it would break app code for anyone using the template compiler, for example.

The usage of immutable data structures is definitely interesting, although somewhat exotic in terms of what most developers are familiar with. I think my suggestion of exposing a low level flag and allowing plugins to figure out the exact implementation of the trigger mechanism would certainly allow for that solution to work.