Hello All,
I’ve gone through(at high level) the Elm guide provided in the official Elm web page. I’ve tried implementing 4 or 5 examples mentioned in that guide.
I think that I’ve got decent understanding on why should I learn Elm and apply this knowledge in real projects.
Well, I’ll want to put my understanding below for your review.
It’s my humble request to confirm or correct my understanding.
Elm is a functional language for developing front end applications. First of it’s kind in Front End application development(not sure though).
Initial learning curve will be high for those who come from Object Oriented or imperative thought process. However, with diligent practice one can come out of this hangover and appreciate the declarative way of implementing.
That’s said, refactoring the code is easy in Elm. Hence, developer can focus on implementing the solution for the given problem statement and need not worry upfront about unknown future enhancements.
It’s architecture style (Model, View and Update) is intuitive and simple. This along with the declarative thought process helps the developers to create small building blocks and use them to construct very complex applications in a simpler way.
Elm outperforms other FE supporting languages like Angular or React(I’ll want to know technical details, HOW part).
Elm compiles to JavaScript. Elm takes care of preventing the exceptions generated in JavaScript(during interop) to enter Elm.
Being a static type checking language and not allowing ‘null’ or ‘undefined’ it wont generate any run time exceptions.
It has it’s own package manager with Semantic versioning support. This would help the developers to maintain the code with ease even though the application/code base has become a mammoth.
That’s said, my understanding leads me to the following points.
Implementing solutions using Elm gives the developers to start with simple building blocks and eventually construct complex functionality. Supports Agile way.
Functional way of implementing gives edge on improving the code coverage. It’s doable with very good set of test cases.
As refactoring is easy, enhancing the application with new features will also be easy.
Better performance hence better user experience.
However, I’ve the following concerns.
Elm is still in Beta. What’s the future scope? Without knowing this, it will be difficult to influence myself and my organization to pick Elm.
As being the new player, building it’s echo system is in progress.
Do Elm has support to implement the applications in TDD way?. For eg, node has Mocha, Angular has Jasime.
In my organization, we use Angular 4(+). Even though I learn Elm and influence the team that Elm is a good choice, if I don’t find a good migration path so that applications implemented in Angular can be gradually migrated to Elm, my efforts would go in vain.
If you read this line, I’m sure that you are here to help the people who are interested in learning Elm. I appreciate you and your time.
I do not think this is necessarily true. Switching to a declarative way of expressing things might require some rewiring for certain patterns but I do not thing that the learning curve is all that high. Elm is deliberately staying small as a language. One can pick the main ideas of Elm in an afternoon. After that… it is a matter of learning the API of various libraries. The effort to learn the libraries will dwarf the effort to learn the language and this is true for most languages out there.
I would say that Elm is competitive in this domain. It has a very fast and tailor made virtual dom implementation and because it is functional it can provide various optimizations regarding the compiled code. You can read more here. With 0.19 some more optimizations will arrive which will reduce the size of the deliverable even further making Elm apps even better, especially for the mobile platform.
Elm is still in development. This means that the language is still changing from one version to the other. The rate of change however has reduced significantly. The main key point around this topic is that businesses already decided that Elm is stable enough to be used in production. There are enough businesses out there with large webapps implemented in Elm in production and the feedback is generally positive.
For the foreseeable future, it will remain a front-end oriented language working on being the best in this domain.
This is true however, the ecosystem provides a wide range of functionality. In other words, for most of the needed functionality there are already libraries.
Elm has elm-test so you can do TDD in Elm right now. The next version of the language will provide even more support for testing.
There are 4 levels of Elm integration:
Using Elm to render some data. In this level you have no interaction with the rendered data but you might have some processing of the data before it is rendered.
Using Elm to display a widget that allows user interaction but has no side-effects. Think about something like an images carousel. It can be configured internally with some data and allow for navigation within this configured data.
Using Elm to display a widget that interacts with the outside world. Think of something like a weather widget or a stocks ticker or some kind of complex form that does validation with various services. The level of complexity is higher. You might want to interact from the rest of the app with the widget, you might want to receive events from the widget.
Using Elm for a SPA. This is the highest level where the app is implemented in Elm and the rest of the widgets implemented in other languages are brought in through technologies like webcomponents.
For a successful integration of Elm into a project, it is advisable to start at the lowest level that makes sense and move up from there. Jumping directly to level 4 might work for a new project but for an established project it is much better to start with level 1 or 2.
Level 3 is probably the sweet spot where one would benefit from all the niceties of Elm without having to fully commit.
From my experience with elm I would advise against it if you’re building a stereotype business application. Tools like Angular seem better for the job. Working with a lot of forms in elm is a bit tedious in my opinion.
First of all, I think it is more fair to say that Elm is roughly on par with other popular frameworks. It has beat Angular and React in some benchmarks, but not necessarily by a wide enough margin that performance is its core selling point. I think the point is more that you will not sacrifice performance if you choose Elm.
Second, Elm has a slightly different performance stance than most other tools. As the compiler is quite smart, it will produce fast code by default (for example it has much more freedom to re-order things, since it knows about all possible effects). On the other hand, it doesn’t have a low-level imperative fallback - you simply can’t write that nasty mutating for loop to squeeze out an extra bit of performance*. So, at least in my experience, your code will often be more performant without you trying very hard than other tools, but if you do need to try very hard in another tool, you might need to rewrite that part of your app in JavaScript.
Third, this is simply my own experience. Others will have different experiences, since many performance issues are specific to their domains.
* That is without porting out to JavaScript, but that has it’s own performance tradeoffs as well as typically some code re-juggling.
Given I’m on my first Elm project, and coming from a true OO background (Eiffel) as well as lots of imperative languages (PHP, Pascal), I don’t think the learning curve is high if you follow the course.
It’s very easy to google for specific “how do I in elm” questions.
I also started to contribute to a library (elm-mdc) and picked up a lot of coding from that.
I still don’t have a full grasp of Elm (don’t 100% grock the currying stuff), can’t read everything, can’t write any code without limitations like I can in other languages, but hasn’t stopped me or limited me so far.
I also wouldn’t say Elm is in beta. And I don’t really care about the future. In my experience apps/websites get rewritten every so many years, so pretty irrelevant if a technology disappears. Even if you pick a technology moving from version 1 to version 2 is often painful. So why not pick up some new skills?
I really love writing “javascript” in a type safe way. So much easier then checking every piece of code and watching the console all the time for errors. If it compiles, it tends to run. Exactly what I’m used to with Eiffel.