- the ones you do get from your JS code – will be shown as console errors not involving Elm runtime in their stack trace
- guaranteed support for time-traveling debugger and model serializability. How would one do this in OCaml if it allows mutable data (possibly cycle dependencies), side-effects and JS FFI?
- better dead code elimination. All the code in Elm is pure
Basically, OCaml brings almost nothing to the table out of things Elm provides because it tries to suit everybody.
> guaranteed support for time-traveling debugger and model serializability. How would one do this in OCaml if it allows mutable data (possibly cycle dependencies) and JS FFI?
The ReasonML debugger supports time-travelling as one of its features.
The Bucklescript compiler that backs ReasonML provides dead-code elimination.
> The ReasonML debugger supports time-travelling as one of its features.
Yes, but the question is: does it guarantee to be working or is it only "sort of" working? Can your view do side-effects? Can it call JS? If yes -- it will break soon.
> The Bucklescript compiler that backs ReasonML provides dead-code elimination.
I didn't say it doesn't. I said it will be way more poor than the one Elm has. I don't have the link, but Todo app in Elm weights less than the one made in React, that's how good it is.
Well, it's one thing to not be mature yet (UI could definitely be improved, it's very minimalistic currently, but works ok for me), and another to not work in principle :)
- the ones you do get from your JS code – will be shown as console errors not involving Elm runtime in their stack trace
- guaranteed support for time-traveling debugger and model serializability. How would one do this in OCaml if it allows mutable data (possibly cycle dependencies), side-effects and JS FFI?
- better dead code elimination. All the code in Elm is pure
Basically, OCaml brings almost nothing to the table out of things Elm provides because it tries to suit everybody.