

Popularity-driven development - mparramon
http://ferrante.pl/frontend/javascript/popularity-driven-development/

======
comboy
Especially in ruby world, it's amazing how big impact marketing has on open
source projects.

It's nothing new that when you prepare a nice webpage with some pictures and
logo your project is more likely to gain some traction. But mentioned element
of social media and virality makes sometimes seemingly random projects to
become popular.

It would seem that when releasing an open source project, your webdesign and
marketing skills are way more important than your programming skills.

It gets fixed a bit later because when project becomes popular some good
programmers join in and get rid of some silly bugs and so on. But the original
design and assumptions stay. API often stays. And since I consider programming
nowadays being a lot of like building from lego blocks, API has a huge
influence on programmers productivity.

~~~
kyllo
Marketing shows that a project has some money behind it, which is a good sign
it's going to be supported for a while, which allays the biggest fear most
people and organizations have when selecting an open source tool: "is it
abandonware?"

~~~
mattgreenrocks
I guess actually evaluating the project itself is completely out of the
question? Or you could, you know, adopt it and continue it?

The idea that the technical excellence of open source is secondary to it's
marketing/influence is toxic at it's core, and reflects yet another way that
developer culture has been infected by Business.

Developers focus more on amassing influence than raw skills. We're told to
work on 'important' open source projects (remember when everyone fell over
themselves to say they contributed to Rails?) and to jump on bandwagons. We're
exhorted to take Github stars and activity streaks seriously (lol). And we're
told that we can never do enough marketing for our open source projects, that
we should buy domain names, blog about it, write more documentation, do
bugfixes in a speedy fashion, speak, and maintain social media handles.

This will only get worse over time, because we're all convinced we have to
amass influence. We're literally working ourselves to death for a few values
stored in a database.

------
lhorie
Here's my experience, being an author of an "underdog" js framework.

My project (Mithril.js) has ~2600 stars on github, a relatively lively mailing
list, and it's on the front page of todomvc, so it's definitely more popular
than many "competitor" projects, although not nearly as popular as Angular or
Ember.

My general impression of the landscape is that affiliation w/ a famous brand
helps _a lot_ in driving adoption. Being a guy in the outskirts of Toronto,
working on the project on my spare time (with two small kids), it's pretty
hard to compete w/ teams that get paid full time and get opportunities to talk
at big conferences in San Francisco. I'm skeptical that this kind of gap can
be made narrower with hard/good technical work alone. This reality weaves deep
even into the design philosophy of Mithril: one reason the project is small is
that I don't have the resources to tech-support a huge complex one. Lack of
time is obviously not a selling point, so the design of the framework itself
needs to account for it - I put a lot of thought into reducing learning curve
and framework complexity because that is something that both reduces my
workload as a support person, and is itself a selling point (especially
considering all the recent Angular criticisms).

I think the only reasons my project enjoys any popularity at all is the
efforts I put into non-coding tasks: writing docs (took me like 2 months of
writing docs nearly exclusively to get to what I consider a decent level of
documentation, even despite having a tiny API), writing articles, talking to
the community, getting on twitter, adding shameless plugs on HN :) etc. In a
way, this is similar to being a startup founder: there's a lot of peripheral
stuff to do. It's not uncommon to be spending more time on non-coding aspects
of the project than actually coding.

~~~
pelonpelon
Why I'm coding with Mithril...

I have experience creating a very complex React app to organize a conference.
It included registration, authentication, personalized schedules and
calendars, news articles, up-to-the-minute updates, a store, physical pass(ID)
verification, and a few dashboards for use by clients of my client. Honestly,
it was a lovely experience. Once in the React rhythm, the coding became an
exercise in pattern application. This was before Flux came along.

Presently, 58% of users of my current client's site arrive via mobile and
minified React tops 145kb, which takes a lot of time to deliver and unpack. I
serve 1000 new users per week who can't rely on finding React in their browser
cache. This is too much overhead. I am a little obsessed with under-one-second
loading and 3 second attention spans. Non-minified React is 642kb and that's
too much code for me to grok if I want to understand what my application is
doing. I did some work converting Bootstrap to React and ramping up took too
much of my time.

Then I found Mithril. It's faster than anything. It's tiny. It does only what
it needs to do, no bloat. And it does most of the good stuff that React does.
It's also FRP friendly, another current obsession of mine.

It's in the early stages, but it is so small and focused that it can be used
anywhere. TODAY. Consider it code you would have written on your own if you'd
had the time (and were a VERY talented js coder). mithril.js is small enough
to understand in detail. It's so well designed that even an intermediate dev
like me can grasp it. Beyond the basic documentation is a blog and API docs
written as precisely and as focused as the code. The API is so small you can
master it in an hour or two. It's a testament to its quality that the earliest
blog entries are applicable today. I recommend reading them from oldest to
newest. They read more like a tutorial than a blog. Post a question to the
Google Group and Leo will likely refer you back to a blog post because he's
already covered your question.

Another sign that Mithril is of great quality: most public discussion about
Mithril revolves around the philosophy and logic of app design, not code
errors. When errors are discovered, Leo patches them within hours if not
minutes.

Leo got so much right. Most things right. More than any other framework I
know.

------
drapper
Popularity might not be the best indicator of quality, but it's a pretty good
indicator of longevity of the project - and this is, I think, more important,
in the long term at least.

All the technical superiority of an unpopular library will amount to nothing
if couple of months down the road the author will not be interested in fixing
some obscure, but important bug, nor there will be anyone to take on the
maintenance from him/her.

~~~
awinder
Importantly, like you said, it's also the measure of some level of quality.
It's incredibly, incredibly rare that a tech project becomes popular without
any level of quality. A lot of people could do much worse than that
combination (some quality + longevity)

~~~
dragonwriter
Nothing exists without some (possibly very low) level of quality, but by any
measure of quality other than popularity itself, popular things may fall
anywhere in the quality spectrum.

------
jkot
If you make living out of your OS project, popularity and huge number of users
might not be necessary good thing. It all comes down to conversion rate,
community maintenance cost etc...

------
cauterized
Indeed, popularity does not directly correlate with quality (which is not to
say that popular libraries and tools are never high quality.) That said, the
reasons most projects fail have less to do with the imperfections of the tools
used than with the approach taken to the project as a whole. And especially if
you're running a business there are good reasons to choose tools that are
reasonably well known and widely used, regardless of whether they're the
absolute best available on the market. The biggest reason being that it's a
lot easier to find developers who know or are interested in learning a popular
tool than an obscure one.

~~~
woah
Something that is sometimes seen as a "marketing" type thing is documentation.
However, good documentation is a clear indicator of a better project, if only
because it makes it qualitatively easier to implement. I'm going to choose the
project with the clear, attractive, well written guide and api docs over the
project where I have to dig through pull requests to find method names.

Worse are the projects that actually expect you to look at the tests as the
only form of docs. This indicates that the author does not care about whether
you have an easy time using the project, and that it was only written for
their own amusement.

A well done project website shows that the author wants you to have an easy
time working with the code, and is "putting out a welcome mat".

Compare mercury:
[https://github.com/Raynos/mercury](https://github.com/Raynos/mercury) with
vue: [http://vuejs.org/](http://vuejs.org/).

mercury is likely the "better" framework, with it's reactive approach, but in
vue, there is attention to detail and documentation through and through. So
vue is inevitably what I recommend to backend developers or others who just
want to get something done.

~~~
jnbiche
I don't use Vue.js (I use React), but I agree that the project is extremely
well-documented and beginner-friendly.

The project also has 3400 stars on Github, so the lead dev is gaining some
significant popularity. Furthermore, a number of for-profit businesses are
almost certainly using the framework in production, as a key part of their
websites (Optimizely is cited on their web site as using it in production, but
I'm positive there are others).

And yet, for all his efforts, the developer is given $5.00 a month on his
prominently displayed Gratispay account:
[https://gratipay.com/yyx990803/](https://gratipay.com/yyx990803/)

$5.00. A single Starbucks cappuccino. A month.

When I see things like this, it makes me despair of ever making a decent
living doing open source software (I have some semi-popular projects, but
nowhere near the level of Vue.js).

In the end, it also makes me wonder if open source development isn't devaluing
the software profession in terms of compensation and prestige. If seems like
if people don't pay for something, they just don't respect it, regardless of
how useful, well-documented, and well-designed it may be.

I love open source, but every time I see a super popular project with only a
few dollars of total donations, or hear the lead dev of a open source project
used by massive companies around the world tell me he's barely making a
living, part of me dies inside.

~~~
sholanozie
This isn't unique to software; the lowered barriers to creation has meant that
the value of almost everything has dropped to the point of worthlessness.
While you may not be able to make a living from your open source software
through donations, you can certainly make a living by providing support to
businesses or assisting with integrations/migrations. We are seeing a shift
towards a service-oriented industry, rather than a product-oriented industry,
and I expect the rate at which this transformation is taking place to
drastically increase in the near future.

------
thetmkay
This is a slight diversion, but if you're interested in the topic of
popularity-driven ethics (diction?) you may be interested in the novel by Cory
Doctorow called "Down and Out in the Magic Kingdom"
[http://craphound.com/down/](http://craphound.com/down/)

I only read it recently, and in addition to recommending it as an enjoyable
sci-fi read, one of the themes is the use of system called 'Whuffie', which is
a reputation-based metric that permeates all of society, including politics
and economics.

------
oinksoft

      > _I was there_ ... In 2007, at the beginning of my journey
      > I started this blog. I remember my first JavaScript
      > tutorial which gained a lot of readers, even though I 
      > wasn’t the expert in the field ... So when I recommended
      > jQuery, some people followed me in this opinion and tried
      > it.
    

This post was a fun read simply because my own career path is not unlike the
author's. I spent this time in comp.lang.javascript (;^)) and ##javscript,
where I learned pretty quickly that I was decidedly not hot shit and that even
frontend JavaScript development already had a significant history. Today I
wouldn't entertain the idea that I was present at the start of some turning
point, it was just the start of another career.

Being a neophyte coming from the land of HTML, CSS, and A List Apart, I took
to jQuery like a fish to water, but more experienced folks correctly slapped
my hand when I championed it (like David Mark, the Voldemort of c.l.j.). I
wasn't quite sure why it was so reviled in these circles, but given that I had
arrived at these communities to learn and not teach, I went with it and just
listened (and didn't write blog posts).

Over time I saw jQuery for the abomination it is. A very usable, imprecise API
that has "fluent interface" and a selector engine as its chief selling points,
where a single prototype is the God object to end all God objects. Given that
all of the other libraries implemented a comparable selector engine, I never
felt deprived when working with Prototype, or MooTools, or Ext.js, or
ultimately Google Closure. I could see that designs written with these other
libraries were far more comprehensible and cohesive than what was coming out
of the jQuery world, but to oppose the jQuery tidal wave was a fool's errand,
so I just kept writing lots of software for my employers, and didn't write
blog posts.

Maybe some day the history of how jQuery "made it" will be written. It seems
like a shining example of "Worse is Better." Recommendations like the one from
the author were just the blind leading the blind. Now we're stuck with it.
Maybe more of us who felt this way should have written blog posts, but as the
author hints, that's the paradox! You can spend so much time writing software,
or spreading ideas, but seldom is there time to do both prolifically. I still
don't feel qualified to write blog posts like this one...

~~~
pcthrowaway
jQuery is beautiful and meticulously engineered (and also modularized) to a
level far beyond other DOM manipulation/cross-browser
compatibility/animation/promise/wart abstraction/whatever else libraries. It
may not be the _best_ at everything, and it's certainly not minimalist (though
its components are now designed to be independent and customizable) but it is
the meeting of many good practices and informed design across its many
capabilities. It's the everything-and-the-kitchen-sink philosophy (with a
focus on performance).

> Given that all of the other libraries implemented a comparable selector
> engine

This is not true; other libraries implement their own selector engines which,
while (sometimes) smaller in size, are also less feature-rich. Sizzle
(jQuery's independently developed selector engine) provides many additional
selectors not currently available in the browser (such as nested pseudo-
selectors: `:not(:has(div:first-child))`).

If none of this appeals to you, you are welcome to use a different library.
There are lots of other strong options. But just because jQuery doesn't fit
your needs doesn't make it 'an abomination'

~~~
oinksoft
You're right that Sizzle was the class of selector engines, and if the story
ended there (with jQuery as a DOM library) then jQuery wouldn't be listed on
many resumes. By publishing `jQuery.prototype' to `$.fn', pushing the idea of
"plugins", and by encouraging DOM operations as the main extension point in
application design, jQuery made itself into something more. The brittleness of
this approach is proven by how calling jQuery UI component methods requires an
additional level of dispatch. This way of doing things has no legacy. It's
considered an antipattern now, and a "mess of jQuery" is a known form of code
debt. I don't think it's a matter of whether this style "fits your needs"
anymore.

~~~
pcthrowaway
A "mess of" anything is a known form of code debt. Just because jQuery doesn't
force you to use it properly doesn't make it unusable. jQuery, or parts of it,
are still used by default in almost every SPA application framework, and some
of the resulting applications are even well structured.

