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 t...
For further actions, you may consider blocking this person and/or reporting abuse
I think it's a human default. "Who's the most popular?" was a question of major significance in grade school, and I don't think we outgrow the instinct to give it gravity.
In Elm's case in particular I could see someone interpreting "Let's Be Mainstream" to mean "Let's Be The Most Popular." It's hard to watch the first 60 seconds of the talk and conclude that's what he meant, but if I only knew the title and hadn't watched the talk, I might mistakenly assume "more adoption is better" was the central theme.
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.
The software industry is continuously growing (estimated to be doubling every 5 years) which has resulted in software being a very fashion driven industry which means that popularity has many prizes associated with it.
Popularity gives a wider ecosystem of packages and training which means that developers don't have to start from scratch when solving problems which has an accumulative effect on reducing the cost of building a wider variety of applications using that tool.
The risk associated with adopting a popular tool is lower for an organization because of the support and training ecosystem around it and the availability of people familiar with the language (external contractors or full time).
This results in jobs across a variety of organizations from small start-ups to large corporations being available using the tool in a wide variety of locations where skills in the tool are valued at the usual market rate.
For someone that is going to invest their limited time in learning a tool, success of that tool is them being able to use that tool in their job without being the one that has to 'champion' it and take on the personal risk of use of the tool being blamed for the failure of a project.
This doesn't mean the tool has to be the most popular, but there is a minimum level of popularity required to maintain this ecosystem and thus maintain the value of the skills that users of the tool have invested their time in learning.
RE this question, let's look at a couple of examples, metrics, etc.
(1) Haskell. As I understand the story, its growth rate was very low for a very long time. That gave those involved in creating the language the time to reflect deeply on the core ideas. The result is a language of uncommon power and expressiveness. One could argue that Elm is going through a somewhat similar albeit more compressed evolution. IMHO that is a good thing.
(2) Javascript. It was developed very quickly and it also became extremely popular quite quickly. That fast design period, however, is at the root of the many attempts to add to and modify Javascript so that it will better meet current needs. But a retrofit, whether it be to a language or house or piece of machinery, will seldom give a better result than a more thought-through initial design. I would argue that sometimes slower is better. (Consider the hare and the tortoise). In our world, fast goes along with popular, but there is a price to be paid for this.
(3) Angular I, II, III, ... [Disclaimer: I've been there]. These frameworks were pumped out quickly, had great initial success and adoption. IMHO the result was not so pretty, and left a lot of folks exhausted as they went from Angular N to Angular N + 1 and then possibly to something else entirely (in my case, Elm). Maybe slower and more thoughtful would have produced a happier result.
(4) Popularity is one metric, but there are others, among which are simplicity, reliability, refactorability, expressiveness, and influence. Relative lack of popularity means that by one metric thing X is "lower ranked." But is that the only metric? Is it the best? Or does it depend, e.g., on what you are trying to do. Different strokes for different folks: it is OK to follow the beat of a different drum.
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.
Success is linked to both attaining a goal and to higher social status. Popularity is more in the higher social status domain.
The main advantages of popularity is the amount of brainpower that comes with it.
The main advantages this brainpower brings are:
I would like to end by saying that popularity has its costs too. You can move quickly with a small SEALS team, not so with a large army. With larger popularity, change becomes costly. Another huge cost of popularity is the large volume of requests which can induce burnout in a small core team if they are not handled optimally.
I think popularity is one measure of success, but by no means the only one and not necessarily even the most important. For example if I release a product to a small market, and nearly everyone in that market uses it, but in general nobody has heard of it... is that product still not successful?
In Elm's case, it is currently in a limited market. Very few webdevs seem to want to use anything other than component-based frameworks. The influx of new webdevs learn Javascript and naturally transition to one of those. Because it is the vast majority of what they find guidance for. And when something is new to you, you don't want to try something on the fringes and risk it fading into dereliction.
It usually takes a long term project to expose the weaknesses in a particular framework. Anyone can make something neat, live with it for a short while, and make a blog post about how awesome it is... long before they start to get worn out on the maintenance burden from accidental complexity. And when you can find literally hundreds of such posts, how could you believe differently until experiencing the bad parts first hand?
I use Elm. I consider it a really good platform. I recommend it all the time. Any product has some issues, but overall it is the best front end dev experience I've had so far. My users love it too, because we can generally repro and fix things quickly. (As yet, we don't keep bugs on our backlog for more than 1 sprint on our Elm projects. We don't get a lot of them reported, and when we do they are frequently fixed and deployed same day.)
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.
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.
A lot more headaches :-D
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~.
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.
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.
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
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.
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 😊