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:
> Our JavaScript application had global variables everywhere, and debugging was a nightmare
Point #3 in their list of cons is especially important for anyone considering Elm:
> 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.
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.
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.
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.
A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like.
The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. Most of the time I see it, it's people flipping out at the very sight of there not being something available off-the-shelf. The actual cost is much lower than the panic implies.
In general, people see ANY time spent in an FP language to solve FP problems as "a waste of time" but they're blind to the wastes of time people treat as "real code" in mainstream languages.
But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point.
My opinion is the long-term technical & cultural benefits and opportunities pay off. And as a developer, I am happy to not optimize my development velocity to the utmost if it means I don't have to waste my brainpower writing imperative code. My mind is in a much better state at the very least :)
> The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here
This isn't a good representation of the argument. People don't want to write libraries because it's more valuable for everyone to spend time writing features using existing libraries, provided there are good libraries available. People aren't "freaking out", they just have deadlines, and you know, other things to do with their lives besides write code that has already been written.
I would imagine that it's a good representation of their experience of such things, but a poor representation of the experience of such things of the person they're replying to.
Nah it's a pretty good representation. And acting like time should 100% be spent writing features is shortsighted - sometimes it's worth it to pay fixed costs such as filling in a gap of the ecosystem of the language you chose for higher reasons than cranking out business code.
"Crank out" was supposed to imply optimizing the short-term. Ensuring your next sprint has the most output as possible.
If you choose an FP language like Haskell, you tend to value things beyond that. Stability, engineering culture, retention, big rate, the ability to extend things for cheap only because you did the hard part of using Haskell to begin with, etc
>The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here
I don't think it is.
At work, I'm adding some basic metrics/logging functionality to an internal library, to see how it's being used. The idea is to log a few parameters and the tech lead suggested using JSON format.
No problem right? Well my work environment is quirky and let's just say it is hard to use outside libraries for various reasons. It can happen there is just a lengthy IT process to go through... eventually most reasonable requests will be filled (copied/mirrored internally, or binaries imported). But there is a delay.
This is all besides the point other than to say: I either need to wait a few weeks, or write my own minimal JSON library.
How hard can that be? I mean, it's just JSON. Well earlier today I was checking reddit and saw an announcement that "JSON for Modern C++ was released" (https://www.reddit.com/r/cpp/comments/p69plb/json_for_modern...). Hey cool, I can see what the library looks like and maybe rip off some of their code while I'm waiting for a "please mirror this internally" request to finish.
This library is thousands of lines long... for JSON. I'm not disparaging the author or JSON, it looks like an awesome library with great diagnostics, I'm more trying to point out that even for the SIMPLE format of JSON, a serious library is 10K+ lines. That's a hell of a lot of extra work to put on a team when writing a JSON (or whatever) library probably isn't the actual work that needs to be done.
Elm likely has a JSON library ready to use, but having your seasoned team reinventing the wheel for so many other libraries isn't a good use of dev time. I can't think of simpler libraries to write than JSON and even that is 10K lines long. Other than the insanity of nodejs and leftpad and libraries like that. If the attitude for every single library needed is "we can write that from scratch" the team is never going to get anywhere.
A json serialization (no parsing) library is not going to be 10k+ lines, and it's going to be extremely simple.
You can define a JSON AST type very simply, and then converting that to wire bytes is also quite trivial. Also simple to test via golden testing (you could even use property testing + shell out to jq to validate the json)
The answer is ditch JSON for something already supported (XML? CSV?) or homebrew a more minimal serialization format that you can implement in a couple of days.
> But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point.
> My opinion is the long-term technical & cultural benefits and opportunities pay off.
How, though? These two points contradict each other. Is using FP going to pay off with technical benefits? Or is it just going to reduce your software development efficiency?
I enjoy writing FP code and using niche frameworks like Elm for hobby projects, but I specifically avoid them for production work because I'm familiar with them.
I always hear claims that using Elm and niche languages is going to pay off in vague benefits somewhere down the road, but in practice the payoff never really arrives. I think a lot of developers pushing these niche frameworks tend to mentally dismiss the actual costs and overhead incurred by using something like Elm.
It's tempting to categorize the struggles as "learning" and therefore try to pretend it doesn't count as lost time, but at the end of the day if your team has to spend extra cycles doing extra things just to accomplish basic tasks, it's a drag on productivity.
Everything you say is optimizing for the short-term. When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps.
But if you can't afford for ANY time to not be spent directly on the business, don't do FP. Sounds like a pretty brutal way to work.
FP has _throughput_ benefits, but may come with _latency_ hiccups while your team climbs the learning curve (which may include writing libraries.)
If you have frequent deadlines (or treat 2 week sprints as deadlines), then FP won't jive..and you probably have bigger pain points in your company than PL choice lol.
> When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps.
This is the core point I was disagreeing with:
In my experience (yes, I have used Elm and I enjoy various functional languages), this payoff never comes. There's always something more that needs attention, needs another developer, needs to be refactored because we forgot a use case, and so on.
And also in my experience, by the time you've invested the years of effort required to fill in gaps in the public package ecosystem, it's time to move on to the next niche language trend. I'd rather invest our time and energy in mainstream languages that have staying power, where we're not obligated to carry large parts of the open-source ecosystem by ourselves.
Years, plural?? Maybe Elm is just way less mature, but I was on a team that shipped Haskell software with millions of users in about a year of dev time..and this included huge investments in many missing libraries..all on top of using GHCJS which required investments to the toolchain itself (Elm is definitely more mature now than GHCJS was at the time.)
But that was Haskell I guess. It's obviously not a "niche language trend" by now, so it was pretty clear it had staying power.
Definitely has paid off for me personally. My side projects move a lot faster and more stably now that I cut my teeth in production Haskell. A real free 10xer to my skills personally. And I gained the skills by getting my employer to finance my learning lmao.
> And also in my experience, by the time you've invested the years of effort required to fill in gaps in the public package ecosystem, it's time to move on to the next niche language trend.
This probably depends on the complexity of what you need to do, as well as how well you want to do it.
I've seen people writing their own packages and pieces of systems in months, to typically pretty underwhelming results. However when writing code with tests, proper documentation, getting started guides etc., then what you're saying does sound way more plausible, especially if scope creep of any sorts is also present.
Would you care to comment on what sorts of systems take years to properly develop, though? Because in my experience that could be applicable to very few software projects out there.
Various classical optimization problems are just pure functions. The sorts of things used all over the place in industry (supply chain ops for instance)
If you want real production software, Starbucks Rewards is/was powered entirely by pure Haskell code and made big bucks
Software having complex state actually makes Haskell even better than the competition. Because most state has nuanced rules about its state transitions.
Haskell definitely has more of a learning curve when it comes to dealing with state, but that curve will guide you towards a ceiling mainstream languages can't even approximate.
Many banks and hedge funds are semi famously using FP (whether that’s OCaml, Haskell, or Scala). JP Morgan has a big Haskell corner. Jane St is the company I most associate with with OCaml. Jet.com is largely built with F#.
In business domains with strict audit requirements, it’s a peace of mind thing, to know that “side effects” (aka persistence and the mutation of persisted data) are constrained to a tiny and highly testable corner of your code base.
For OSS, the examples that spring to mind for me are RabbitMQ (Erlang) and Pandoc (Haskell).
> I think FP wins out even if you have to fill ecosystem gaps.
What proof of this is there though? People have made the same claims about lots of things: FP, OOP, statically typed languages, dynamically typed languages, LISP variants, etc. The fact is, any of these solutions can work, and you can also write terrible code with any of them.
Elm's library ecosystem is a bit iffy in my experience compared to Haskell or Scala. Those two don't really have huge gaps nowadays, and they're buoyed by better FFI (Haskell w/C, Scala w/Java) than Elm's draconian JS interop.
> The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here.
Maybe in the context of the parent comment this holds true, but in my experience this is like walking on a knife's edge.
There's the very distinct possibility that you'll end up with homebrew frameworks and libraries that are overcomplicated, buggy, not commented and exceedingly hard to work with. I've seen that happen many times and it makes me consider not just whether people want to do that, not whether people have the time to do that, but even whether it's possible for them to do.
In one project people wanted all of their front end components to be custom and as a consequence spent 3x-5x longer building everything, none of their components were Googleable for someone who's been onboarded and thus people forgot how they even work after 2 weeks of not editing them and had to rediscover that later. I tried adding a component sandbox/playbook to help them provide examples, but no one was interested in doing that when they were already behind the expectations of the business. Picking an off-the-shelf framework would have saved them all of these troubles. Maybe there were actual reasons behind the choice of approaching the project this way, apart from padding their resumes, however after inquiring about those, i didn't get a convincing response.
In another case, i had to work on a custom web back end framework, which had been developed by another company, in a country the language of which i don't speak. Curiously enough, all of their code comments were in this language, there yet again was a lack of any sorts of documentation, the implementation was obtuse, slow and any simple changes to the forms took days to implement properly, even when it would take around 30 minutes in established technologies. Furthermore, the actual framework hadn't received any updates in years and therefore i fear to think what sorts of security issues it had. An off-the-shelf framework would have at least been updated and probably would have more decent documentation.
In short:
- never underestimate the ability of people who lack oversight to make things worse
- frameworks and libraries that are used by thousands of people are probably at least decent
- there's definitely also something to be said about how well tested they are and how known the bugs are
- because of the above, popular technologies seem like a pretty safe bet, as does off-the-shelf code appear to be
- of course, despite all of the above, it's perfectly okay to explore new tech stacks and write your own code, just don't half ass it
> 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.
This is an important point; I think it applies to varying degrees to any less popular language or framework. It’s a little worse with Elm because of the restrictions they’ve placed on JS interop. I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work; you'll just encounter surprises during implementation along the lines of "wow I can't be believe they don't have a library for x." On the plus side, since the work of implementing these libraries is very generic with regard to any specific application, it's easy to delegate to other employees or contractors.
I’m currently working on a large PureScript project. At various times I’ve had to implement my own base libraries and components, but in many cases I’ve just been able to wrap existing JavaScript code. Some of the key libraries I use, which were developed by other community members are wrapped JavaScript libraries. This has been a pretty powerful mitigation strategy.
In the case of PureScript, I also have the benefit of reusing a substantial amount of front end code on the server. For me, on this particular project, the benefits of using a language with advanced features has far outweighed the above mentioned costs, but I think you've got to look at each situation differently and do that evaluation.
I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work
I think you've just defined a pretty good benchmark for when it's sensible to consider a less popular choice. Are you familiar enough with it to be confident of coming out ahead by using it? Perhaps you have a backup plan like the interop you mentioned if some functionality is missing. Perhaps the tool is so much more productive in general that you are reasonably confident any extra development work to fill in the gaps will be outweighed by the overall benefits. But there should be some clear reason you think the risk is justified.
curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.
This is an area where I ventured far from the ordinary and wrote my own application framework. I'll eventually open source it and write an article about the process. In short:
I was completely sold on the Elm architecture, but I used Haskell too long to be comfortable working without typeclasses, so I went through a couple different elm-like frameworks written for PureScript. I settled on one only to later realize what (I think) people are talking about when they say "Elm doesn't compose", which is not well articulated in that statement. I take it to mean: you can never really deal with stateful components in isolation because they have to work off of a unified global data structure. I developed some new tech that makes different tradeoffs and it got me what I wanted.
I knew developing my own framework was going to add a lot of extra work:
* Writing the framework (not too bad, actually)
* Writing the reusable components and combinators (exactly what you'd expect)
By far he hardest part has been establishing patterns and best practices working with a new and different architecture, I struggled with that for a while.
I'm a strong believer in the points made in Graham's Beating the Averages (actually what brought me to HN) and in my case I'm establishing a tech stack for my current and future projects, so I believe the framework was a worthwhile investment.
I thought the idea was that you'd have layers of actions so you have a top level handler of some sort that would then dispatch a contained-within-the-primnary-action component-scoped action and then pull the new component data back into the global store.
(apologies for the lumpy phrasing, insomnia is a pain)
That may be best practice, I'm not sure. Regardless, you can imagine as a result of that style of coding, any changes to the type of your components state will require at least some changes within the component, changes to one or more of those layers of action handlers, and a change to the initial/default instance of your applications model.
I'm absolutely not an authority on Elm architecture, I just know that my experience doing stuff like forms with validation really sucked.
I'm not sure an optimal implementation of the pattern requires onerous changes but it seems like one of those things where even if I'm right about said optimal implementation, learning how to get all the details right such that you get to that state is exceedingly non-trivial and the world seems to be divided into people who've already had the relevant "aha" moments and for whom it's now Just Obvious ... and people like us, who know just enough to blow both feet off ;)
> but it’s not ideal if you’re trying to run a lean team that ships products quickly.
Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. I would prefer the quality of engineering required in knowing how to do some of these things yourselves.
Take your time. Understand what you are doing. Some of the world class technologies we all know and use daily use minimal dependencies.
And with more malicious code entering more package repositories, it might be apt advice more than ever today.
Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_.
That never happens in the real world. One always has limited time to produce a viable product. There is always some extrinsic constraint to how much time can be spent taking your time and understanding what you're doing.
Moreover, if you are operating in any commercially viable product space, you're always competing against other firms for finite market share. If it takes x years to ponder and understand how to build and ship a masterful feat of engineering, while some other company ships a "sort-of-works" product with bugs and engineering flaws in <<< x years, the other company will usually win in the marketplace.
Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days.
This is the popular wisdom but I question how universally applicable it is. We all know that having the best technology doesn't necessarily mean you win in a commercial market and we all know that being first mover can be an advantage, but those observations don't tell us what will be successful in the long term.
How often does substandard technology and technical debt become a drag on a business not long after that first move, allowing someone else to overtake because the poorly built system couldn't scale to production levels or wasn't adaptable enough for changing requirements or failed so often that the early users drifted away? How often do we see developers advocating shortcuts and showing limited understanding of basic software development or computer science ideas, only to see the product they work on being rewritten within a year or two, or the whole team shut down?
You can try to be fastest always. You can often succeed, at first, if you take enough shortcuts. But you can't sustain that pace without enough quality in your people and your code. Planning to throw each implementation away and rewrite with more resources every year or two is a very unicorn-like strategy. It reminds me of VCs whose strategy is to invest liberally, who are fully aware that most of those investments won't work out but they're hoping for one or two in each batch to become the next big hits.
Real engineering isn't done in a vacuum and its goal isn't perfection. Real engineering takes issues like costs and timescales and staffing into account and aims to find a solution that is good enough on all counts. But it still has to be good enough. Producing junk but quickly and cheaply is an effective strategy until it's not and the success of any product using that strategy comes down to little more than the luck of the draw.
I totally agree. Engineering should be the best it can be, within the constraints of the resources available.
My post was addressing the common case where an engineer seems to ignore the 'resource constraints' side of the equation altogether.
Balancing these factors is more art than science. No two projects have the same set of resource constraints, nor the same set of engineering challenges. Luck is a big factor. The solution depends heavily on the exact details of each particular case.
See also: engineers who think that engineering considerations trump all other business considerations. You need to know when it makes holistic sense to rewrite, or ship a hack. There are a lot more people at the decision-making table than just engineering.
That is certainly true but somehow I suspect under-engineering is a more frequent problem in our industry than over-engineering.
IME retrospectives rarely sound like "We hired a team of strong developers, they did a solid job, but then the business failed as a result". The kind of developers who are strong enough to do a solid job are probably also experienced enough to recognise the other considerations in play and adapt if necessary.
> Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_.
While this is obviously true, I don't think it depicts the actual decision making process that leads to messy codebases and crappy products. In my experience lack of experience and/or laziness play a big part.
A competent tech lead that's passionate about quality AND is willing to be annoying for the greater good makes an enormous difference. I'm talking multiple orders of magnitude difference.
It's the difference between spinning up a k8s cluster + service mesh vs tiny single server vps with basic failover. The former is thousands of hours of dev time across multiple disciplines while the latter a seasoned engineer can handle by themselves.
> Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days.
This is precisely why I try to interview tech leads about what they shipped rather than what they built. There are a lot of otherwise very talented developers out there who will spend years playing around in your codebase, writing beautiful code, but not actually shipping anything useful. Replacing them with shipping-focused engineers, even if they're not as technically competent, usually results in big productivity boosts.
This isn't a popular opinion among developer communities, but it's a common theme in the management forums I'm part of. It's important to have fun and budget some time for things like open-source contributions and library building, but the top priority must always be on shipping product.
> I would prefer the quality of engineering required in knowing how to do some of these things yourselves.
Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing.
Writing your own implementations of everything can be fun, but it’s not possible to compete with all of the iterations and reviews that a mainstream library collects over time.
This is a common argument i have seen devs make when evaluating building from scratch vs adoption, here's what building from scratch gives you, a leaner more understandable piece of code that does what you want and nothing more.
An open source library is necessarily generic and has to be battle tested to make sure it fulfills all use cases, while the library you write only has to cover your own needs that makes it easier to understand, extend and debug
Not to mention when the language you are using updates and you have to update the code. If the 3rd party library is no longer maintained you have to upgrade the library yourself.
It's much nicer if it's a small bit of code you wrote with only the use cases you need.
Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing.
That's true but the vast majority of what you find on NPM is not mainstream, battle-tested libraries.
Libraries that do clear that bar tend to be widely useful but that suggests generality you won't necessarily need for any single use case. A couple of good engineers might struggle to beat a well-established open source library at everything it does, but that is rarely what they are trying to achieve. They just need something that is better for their own specific needs at that time, which might be a useful and realistic target.
Often you don't need to reimplement 100% of functionality of a library but just a 1% of it. Then, a talented team can usually make that 1% higher quality just because they are not limited by the complexity and tradeoffs added by the remaining 99%.
Also many "battle-tested" libraries are not really very high quality - they all have bugs, unnecessary complexity and technical debt. Higher degree of testing they get is often offset by the higher number of feature requests, and more features means more complexity and more bugs.
And in reality I saw it many times when a niche library written by a solo developer is of a higher quality than a super popular behemoth written by hundreds of developers over 10 years.
Once you detach from "I must use a library for every thing" land, you begin to realize you don't need the overwhelming majority of them. Which results in writing cleaner, simpler, more focused code, with less of a surface area for bugs. It's a whole mindset, tbh.
This is exactly the case where you don't need a library. This is a single function (or two) and you can easily translate an existing code example into the language you're using in a few minutes and be done with it.
except for the last one, all of those should be part of the language you are using, and well thought out + researched. I guess I should have been more specific: third party dependencies.
> Often these people built their own (albeit less powerful) libraries and could work much better with them.
In my experience, if someone fails at using mainstream libraries, they will also likely fail in creating their own, at least if it is to later be used and maintained by anyone else successfully.
The problem with mainstream libraries is to grasp the mental model of their creators.
I met a bunch of developers who understood software design patterns as they are taught in the GoF book, but couldn't see them when applied in a framework/library. Often this was because the design patterns weren't used 1:1 or framework creators simply used the wrong name for a pattern.
as an example i made a firebase auth client in elm using their api and json decoders in elm. honestly i feel it's much better than the official js client for the app i was building because it's so focused, minimal and exactly suited to my app's architecture
> Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing.
It's not that simple. I realize this may be uncommon, but it's possible to work on a product that is truly worthwhile, that improves peoples' lives, and whose target users urgently need a solution to the problem you're solving. I recently developed a product that I believe meets this description (I won't plug it here). I chose Elixir for the web application. While I think that's a defensible choice, given the real-time nature of the application, I sometimes wonder if I would have been better off choosing a more mainstream language -- one with an official Stripe client library, for one thing. Any day I spent unnecessarily reimplementing something because I chose Elixir is a day that the target users couldn't benefit from my product. And, bearing that in mind, I should get back to work.
In a more mainstream language, while it may have a few Stripe client libraries but if your true use case of being real time isn't full filled then it makes no sense to choose them. A working stripe client takes at most a day to write, compared to years that can go in changing the architecture of your application
If you have enough talent that a good quality Stripe integration takes only a day to write, bending Rails or Laravel to serve websockets is not going to take more than a few days to write either. The true pain of non-standard languages is not in having to implement any specific dependency yourself but in having to reimplement a few dozen trivial-but-not-easy things yourself. It's a death by a hundred small cuts.
On the one hand u r writing a wrapper over an already well specified rest api of stripe and on the other hand u need to modify a programming language runtime to be faster and reliable for real time operations. I'm not sure these tasks are really comparable in any way.
Choosing non-popular languages is a trade off yes but not as much as people think especially if you have a good team willing to learn them.
There are also benefits apart from technical ones like better job retention and attracting finer talent without having to filter hundreds of resumes. I will say if your business is made around hiring and making anyone work of the shelf then it's a bad idea.
I've worked on, and am working on projects that are dying because the libraries that were added are now out of date.
It gets really hard to maintain after 10 - 15 years. I wish we had rolled our own libraries for some of the simpler functions. Even in PHP this would have made life so much better.
> 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.
I dunno, having seen both sides, there are pros and cons to each.
Teams that reach for libs quickly often think in terms of libraries instead of solutions (one recent example was some folks who were asking for my advice on some over-engineered client-side PDF generation thing, and me suggesting `window.print()` as a solution, considering this was for an internal tool and you effectively want print stylesheets anyways), and often use them as crutches due to a self-fulfilling cycle of "I don't know how to do X, let's use a library so I never need to find out" (and then pulling in a huge lib to do the job of a literal one-liner regex - `uuid.validate()`, looking at you). In my experience, they also often end up buried by their own complexity due to gluing too many things together. But at the same time, it's hard to argue with the ease with which one can plop a modal dialog or a calendar or a collapsible table in a React app.
I find that teams working with more exotic technologies tend to be more creative with solutions (e.g. "oh there's no zoomable map UI lib bindings, so let's ask ourselves, do we really need a map library for that contact us page or is a static jpg good enough?") and a have a deeper appreciation for how hard things are to implement. But conversely, UX can suffer from too much "creativity". For example, if care is not taken w/ accessibility concerns for some UI element. Or, as you said, things just take longer to ship because people need to reinvent wheels.
From the opening section of the blog post, I wondered why an incremental move to TypeScript wouldn’t have worked for them. The rest seems to be all about Elm (I haven’t read it thoroughly), but I feel there’s a disconnect between the problem they started with and their choice to dive into a wholly new ecosystem.
edit: Ah, hold on; I just got to where they comment on this. “TypeScript, which adds optional static typing to JavaScript and is probably one of the best things to happen to JavaScript, can partially mitigate the issues with the JavaScript dynamic type system. But being a superset of JavaScript it needs to compromise on elegance and simplicity. It also has several ‘blind spots.’” etc. I don’t know that I’m 100% convinced.
To play Devil's (Elm's?) Advocate here: sometimes I wonder if the TypeScript promise of incrementally adding types to an existing JS code base is wishful thinking.
I'm at a company that's transitioning to TypeScript, and the reality is that you can't just flip a switch and have a well-typed codebase: if we just turn `strict` on, `tsc` gives us thousands and thousands of errors. And as we've gone through trying to annotate things, it's clear that in order to get various components to a state where they're properly type-safe, we'll need to almost completely rewrite them.
Compared to Rakuten, our codebase isn't even that huge or legacy - it's often very poorly written, but it's less than 50K lines and less than a couple of years old. No doubt the situation for Rakuten would be even worse; I'm sure huge swaths of their code would need to be trashed anyway.
If TypeScript is ultimately going to force you to rewrite - and still leave you with a less-robust solution - I could see why starting with a clean-slate with Elm would be appealing.
TypeScript has a slow compiler and horrendous error messages (especially compared to the Elm). Plus it is far away from the no runtime exception guarantees that Elm offers by design.
Also TS is just part of a potential solution while Elm comes with all batteries included. You still have to set up your code formater, liner, decide on a framework, state management library and so on and so on. With Elm, you just use elm-format. No arguing about code style, not arguing about how structure your code. There is only way to do it. It is not only a language but a framework. You get everything you need out need out of the box.
If you use something like nextjs and strict compiler options for TS a lot of these concerns go away.
> You get everything you need out need out of the box.
This is specious. There's lots of comments about how you don't get everything out of the box and for the parts that are missing it's a pain. Perhaps your particular use cases are covered, that's great.
> 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.
Is this your experience writing Elm apps in production? I am writing large Elm apps in production and I'm having very different experience to what you just described.
Elm is build on top of solid foundations, and has a good standard library unlike js so it's much easier to reinvent things as you say.
One of the core ways to ship products quickly is to ensure you don't break things often, and elm lets u do that provided one learns it well enough
Elm is awesome, its compiler is awesome, but its ecosystem is kinda stalling, isn't it?
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.
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.
As I understand it, there was a rift in the community over the leadership's tone in messaging and communication. Some Developers also felt like they could not contribute in a meaningful way or have constructive discussion with maintainers.
See posts like these for more details and comments:
Honestly I think the main reason for this perception is that people in the Elm community have gotten increasingly tired of correcting inaccuracies people like to post about Elm on Hacker News.
I spent a bunch of time doing that in the past, and eventually stopped because I felt like Sisyphus. The same people would crop up on the next thread repeating the same things anyway. Of course if the claims go unchallenged, it leads to the perception that they're accurate...but that doesn't make engaging with them any more enjoyable a way to spend one's free time.
If you want to check the health of the Elm community, visit Elm Slack and ask in the #beginners channel how people feel about it. It takes about the same amount of time as posting a HN comment, but it gives a very different perspective than the one you'd get if your main source of Elm information was Hacker News comments! :)
Speaking as someone who liked Elm for a while, then abandoned it, I will say that the biggest problem with the language is absolutely its leadership. Development moves at an absolutely glacial pace and basically takes place with no transparency at all. I would argue that it's more like a "source available" project than an "open source" one since the core dev team is so exclusionary. Most planning takes place inside Evan's head, leaving others to just speculate as to what's going to happen to the language.
On top of this, the community is run like a dictatorship. Dissent is silenced and banned, and faux positivity is spread far and wide. I got sick of it and was banned from the Elm subreddit after I expressed my frustration. That's pretty much when I gave up on the language, years ago, on version 0.18 (fwiw, they're on version 0.19 now, that's how slow updates are)
This is an example of the type of post I was referring to being tired of correcting.
I don't use Reddit anymore, but if memory serves there have been about 5 people total banned from the aforementioned Elm subreddit, which is fewer than 1 ban per year it's existed.
I invite anyone to evalute the accuracy of "Dissent is silenced and banned" with that data point in mind, and to evaluate the accuracy of the other above claims accordingly.
FWIW, I have the same experience as the parent poster. I used to love Elm, evangelized the architecture, wanted to write Elm professionally. I was constantly bumping into things that were not finished or working, but didn’t really mind. But I also often encountered cases where the leadership team was saying “we don’t want this discussion here, thank you very much”, even if the discussion was perfectly legitimate, friendly, technical and related to some sorely needed feature or bugfix. I constantly felt unwelcome, like I was trespassing on someone’s lawn. I didn’t want to base my work on that. Eventually I just shrugged and left.
Totally fair! I'm sorry to hear you had that experience, although I hope maybe you'll someday consider giving it another chance in the future. :)
My personal experience has been different, but I upvoted this because I really appreciated that you shared your own experience without overgeneralizing it.
Interesting food for thought. I bought your book awhile back and was 2 chapters in before reading about the aforementioned "Dissent is silenced and banned" issues which led me to abandon continuing at the time. Maybe I'll jump back into it.
I've not heard of such misinformation being spread about other languages. Id love to hear your side on why Elm itself seems to attract such ire if its inaccurate.
I think there's more than one factor, but the biggest one comes down to setting expectations, especially in the early days.
Elm does a lot of things differently than other languages, and while I think that overall those differences have been instrumental to its success, especially early on it sometimes wasn't clearly enough communicated when "this is temporarily different because it's a WIP; you can expect it to be more like what you're used to in the future" versus "this is different by design, so expect it to stay different or even to become more different."
Examples of this include typeclasses (a lot of people coming to Elm from a Haskell background assumed Elm would add them as a matter of course), JS interop (by design, it's not a traditional FFI, although there was an unintended backdoor that kind of worked like one; when that backdoor was finally removed, after much communication that in retrospect should have happened at the outset, some of those who had been relying on it were understandably upset), how the project is run (more like Clojure than like JavaScript), and what the release schedule looks like (batching large projects rather than more frequent smaller releases).
I think things are a lot clearer today, but for some it's unfortunately too late to make a difference.
One thing is that it wasn’t communicated that well, but other (and that’s what made me feel really uncomfortable) is that it felt like „This feature is not allowed anymore - except for some dudes, they’re cool enough and can use it” (e.g. native modules, operators). Either keep or drop feature
Kernel code and custom operators are only allowed under elm/ and elm-explorations/, so only 7 core packages can use them. The core developers cannot use those features in projects like everyone else.
And who can contribute to `elm` and `elm-explorations`? The 7 cool dudes.
The Elm contributor circle is a clique that you literally have to be a strong contact with one of the contributors to get into it. It goes against everything open source stands for.
> It goes against everything open source stands for
Sorry, that's not correct. It goes against your opinion of what open source should stands for, and many projects run in a way where everyone can contribute. But, it's not the only way.
The license determines how the code comes, that's the only rule. There's no rules about how a community must run. It's for the code creator (maintainer) to determine how or even IF they want a community of contributors. There's lots of ways of doing open source!
And saying it's not "open source' if you don't do X outside the license is just a No true Scotsman.
The problem is there are some reasonable features that cannot be implemented with the current ports system that _should_ fit into the expected design. Specifically, I feel you should be able to replicate the `Http` module using ports or some other available system. However, you cannot properly dispatch a task and then tie together the result with a curried `Msg`, as you might expect or hope [unless you store a complex state object in your model]. These types of issues are the frustrations that, I believe, cause some discontent in the community. I feel more people understand why you should not, per se, make random FFI calls in the middle of pure code (e.g. since it would break dead code elimination and require evaluation order guarantees), but other restrictions seem arbitrary.
The thing I found unsettling wasn’t that something was disabled (fair design decission), but the mindset that considers some features harmful , but is happy enough to use it in its own „special case projects/packages”. It doesn’t really matter for how many packages its available, since it can be changed on a whim. I can only speak for myself, but I found it unfair and patronizing
I don't think that's fair. If elm ever wants to replace js it only needs to rewrite the kernel modules, they govern. Otherwise the whole ecosystem would break in that case and yes, that would be a harmful feature.
I didn’t mean locking features, especially native modules - didn’t write a single one, so personally I won’t miss it. I meant „some repos are more equal then other” mindset. It’s clearer in case of custom operators - they are considered confusing, unless you mean parsing and by parsing you mean elm/json or elm/url, then it’s cool.
By all means, I’m not saying those are crucial features or that they don’t have right to do whatever they want with their language. They can and they do. I just find this kind of atitude and reasoning patronizing.
I'm a fan of Elm, and I'm using it in production, but I think this is very much a case of using some flaws in the way people see Elm to ignore some correct criticism of it.
The community absolutely suffers whenever anyone comes across one of these issues where there just isn't a solution, and more than that, no communication at all. It implies the project is dead.
I accept that Elm is functionally just stalled and won't see any changes until some arbitrary point in the future, I can live with that. I don't think the project communicates it's state and direction well though, and that leads people to disappointment and the posts you see.
That's a good point and maybe I shouldn't have re-posted these stories in my comment as I have not personally witnessed this behavior. I just know that when I started learning Elm initially (Nice Frontend master courses btw) I ran into this sentiment a good bit on reddit and hackernews so thought there was probably something to it if it was being echoed by so many.
I'll add a reply to my comment to make it clear this is hearsay and doesn't necessarily reflect the truth.
After considering the way I phrased this comment above, I want to clarify that I never personally observed or witnessed this kind of behavior myself. My own dealings in the Elm community have been almost entirely positive. I had heard a lot of these criticisms from comments on hacker news or reddit and realize now they mostly resemble hearsay or people like myself repeating what they heard from others resulting in a sort of echo chamber. I apologize for adding to that echo chamber.
Also Mint at https://mint-lang.com, which is heavily inspired by Elm (and better, IMO). The open source aspect is also the opposite of Elm - the community is very friendly, the developers are responsive and positive, and PRs are encouraged.
F# solves many of these problems with it's ability to pull in C# libraries. When looking for a functional language to learn I settled on F# and am loving it so far. I'm not sure if I'd ever use it in production as it is still very niche.
What Evan is doing with Elm is awesome, he has a small closed set of features to make a language that is aimed at doing one thing. He has very tight control to make sure there is zero cruft in the language. It's an amazing project. The cost is that it's very hard for outsiders to have any input into the language. So the ecosystem will never take off.
I would argue the opposite! The elm slack is very active with people who frequently contribute to the ecosystem. I don't think the "a lot of libraries aren't updated to the last lang version" is true, the vast majority are.
Debugging elm-JS interactions is not really a problem when using the standard interop methods of ports and webcomponents. It's just not something that comes up often.
Source: have been writing elm professionally for the last 2 and a half years.
Disclaimer: I'm just describing an annoying technical problem, it's not a blocker for the use of Elm. Elm _is_ great :)
I have been using Elm for a kinda-simple project on my work: dashboard for microservices, deployment configs, nodes, etc.
One of the biggest time-drains was debugging JS-Elm port interactions, looking whether there is a mismatch in types.
Cuz the error looks like this:
Elm eventreceiver failed: Error: Trying to send an
unexpected type of value through port `collectPeerInfo`:
[object Object]
I know of no way of even looking into that `[object Object]`. Simply logging its fields would already be a relief, lest telling what field/type caused the error.
I'm not an Elm veteran like a lot of the folks here, but I think an aspect of Elm is that a lot of the traditional ways that people expand ecosystems are discouraged by Elm's approach. For instance, components are hard to do in Elm and are discouraged in the documentation[1].
So my own personal Elm projects have involved a lot of reading other code and often copying and modifying open source code, but it's hard to wholesale import components in the way that JavaScript and other languages do it. My experience with the language is that it is very easy to do what I want in it, but it seems more difficult to share that as an open source contribution in Elm than in similar languages.
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.
His experience working at a teaching company made his book very well structured for new comers.
I have fond memories of using the pine email client. It was so fast. I know mutt is another one, supposedly, but by the time I was considering switching, I had exclusively moved to web mail.
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.
I had a similar line of thought in the beginning too. If you google Elm these issues pop up. However after some time posts about it lead back a very limited set of occasions and block posts. Which are either criticizing the leadership style or a few events. I view the leadership as a trade off which ensures a high level and guarantees for the core at the cost of a high barrier. For the fee events, I think we are all humans and make mistakes and usually it is a miss communication between two parts more then a real issue.
> We had global variables everywhere, and debugging was a nightmare.
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.
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.
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.
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.
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.
The big question is whether it will be for long enough to be worth the investment.
esbuild and TS are a good step you can take incrementally as you move away from webpack/babel. Still the lesser of some evils, but less evil is better.
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.).
Elm-UI made working with styling much easier for me and was the main reason I gave Elm a try.
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.
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.
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.
Since then, I've always avoided going away from the mainstream toolset.
> Wouldn't it be difficult to find other developers that are experienced using Elm?
Yes, however:
- Elm has a very small surface area (you can read through the guide [0] in a weekend)
- There are many folks who love functional programming && are willing to learn Elm
So, given those two facts, the lack of Elm developers compared to other "markets" is not a big issue.
For me, personally, the only risk with Elm is its incredibly opaque development. It's led by Elm's BDFL and a few other folks and it's almost as though they go out of their way to make Elm hard to adopt for outsiders.
For example, all you have to do is change elm's version to 1.0.0 to signal to outsiders that, yes .. Elm is and has been production ready for quite a while now (years?). Instead "insiders" will reason and rant about how 0.19.1 is fine.
I appreciate that I am biased because of my background, but I've met precisely one person who's used Elm while just about every dev I know has worked with WordPress at some point. For most enterprises I work with, 10 years in production is about close as they're willing to get to the bleeding edge. They don't really care about code quality or features. They want to be safe, secure and future-proof for as low a price as possible.
That said, I know very little about Elm and would love to understand more about what it offers that's so exciting. I skim-read the article, will read in more detail later.
My bias is the opposite, probably because I've worked at an Elm shop. But I know zero people with wordpress experience, in my circles I'm the only one I know of with professional php experience at all. But I need more than my hands to count all elm programmers I know.
FWIW our experience has been:
- finding devs with experience is hard
- finding great devs who want to use interesting tooling is easy
In the end, we hire interesting, curious devs, and ask them to use tooling (elm) that has a pretty shallow learning curve.
I think bootstrapping a project in Elm without any experience on the team could be tough, but once you have some expertise, the seeds you plant in yield abundant fruit. At NoRedInk it's been a great success -- especially with regards to "finding other developers".
I think when something is built by several people, catering to outside interests, you end up with more churn, bloat, inconsistency, instability, etc. But your specific need has a better chance if being addressed. When something (like Elm) is built in a silo, you end up with less churn, bloat, instability, inconsistency. We forget how we got these nice things, and when we want something NOW we get cranky about the development model. So, as a developer with 20+ years of experience I can say that EVERYTHING (tools, languages, paradigms) is shitty in some ways, and I vastly prefer the ways that Elm and ecosystem are shitty.
Having worked with "the main dev" I can't say I share this view. It has been very nice to be able to pick his brain and hear his thoughts. It can be exhausting, when you want to improve things now, but come up with a better long term plan. I guess that's a language designer thing.
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.
Even though Rakuten is a Japanese company and all this happened in Japan, the department where it happened is almost entirely not Japanese, so the "elevator sales pitch" has nothing to do with Japan. There were already several developers that were on board with Functional Programming, this is what helped a lot.
As a matter of Japan, there is a very lively Elm community and I know few companies that use Elm in production.
Also, I heard that the Japanese academic world is active in Functional Programming research
I had a problem with perf optimization on Html.Lazy long time ago that I can't solved before I moved on.
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.
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.
I could use Elm as it is today for at least a decade without updates, since it's very stable. Anyway, I am sure there are very competent people from the core devs or from the community that could make a new leadership if that happened.
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.
I had the opposite experience with my last job interview. I didn't know any Ember but I did know Elm (and other languages and frameworks). My enthusiasm about Elm absolutely contributed to my being hired and my lack of Ember knowledge didn't hurt me. This was what the hiring manager told me.
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.
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 have coworkers using Rails for the back end of their Elm app. I think NoRedInk is using some Rails and some Haskell. I've have a friend who uses Python for his back ends. Also heard that some people really like using F#, as well as Node.
> They don’t hinder anyone from forking and removing this limitation, allowing any package author to run native code on your machine.
That has arisen a few times here. Yes, they actually do actively discourage forking (to the point of threatening “excommunication” from the community).
Just to correct this: for as long as I can remember, Evan's stance has been "feel free to fork Elm, just please don't call your fork Elm, since that would confuse people."
There have been a couple of forks with different names, and nobody's been "excommunicated" or whatever. The forks haven't gotten much traction, but they're probably still out there.
My word choice certainly could have been better (I was upset, and it showed), but to quote what I said there anyway: "If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals?" - in substance, this is consistent with what I said above: it's totally encouraged if anyone wants to go in a different direction from Elm's design, just please don't call it Elm.
As it turned out, this is exactly what the OP in that thread did - he created https://www.mint-lang.com - which I think is a very positive development indeed!
That's not true, lamdera is a fork and has it's own channel inside elm slack. Terezka (that is from core team) already said that if part of the community wants to fork Elm, that would be ok.
• Your company has a patch allowing installing binary code from other sources
• When you want to update to a new version of Elm, do git rebase and reapply the patch.
• Now your source tree and history is identical to upstream, plus one commit
Most likely the code restricting installing binaries from only one source isn’t changing a lot, so patch conflicts should not be too much of a hinderance
It can be as simple as having a patch and just updating by reapplying the patch over the master branch. You’d have to build from source of course, rather than downloading someone else’s binaries.
mkose@casper:~/Desktop$ ./elm repl
---- Elm 0.19.1 -----------------------------------------
> Basics.modBy 0 3
Error: Cannot perform mod 0. Division by zero error.
I believe there are a couple of things in the standard library which should have returned a Maybe (or even better taken a NonZero as an argument). The community Extra libraries tend to offer safe versions of these cases, so it's easy to avoid if you know about it.
Another gotcha that will give a runtime error is the stack overflow if you have too many recursions in a function. You can get around it by using builtins like maps and folds, or refactoring for tail-calls.
Since recursion is often taught to FP beginners as the go-to replacement for loops without explaining TCO, I think many users are surprised by this early on, and with just the compiler they would otherwise have no warning of this without knowing how and when to test for it.
I believe Elm-review is coming out with a method to warn about these cases, so it will be detectable with standard tools.
On the whole, though, these are the few avoidable edge cases, and the promise does hold the rest of the time.
My team is working on a very large Elm codebase for over 3 years now, we got a runtime error in production only once (stack overflow when parsing an unusually large file, made it tail call optimized to get rid of it).
I will consider it sticking to it's promise of no runtime errors.
Obviously Microsoft is a huge company so they use all of the languages, but I find it surprising given the amount of investment they've made into Typescript.
It's not surprising for a large company. For example, Google uses C++, Rust and Go on Fuchsia. They have Angular with Typescript and Angular with Dart. Big companies are what they are, an association of a lot of people that are all different.
> Our JavaScript application had global variables everywhere, and debugging was a nightmare
Point #3 in their list of cons is especially important for anyone considering Elm:
> 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.
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.
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.
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.