Why NOT?

[nelsonic]

A few reasons why we might NOT want to use Elm: (feel free to add to this list!)

• additional learning curve for people who have only just learned JavaScript
• functional/immutable paradigm is not everyone's cup-of-tea. it can be perceived as "too mathematical" and not very beginner-friendly...
• it's virtually impossible to find/hire a person with Elm experience on their "CV" (which means our clients will have to train up anyone they hire to maintain/extend any code we write for them...)
• encourages more front-end-heavy apps as opposed to progressive web apps
• no server-side rendering (yet) ... see: https://github.com/elm-lang/virtual-dom/issues/29
• may be "difficult to sell" to organisations who have not heard of it. (i.e. all orgs that don't have a tech-focus or at least a tech-curious person in a decision making capacity!!)
• (I might be mistaken, but...) at the time of writing, it appears that there are Zero Female Contributors to the Elm Compiler: https://github.com/elm-lang/elm-compiler/graphs/contributors this could be a coincidence or it could be that the Elm community is not very welcoming...? @jessitron might be able to enlighten on this... https://youtu.be/cgXhMc8M4X4?t=5m11s
• There is no published book on Elm or the Elm Architecture which can suggest immaturity... the online resources are good and there's "Elm in Action" which is due Summer 2017 ... but that won't be enough to "convince" some clients.
• What else...?

Note: some of these "reasons" are not specific to elm but are applicable to all compile-to-JS languages e.g. clojurescript because by deciding to use them you are forcing all the people on your team and client(s) team(s) to learn a whole other language just so they can update a line of code in the codebase...

[iteles]

All of the ones on my mind are in your comment above. The really big ones for me is how hard it is to find people who code in elm, which will mean our QA process will suffer of course, but in particular means we leave our clients with something that's difficult for them to extend - this goes against our core philosophies. We can provide beautifully composed, commented and documented code, but if they're going to find it either near-impossible or unnecessarily expensive to extend/use further, are we really doing our job to the standard we want it to be?
The other big one for me is the learning curve. Even if it's not hard, it forces people into learning one more thing which they will o my use in certain cases (if/where appropriate).

[nelsonic]

@iteles Yes, I hear what you are saying
And I listened intently to what @sofiapoh & @nogainbar said on Friday @ Lunch.
Learning JS is difficult enough at the start of a code-crafter's journey...
.then after a few weeks/months of JS we are expected to learn Functional Programming and 20 other things... It's exhausting! 😫
That's exactly why we need to have this list.
And we need to consult people: https://twitter.com/nelsonic/status/795164336834617344
I would never "force" anyone to learn an entirely new programming language just for the sake of it. At this point we are 100% at the investigation phase.
If we conclude that elm is a "too much" at least we know we gave it a fair chance. 😉

[jedwards1211]

@nelsonic also now that it's possible to run the same JS on both client and server and there are tons and tons and tons of great JS libs in npm, not being able to take advantage of that (though I don't know for sure if it's impossible using Elm) is a disadvantage.

[nelsonic]

@jedwards1211 Yes, the promise of running JS code on both Servers and Client was the original reason we moved to Node.js 🌈
And and until node V4 we were able to write universal code without needing a "transpiler" ... 😞

Yes, there are many good JS libraries on NPM 📈
And we have a few packages in the "top 1%" of usage ...
And we still ❤️ the platform
However, we don't want to let our current "good" system prevent us from exploring a great one. 😉

So ... we are investigating our options ⚖
And hopefully we can make a proposal (either way) back to our team for consideration... 👍

[jedwards1211]

@nelsonic another important question: does Elm provide some way to use duck typing when desired?
Seeing the vitality of the JS ecosystem after coming from Java, I try not to underestimate the value of dynamic typing anymore.

[nelsonic]

@jedwards1211 from my limited knowledge I don't think "duck typing" is a "thing" in Elm ... this is probably worth opening a _separate issue_ for and investigating it with the help of the people with way more experience than we currently have. 👍 (Yes, it could be a "reason" why someone might not consider using elm-lang And is it a "deal-breaker"...?)

[rjmk]

In languages like Elm, I believe type classes are the closest technique to duck typing. They are not present in Elm. This is a way in which Elm eschews power for approachability.

Some people have found it to be annoying (1, 2). It can sometimes be circumvented in interesting ways (e.g. http://package.elm-lang.org/packages/eeue56/elm-all-dict/2.0.0/EveryDict).

So that's one reason why not. These slides on problems with Elm are excellent and contain good examples of how Elm's limited power can be frustrating in certain circumstances. Worth noting, there's no implication that JavaScript would be a better choice despite those frustrations

[jhg]

Elm hasn't basic features in core development even it hasn't it in comunity development, because they are "conservative". Then for basic things like have a CSS external and work whit designers in the team you need third part libraries, that don't give you guarantee of maintenance in a short future, or you need write your own libraries like anyone.

It need still more development and to be mature, and the first step I think it's accept more easy libraries in the core for things that all people need. One HTML generated from the compiler that nobody can use because it's ugly (not unfriendly, ugly, not CSS and you can't add it) and you haven't option for add CSS is a bad feature or a incomplete feature in the compiler.

https://github.com/elm-lang/html/issues/113

[nelsonic]

@jhg all great points. ✅ (welcome to DWYL!) ☀️

We agree that HTML output from Elm Compiler is "unfriendly".
I don't think it's meant to be human-readable, however we consider this more of a "tradeoff" than a "flaw". Making generated HTML look good is a "nice-to-have" not a "requirement" the Elm Core people need to be wasting their time on at the expense of Server Side Rendering... 😉

If you "View Source" on any Google Page e.g: view-source:https://www.google.co.uk
the HTML+In-Line-JS+CSS is not human friendly because it's (highly) Optimised for lowest possible transfer/load time.

Not saying that is the case with Elm because there are many Language features e.g: 9 Levels of "Currying" that I know I'm never going to use, which I would prefer to be stripped out.

I think I can "pipe" the Elm compiler output through an optimiser like dwyl/learn-closure-compiler#1 to trim down the unnecessary functions and make the output much leaner.

As for not "allowing" CSS we're embracing that "constraint" and making it a "feature" by using Tachyons! see: https://github.com/dwyl/learn-tachyons
This allows us to declare all Markup and Presentation within the Elm Component without fear that it can be "mutated" by someone accidentally updating a style somewhere else...!

If it was up-to-me, I would never write another line of CSS again! 😮

As for not allowing lots of new features into the "core", I'm delighted that they are being ultra-conservative with what gets in. I've seen platforms get unncessarily bloated very quickly because too many (good) ideas were included at the expense of few fantastic ones.

see: http://www.slideshare.net/InfoQ/less-but-better

Babel is a (feature) "free-for-all" and while it has more users it also has way more bugs!
Babel had to remove their bug-tracking from GitHub cause it was getting embarrassing...

I'm personally a huge fan of what Evan has done with Elm.
I don't "love" everything, but the good is 95% and "bad" only 5%
and it's so much better than the alternative!

I'm excited every time I read Elm Code instead of JS! 😍

Thanks for your feedback! All valid points everyone should consider before adopting Elm. 👍

[jhg]

My point about add CSS is not about write CSS inside Elm app, the problem it's Elm not allow that HTML file generated by Elm compiler to have an CSS (generated with any other tool, etc). You get an ugly (visually) HTML or an JS to add to other HTML, but the HTML generator can't to add a custom CSS file. In the end, the generated HTML by Elm compiler is only useful for a fast test one weekend, finally you need use only JS generator and write your HTML (or use another tool to generate it, not Elm).

Also some basic features need ports (then you need to write JS not checked by Elm compiler because Elm is so basic). Ok, maybe change title could be optional, at least if you could change it in generated HTML, but many people requests common and basic things since years ago and they have nothing official (even not in community official packages).

The problem of Elm is that it looks beta, ok maybe it's good take care what to add to core but then it needs more to be mature enough.

[jhg]

And sincerely, I was excited with Elm, I start thinking not write more JavaScript and write all web application with Elm, write a CSS and, done; with the HTML that the compiler generate. But when I see it's not possible to do it, that need compile to JavaScript an write JavaScript for make Elm run... the good first contact was broke.

[nelsonic]

If you've read this far ...

GOTO: #129

For the reasoning why we think Elm is the best choice for front-end web applications in 2019!