The rise of front end functional programming- hacking with ELM

11 November 2015

Last night I went to the Elm hack night with the creator Evan Czaplicki. 

Evan's hack night was well organised by putting emphasis on people trying Elm for themselves and making something work. London also happens to be the city which uses Elm the most outside San Fran, where Evan is working on it with Prezi. This allowed Evan to spread the word about Elm and get people hooked on functional reactive code where old components can be reconfigured and new ones added without messing up. Evan's foresight is rather deep - he predicts that if JavaScript is difficult to maintain now (or as he says 'publishing a new feature is itself a feature'), it will be even worse in the future. A solution, though strict in its type immutability, allows people to write code, which not only renders to quicker JavaScript (which we can change to assembly later... tbc) and doesn't break when you add new features.

This strategy is pragmatic - front-enders who want an efficient solution to their real-life problems and are enjoying the advantages of ReactJS are now looking for something even better and coming across the beautiful world of functional programming. 

There were many people in the room and everyone learnt something useful. Functional programmers proved to themselves that you can solve different kinds of problems using FP. Front end engineers saw how you can write easy-to-maintain JS, by avoiding JS, but retaining the capabilities. You could choose between two playground projects: tree creator and Spotify album cover presenter. Evan structured the projects to make people think about modules and functional approach for solving real problems. Evan made sure people with less FP experience didn't get too scared by foreign concepts and focused on the usefulness of the language and how easy it is to get something up and running. One of the advertised advantages of Elm is its ease of maintenance and ability to add new features without breaking three (looking at you, 10000+ LoC JS projects) and unfortunately the nature of a hack night, doesn't allow people to see that advantage in action. As a beginner coming from python and basic understanding of algos and data structures, I am yet to see the light and fully embrace the Elm way. However, the higher level overview and the well-advertised advantages of Elm are definitely appealing.

Talking to several people, some from reactive, others from FP backgrounds, an overarching consensus was forming about the beauty of writing type immutable code that compiles to JavaScript. One of the things people showed interest in is the stability of language. One of the chaps there said he had to relearn elm, because he hadn’t used it for a year. I suppose a new language going through its adolescence is always going to change rapidly, but it’s also a good thing that people share their experience. The ability to compile to more than just JavaScript is another popular suggestion with web and mobile apps potentially and I am sure there will be many more.

As a headhunter I enjoy observing new trends and seeing what takes hold and how. FP is definitely on the rise, as seen by the increasing number of clients who look for proficient Erlang and Haskell programmers. Reactive front-end and web apps is a necessity now for every product. I hope Evan and us, as the community, open more front end engineers to functional concepts and people make that leap of faith and adopt a strict paradigm, which might help them in the long run.


What do you think about the spread of functional reactive programming in general and Elm in particular? If you already code in Elm - how easy is it to maintain?


Get in touch with your thoughts,

Petr Tikilyaynen

View all blog posts