- It's very easy to find JS programmers. There's a _lot_ of them. But programmers proficient with pure functional programming languages are harder to come by.
- JS is natively supported by browsers and it is pretty much guaranteed that the code you write is going to work for ever. Elm on the other side, who knows? It might lose steam and go into support mode, or drop support, or maybe they introduce breaking changes in a future version. JS is a much safer bet.
- Writing Elm does not guarantee a good polished product. You can write bad software in good languages and vice-versa.
That being said, it's only a risk. Maybe your team is more comfortable with Elm and they get more productive. Maybe the language design makes easier writing code with less defects. Maybe it actually gives you an edge.
It is hard to say if Elm brings value to your business. It most likely depends on what kind of a business that is (web agency than cranks 3 visit-card websites a day? Or is it one developing a complex app?)
In any case, managers get very nervous about languages that are not mainstream. And they do have good reasons.
> But programmers proficient with pure functional programming languages are harder to come by.
I used to get a similar argument when pushing Python over Java, and my counterargument is the same: I wouldn't hire a JS programmer who was afraid or unwilling or unable to learn Elm. I would bet that any normal person smart enough to solve Sudoku problems could learn Elm, I wouldn't make that bet with JS/CSS/HTML.
> It might lose steam and go into support mode, or drop support, or maybe they introduce breaking changes in a future version. JS is a much safer bet.
But who is using just JS these days? Frameworks and transpiling are the order of the day, no? Same argument applies to them. And JS is a moving target too. As for "breaking changes", well, it is just version 0.19 so far. Once they hit 1.0 I would bet on Elm being more stable than JS+Whatever.
Weigh this against zero front end bugs. That's a staggering (if hard-to-quantify) cost savings.
> Writing Elm does not guarantee a good polished product. You can write bad software in good languages and vice-versa.
Yeah but that's not an argument in favor or against any particular language, and in the specific case of JS vs Elm I think it's clear Elm wins. If your developers are truly crap then, yeah, Elm won't save them. But then you also have bigger problems than what tech stack to use, eh?
If you started with Elm then JS/CSS/HTML+Frameworks|Transpiled-langs et. al. would, I imagine, seem like a massive amount of stuff to learn, eh?
I think the Elm-first programmer would be right to ask, "What's the payoff? What awesome new powers do I gain, impossible with Elm, as reward for all this blood sweat and tears?"
(Elm is wildly easier to debug than the status quo stuff. The compiler is awesome for that. So the hypothetical Elm-first programmer has to learn not just the status quo stack but also how to debug it!)
So, again, it seems to me like it behooves the cost-conscious programmer to carefully examine the cost/benefit ratio of non-Elm-implementable features in light of the availability of Elm.
I am presupposing, like I said above, that you can take pretty much any member of the Sudoku-solving public and train them up in Elm in a few weeks. Even paying them at parity with JS devs, the time and effort savings of Elm vs. JS et. al. would be substantial, I believe.
(Personally, I would want at least two or three people on the team who knew what was going on under the hood.)
So you're ok with an elm programmer not willing to learn JS, but not ok with the reverse. That just sounds like good old fashioned tribalism; and personally I'd never hire a tribal programmer, whether that tribalism is about a great language, or the latest coolest JS framework.
What I'd look for is an open, sharp mind. Willing and happy to learn new things and paradigms, even those that go beyond their comfort zones, whether it is JS, Elm or Java. Someone to whom programming languages, frameworks and libraries are just TOOLS to accomplish a certain goal, and not part of their identity.
I'm not sure where you're coming from, but when I'm looking for a job, I pay attention to the tools that companies have picked, and if I get the chance to ask them, why. A company that picks good tools is a lot more attractive to me. All other thigns being equal, if I had to choose between a company that used JS, and one that used JS and one that used Elm, I would prefer the Elm one. I've never written a line of Elm before.
I'm willing and happy to learn new tools. I'm happy with hiking in flip-flops if that's all that's available, but I'd certainly choose hiking boots if given the choice. I suspect most "good" developers have the same attitude.
> So you're ok with an elm programmer not willing to learn JS, but not ok with the reverse.
That's not exactly the spirit of what I meant, but, yes.
> That just sounds like good old fashioned tribalism
I can't really control what it sounds like to you, can I?
My whole point is that Elm is (or one day soon will be) much superior to JS et. al. This is a cost/benefit analysis, not tribalism. (I'm not an Elm fanboy. I don't actually like it that much, in fact.)
It's puzzling that more JS programmers don't adopt Elm.
It's reasonable for an Elm developer to ignore JS to the extent possible.
That's the point of Elm, eh?
> What I'd look for is an open, sharp mind. Willing and happy to learn new things and paradigms, even those that go beyond their comfort zones, whether it is JS, Elm or Java. Someone to whom programming languages, frameworks and libraries are just TOOLS to accomplish a certain goal, and not part of their identity.
Sure! Me too. But now I can make the scarcity argument, no? And you've got to pay those folks well, eh?
I'm postulating that you can take normal people (smart enough to solve Sudoku) and have them productive in Elm within a month or so. You probably would not have to pay them as much as an equivalently-productive JS programmer, and certainly not as much as the kind of person you described.
Again, I'm talking about the business value of a given software production tool not the entertainment value or the personal-growth value for the devs.
In all fairness the functional paradigm isnt exactly all too hard to grasp (when it comes to what you need to be effective at least, you dont need to understand what a monad is, I still dont!). I started learning Clojure completely cold going through Exercism and it took me maybe 2 weeks of doing a problem a day (not much work at all) before I felt like I started to "get" FP. In fact, I would say it's even easier in a lot of cases because FP is a much "purer" skill set- any imperative language still uses functions, and arrays, and switch statements, and overloading. In FP, you have all of those familiar concepts (just presented in a possibly different way) but you dont need to worry about how classes work at all, or even loops in some cases!
What most people do not realize, is JavaScript was designed as a functional language, with a C-like syntax. When I talk about learning proper JS, I mean getting back to its functional roots, because that where it really shines.
If you're open to remote hiring, I highly doubt it, I dont know much about elm (except that the people using it really like it) but the argument is one I've heard before with elixir. Hang out in the elixir slack or a FP discord for a day/week and you'll notice a massive amount of people taking about how much they like the language and wish there was somewhere hiring that used it. The people are definately willing.
Kolme's comment is a very good reason, as someone who picked a non-standard frontend language I'll add my 2 cetns. I'm working on a project that went from javascript to reasonML when we felt the lack of a really strong type system was making managing the complexity of our app (which is unusually complicated) unmanageable.
When I was evaluating Elm it was my favorite choice out of all the various strongly typed flavors of javascript, clean syntax, good abstractions, and very strong runtime guarantees. The thing that made us reject it, and will keep me from recommending it to others, was the change made, I believe in version 0.15 which, as I understand it, restricted FFIs so that only core maintainers could write them. I know several companies have frozen their version of Elm due to the change.
Particularly when working with external packages written in JS, not having an escape hatch is a huge vulnerability. We've already hit one instance since using Reason where if we could not drop down into pure JS we would have had to either rewrite one of our main dependencies or at least hard-fork it and re-write substantial portions of the application, a multi-month (maybe multi-year) slowdown that would have killed the project.
At this point I would not recommend Elm to anyone who is not willing to rewrite any pure javascript module they might want to use (this may fit the bill at some very large corporations).
> But what happens when you need to do something in JavaScript? Maybe there is a JavaScript library you absolutely need? Maybe you want to embed Elm in an existing JavaScript application? Etc. This chapter will outline all the available options: flags, ports, and custom elements.
Ports have always existed. The change was to stop people writing "effect modules" which were the unsafe version of this where you could run arbitrary JS.
The upside to this is that because ports work by message passing, it means that all the language's guarantees can be held even when using them, and packages can't do anything without you knowing about it.
The downside is it is a lot more verbose and awkward. In my opinion, it also makes community contribution to the standard library a lot harder.
Those languages are also subjectively much harder to learn. I liked Elm and really tried to learn it on the side, but even after a week or so of spending time with it I had a hard time wrapping my head around how to simple DOM updates.
Compared to that, React took me a day to get comfortable with. There is an argument to be made though, that behind that day there's potentially all those years of working with imperative languages which just isn't there for Elm.
In my situation we specifically avoided Elm due to the instability of their documentation. v0.18 docs were cleared off of their servers and replaced by v0.19, with unannounced breaking changes.
The (B?)DFL pushes that even though it's not hit a 1.x version that it's production ready and stable, in our experience that isn't the case :(
How does "use Elm" fixes the problems mentioned in the article? Elm is compiled to JS after all and has to be downloaded/parsed, which is what the article is talking about regarding cost.
After playing around with elixir and Phoenix, elm is the last point of the trident I've been meaning to touch. now if only I could find somewhere near me that uses any of those...
- It's very easy to find JS programmers. There's a _lot_ of them. But programmers proficient with pure functional programming languages are harder to come by.
- JS is natively supported by browsers and it is pretty much guaranteed that the code you write is going to work for ever. Elm on the other side, who knows? It might lose steam and go into support mode, or drop support, or maybe they introduce breaking changes in a future version. JS is a much safer bet.
- Writing Elm does not guarantee a good polished product. You can write bad software in good languages and vice-versa.
That being said, it's only a risk. Maybe your team is more comfortable with Elm and they get more productive. Maybe the language design makes easier writing code with less defects. Maybe it actually gives you an edge.
It is hard to say if Elm brings value to your business. It most likely depends on what kind of a business that is (web agency than cranks 3 visit-card websites a day? Or is it one developing a complex app?)
In any case, managers get very nervous about languages that are not mainstream. And they do have good reasons.