When comparing Aurelia vs Elm, the Slant community recommends Elm for most people. In the question“What are the best React.js alternatives?” Elm is ranked 1st while Aurelia is ranked 6th. The most important reason people chose Elm is:
Lack of run-time exceptions makes it easy to produce large swathes of reliable front-end code without drowning in tests.
Specs
Ranked in these QuestionsQuestion Ranking
Pros
Pro Out of the box Typescript support
Full support for Typescript built in
Pro Good binding system
Clear, intuitive and HTML/SVG compliant binding syntax.
Examples:
Default binding => value.bind
One Way binding => value.one-way
Two Way binding => value.two-way
One Time binding => value.one-time
Pro Conventions over configurations
Configured to give you the most common use cases by convention, which means you only need to change the default configuration for edge cases. This means that for normal cases far less boiler plate code has to be written.
Pro Out of the box ES6 support
Aurelia includes native support for ES6 and even comes with a Gulpfile which helps with transpiling ES6 code to ES5.
Pro Allows developers to build their application however they want
Aurelia is extremely unopinionated and was designed to be highly modular. This gives the developer the freedom to develop their application however they want, without forcing them in paradigms or rules predefined by the framework. Likewise, any of the individual components can be swapped out if so desired.
Pro Standards compliant
Aurelia developers always try to keep within existing and emerging Web Standards, making it easier for developers to follow best practices in web development.
Pro Agnostic code
Most of the code you write is Aurelia-agnostic. It's one of the closest libraries that you'll find to basically write plain-old, vanilla Javascript or TypeScript code (classes) and doesn't polluate your HTML/SCSS. That way you can easily test it, switch to another implementation and make it look clean (business oriented). Even the HTML.
Pro Easy to learn
Learning aurelia basically means learning EcmaScript and HTML, since aurelia is designed for standards compliance. Also, aurelia embraces upcoming ES language features by convention, such as ES class decorators for dependency injection, encouraging clean architecture and future-proof code.
Pro Variable binding helps with self-documenting the code
The syntax used to bind variables within the application class is very similar to Javascript itself. You can specify the type of the binding you are using explicitly, which practically self-documents your code and makes it easy to understand whether a value is one-way or two-way binded.
Pro Structure
Aurelia.js consists of modules that can be used as a full framework or separately.
Pro Great documentation
One of the most crucial pieces of any new technology or framework is the documentation. At present even though Aurelia is pre-beta, the documentation is pretty complete. There are code examples missing and whatnot, but for the most part it is concise and makes the main parts of the application easy to understand.
Pro Full commercial support
Aurelia is officially backed by Durandal Inc. and has commercial and enterprise support is available.
Pro Data binding choices with sane defaults
Aurelia defaults to one-way data binding, alining with conventional wisdom. However, there are times when two-way data binding proves useful, such as binding an input widget with a view-model. Aurelia makes two-way data binding available to developers and uses it by convention when appropriate.
Pro Plays well with other frameworks
Aurelia can be used alongside of React and Polymer, since it is designed for interoperability. In practice, this means Aurelia developers can use React components by including an Aurelia custom element:
https://github.com/Vheissu/aurelia-react-example/blob/master/README.md
It also works well with Polymer, since they are both based on the WebComponents standards:
http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/integrating-with-polymer
Pro Powerful helper CLI available
https://github.com/aurelia/cli
The CLI helps rapid creation of projects with generators, building, deploying and hot reloads. Webpack should be coming soon.
Pro Growing community
The Aurelia community is growing at a great pace. Still doesn’t rival the big players line Angular or React, but the answer to an Aurelia issue is a quick question away on their Discourse.
Pro Provides dependency injection
With dependency injection, you can load in extra javascript and new functionality just when you need it.
This is particularly helpful with testing as you can swap out services for test services.
It also means in single page apps you can load dependencies only as you need them instead of loading them up all up at the start.
Pro No run-time exceptions
Lack of run-time exceptions makes it easy to produce large swathes of reliable front-end code without drowning in tests.
Pro Inferred static typing
ML static typing is great because it's always there, you just choose how explicit you want to be and how much you want the compiler to do.
Pro Super easy refactoring with very helpful compiler errors
In no other language you can refactor so easy without any worries, since the compiler will guide you through. It is like TDD but than compiler-error driven.
Pro Designed around high-level front-end development
As Elm was designed as a front-end langauge, it has out of the box support for things like DOM-element creation, letting programmers focus on their application logic, rather than implementation details specific to the web.
Pro Great and simple way to learn Purely Functional Programming
You can try to apply some functional programming ideas in other languages that have an imperative basis, but you haven't seen the real power unless you tried it in the environment of purely functional programming. Elm is a simple language with great learning resources and easy graphical output, which makes it easy to explore the power of functional programming. Plus programming in Elm is very readable.
Pro Good tooling
All major editors have great support. With Atom for example, Elm plugins are available for linting, formatting, make/compiler support and Elmjutsu will simply overflow you with super useful functions, like navigate to referenced definition and show expression type.
Pro Batteries included
The Elm Architecture means you don't need to spend valuable time and effort choosing the right frameworks, state management libraries, or build tooling. It's all built in.
Pro Static module system
Elm uses easy to use modules.
Use:
import List
import List as L
import List exposing (..)
import List exposing ( map, foldl )
import Maybe exposing ( Maybe )
import Maybe exposing ( Maybe(..) )
import Maybe exposing ( Maybe(Just) )
Creation:
module MyModule exposing (foo, bar)
Pro Missing syntactic sugar
Easy to learn, most functions have only one way, not 5 alternatives where you must study where to best use what.
Pro Growing community
Pro Interactive Programming and Hot Swapping
Support for hot swapping and interactive programming is included.
Pro Easy to code review
The lack of side-effects and simple, consistent language semantics make it easy to quickly review incoming changes.
Pro Higher confidence in code correctness and quality
Pure functions, immutable data structures, amazing compiler, clean and homologous syntax used for HTML, logic, and optionally to replace CSS, elimination of entire classes of bugs so you don't even need most unit tests. These factors lead to better code, better programs, higher confidence, and ultimately, more satisfaction.
Pro Not quite Haskell semantics
Luckily you do not have to learn Haskell to be able to do any Elm. It is meant to be a language that compiles to Javascript, so for Javascript programmers (Front end) not for CS students who want to learn as many different algorithms as possible.
Cons
Con No big success stories yet
There are no notable big web products build with aurelia yet
Con Needs more support from the community
It would be great to have a lot of plugins made by the community, or video tutorials from experiences when using it. Hopefully in the near term future.
Con Two-way data binding is often considered an anti-pattern
Two-way data-binding means that a HTML element in the view and an Angular model are binded, and when one of them is changed so is the other. One-way data-binding for example does not change the model when the HTML element is changed.
This is a rather controversial subject and many developers consider two-way data binding an anti-pattern and something that is useless in complex applications because it's very easy to create complex situations by using it and being unable to debug them easily or understand what's happening by just looking at the code.
Con Lack of typeclasses
Elm doesn't have typeclasses which means some code needs to be duplicated. A fix in a function that needs typeclasses means all of the duplicates need to be fixed too.
Con limited js interop
only one way ports are available as a crude js FFI. This means you can only call functions both directions but will not get a result.
Con Harder to get buy-in from devs and mgmt
It's a total divergence from what most people are used to in the JS ecosystem. The change in syntax can be scary, the change in approaching problems can be scary. The fact that it's not backed by FANG can be scary. The fact that it's not v1.0 can be scary. The governance model and the deliberately slow release cadence can be scary. There are a couple harsh medium articles, hackernews/reddit posts out there made by people with an ax to grind that can be scary if you don't have a better picture of the Elm community, the tradeoffs that have been made, or the benefits to be had over other options. None of these are good reasons to write off further investigation of a great tech, but it happens.
Con Code Repetition
Because of the lack of genericness Elm needs a lot of code to be repeated. There are 130+ implementations of map in elms core libraries.
Con Features get removed without warning
Often features that are deemed to be misused by the community like infix operators get removed without much of a warning.
Con Community harsh if criticised
If one even dares to start a discussion about a feature on elms slack, discord, subreddit or github one will be aggressively shut down often argueing that one should use purescript instead
Con Poor Windows support
Few if any of Elm's core contributors are Windows users and breaking bugs are sometimes left for weeks or months.
Con Good for beginners not good for experts
Development in elm is quite nice until you need some more advanced features. These however are actively discontinued and removed because elm wants to establish a "single way of doing things" philosophy
Con Updates break existing code often
The last few updates of elm broke existing code in major ways.
Con Adds an additional layer of abstraction
Some users claim that Elm adds an additional layer of abstraction, meaning that it is one more hurdle between the brain and the product.
Con Functional programming itself has quite a steep learning curve
Functional programming can be quite difficult to get your head around. It takes time to unlearn object orientational habits.
Con No Genericness in the future
Currently there is no code genericness like typeclasses possible, it has been officially stated that this will never change.
Con Not database-friendly
It is lots of work to make a server or database your "one source of truth", as Elm makes you write endless JSON parse boilerplate to talk to the server.
Con No Syntactic Sugar
Often you need to write longer and less readable code because there are no alternatives that are more concise.