Experience report: Rocket lander in Elm | Hacker News Reader

Experience report: Rocket lander in Elm

blog.wearewizards.io

67 pointsteh21 comments

> 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.

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

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.

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.

Is there a benefit to use ELM, aside from its functional properties, when using the canvas then? Does using SVG with ELM offer benefits over canvas with ELM?

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.

> 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.

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 ;)

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.

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.

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

> 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.

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.

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.

Try to edit JavaScript code in offshored projects with 30+ developers.

Is there any language that makes that straightforward? I trust that this scenario is common, but it seems almost comically designed for failure. Why not have someone in the same timezone as the stakeholders break the project up into smaller, more easily offshored modules?

Any language with static typing helps a lot, specially since unit tests tend to be non-existent.

You can seldom do any validation given the ratio developer/on-site devs.

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...

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.

Thanks for the tip off :)

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.

Reply on news.ycombinator.com