An Alternative to Elm - Part 1

Part 1 of 2:

So why an alternative? Isn’t Elm supposed to be great?

Here are some things that I really like about Elm (compared to other web front-end libraries):

• A modern typed language (so, its easy to find errors during compile) (ex: Typescript being built in)
• Minimal and clean syntax.
• It’s not Javascript. (If you don’t understand this one, sorry can’t help you there.)
• It compiles to Javascript, and yet you don’t really need to know it. (For the most part.)
• It’s pretty fast, usually faster than all the other Javascript frameworks.
• TEA - “The Elm Architecture” - Where Redux came from if you know what that is. Basically a global state storage and Init-Model-View-Update tied to that state.
• Integrated ecosystem. So no need to pick Redux for example and wire it together. It comes prebuilt in. (Reduces boilerplate, greater speed to deploy, etc…)
• With 0.19, it basically comes with their own version of tree-shaking built-in.
• It has a REPL, though it is project based.
• It has its own syntax for HTML templating and its great. It’s clean simple to understand and works well with the rest of the language. So other code around it just flows together nicely, since it basically looks the same. Versus something like JSX in React where you need to put HTML inside a Javascript string. Looks horrible and causes context switching. Vue does it slightly nicer with variables and it’s separate enough, but it’s still messy and no-cohesive. Though it will take some time getting used to, since it doesn’t really look much like HTML anymore.
• Partial application - pretty cool once you get your head around it.
• No callback hell
• Don’t need to deal with Promises, a much cleaner solution that’s part of TEA.
• Comes with live reloading server (though other solutions are probably better).
• Comes with a pretty cool debugger, with time-traveling.
• Awesome error messages. Probably the best I’ve seen.
• Functional.
• If it compiles, then there are no runtime errors. (Almost always, like 99% of the time.) I’m not talking about logic errors, which of course still happens.

Here are some downsides, which may make you consider some alternatives:

• The language is still pre 1.0, so every release usually has breaking changes. Some of which can be significant.
• The language is developed by one person, the creator, and pretty much he has all say in the language and not that open to ideas outside of his own. Some features of the language are intentionally disabled for users, but the language itself uses them to write parts of the language.
• It’s just a front-end language, no server-side part to it for now.
• The importing part can get verbose, but not necessarily much better from Javascript.
• There are not many libraries for it yet.
• The interface to Javascript is very verbose and tiresome. Since the language is strict on being typed, you need to define all your types coming in from Javascript, one at a time.
• If you are not familiar with a similar language, the time to understand functional concepts and the syntax can take a little while to learn.
• While the docs look nice, it can still be improved. Many times, I’m still left wondering how functions can be used. It has an over reliance on type signatures. It’s getting better with time though.
• This could be a pro or con. It has a code formatter, but not adjustable at all. So, while I like the idea, I don’t necessarily agree with all of the decisions, so I can’t use it.
• This is somewhat related to the previous point, but basically, the language encourages readability, but sometimes makes the files really long, very easily.
• Since its strictly typed, you need to consider every single situation, meaning handle all the error cases, even if it is just to put a mock value, like an empty string or zero. This is good in the long run, but initially, you may feel that you are fighting to get a working program, if you aren’t used to it.
• Lots of boilerplate since it doesn’t really have the higher level features from other functional languages. This keeps things simple to understand, but can make things also get really big.
• Native features which aren’t supported yet, which require hacky workarounds, or using the Javascript interop.
• No transparency on what’s going on with future versions.

There are more to add to each list, but I just thought I wanted to point some of them out.

This isn’t to say that Elm doesn’t have a future, there a lot of good things going for it, and many of the bad points can be fixed. Just that I’m looking for something that I can use right now and is more practical.

Since this is getting long, stay tuned for Part 2 where I reveal which alternative I picked and why: Part 2