As I wrote the application on Elm

If you are not at all familiar with Elm, then, in brief, this is a functional programming language and platform for writing web applications. Code written in Elm is compiled into JavaScript and embedded on the page. In more detail about the basics you can read for example here on Habré or simply on the official site . I wanted to summarize my experience, which I got by writing my first application, so the article will contain a large number of obvious things, a bit unobvious and many references.

I decided to make my application after writing a few simple programs and passing the Elm Tutorial tutorial . While reading the examples from the tutorial and writing the examples, it was quite difficult to understand all the concepts at once, so I tried not to dwell on the places that were difficult at that time (routing, composition) and tried to get a ready-made working site.

After that, I began to write my application, which consists of a form where you can specify the name of the event, optionally a URL, and the date when the event will occur. After saving, all these data are shown in the form of a small card with a countdown to the event. The code and link to github pages can be found here .

Language, documentation and sources of information

The obvious thing, even though Elm is intended for the frontend, is a completely different language compared to JavaScript. Therefore, it is necessary to learn the syntax, to understand the concepts. On the official site there is a small dock for syntax , there is a table of comparison with JavaScript. It is useful to read the official manual at the very beginning and try to run examples from there. There is a weekly newsletter where you can find many interesting articles, videos, examples.

Since before that I had practically no experience in using pure functional programming languages ​​- it was interesting and useful for me to read materials that explain general concepts. From such materials I can advise a series of 6 articles from You , where you can find out the basic concepts and the book Mostly Adequate Guide (there is a partial translation into Russian).

During the solution of my task, the tutorial I helped a lot, the example of which was at hand. It is very useful, because there are covered a lot of aspects of creating a website: from the basics of the language to the assembly, architecture, routing, interaction with API. For example, from there I initially transferred the router to my task with almost no changes. Then, solving the problems arising along the way, I figured out how the parsing is done, how the gamers work, and so on. Plus, this tutorial constantly updates all the examples to the latest versions of the language (currently it is 0.18).

With tutorials and code examples on the Internet is often associated with one interesting feature. The code imports libraries that use the so-called open import . That is, the use of the s function is encountered, rather than UrlParser.s . This somewhat complicates the reading of someone else's code. Always see how, what and under what name is imported in the module. In turn, I myself try to use qualified import and this is the official recommendation . More letters, but it is always immediately clear what type or function is used.

I advise you to be sure to connect to your editor Elm Format , which formats the code according to the official guidelines. Elm Format seems to be used by everyone and the syntax common to all is really convenient.

Application architecture

It is important to study the architecture that is considered the standard for writing an application: TEA (The Elm Architecture). Details can be found in the official manual . If you are familiar with Redux, it is not difficult, and if not, then in any case, the study of this concept does not seem to me to be something difficult. There are three main parts: the model (stores the state of the application), the update (change handler that modifies the model) and the view (the appearance of our application, rendered in accordance with the state of the model).

Accordingly, our minimal application is initialized with these three parts. In more complex cases, subscriptions can be added to them, the update function when the URL is changed, javascript flags, and perhaps something else. But the base is always the same.

Compiler and debugging

The compiler really works fine, errors are shown as informative as possible and you can always be sure that the output will be a working program. This, however, does not insure against the need to closely monitor the code and watch what and how it works. I want to say that at first the compiler is a delight and it seems that this is some kind of magic. But when you start writing real code, it is easy to return from the function an incorrect value of the correct type that the compiler will miss.

The code can be debugged using the Debug module. Although even such an action familiar to JavaScript is not easy. Debug.log is a function that takes a string (just the text before output) and a value and returns that value, while producing a side effect of outputting to the console. Debug.log can not be used anywhere in the program and in any part of the function. That is, it can be put only in the place where there is already some value.

In Elm 0.18, a debugger appeared that allows you to track the status of an application, go back in time, and even export a state with a history to open in another browser. I wrote my application on version 0.17 and have not taken advantage of the debugger myself.

Modules, scaling and refactoring

The biggest and unresolved difficulty for me was the division of the code into modules. Most of the example code is in one file. The official tutorial in the Scaling The Elm Architecture section talks only about the division into functions, the basic concept of modules. There is a section in the tutorial, there are other examples on the Internet, but I didn’t manage to apply all this from the first visit to my project, as there were difficulties in inserting into the modular structure of the third-party component elm-datepicker that I use. At the moment I have done the separation, which so far suits me: the main code with updates and functions in the main file, all types and layout of pages are rendered separately. But in the process of global refactoring of my application, I discovered an unexpected thing, which I had read a lot about, but was not aware of. Refactoring is absolutely not scary, but even interesting. The whole system with types, immutable data, pure functions and the compiler controlling it does not allow to break the code . One may change the names of everything, change the structure, create and delete files and be sure that after successful compilation, the output will be a working application.

findings

I was interested to try something very different from the standard JavaScript programming scheme. It was not easy at times, because functional programming breaks the brain for me, as a person who mostly wrote only in JavaScript - the threshold for entry is very high. Simple things that are done in Elm is not easy at all - like getting a date, http request, at first cause bewilderment and pain. With the gradual mastery of concepts and tools, it becomes both easier and more interesting.

Whatever the future of Elm, I think that investing my time in studying it is justified. It seems that the ideas of functional programming are easier to grasp using a pure functional language, not being able to quickly write something wrong in case of problems. And then, even if you continue to work only with JavaScript - you can transfer and use new ideas, and understand the benefits of using the JS functional approach in general and, for example, such libraries as FlowType , immutable.js , Ramda .