'Porting' a react application to elm - starting with a conclusion

As I threatened over here, my main aim in writing the morse learning app “remorse” was to have a baseline to which I can compare ports to other languages. Now that I have done the port towards elm*), I would like to start with a conclusion and only in later posts do some direct comparisons between solutions.

When you have developed an application based on react and redux, you know a little bit of what’s coming to you in terms of how the UI is the source of messages, which changes the application state as well as triggers activities.

You will find those architectural components again in elm albeit assembled into a more stringent form.

• The UI raises a message
• This message must be handled in an update function.
• Handling the message, you return a tuple that contains
  • The desired mutation of the application state, if any
  • A desired Command to be executed which may produce a new message, if any
• After which the UI is rendered with the new state

If you happen to have written all your UI as functions in react (which actually happened in remorse without me really aiming for it), you are already in a good mindset to get into elm, since views in elm are pure in that they cannot depend on any sort of internal state but only depend on their input.

Elm’s rampup is quite excellent and you will be up and running in a short amount of time. I have been developing in vs code with the elm plugin by Sascha Brink, which provides some basic support to display compiler errors in place and helps you a little bit in auto-completion, etc. Granted, considering the static typing nature of elm, more could be done in this area.

Elm loves refactoring

What I did wrong in a previous experiment but got right this time is to not overthink your solution. That is, start messing around in Main.elm and when you feel like you have to refactor, do it then. If you have a working application, refactoring in elm is quite straightfoward and when your pieces compile again, the chances of it also working again are pretty high.

Right now, I don’t like the Haskell-inspired code formatting

This is the standard formatting

ul [class "grocery-list"]
  [ li [] [text "Pamplemousse"]
  , li [] [text "Ananas"]
  , li [] [text "Jus d'orange"]
  ]

Right now I’m doing this.

ul [class "grocery-list"]
[ 
  li [] [text "Pamplemousse"],
  li [] [text "Ananas"],
  li [] [text "Jus d'orange"]
]

If I wasn’t working alone, I would have to adapt, and at the end of the day, formatting is only so important, but I sure don’t like it.

Json Encode/Decode I don’t even

When I first encountered how json must be handled in Elm I was fairly disappointed. If I have defined some type, it would be great to be able to use exactly that information that I have already distilled into said type to be able to get an instance from json or the other way round. However, you will have to define encoders and decoders to perform the feat of moving to / from json.

This post, however, reminded me, that this step will lead you to develop your serialization models independently from your application types (if it’s not clear what I’m saying, have a read through the post). My first attempt to let the user store the current state was to store the complete model, because in javascript it is a no-brainer to store a javascript object like that. This was an uphill battle. The next approach, checking what exactly I need to store and then map the values into the structure to store the data to json, felt much better and more productive.

Elm is opinionated

Elm gives you very clear guidance on how your application works. It is clear on how you do view changes, how you perform actions and how outside data enters your application. It has an opinion on how to do json and beyond the code, it has clear opinions on how to advance the language and its ecosystem. If you approve of those opinions you should be in for a smooth ride.

— *) Without the trainings evaluation and charts for now