22 ms·
Why and how we retired Elm
- savanaly 4y agoI'm not surprised Elm is not viable anymore at a medium or large company, despite continuing to use it every day myself for side projects. The creator has deliberately shunned publicity or popularity for it in the last few years so adoption and therefore hiring has slowed to a crawl. We still have a vibrant and passionate small community, but the emphasis is on "small". No matter how superior it is to e.g. React it will lose out at a company level if you have pay the price of retraining all your frontend devs to "think in elm" to continue using it. I'm mainly sad that we'll be losing the chance of any future Kevin Yank videos about Elm. I really love the videos of his I've seen on youtube, including non-Elm ones such as the one about how to use VoiceOver for devs [0]. [0] https://www.youtube.com/watch?v=38qQzmkXGS4 https://www.youtube.com/watch?v=38qQzmkXGS4
- slimsag 4y agoWhat are your thoughts on the direct descendant, Roc? [0] I know it's pre v0.1 so maybe you don't have any, but as a fellow Elm lover it seems pretty compelling on the surface albeit less directly frontend-dev focused. [0] https://github.com/roc-lang/roc https://github.com/roc-lang/roc
- JohnCurran 3y agoThere is also gren, a fork of Elm being actively developed https://gren-lang.org/ https://gren-lang.org/
- pyrale 3y agoThat's the language's claim, but it really feels weird to call oneself a direct descendent when the original language creator has not left the boat.
- ricardobeat 3y ago> it will lose out at a company level if you have pay the price of retraining all your frontend devs to "think in elm" to continue using it This is something every framework is up against, since React won. It has become more and more of its own JS dialect, so devs that grow up with it also “think in React”.
- rcme 3y agoOn the other hand, React is super slow, a problem which is further exacerbated by the fact that rendering and invalidation happens somewhat indirectly, meaning it’s really easy to accidentally make something super slow. For your run of the mill website, this probably doesn’t matter. But for interactive web content, it can absolutely be a competitive advantage to use something faster and more responsive.
- MajimasEyepatch 3y agoI don’t think I’ve ever seen a web app where the performance of React was such a bottleneck that it would in any way justify migrating to another tech stack. You’d have to get so far into a project for that to become an issue that the cost of switching would be huge.
- deleted 3y ago[deleted]
- G4BB3R 3y agoElm is used in many medium/large companies. The biggest ones are NoRedInk and Vendr, the later reached 1B valuation recently with 600k+ loc Elm codebase.
- brundolf 3y ago> not viable anymore at a medium or large company That's not really the point made in the article, he mainly talked about the difficulties of maintaining a hybrid codebase split between Elm and another framework, and how their specific company situation nudged them to choose React to go all-in with
- cwzwarich 4y agoTL;DR: they bridged Elm with React, and when they started using Web Components there was an impedance mismatch between the bridges between Elm/React and WebComponents and the bridge between Elm and React, so they had to pick one of Elm and React.
- savanaly 4y agoI would say the Web Components portion of this article is a detour, mainly he was explaining his discovery you can't utilize web components to marry React and Elm together as one would hope. The real TLDR is it's too hard to hire Elm devs.
- zackbloom 3y agoI wonder how you got that TLDR. He literally said they hired a bunch of people only because they did Elm.
- macintux 4y agoThat's a bit too short, I think. TypeScript plays a role as well, as does an acquisition. I liked the description of the internal discussions. Working at a larger company where decisions are made in a completely different part of the organization and you're stuck dealing with the ramifications leaves me a little nostalgic for a smaller firm where it's practical to engage all stakeholders.
- jrumbut 3y agoOn the other hand, at this larger organization it was possible to have devs devote months to experiments that were ultimately shelved. It was kind of cool that they really explored all the avenues for making it work.
- Herval_freire 4y agoThey had an acquisition where the code became 75% react over night due to the acquisition. This was the major turning point. Purely business, purely popularity. It wasn't technical superiority.
- anonymouskimmer 4y agoI can't be the only person who wondered why a company was still using the Elm email client. Edit to add: There are enough names and acronyms available. To avoid even temporary confusion, and to make literature searches easier, try to avoid popular ones from yesteryear that were used in your general discipline.
- elm_master 4y ago[flagged]
- capableweb 3y ago[flagged]
- wiseowise 3y agoParent comment implies that TypeScript + React + Redux combo is superior technology and the only reason Elm got traction in the first place is that mentioned combo hadn’t been invented yet.
- wpietri 3y agoAre you perhaps misunderstanding what "precludes" means? Or perhaps the person you are replying to does?
- deleted 3y ago[deleted]
- satvikpendem 3y agoElm "prevent[s] from happening; make[s] impossible" TypeScript and React+Redux? I think you don't mean "preclude" in that sentence.
- iudqnolq 3y agoI only looked enough into Elm to determine it's not for me. But this relates to the main reason I made that decision: it's explicitly designed to be hard to integrate with javascript. Integrating React and Elm is hard because they can only communicate via message passing. Synchronous js calls are restricted to packages whitelisted by the Elm compiler. So preclude is I think a reasomable word.
- satvikpendem 3y agoSame, I never got Elm, I'd want to work as close to JS as possible. I like TypeScript but I likely wouldn't use another compile to JS language, if only based on the npm ecosystem size in general. Then I heard the horror stories about Elm, and how the creator really hates criticism while simultaneously carving out features in the compiler for his friends, and I decided it wasn't for me.
- vmchale 3y ago> I tell myself that it would be rude and ungrateful to the Elm community for me to publicly declare Culture Amp’s departure from the fold > What We Owe to Elm Everyone who talks about Elm sounds like they have Stockholm syndrome. Don't think I've seen a single good experience lately.
- SantalBlush 3y agoI don't know, these two quotes don't immediately take me to "Stockholm syndrome."
- vmchale 3y agoIf you read more about the Elm community you'll see similar things. Been happening for years! https://dev.to/kspeakman/elm-019-broke-us--khn https://dev.to/kspeakman/elm-019-broke-us--khn
- SantalBlush 3y agoCould you explain how the two quotes above are similar to the story in this link? Because they don't look similar to me.
- deleted 3y ago[deleted]
- epolanski 3y agoBecause the language is frozen in 2019, it's last meaningful release. It was doomed to end this way due to the close leadership and being developed behind closed doors by a single developer. This kind of projects, as amazing as they are, and Elm is absolutely an amazing language and project that has changed and influenced web development meaningfully, are just untrustable. If you can't have a discussion with library authors where they confront their ideas in the open, you need to move on or pay the consequences.
- 3y ago
- notreallyauser 3y agoIs anyone else disappointed this wasn't about old school email clients, and a belated migration to, perhaps, pine?
- dangjc 3y agoSome nuggets of wisdom from the article when managing an engineering org: - “if the only reason an engineer wants to work for you is because of your tech stack, that may be a warning sign. Culture Amp therefore avoids hiring engineers who are purely technology-focused. As a product company, we seek to hire people who are mostly excited about our product and its mission, and who are happy to learn new things when necessary to progress that. When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.” - “Perhaps the greatest challenge for engineers as they reach more senior levels in their career is to make decisions that balance the moment-to-moment joy (or frustration) that a given tool affords them, and the costs (or benefits) that same tool might create for their team, company or client over time and at scale”
- hgsgm 3y ago>> we seek to hire people who are mostly excited about our product and its mission, Consider the source: https://www.cultureamp.com/ https://www.cultureamp.com/ A completely generic me-too startupy startup. I can't even figure out what their product is.
- jrsj 3y agoWhy are the people who talk the most about company culture typically the ones with the cultures I find most off putting?
- kevbin 3y agoAt least those that talk publicly about company culture. It feels performative and inauthentic, but maybe that's necessary to compete? They are selling culture surveillance technology of some sort. Reminds me of mandates to get more on the engineering blog: makes an organic, authentic good into something performative.
- sli 3y agoBecause if there was something more concrete to offer that isn't done better, either from them or from the firm they represent, they'd go with that instead.
- pickledish 3y ago> When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit. Hmm. I’m not one of these tech-stack-driven types of developers they’re talking about in this paragraph, but even I had to raise an eyebrow here — this seems like the kind of rule that’d have a super high false negative rate. I understand the kind of person they’re trying to avoid hiring by accident, but… being excited about a cool language being a “point against” to try to serve that goal? Seems a little over the top
- deleted 3y ago[deleted]
- autarch 3y agoHe doesn't go into much detail here but what I _imagined_ he meant was that if someone came to an interview excited about Elm but knew nothing about the company, that would be a strike against them. If someone came excited about Elm _and_ was interested in the company's product that was fine. But this is just me filling in the blanks as I think they should be filled in. It'd be great to see him spell this out a bit more.
- duxup 3y ago> but knew nothing about the company How much does anyone really know about a company they don’t work at? And if that’s the issue (I don’t think it is from what o read) then they just have to say that and not the bit about functional programming.
- whateveracct 3y agoIt's just ego imo.
- bawolff 3y ago> If someone came excited about Elm _and_ was interested in the company's product that was fine. We're talking about a company that makes workplace engagement surveys. I have trouble imagining anyone is actually truly excited about that product. No 5 year olds ever said that they want to grow up to write engagement surveys. They aren't saving the world. And that's ok. Most products aren't very exciting when you get right down to it. One of the most toxic beliefs in tech companies is that everyone should be obsessed with the product.
- javchz 3y agoI really felt this story as someone how had to abandon coffeescript like 8 years ago in a similar fashion. The syntax was easy, simple, and enoyiable. But at the end of the day, when you implement something like react or angular in real projects can get messy really fast. At least a lot of the good things of coffeescript still kinda live in TS and new versions of vainilla JS.
- tomca32 3y ago> Culture Amp was well on its way to doing this in 2018, when things started to get hard for the recently-formed Design System team. This is the problem right there. Design system teams never work well. A design system that’s complicated enough to need a dedicated team always creates more friction than it’s worth. Turns out that it’s really hard to standardize UI components in a way that makes them flexible enough to be used across different teams. The only design systems I’ve seen work well are the minimal ones that just define the color values of the visual theme and look of some basic components like buttons but leave the implementation up to the individual devs.
- epolanski 3y agoHmm, that's not true? GitHub, Atlassian, Microsoft, plenty of greatly and widely used design systems out there. The problem is different: they are huge investments that most non-large companies cannot afford for economic and logistic reasons.
- the_gipsy 3y agoBut those companies are several leagues higher than whatever Culture Amp is.
- joneil 3y agoI work at Culture Amp and was once team lead of the Design System team. Its not hard to justify the team. If 4 front end engineers in a design system team can solve some common problems (writing components, improving accessibility of existing components, writing docs, answering technical questions etc) in a way that makes 40 product facing front end engineers more effective than 44 who don't have access to the team... then the team is a net positive. At our scale we'd need to give a 10% improvement in efficiency to the product engineers. Both the engineers in product teams, and the various levels of leadership, have seen enough to believe we're making at least that much of a difference. Like almost any other company... measuring that accurately is a nightmare (and would require a significantly larger team just to measure ) but its a safe enough bet that we continue to invest in it.
- surprisetalk 3y agoEvan will be giving a talk about "Elm on the Backend" later this month. [1] https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend The video will not be published online. > NOTE: My goal is to get some early feedback from the in-person audience, so the video will be held back for now. I am not announcing a release, and the roadmap and this status update are still the primary documents for long-time Elm users to set expectations about this work. [2] https://github.com/elm/compiler/blob/master/roadmap.md https://github.com/elm/compiler/blob/master/roadmap.md [3] https://discourse.elm-lang.org/t/status-update-3-nov-2021/7870 https://discourse.elm-lang.org/t/status-update-3-nov-2021/78... EDIT: In the second link, Evan says the following: > As I allude to in the roadmap 410, nearly ten years of working in constant interaction with “silicon valley mindset” had taken a toll on me in many ways. Within the dominant value system, there are specific rewards and punishments for specific behaviors, and despite my personal views on this value system, I had internalized certain patters of thought and behavior by interacting with it online. I think sometimes HN gets excited about technology and forgets that tech is made by humans. Just a reminder to be kind :)
- epolanski 3y agoEvan has always hid away from confrontation about his work.
- boxed 3y agoI want to be kind, but sometimes you also have to be HONEST. Evan doesn't just hide from confrontation. He and his team bans everyone who are confrontational. Like me. They wouldn't even acknowledge that they banned me, which is just cowardly. No one I worked with who used Elm would go close to talking with their own account on the Elm reddit because they were sure they'd get banned. I argue hard because I was raised that way and I believe it's the best way to quickly find the truth. Like Steve Jobs said: strong opinions, loosely held. You argue hard, then when you are convinced by the other side, you flip with absolutely no time in between trying to "save face".
- 3y ago
- mrcwinn 3y agoI still take the overall point that Elm was simpler, but it’s funny how people react to curly brackets. When I look at the provided screenshots comparing Elm to JavaScript, I see no meaningful difference in terms of visual noise. Maybe I’ve just spent too much time with too many languages.
- sickcodebruh 3y agoI remember looking closely at Elm in 2016. I was a year or two into being the first and only web-focused software engineer at a hardware startup. Working solo, moving fast, refactoring aggressively as we iterated and sought our product’s UI, I was craving more help from my language than JavaScript and React alone could offer. Elm was appealing for all of the reasons described in this post. Functional programming, static typing, batteries included so there would be fewer dependencies to juggle. Improve predictability of my code, cut down on bugs, make it harder to screw up, easier to refactor. People using it seemed to love it! But TypeScript’s promise was too good. The JS I already knew but stronger! Keep my existing React code base but refactor it to be safer! No need to learn entirely new syntax; instead, adapt my ways of working to let the compiler be a better collaborator! Easy to break out of it when I absolutely had to! Elm offered many of the same things but require more faith. You invest in different syntax and the Elm way of doing things and you get more safety, better syntax. But the risk of being stuck on a path that’s hard to get off, the cost of ramping up, the challenge of onboarding anyone in the future — that was not in my budget. Even if it was, even if it offered much of TypeScript’s value but did those things better… Was it going to be so much better than it justified the risk? I didn’t see how it could be. I went TypeScript immediately after the 2.0 release so I could use @types packages from definitely-typed. I spent a week refactoring the entire project and never looked back. It was one of the best investments in technology that I ever made. I remember a ton of advocacy for Elm on forums and blogs until then. I’m far from an Elm insider so this is pure speculation but if I had to guess, I’d bet wasn’t the only person who doing napkin math about the right frontend language/tooling investment right around that time. I wonder to what degree the rise of TypeScript clipped Elm’s wings and whether a different timeline, maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future.
- michaelcampbell 3y ago> maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future. It's an intriguing thought exercise, but even with a head start it would have had serious issues like it has today; the pace of the language is _SO SLOW_ that in today's world it just has a hard time due to that. I'm not asserting that it SHOULDN'T be slow, that the reasons for doing it that way are bad, or anything like that; it just is what it is, and that's a downside for many people.
- deleted 3y ago[deleted]
- ShadowBanThis01 3y agoI was going to be impressed that anyone was still using Elm. But this turns out NOT to be the E-mail client.
- crispinb 3y agoI wish I had, just once, had as thoughtful and thorough manager as Mr Yank (terrible name for an Aussie) seems to be (at least as far as you can ever tell from the self-presentation of an article).
- efitz 3y agoI must admit, I read this headline and wondered why I should care which email editor they used. I read half the article and still don’t know what Elm is but I’m guessing it’s a language?
- andrewstuart 3y agoKevin did the right thing. IMO these days you have to have very strong justification to use anything other than the top 2 or maybe 3 “mainstream” technologies in any field. Unless you’re doing something extraordinary (and you’re probably not), most software can be built with VueJS/React TypeScript C# Python Postgres MySQL/MS SQL. That’s your entire stack covered there. These technologies get the job done, people know them, there’s massive community support and critically important when you’re hiring, you’re fishing in the big pool. Also, ChatGPT knows these technologies well and that’s increasingly important. Any other technology choices really need very strong justification. And, if your company is still using some branch of the technology tree which several years ago looked like it might have something to offer but has since become obscure or withered in its popularity, it might be time to do as Kevin Yank did and prune that branch off your tech tree.
- tinco 3y agoMS SQL? I've been a ("full stack") web developer for 18 years now, and I've never seen anyone use MS SQL for a web application. That's immediately a tell that I'm in a bubble, and obviously you are as well if you think MySQL/MS SQL are even in the top 3 (behind Postgres, MongoDB, Oracle?). Since you mentioned it, I just asked ChatGPT and in a list of 30 unicorn companies based around web applications, half of them were built in Ruby which isn't even in your list. If becoming a successful company is part of the justification for technology choices, you'd need a very strong argument to not pick Ruby. I'm not really sure that's true, but if you want to make strong recommendations I feel they need to be backed by data, and not some hunch on what technology is popular right now. And Ruby has been less popular for over a decade now, and it's still used by half the most successful companies out there. So the data isn't on your side here.
- andrewstuart 3y ago>> I've never seen anyone use MS SQL for a web application Are you working in the corporate world? The data you request is that on my local job board there are > 833 jobs for MS-SQL - that's mainstream. MySQL/MS SQL - I would not use them personally but they are very popular. Industry acceptance and popularity matter when pragmatically choosing a tech stack for a company. Ruby is definitely not in my list - it may be fine if you are a unicorn company with a vast flow of developers who want to get on board the success train, but for the other companies hiring is a nightmare. "Whatever happened to Ruby?" https://www.infoworld.com/article/3687219/whatever-happened-to-ruby.html https://www.infoworld.com/article/3687219/whatever-happened-... Again, my local job board has 148 Ruby jobs versus 1554 Python jobs versus 855 C# jobs. The fact that a technology is used by big companies does not mean it is not in decline. Facebook still uses PHP - a technology clearly in decline. Like it or not, Ruby's best days are behind it - the fact that so any successful companies are built with Ruby is historical information. And besides, its up to you what you think the list is of modern mainstream technologies - doesn't matter what I think is in that list. The point is that choosing something less than mainstream such as Elm or Haskell or whatever is likely to cause problems. And for the record - that same job board returned one job when searched for "Elm", and it was actually an ad for a Ruby job.
- comp1927 3y ago[dead]
- tantaman 3y agodon’t hire people if they’re too excited about the tech stack, proceeds to rewrite their app every time a new shiny comes out.
- karmakaze 3y agoThe problems were not with Elm per se but rather maintaining both Elm and React components. > It seemed we were faced with a choice: Elm or React. Continuing to support both was fast becoming unsustainable for us. > The thing that ultimately tipped the balance in React’s favour for us was that we acquired another company whose entire codebase was written in React, and whose team knew nothing about Elm. Overnight, we went from a company that was writing about equal amounts of Elm and React (and which might well have decided to double down on Elm) to one that was writing about 75% React.
- ParetoOptimal 3y agoThere are libraries for using react components in Elm, but I haven't used them. I bet those weren't considered though.
- joneil 3y agoThey were considered, I was on the team that considered them. (I work at Culture Amp and at one point was leading the Design System team). To be clear: embedding Elm in React is easy (we host the main NPM library for doing so: https://github.com/cultureamp/react-elm-components https://github.com/cultureamp/react-elm-components). But embedding React in Elm is harder, as Elm doesn't give any easy "escape hatches" to interact with native JS code. The main opportunity is to use Web Components. Elm knows how to render any HTML component, including `x-my-custom-button`, which could render using React or something else. We looked into options for this, including prototyping https://www.npmjs.com/package/backstitch https://www.npmjs.com/package/backstitch as a way to embed our React components as Web Components for consumption in Elm. (No open source packages existed to do this at the time). We also did quite a deep dive on using Stencil, which has a React-like API, to create web components for both React and Elm - even including publishing new plugins for the ecosystem to generate Elm bindings for your web components. Kevin went into some of the detail for this in the post if you're interested.
- theK 3y agoThe title is misleading, they haven't retired anything and won't for a long time. > Codebases written in contained tech stacks can continue to exist and have features added to them Phasing out might be a better term.
- mebassett 3y agoI have used elm for a smallish (10 people or so?) team writing software for revenue, and regretted it. that was 4-5 years ago. my reasons had a lot to do with the community around elm, which other comments allude to. This group had different concerns to mine: The thing that ultimately tipped the balance in React’s favour for us was that we acquired another company whose entire codebase was written in React, and whose team knew nothing about Elm. Overnight, we went from a company that was writing about equal amounts of Elm and React (and which might well have decided to double down on Elm) to one that was writing about 75% React. By that time, TypeScript had grown to be capable enough (and developer-friendly enough) to balance much of what sold us on Elm originally: a usable type system, good-enough error messages, etc. React had baked in some more useful state management primitives that roughly matched Elm’s “batteries included” state management. if you like the ideas in elm but don't want to commit to it I'd encourage you to check out elm-ts (https://gcanti.github.io/elm-ts/ https://gcanti.github.io/elm-ts/). It has a little bit more boilerplate than elm (I find elm to be quite verbose already!) but a better experience for individuals and teams overall, I would say. It's a good example of how "TypeScript had grown to be capable enough (and developer-friendly enough) to balance much of what sold us on Elm originally: a usable type system.."
- alberth 3y agoOff topic: I always really liked https://cultureamp.com https://cultureamp.com web site design. It uses Tailwind, though appears to be highly customized.
- gumby 3y agoTIL there is a language called Elm. I had thought from the title they had changed mail clients. Despite the article I now want to learn more about the language Elm.
- xiaodai 3y agoWhat ever u say, he's a very good writer. I often have to make these practical considerations too.
- pharmakom 3y agoI always felt the lack of an ABI would hurt Elm, even though I understand the reasons for it. If you are "ML curious" then I think that Fable / F# is currently the strongest option for compile to JS languages. It definitely benefits from being a mature backend language already.
- k_bx 3y agoMan, it's 2023 and Elm is still the best thing to use for one-man SPA apps. Unfortunately, the author is right and it's Elm-or-nothing most of the time, no real coexistence of Elm components with TS/JS ones. That adds to the state of Elm being essentially abandoned by its creator. I'll keep using Elm for now for my one-man UIs, the language doesn't feel old but rather "done". I'm still productive as hell with it, TypeScript will never match. But I'll also never recommend building their startup with it and won't force it to anyone anymore.
- bayesian_horse 3y agoAt the moment I have a bit of an opposite problem from the "don't hire for passion only": I can't find a new job because I can't hide my passion and experience in Python well enough and somehow Python is regarded as very unprofessional in Germany, so not many companies want to use Python for Full Stack development at all.
- bayesian_horse 3y agoI feel much happier writing functional code than OOP code... And I don't believe much in engineers believing in the company's mission. That is an HR delusion, in my opinion. Yes, of course, some buy-in is good, even ideal, especially later on. But really. At some point, you want a job, you want to get paid, you want it to be somewhat meaningful, but how many choices do you have? I don't have a lot of choices of companies that want me, so I don't much care about the topics I work on. Unfortunately companies care a lot about what they think I want to work on, and they deduce it from facts in my CV I am legally obliged to disclose.
- davidwritesbugs 3y agoYea this looked a bit odd, and I'd not heard anyone say it before. I have therefore made a mental note for job interviews: "I was attracted to your job ad by your tech stack, but I made the application because I was just BLOWN AWAY by your awesome mission to re-invent inventory cataloguing."
- mnming 3y agoI feel the article is talking about why they fix a strategy mistake by senior engineering leadership. I guess money was easy enough to get in the last two years so company can afford this kind of expensive experiments..
- DarkNova6 3y agoThe first time I heard about Elm, I was overjoyed with its promise. For the first time, it made me interested in working on a web FE. To bad it ended the way it did. Thank you for sharing the article. It makes good points, particularly on the historic context as well as the steam behind Elm waning.