Few comments.
I do not think this is necessarily true. Switching to a declarative way of expressing things might require some rewiring for certain patterns but I do not thing that the learning curve is all that high. Elm is deliberately staying small as a language. One can pick the main ideas of Elm in an afternoon. After that… it is a matter of learning the API of various libraries. The effort to learn the libraries will dwarf the effort to learn the language and this is true for most languages out there.
I would say that Elm is competitive in this domain. It has a very fast and tailor made virtual dom implementation and because it is functional it can provide various optimizations regarding the compiled code. You can read more here. With 0.19 some more optimizations will arrive which will reduce the size of the deliverable even further making Elm apps even better, especially for the mobile platform.
Elm is still in development. This means that the language is still changing from one version to the other. The rate of change however has reduced significantly. The main key point around this topic is that businesses already decided that Elm is stable enough to be used in production. There are enough businesses out there with large webapps implemented in Elm in production and the feedback is generally positive.
For the foreseeable future, it will remain a front-end oriented language working on being the best in this domain.
This is true however, the ecosystem provides a wide range of functionality. In other words, for most of the needed functionality there are already libraries.
Elm has elm-test so you can do TDD in Elm right now. The next version of the language will provide even more support for testing.
There are 4 levels of Elm integration:
- Using Elm to render some data. In this level you have no interaction with the rendered data but you might have some processing of the data before it is rendered.
- Using Elm to display a widget that allows user interaction but has no side-effects. Think about something like an images carousel. It can be configured internally with some data and allow for navigation within this configured data.
- Using Elm to display a widget that interacts with the outside world. Think of something like a weather widget or a stocks ticker or some kind of complex form that does validation with various services. The level of complexity is higher. You might want to interact from the rest of the app with the widget, you might want to receive events from the widget.
- Using Elm for a SPA. This is the highest level where the app is implemented in Elm and the rest of the widgets implemented in other languages are brought in through technologies like webcomponents.
For a successful integration of Elm into a project, it is advisable to start at the lowest level that makes sense and move up from there. Jumping directly to level 4 might work for a new project but for an established project it is much better to start with level 1 or 2.
Level 3 is probably the sweet spot where one would benefit from all the niceties of Elm without having to fully commit.