Heads up! This post has some claims that lack citations. The power dynamic here is such that I'd rather be dismissed to generally no effect than to put the heat on some developers without a platform who write internet posts that I think are wrong.
Anyway, let me frame up this discussion a bit:
I am a member of the Elm core team. I made a significant outlay of personal effort to reach this level of contribution, so I think it’s reasonable to claim that I understand what it’s like to care about a project and desire for it to succeed.
A lot of the online lobbying directed at us for changes in prioritization is based on the idea that Elm is not successful unless its community is growing faster now than it was some amount of time ago. This commentary rarely explains how the poster personally defines “success” for Elm, so I have to assume that adoption and success are one and the same in their mind.
For Elm, we reject the idea that adoption is success or even a very good reflection of success. Elm seeks to be an exceptionally good programming language and platform for building front-end web applications. It is successful to the degree that it does that. Major, concrete steps toward this goal will not always result in community growth, especially under Elm's long release cycle. That is okay!
As a final thought, here is an illustrative example of my confusion: if we grant that adoption and success are related, then what does it mean to be the most popular and thus most successful project? If Elm were the most-used front-end technology, what prize would the Elm community win?
So. What do y'all think is the cause of this apparent linkage in the mind of The Developer?
I think that if I can better understand why people feel this way then I will be better at explaining how to measure Elm's success to the Elm community.
If you would like to share your thoughts anonymously you can email me at hello@lukewestby.com.
Latest comments (16)
I actually think this is (at least partly) because people have a limited amount of time and cannot consider all options exhaustively or even at a surface level. So what comes into play then is a cognitive bias called “social proof”.
From Wikipedia: When a person is in a situation where they are unsure of the correct way to behave, they will often look to others for clues concerning the correct behavior. When "we conform because we believe that others' interpretation of an ambiguous situation is more accurate than ours and will help us choose an appropriate course of action"
.. and I definitely think choosing a frontend-technology is an ambiguous situation 😊
Luke - It's a wonderful question you are posing here :)
I think the developer world is intimately linked to the Silicon Valley Growth Mentality where success is defined by companies growing hugely and picking up significant market share. It's like Miracle Grow making plants grow really quickly. It's super exciting and feels compelling, as if the plant will grow forever. Spectacles are really exciting. This metric feels more sure-fire than the alternative, namely that progress in everything is slow and there are no silver bullets.
I think an emphasis on long-term thinking is a nice way to frame the conversation. I like to think of Elm as the language that is geared towards maintenance and unsexy refactorings. Stability shines best as time goes by.
Don't know the discussion/drama/issue that caused this, not an Elm user (yet) BUT I do recognize a lack of separation of concerns when I see it.
You cannot create an equivalency between technical success and commercial success (IE: popularity). Many good engineering teams go down that path, never to return.
Technical success is the result of an engineering team making quality and sustainability a central value, and not bowing to pressure to release faster or do more unless they are confident it brings value to customers and doesn't add technical debt. It's a beautiful thing to be a part of.
Commercial success is the result of marketing, to include direct marketing and word of mouth (and probably a million other marketing terms that I'm not familiar with because I'm a developer and I hate those marketing guys!) When teams start to reach for commercial success it's when they are accused of 'selling out' or 'going mainstream' because many times users see them making compromises in quality, or adding features that the core user doesn't need, because these changes will quickly drive adoption from an untapped segment of new users.
You CAN have both technical and commercial success, but one does not require the other. It's striking a balance between the two.
As it relates to things like stars on github or number of downloads from npm or whatever 'popularity' metric you're using, remember that developers are herd animals just like any other human. If they see that people are using something, and they KEEP using it after initial contact, then they will think it could be a fit for them too.
This is how JQuery became a thing, how React and Angular became popular and how Python, TypeScript and a ton of others became popular. It was marketing, not necessarily technical excellence. Some of those frameworks and languages are better written than others, but the thing that made them POPULAR, was a sustained and growing user-base that drew in other users. Users may have made points about the technical excellence involved, but at the end of the day, marketing (either direct or through word of mouth) was what got thousands/millions of people using those things, not technical excellence.
If technical excellence is a core tenet of the Elm team, then you seem to have an 'If you build it, they will come' marketing strategy. What you may be running into is that other people would rather that you had a direct marketing strategy that pushed people into adoption. You have to address THAT issue, not a technical excellence vs popularity issue. If you're talking in 2 different languages, no one will ever be happy :D
I've started reading "Out of the Tar Pit," (OOTTP) by Ben Mosely and Peter Marks. On page 3, there is this quote from Tony Hoare in his Turing Award speech: "... there is one quality that cannot be purchased ... -- and that is reliability. The price of reliability is the pursuit of the utmost simplicity."
The guarantees given by Elm's type system and compiler make the design and construction of reliable code much easier than with many competing frontend languages. By that measure, Elm is successful.
Another point from OOTTP. The authors identify complexity as the main source of trouble in developing software, and they go on to say that the main source of complexity is program state. Then, on page 8, they declare "As a result of the above [arguments] .. the more we can do to limit and manage state, the better. This is what Elm does via the Elm Architecture, and it is one more reason why Elm is such a good tool for building web apps.
NOTE: I have seen reports of use by Elm at Amazon, Ford, and Microsoft. It would be worthwhile to understand why groups at these companies have chosen to use Elm, and to understand what this may mean for the future.
As a single point of data for you: I honestly thought you were talking about the existing email client until you mentioned programming languages.
I was thinking about how popular something is being measured by how many people have it installed on their systems by default, perhaps even without their knowledge.
If nobody uses your project, it's self-evidently a failure. The logical inverse of this axiom is that if everybody uses your project, it's self-evidently a success. This makes intuitive sense, but doesn't automatically follow: popularity might come at the expense of the core goals the project initially set out to achieve. Like Kasey said, there are multiple metrics for success.
Oh, I love Elm! Anyway, success depends on whether something achieves a goal. So, if Elm's goal is
Then that's totally cool, but how do you know if you're succeeding at it? I'd propose identifying things you can measure which indicate how effectively Elm achieves this goal. Note that popularity does seem like a reasonable metric because we'd expect that if it's exceptionally good at this, then more people would want to use it for this purpose. Given the specific hurdles of Elm (it looks and feels different from the languages most people know), conversions could be a better metric. Eg how many people that try Elm for a week continue using it for their front end projects. Or perhaps twitter sentiment analysis or something.
Anyway, if someone then points at popularity or market share, you can point them to a page saying "this is our goal, this is how we're measuring, these are our numbers over time." And I think that will make total sense to anyone and also help guide your decisions. If you do it, then do be careful about gaming the metrics, b/c success isn't actually excelling at these metrics, it's achieving what the metrics are expected to indicate.
What I find is particularly perverse is that many devs equate the number of questions (e.g. on Stack Overflow) to the quality of a project!
For me that generally represents a lack of documentation, a particularly obtuse API, etc. and does not really have anything to do with quality.
Many other devs look at the frequency of updates (e.g. Pull Requests) as a measure of quality. I find this last measure somewhat better.
I think that some measure of pull requests regarding the ratio of bug fixes to new features would be a good measure. I would probably factor in the maturity of the project and then use a measure of popularity after that.
Popularity is not everything but it certainly is a significant component of success; if Elm was wildly popular there would be less resistance to using it, and it should be used because it is very good. The notion that success equates with frequent updates is completely wrong however.
Popularity is actually a symptom that might happen if some piece of technology has some good ideas. It is not the cause of the good ideas, and only one of multiple potential effects of it.
But it definitely is easier to look at a number (like the number of stars a GitHub repository has. c.f. hasvuepassedreactyet.surge.sh/ ) than it is to create an in-depth assessment of the ideas a piece of technology uses to see if these ideas:
a) resonate with you
b) make sense for the task at hand
Of course, the only way to make an informed decision of what tool(s) to use, is by doing the latter. But because time is limited and people are lazy, the former is super tempting.
It is true that popularity does not appear out of thin air. But after this 'initial surge', the following happens:
Just my two cents and unfiltered train of thought~.