Very interesting post about how the Elm community works and how it is organized, thanks a lot.
I don't have much experience with Elm itself but I do know Fable-Elmish, so before switching please consider the following differences (and also consider that my experience is based on Fable 1.x, but Fable 2 is already in beta, although I don't know if Fable-Elmish changed).
Elm subscriptions are based on the current model and are described as data, which means they are equatable and Elm knows when a subscription changed. In Fable-Elmish it is logic, i.e. a subscription has the signature (msg -> unit) -> unit, i.e. a function that gets a dispatcher and returns nothing. So Fable-Elmish can't know when a subscription changed and I assume that's the reason the subscription is only generated once, i.e. on init. So in Fable-Elmish you can't setup subscription based on your changing model, because you'll only ever get the initial model when setting up subscriptions.
(msg -> unit) -> unit
Fable-Elmish is based on React. I'm not familiar with React and I find it a bit hard to write the glue code to be able to use existing React components from Fable-Elmish, but your mileage may vary.
Interacting with JS libraries is very easy and almost a joy with Fable-Elmish, but sometimes I get a bit lazy and I do a lot of dynamic typing. I don't think you can get that lazy in Elm, which I consider being an advantage of Elm.
We’re a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.