Open nelsonic opened 7 years ago
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).
@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. ๐
@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.
@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... ๐
@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.
@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"...?)
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
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.
@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 https://github.com/dwyl/learn-closure-compiler/issues/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" andwhile
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. ๐
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.
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.
If you've read this far ...
For the reasoning why we think Elm is the best choice for front-end web applications in 2019!
A few reasons why we might NOT want to use Elm: (feel free to
add
to this list!)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...)"Elm in Action"
which is due Summer 2017 ... but that won't be enough to "convince" some clients.else
...?