Background:
Started my corporate development career in the mid 80’s with COBOL on the mainframe. I participated in the evolution of computing: batch/terminal applications, mini-computers, workstations, client-server, n-tier, Object-Oriented, then the Internet. I was a mediocre developer at best, and I took a non-technical career path into business analysis and project management. I still liked to maintain my hand in coding, just for fun.
How you heard about Elm:
About three years ago, when I semi-retired, I wanted to build a platform for my new career as an author. I started evaluating web technology (I had a basic understanding of web-servers, HTML, CSS, etc). I evaluated the trade-offs between application platforms and frameworks and determined that, for my goals, I needed more control of the end-product.
That led me to evaluate the JS frameworks (Vue, React, etc). After an extensive bit of research, I started an evaluation project using React. Somewhere along the way, a Google search turned up Elm.
Moment you were convinced:
My corporate spidey-senses told me that if Elm could do what it promised, it was the way to go (as a higher-level application implementation, it avoided all the foot guns buried in JS).
As a corporate developer, I was used to good documentation; give me the syntax of a language and what the constraints are and I can figure it out. Elm’s documentation is nowhere near corporate standard (the “formal” documentation still doesn’t even have a specific list of keywords for the language, nor does it even link one of the many cheat-sheets others have developed).
So in that environment, the only way to learn is to google to find tutorials and working code. My first breakthrough was finding “Beginning Elm” which helped me understand the syntax and basic functional programming. Along the way, Richard’s implementation of the RealWorld SPA was the piece of code that convinced me useful applications could be built. Once I found the elm package library (elm-ui, elm-spa, elm-graphql), that was when I committed to Elm and to really learning the functional paradigm.
Commentary
To your specific question Ryan, I didn’t come from the front-end world, where one would presumably already know HTML, CSS, and JS. The packages allowed me to develop a database connected application without really knowing those technologies.
I think corporate developers, that are tasked with delivering web applications, would pick Elm over the other JS frameworks if they could evaluate it more easily. There are so many compelling engineering reasons to choose Elm over the other options. Currently it is a lot of work for someone to enter the Elm ecosystem cold turkey - they need to work very hard to learn and understand it (and learning in a way that is different for corporate developers).
Another big hurdle is the Functional Programming paradigm shift. I still struggle - there is nothing one can do to help anyone - it’s just working on it until the eureka moment.
The big risk, from a corporate perspective, is the roadmap for Elm’s evolution. The current stewardship will give pause to a company that is looking for a technology that will meet their long-term development goals. There is too much uncertainty - kudos to the community members that are addressing that issue.
Then AngularJS.
I actually considered quitting my job to program in Elm, but instead convinced everyone to use Elm at work.
Elm and I’ve been trying to convince others to use it with no real success.