

Experience report: Rocket lander in Elm - teh
https://blog.wearewizards.io/experience-report-rocket-lander-in-elm

======
phamilton
> I.e. the help-screen at the beginning is re-rendering 30 times a second,
> even though nothing changes.

Not true. the nature of the virtual-dom is that it doesn't rerender if nothing
changes. The implementation in elm is extremely efficient. It doesn't even
diff the actual DOM, it diffs the inputs to the DOM. It can do this because of
the pure functional requirements of Elm.

~~~
teh
Interesting! When I check the DOM in inspector I can see it refreshing - maybe
that's a bug?

~~~
phamilton
[http://elm-lang.org/blog/Blazing-Fast-Html.elm](http://elm-
lang.org/blog/Blazing-Fast-Html.elm)

It's possible that only applies to HTML and not to canvas. If that's the case
then I would hope the technique will be applied to canvas soon.

~~~
jwmerrill
Canvas doesn't work that way. It's immediate mode, so unless you are doing
something purely additive, you reissue all draw calls on every frame. Compare
to SVG, which is retained mode.

~~~
skybrian
Huh? A canvas element has a buffer and it will show the same frame as last
time unless you clear and redraw it. If nothing has changed then it should be
easy to skip the redraw.

~~~
dandelany
> If nothing has changed

That's the hard part. The virtual-dom takes care of this for you, but in the
case of canvas, you'd have to determine whether or not anything actually
changed, which involves keeping around a previous state and comparing it to
the new state. It's certainly doable, but nowhere near as simple as using the
virtual-DOM.

------
mrspeaker
I wrote a mini platformer in Elm and it was great fun to make, but suffered
the same problem as this demo: quite janky (seemed to suffer a lot GC hicups,
especially in Firefox), and that's just at 30fps. At the time I thought it was
because it was doing a lot of unnecessary canvas operations under the hood -
which you just can't afford to do if you want buttery-smooth games, but
figured I'd revisit Elm when it's sorted out ;)

~~~
zapu
What do you mean by unnecessary canvas operations? I'm genuinely curious, as
I'm very interested in elm (and FRP in general), just could not find the time
yet to do anything with it.

------
bshimmin
The JavaScript output from Elm, in this case, is over 12,000 lines of code.
I'm pretty sure you could write this in <100 lines of JavaScript, the lack of
a "coherent and strong type system" notwithstanding.

~~~
phamilton
The output code is sort of a complete Elm runtime. The application itself is
only a few lines of javascript.

------
colinramsay
> First though, why is JavaScript hard? Consider the following cases

I've _never_ come across this problem in a real life project, and this is a
pointlessly contrived example that diminishes the rest of the article. This is
not hard. It might be slightly baffling at the beginning, then after ten
minutes you get used to it.

~~~
tel
I don't think the particular examples are pitfalls that people actually fall
into, but I do think they illustrate what makes Javascript hard: it's got a
lot of arbitrariness.

Arbitrariness is a constant mental penalty a programmer must pay for while
reasoning in a language. It is not insurmountable, but one must wonder what
could happen if the arbitrariness tax were reduced or lifted. It could be that
whole realms of greater, more trustworthy abstraction are obscured by mental
barriers such as this.

~~~
bshimmin
I think the seemingly arbitrary behaviour of things like `[] + []` vs. `[] +
{}` doesn't really affect you, as someone writing real JavaScript in the wild,
very often (but perhaps they still might do occasionally, depending on what
you're doing).

On the other hand, errors in logic because of truthiness/falsiness do occur
pretty regularly in real code (I'm sure every JavaScript developer has at
least once forgotten to check whether an argument is really undefined and then
not very gracefully handled `0` being passed to that function)... and these
problems do all have the same root cause: JavaScript's type system.

------
Xophmeister
In my dev team, we eschew WebSockets as it somewhat bastardises the HTTP/REST
architecture. (F)RP is clearly a great UX model, but it can't be done properly
without state being pushed to the client (faking it with polling doesn't
really cut it)... That said, as a Haskell convert, I really like the look of
Elm, but can it do backend communication via traditional XMLHTTPRequest?

 _EDIT_ I guess this[1] answers my question. Gonna have to get into this...

[1] [http://package.elm-lang.org/packages/elm-
lang/core/1.1.0/Htt...](http://package.elm-lang.org/packages/elm-
lang/core/1.1.0/Http)

~~~
deadfoxygrandpa
You might be better served by waiting a little while. The Http library is
going to get totally revamped soon by the new Promises API.

~~~
Xophmeister
Thanks for the tip off :)

------
bonn1
This thing doesn't seem to run with 60fps. Why?

HTML5 offers now few ways to get easily to rock-solid 60fps considering that
the graphics are very simple.

