Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and maybe not representative of a good or even typical JavaScript app:
> Our JavaScript application had global variables everywhere, and debugging was a nightmare
Point #3 in their list of cons is especially important for anyone considering Elm:
> Because Elm is not a mainstream language, it is sometimes necessary to reinvent something that could otherwise have been acquired by adopting a different technology.
This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online.
This attracts a lot of developers who enjoy working on libraries and tooling, but it’s not ideal if you’re trying to run a lean team that ships products quickly.
Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done.
> Our JavaScript application had global variables everywhere, and debugging was a nightmare
Point #3 in their list of cons is especially important for anyone considering Elm:
> Because Elm is not a mainstream language, it is sometimes necessary to reinvent something that could otherwise have been acquired by adopting a different technology.
This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online.
This attracts a lot of developers who enjoy working on libraries and tooling, but it’s not ideal if you’re trying to run a lean team that ships products quickly.
Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done.