Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and maybe not representative of a good or even typical JavaScript app:<p>> Our JavaScript application had global variables everywhere, and debugging was a nightmare<p>Point #3 in their list of cons is especially important for anyone considering Elm:<p>> Because Elm is not a mainstream language, it is sometimes necessary to reinvent something that could otherwise have been acquired by adopting a different technology.<p>This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online.<p>This attracts a lot of developers who enjoy working on libraries and tooling, but it’s not ideal if you’re trying to run a lean team that ships products quickly.<p>Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done.
Elm is awesome, its compiler is awesome, but its ecosystem is kinda stalling, isn't it?<p>I mean, a lot of libraries aren't updated to the last lang version, debugging JS-Elm interactions been a real challenge for years, yadda yadda. Overall I'd say Elm ecosystem doesn't receive enough attention to survive.<p>I'm not complaining, I'm just sad about that and kinda surprised I didn't found a mention of that in the OP article.
For those want to learn Elm, or to learn strongly typed functional programming in very well thought out order @rtfeldman's book "Elm In Action" is super good.<p>His experience working at a teaching company made his book very well structured for new comers.
I wonder if someone will create 'pine' - "pine is not elm".<p>(For younglings: elm was an email client. pine was also an email client. The latter was often thought to be short for 'pine is not elm').
After the relevations about Elm's dysfunctional leadership culture[1] I have seen vocal discouragement about investing in Elm, and reasonably so. This is a culture where Elm's leaders actively attempt to shut down criticism as "emotional violence"[2], which is just incredibly immature hyperbole. I couldn't imagine investing the future of my job and workplace on an operation like this.<p>[1]<a href="https://news.ycombinator.com/item?id=22821447" rel="nofollow">https://news.ycombinator.com/item?id=22821447</a>
[2] <a href="https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/dur9k1q/#t1_dur9k1q" rel="nofollow">https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...</a>
> We had global variables everywhere, and debugging was a nightmare.<p>ES6 module imports really helped solve this problem and is a giant step forward in the JS ecosystem. Despite being relatively straight forward they were (and are) a big deal.<p>Any JS project before that was a giant dance of complex window namespacing, closure wrappers, and hoping the 3rd party library you’re using doesn’t expect some weird custom thing to ‘import’ it.<p>The next step obviously is fixing bundling and replacing Webpack and Babel (the closest thing to a widespread standard today in JS) with something less magicy and more native. And these are a big reason newbies/non JS devs freak out when they see a thousand packages in starter kits.<p>These two things (importing and bundling/preprocessing) were a big reason why there always seemed to be a never ending output of new build tools. Just having those two to be predictable is a godsend in any JS developers but IRL even the best internal practices was never consistent across libraries, teams, and projects.<p>I’ve always wondered how much frameworks like Elm and similar are motivated simply but attempting to establish best practices and standards in JS projects vs the abstraction/language innovations they provide (like pure FP and reactivity stuff). It’s at least 50% of the value proposition.<p>The big question is whether it will be for long enough to be worth the investment.
From a self taught view, the compiler helped me a lot and when it compiles it usually works and when not the community is very helpful. Over all I found libraries usually of good quality while also not needing a lot as Elm includes a lot out of the box (i.e. React, Redux, axios, type guards, etc.).<p>Elm-UI made working with styling much easier for me and was the main reason I gave Elm a try.<p>The Evan and the core team seem to have a clear vision of what they want and I can understand that but this is personal opinion. To make a system work well you have to be strict and including new features all the time might introduce complexity down the line. This might seem a bit closed in form the outside.<p>So far I am very happy with it.
It is refreshing once again to see an Elm post that looks at the pros and cons of the language and ecosystem, instead of solely focusing on a perceived problem with the way that the community is run.
The pros and cons listed hear mirror my own views of Elm. Although, we’ve only got a handful of small Elm apps in production it’s a joy to work on them. I can rip into them with a fairly big refactor, fix the compiler errors and be confident that it’s all going to work. I do which there were a larger selection of Elm packages to take advantage of, but integrating Web Components into Elm hasn’t been bothersome.
Wouldn't it be difficult to find other developers that are experienced using Elm? I don't know much about it tbh.<p>Probably, one of my biggest career mistakes was opting for a little known PHP cms instead of WP as I thought it would be easier for the stakeholders to work with the limited options.<p>Since then, I've always avoided going away from the mainstream toolset.
Elm looks interesting but when it pops up around here and other places it is usually about how the main dev does not work and play well with others.<p>It is a bit off putting.<p>It is nice to see a different perspective.
The part of the article that I was waiting for was how they got it adopted in Japan. Having worked in Japan for almost a decade I can easily say it is not an easy feat to change Japanese corporate mindset when it comes to a programming language or environment. I wonder what the elevator sales pitch was. Other than that I think this was a great article.
I had a problem with perf optimization on Html.Lazy long time ago that I can't solved before I moved on.<p>Since Elm is immutable and lazy render, most of the time, compare underline object reference (referential equality check), the reference (memory location) almost always changes on every update cycle because it needs to update model, thus, a new reference as a result. And that makes Html.Lazy worthless. I had some kind of 1000 html tree nodes, and it rendered every branch every time. I probably did something not right, but I already tried solving that for a few days, no success.<p>If you have the Elm in Action book, that memory location pitfall is explained on the very last page about when memory location of a object changes.
little anecdote: I did a couple of personal projects in elm in 2017. one thing I'm thankful for it taught me functional programming. Elm was easy to start with for someone new to functional programming. it also taught me, one important lesson - the market doesn't really care. a company when you're looking for a gig doesn't care if you know elm, it wants you to know the 'framework'they're using currently. so yeah, I see elm being a dead end. either people using it already solved product/market fit. but for a startup getting off the ground - elm offers no benefits at all compared to js.
Rakuten is basically a scam on merchants right?<p>By that I means they use affiliate links to make money.<p>But most of their referred traffic comes from people checking out and saying "I use rakuten to get a discount at the places I already shop".<p>The stores then don't know how much business rakuten is really bringing them, so are scared to stop it.<p>Consumers keep checking rakuten to see if they get discounts on things they want, because why not?<p>Is this a good summary? Anyone have a more favorable impression of their work (from the store perspective)?
I'd like to recommend Elm at work but I can't because it's still below a major version of 1, which implies there may be a good deal of rework in the short term.<p>I did get an Elm app upgraded from 0.18 to 0.19 without too much extra work, but I'm concerned a major version release may bring much more changes.
I'll never even consider Elm after they added DRM to the compiler. <a href="https://news.ycombinator.com/item?id=27819874" rel="nofollow">https://news.ycombinator.com/item?id=27819874</a>