Designing Elm-lang Apps : Is it similar to the Windows Main Event loop?

27 May 2015

Designing Elm-lang Apps : Is it similar to the Windows Main Event loop?

Let me preface this with this, is not a particularly well formed thought, as I’ve not been programming with Elm-lang that long, less than week at this point.

Elm is a newer programming language , that attempts to bring Functional goodness to the quagmire of javascript. Essentially, write your application logic and some of your view in Elm, then compile to javascript. In Elm you might not even have a css stylesheet, etc… . Aside from some of the initial shocks of serving a blank page with a script tag. Think about the great power you gain in being able to be explicit about the styles you are applying to your HTML elements or views, having types in javascript, and following functional programming paradigms to have clean lines. Think no templating language, and potentially no awkward sharing of widgets/ html components. In addition to this , there’s alot going on under the hood that takes advantage of shoe horning the user into a functional paradigm, some of which allows for faster page rendering etc… . Blasing Fast Html

One thing that struck me as interesting is this newish architecture [guide] (“http:// Within the guide, the elm framework setup , basically has you funnel all your events(muxed signals) into a single handler, that then can take the appropriate action. This started to feel familiar when I realized that really, this was the same way that I used to write games in Windows 95 as a kid. You’d have your main event loop, that would be able to react to various signals . Most of the logic for how things were routed were right there. Windows Event Loop

I suppose in javascript today, we have a tendency to have events being handled or routed all over the place, where as javascript under the hood probably, much like many systems, such as the OS has some event queue that it processes in some order , where essentially all the critical events flow throw the queue and are funneled off to their appropriate handlers. Only abstracted by getting assigned a slice of the CPU, and the process or thread taking over the main context.

I haven’t really played around deeply enough with the paradigm, but I think that maybe Elm-lang is right having your events being handle in a somewhat central location , leads to a more stable and able to reasoned about app.

comments powered by Disqus