I always think that usage of such technologies can be only in some cases – mostly for small companies, which are not sure that this product will be maintained m

I always think that usage of such technologies can be only in some cases – mostly for small companies, which are not sure that this product will be maintained more than few years. Like, it is not that bad to use it in startups, in some small projects, or if you have pretty strong and enthusiastic team with a lot passion, which are ready to dive into new cool technology. Moreover, in the short term it can be even more beneficial, because you can attract even better developers, who like cutting edge stuff. But the problem is what if this product will be maintained throughout years? Then to support it, you have definitely hire much more skilled engineer than for the same in stable JS framework. I completely understand about types, strict rules how to write Elm code, etc, but there are literally no guarantees that it will be the same after some time, that new developers will pick it up quickly, and, if you decide to rewrite it much later, there is a big chance that you'd have to rewrite it completely (this applies for JS too, but there are quite a lot of success stories of gradual integration of new framework). To summarize, I don't think it is bad, it just doesn't scale and creates big technical debt, so you'd pay for it later; though it is a great chance to attract very skillfull and passionate developers – so, it is all about risk.