Elm is a lot more experimental than Elixir, for instance. Elixir is still built on the classic Erlang BEAM virtual machine. And its syntax is fairly similar to that of Ruby, which is an immensely popular language among web developers. Elm looks like Haskell, though, which very few developers are competent with. It was originally based on FRP, which has long been considered highly speculative and theoretical. But I think by shedding FRP it's growing into a very practical language, and while it has a Haskell-lite syntax, it's considerably easier to use than Haskell.
:D
Somehow, though, convincing them to use a language that almost never has any runtime errors was not a hard sell.
The difficulty I'm having at the moment is just trying to find examples of non-toy application architectures. An application with multiple top-level screens, for example.
For a bit of context, the product I'm working on is a customer-facing kiosk. It'll be driven by a C# ASP.NET back-end. We have several different products using common back-end code but exposing different sets of features to the customer. We're moving from an old architecture that was your standard WinForms UI to something using HTML5 as the UI layer (definitely a big mindset change!).
Right now I'm trying to figure out what the front-end Elm code structure would look like. Is it going to be one huge monolithic Elm project that covers all our cases? Can it be broken up? Does the front-end have to know in advance what screens will be available? (the back-end uses the typical 'load features as plugin DLLs') etc. These are all questions I'm facing right now.
This is especially exacerbated by the recent change from 0.16 to 0.17. The changes themselves seem extremely positive (I jumped in at 0.17, so I'm only going off an impression here) but much of the example material that I've found which might be useful is still using stuff from 0.16 and I'm having trouble wrapping my head around it right now.
So from a commercial dev perspective, Elm, like anything else so new, is massively risky. I'm pushing on for the moment (would love any pointers if anyone has them!). I'm aware of the huge element of "not knowing what I don't know" that I've taken on right now. I'm hoping the payoff will be worth it :)
https://github.com/plentiful/shop
https://github.com/srid/chronicle
https://github.com/CultivateHQ/seat_saver
https://github.com/NoRedInk/elm-blogger
https://github.com/elm-lang/package.elm-lang.org/tree/master...
I would probably agree with your first 2 hypotheses. However I don't really see any momentum against Elm. Just the opposite in fact. There are other projects that have the same kind of goals such as Purescript or GHCJS but Elm is the one with the momentum.
>However I don't really see any momentum against Elm. Just the opposite in fact.
I just edited my comment to reflect that by "momentum against Elm" I meant to suggest that Elm is fighting against momentum that is currently behind technologies like JS, angular, react, etc. in the web programming community.
So it's basically a language we desperately want to use, but can't.
The problem isn't that it doesn't work. It's that what you do with ports only work in the context of your application. The JavaScript part has to be defined somewhere else, the Elm code assumes the JavaScript part will be there. You can't redistribute that easily.
How to make it better? that's easy. IT ALREADY EXISTS and is part of Elm. It's just a private API. But it totally does work. It's how the native wrappers are written.
Ports use publisher/subscriber. If I want to, let say, wrap moment.js, which is just a bunch of synchronous functions, how would I do it? Dispatch side effects to "compute dates" and listen to the "response" in my update method? That would be silly.
The port system works beautifully to interface with the outside world. It is very poor to bring the outside world in.
You mean like this: https://github.com/mcapodici/capodicis-notes/blob/master/elm...
That is an example where I connected chrome extension storage functionality using native wrappers.
This is the Elm wrapping for it:
https://github.com/mcapodici/capodicis-notes/blob/master/elm...
For the record, I looked at Elm over 2 years ago and completely dismissed it. I regret that strongly now as I am extreeeeemely happy developing with it and I can build stuff in far shorter timelines with zero runtime errors than I could in react even (which was a high-watermark before Elm for me in that respect)
I understand why but in the meantime I'll use something else and will try it again once it's more open.
As far as why people don't just use Elm, I think it's the same reason functional language are less popular in general: fewer familiar engineers and steep learning curve.
But, I thought the same about Coffeescript. And then Rails gave it massive traction. I wonder if the same might happen to Elm, should Phoenix adopt it as their browser language of choice. That might also offset concerns about Elm's fledgling status and key man risk.
There's definitely a connection there -- for what it's worth, the keynote at 2016's Erlang Factory conference was a shared talk between Chris McCord (creator of Phoenix) and Evan Czaplicki (creator of Elm), "Making the Web Functional" [0]
All that said, I'd probably check out elm now only because I've heard good things about it's developer experience.
Elixir is getting bigger with Dockyard and Pinterest using it among others, though it has the benefits of running on proven technology, having an "easy" syntax, and Phoenix.
I'm not deep enough into it to really assess yet, but I suspect the difficulty is how you integrate it with existing JS code. It feels like maybe it's an all-Elm or nothing world, which makes it hard for organisations to take it for a test run when they have an existing codebase to play nice with.
My exploration is an ongoing activity to figure out which framework / methodology is best to continue building our existing product on. We're currently using Angular (1) and some react components. I did some prototyping with Redux (including investigating Sagas) and familiarised myself with RxJS and MobX. I found the boilerplate in Redux distracting some I'm still looking to see what else is out there – would love to hear how others are assessing these tools.
One of the things that's really attractive about React is that there are already a lot of components you can drop in to handle behaviours for you. If I could somehow utilise those within Elm, it would lower the entry barrier for me.
It's not that I even have a clear picture of what I need to achieve but with each of these different tools I'm trying to poke at them to see where they fall down. So far, Elm feels the nicest, but it's the smaller ecosystem / lack of libraries that's the most obvious shortcoming so I'm trying to understand what the options are for interoperability on that front.
Please don't reject something based on its current (admittedly not 1.0!) state based on assumptions about its future! Evan and co. are in fact extremely smart and by no means does anyone consider Elm "done." I'd suggest playing with the language itself. That's the important part - not the state of the current runtime.
Elm is not just a language, it's a language + frontend UI framework. It is theoretically possible to run Elm code under Node, but the relative level of craziness is similar to "writing a C++ compiler in Angular", please let me exaggerate a bit :-)
After this adventure, I realized that having the ability to share code between server and client is too indispensable for me to trade for lack of runtime errors.
Native interface - I use a lot of js code already written by somebody else. I have a very extensive data manipulation library developed in Coffeescript for my application. It's proven, tested, documented and presents a solid foundation for whatever I decide to write using the data I have. I want to use this code freely. In Elm native interface is frowned upon and the official way is to use ports, which is quite cumbersome, especially for procedural libraries.
As an OSS project, Elm is too centralized for my taste. I'm fine writing helloworlds, toys, learning projects, etc in the language that is being designed and developed by a single person not accepting contributions from the public, besides probably a very small curated list (not sure about that part). But for the business, it's just too much risk yet.
I moved to Purescript. I haven't yet started writing for the browser yet :-) but so far Node and Google Apps Script were doing pretty well. In a sense as a language Purescript is both more demanding (it's much closer to Haskell than Elm) and more forgiving, more javascripty in a good sense of this word, just a part of the toolchain, not pretending to be an ultimate answer to everything. The native interface is best in class.
Frankly, for the category theory idiot like me, Purescript is easier than Elm, while Elm is considered much simpler exactly due to many compromises with "The Math". Almost every decent beginner-friendly Haskell book will work for Purescript, you don't need to break your head over "Elm doesn't have monads, but it does have Effects and Maybe and what not, which are technically monads, but we don't call them monads, etc...". Maybe for others it's different. I can recognize design decisions Evan made and why he made them and I'd like to see how it goes. But I'll watch from the sidewalk for now.
Just my 2 cents.
Another great thing about the community is a goal of a single great library for every use case, rather than a lot of half-baked competing libraries. So expect there to be a single great modal library. Etc.
The only "official" interop channel is the "port" system, which only lets you do a publisher/subscriber type thing with your application at runtime, and cannot be used in a library.
So you basically cannot make a "blessed" library that uses native browser APIs.
With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses:
1) There are no unhappy users because unhappy users just don't use it. 2) HN goes easy on technological curiosities, saving harsh criticism for large projects that deserve it 3) While there may be a widespread lovefest for Elm, there is too much momentum behind current technologies.
Any other thoughts as to what the disconnect is? Moreover, how do we get to a world where the webstack we all use is "a great little webstack"?
[0] https://news.ycombinator.com/item?id=11846707
edit: clarity