Depreciate elmish-snabbdom

[elmish]

Depreciate elmish-snabbdom

[Zaid-Ajaj]

@MangelMaxime Thanks a lot for the detailed explanation 😄, these are all valid points indeed. However, I think it is worth noting that snabbdom has the advantage over React when it comes to enforcing statelessness, there are no components, which I thought was the whole point of Elm. React can be totally stateless but it leaks that abstraction and let the developer decide how he makes his state soup.

Anyways, that was just two cents :)

Keep up the good work 👍

[Zaid-Ajaj]

😱 But why?

[et1975]

@Zaid-Ajaj just a side note: baseline React lib itself has no stateful components and as this is elmish, you'd have a hard time making use of such a component (I've tried that with some of the legacy Native components), so I don't think it's a valid concern.

[ncave]

@MangelMaxime Thanks for sharing the long-term view, +1 for performance.

[MangelMaxime]

Yes I probably should have explain the reasons :)

I tried to use the Snabbdom DSL over a real case application and it's neither readable neither maintainable.
There is too much code pollution due to the separation between the events, property, etc.

So the solution would be to convert the DSL to something else and this something else is the same as React (which is the same as the Fable-arch, Elm ones etc.).

After, discussion with @et1975 we conclude having to maintain both could be hard and also leads to the same mess up as with fable-arch and elmish.

Elmish, will probably have others renderer available in the future. For example, for WebGL, ReactVR or another target than the DOM.

And yet the performance where better with Snabbdom but the ones we got with react are pretty decent. If we have some performance problem, in the application this would probably come from the user code and not react-dom.

Finally, snabbdom was still in alpha stage and shouldn't be used by a lot of people (As no one reported the bug it's having when dealing with nested application) so it's the best time to remove it.

[Zaid-Ajaj]

@et1975 Yeah you are right, the default is stateless (what it should be). I am not againt stateful tho, I think it just should be implementation detals rather than consumption details :)

[ncave]

@MangelMaxime I wanted to ask for some time, does the same reasoning preclude adding support for preact too?

[MangelMaxime]

@ncave
For the moment, I would say yes.

The reason are if we add preact support we will end up with the same DSL as for React.
So for the moment, I prefer focusing my effort on testing the template and working on the doc site (which is now my priority).

After, as preact offer the same API as react but with better performance (from my search 8-10 times better) than react we could consider supporting it :). Performance problems are rarely hit I think, but having a quicker renderer is never something bad from my point of view.
But we need to guide the user to one of the renderer and avoid the situation like: "I'm starting a project but don't understand the difference between React and "renderer X". Which one should I use".

We could say later:

• Browser = preact because it's faster, smaller and that something cool :)
• Mobile = react-native so use need to use react

To conclude, if someone want to add the support of another renderer I don't think myself and @et1975 are close to this idea :). But the new renderer need to provide something more than react IMO.

This is my opinion perhaps @et1975 got another one ?

[et1975]

Personally I didn't find the situation confusing at any point and as long everything remains sufficiently decoupled I'd always welcome additional renderers. In fact, we had some folks here at work trying to get WPF one going... it didn't go well :)
A console renderer for node apps could be fun too!

[Zaid-Ajaj]

@et1975 Actually, someone was already working on such implementation for WPF. I would just go for fable-electron instead

[et1975]

We've seen it, the point is rather to use elmish as is (which works) and target WPF which works on trivial stuff, but introducing a VDOM on top of WPF is not a promising direction when there's react-native that already works on Windows. If there was an existing differ for WPF, now that would be worth a look!