So what is Elm and how or why is it better than Typescript?

Let start with one thing: Elm is a functional language, and if you have never touched one before, this is going to be a big step going in.

Elm is a language that compiles to Javascript, just like Typescript, but it’s a whole new language that does not try and make compromises.

Elm guarantees that you will NEVER get a runtime error.

It is a language that once data is in its system, nothing can ever be in a state of null or undefined. Things will always have a value, and the system will never crash because things have their proper type as well.

Elm comes with Data Immutability right out of the box, Bundles and Minify code for you, and most importantly, it Enforces type safety , preventing developers to try and cut corners. It is very fast and very lightweight.

If you are concerned, the output can be embedded in any web page easily, so it’s not that hard to get started with a small trial if your project is immense (You don’t need to convert all your code to elm to embed it).

It has an advanced typing system that allows you do to even more, which I will cover entirely in another blog post.

Because elm is a functional language, you cannot get into a weird state caused by side-effects and your code is very easily testable. Functions you write will always return exactly the same result given the same input data.

Because you can so heavily depend on the Elm compiler, updating and refactoring pieces of code is an absolute breeze. The compiler will complain for quite a bit of time, but the moment it stops from doing so, you are good to go. No need to test anything, simply follow the compiler guidance about each error he finds and your code will all start working again once you have done so. This experience really gives you a good confidence level in your software even after destroying it apart and rebuilding it. (Which normally, you would be unsure if you have missed something somewhere)

The Elm Architecture (TEA)

Elm has what it calls its own architecture that some project is based on (Redux). It’s very pleasant to work in TEA, things are straight forward and a lot easier to manage. It does an extremely good job at separating the logic from the rest, which comes in nice when testing your code.

Because the language is built that way, all developers are forced to follow that pattern and to be strict about anything they create. There is no such thing as any in elm, and thus, every contributor is forced to properly write code. The result is quite simple: Better code, better maintainability, no runtime errors.

Elm will force you to handle all the cases all the time, which in a way, has a strain on you as a developer, but a good one. If you do an API call as an example, then you must handle the cases of Failure , Success and Loading , but the end result is that all those handled case will give not only a better understanding of what is going on to the user but also no errors in case something bad happened (which you might not normally write code to cover that case in Typescript).

The hard part going into Elm

Coming from a background of C++, C#, Java, Typescript, Python, I am more than used to write loops (While/For) and when you get to a functional style language, there is no such thing. You must use functions such as Map , Fold , Filter and more, and that is how you manipulate your data when you want to loop. I found it hard initially to get used to that.

The result is amazing when you start to understand how it all works. You become a lot more efficient going back in an older project and applying those principles.

Elm is a completely different language, it took some time to learn it and you will have to work hard as well to understand the new keywords and patterns of that language. A good place to start is at ElmProgramming.

Writing Encoders and Decoders initially are a complex task and feel long to do, but it's because of those that elm is capable of ensuring your data is always safe and validated before going into the elm machine. The compiler is capable of ensuring input and output data are always safe because of those. You must take the proper time to learn how to create them and use them.

Elm does not allow you to save anything by yourself. You do not create variables. You simply pass back your whole new model and elm takes care of saving that model for you in memory (Because that is an unpure method to do). This was for me, hard initially to grasp because I was used to keeping data in a class as a class parameters (a private variable as an example). This makes it so that you only have one state that is saved, and that state is your main model, which you can manipulate and change the way you want it. It’s just, hard to change your way of dealing with code.