Tag: elm

1kb JavaScript library for building frontend applications

HyperApp is a JavaScript library for building frontend applications.

  • Declarative: HyperApp’s design is based on the Elm Architecture. Create scalable browser-based applications using a functional paradigm. The twist is you don’t have to learn a new language.
  • Custom tags: Build complex user interfaces from custom tags. Custom tags are stateless, framework agnostic and easy to debug.
  • Batteries-included: Out of the box, HyperApp has Elm-like state management and a virtual DOM engine; it still weighs 1kb and has no dependencies.

https://github.com/hyperapp/hyperapp

Elm in the real world

“Elm is a beginner friendly functional reactive programming language for building web frontend. Choosing Elm for a customer project made my job nicer than ever and helped maintain project velocity during months of development. This boils down to two things, in my opinion:

  1. Elm restricts the way you program, resulting in maintainable code no matter what.
  2. There are no runtime exceptions so debugging is way less of an issue.

At the Reactive 2015 conference, where I gave a lightning talk on stateless web UI rendering, many people asked me: “How hard is it to debug compiled Elm code on the browser?” I was more than a little confused by these questions, until I remembered what it’s like to write JavaScript. You make a change, switch to browser, set up debugging stops, click on a few things in the app, check the debugger and go “Uhhh… How did that happen? Maybe I should console.log something?”

Writing Elm, on the other hand, is like this: you make a change, check the superbcompiler errors, fix them. Next. Of course, you should then switch to the browser and check that it actually does what you wanted, but the point is: you don’t spend half the time coding digging through the debugger…”

http://futurice.com/blog/elm-in-the-real-world

Understanding Elm

“Elm is an unusual programming language as first one needs to learn to think in a different paradigm (FRP). To me, one of the challenges in such a process was to gain sufficient understanding of how tasks and ports are related to each other.

Part of developing an idea in Elm involves understanding the dataflow of your program. In normal imperative programming (say in Python or Java) one essentially constructs a series of operations to perform (thus “imperative”). Whereas in Elm, you define the dataflow. There is no sequence of logical steps to define, hence the paradigm is fundamentally different.

The architectural abstractions entailed in constructing such a dataflow are: models, actions and view. The model describes the current state of your entire program at any point in time; outside of the model, there is no state and everything is ephemeral. Actions happen to the model. Acting upon a model updates it, resulting in a newer model; this is how your program handles state. Finally, the view defines how to render any model on the screen. For more information, see the Elm architecture tutorial…”

http://www.srid.ca/posts/2015-05-24-understanding-elm.html