Hacker News Reader

Comment by Tarks | Hacker News Reader

The escape hatches were one of the first things I used to explain why I initially liked react, called them exactly that too.

"They're smart enough to know they're not smart enough to build perfect abstractions, so they do a great job but leave escape hatches just in case"

View on HN

This is why I felt out with Elm. It is harder to escape the hatches with it.

you dont escape hatches; you escape THROUGH the hatches

So not \h\a\t\c\h\e\s ?

You can use the ports system and interoperate with js in Elm. I used it in the past and it is quite a clean abstraction.

It's frustrating that it forces you to jump into handling async code, though, in all cases. This wasn't always the case, and for good reason: sometimes async code is just vastly more complicated for no actual benefit if you can tolerate the FFI causing a crash at any calling point.

The interest in Elm took a major hit after the compiler banned use of JS.

That is what I mean! You need static top-level declarations of every out-of-elm iteration you want to do.

React on the other hand can wrap a JQuery calendar in a React component and from a programming point of view, using that component you would be none the wiser.

Also ports force everything to be async - and I am not talking just promises - I mean a new render per call response! So calculating 1+1 on a port requires generate a new render, and intercepting the result in a Redux-style handler, bubbling that into a component.

While you won't need to do 1+1 via ports, you might need to use a synchronous web-api feature that has not been ported to elm, or even use a math package to multiply some matrices.

Reply on news.ycombinator.com