“Yo, check out this new shiny piece of technology!”
“Because it is functional, distributed, cloud enabled, big data, IoT, bla, bla, bla platform”
“But what problem does it solve?”
When I see product descriptions, I often have no idea, what problems do those products solve. Take docker for example: “An open platform for distributed applications for developers and sysadmins”. Now I know why people like docker, but it is only because I used it.
Debugging runtime exceptions
One of standard elm libraries is called Html, which is used to generate (surprise, surprise!) HTML. Every element is a function, that takes two arguments: a list of attributes and a list of child elements. Check it out!. This is seriously huge! No more templating languages with their limitations. I have the full power of a real language. I can easily print recursive structures and group elements or entire widgets as functions, that can be parameterized. All things that are hard to do in templating languages, become easy. The notation is also very succinct and readable.
SASS, LESS and other CSS preprocessors give me variables, arithmetic operations and other things, that make CSS more manageable. In Elm I can do the same things out of the box, because style is simply one of attributes. If my templating language gives me the full power of a regular programming language, then I can use it for CSS too! I am not sure, if it is good idea… But it is possible!
Semantic package versioning
Have you ever upgraded a library (only minor release) to see, that it actually changed API? Elm static typing can detect, if the library API changed and enforce incrementing the major version number. Sweet!
Elm has only one way of updating DOM. It is a function that takes application model and returns Html. No messing with the state – everything is generated from scratch on every model update. OK, not exactly. It works like in ReactJS. It generates a virtual dom, diffs it with the previous virtual dom and applies a minimal set of changes to the actual DOM. It is fast and it is conceptually simple.
Elm doesn’t allow circular dependencies between the modules. Hurray! There is also tutorial about creating reusable code and composition in elm.
Testing is much easier, when I don’t have to deal with the state. No more mocks! Only functions with arguments and return values.
Learning elm requires learning couple of unfamiliar concepts too. Functions in elm do not have side effects, so how can I change something on the screen? I can define values changing over time. They are called Signals. The user inputs are signals. Combining user input with the current model produces a new model, so there is a signal of models. Models are translated into views to produce a signal of HTML. In elm every application is just a signal of HTML. It may sound very formal, but it really makes sense.
Signal of user inputs -> user input + previous model = new model -> Signal of models -> model renders to Html -> Signal of Html.
Higher order functions on signals
I use functional programming in my day job, so I am used to transforming lists with higher order functions. The same concept is applied to Signals. It took me some time to grasp, that stream of events can be processed with the same set of functions as normal lists. Beautiful idea!
Addresses and mailboxes
Signals have their mailboxes with addresses. If an element will be used to generate user input, it needs to have an address. It looks a little bit like in Erlang, so I like it very much, but it may seem foreign for newcomer.
Interacting with JS libraries
After only couple of days of learning, I felt much more productive writing webapps. So? What are you waiting for?Follow @snajper47