> Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds).
Refactoring Elm code isn't as painful for me as Javascript or Ruby - because it's statically compiled, it gets rid of a whole class of errors. The compiler does an excellent job at where compilation fails and suggestions to fix the error.
Additionally, I find in Elm (and other ML-typed languages) that it's easy to model states of your app (e.g. like a state machine) and events that change the state of your app. Adding/modifying states and events in Elm is one of its strong suits and it really forces you to logically think through how your app transitions from one state to another. Scott Wlaschin has an excellent talk on Domain Driven Design in F# that articulates this point quite well.
Refactoring Elm code isn't as painful for me as Javascript or Ruby - because it's statically compiled, it gets rid of a whole class of errors. The compiler does an excellent job at where compilation fails and suggestions to fix the error.
Additionally, I find in Elm (and other ML-typed languages) that it's easy to model states of your app (e.g. like a state machine) and events that change the state of your app. Adding/modifying states and events in Elm is one of its strong suits and it really forces you to logically think through how your app transitions from one state to another. Scott Wlaschin has an excellent talk on Domain Driven Design in F# that articulates this point quite well.