Live data from Hacker News

Popularity-driven development

ferrante.pl

21–30 of 36 posts

Re: Popularity-driven development

#21
post #3

> _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.javascr…

You're forgetting one of the driving forces behind jQuery: browser incompatibilities. Now, with IE on board with HTML5 (whatever the hell that is) and most browsers at least trying to be standards-compliant, it's easy to forget that without a compatibility layer, building a cross-browser Javascript application was literally impossible.

Furthermore, jQuery offered a pretty nicely-engineered codebase and a very friendly and predictable API at a time when client-side JS was very unpredictable.

I don't use jQuery much anymore, since it's often just as easy to use plain JS. Plus, I'm often compiling so I can use a ES6 compiler to make it even nicer.

But I definitely leaned heavily on jQuery in the days prior to IE8-IE9 and client-side builds.

And even disregarding all my arguments above, I don't think it's fair to call such a carefully-designed and maintained project an "abomination", even if you do disagree with some of its technical decisions.

Re: Popularity-driven development

#22
post #21
post #3

> _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.javascr…

You're forgetting one of the driving forces behind jQuery: browser incompatibilities. Now, with IE on board with HTML5 (whatever the hell that is) and most browsers at least trying to be standards-compliant, it's easy to forget that without a compatibility layer, building a cross-browser Javascript application was literally impossible. Furthermore, jQuery offered a pretty nicely-engineered codebase and a very friendl…

jQuery was far from the only popular cross-browser DOM library. We had a choice of jQuery, MooTools, YUI, Prototype, Dojo, Mochikit, and quite a few others, along with good presentation of standalone cross-browser techniques from sources like QuirksMode. jQuery mostly succeeded through its marketing to web designers which formed a critical mass of well-written extensions and hireable know-how, and a zeitgeist of jQuery as a baseline.

Re: Popularity-driven development

#23

Earlier quoted context omitted.

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 acr…

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 ca…

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.

Re: Popularity-driven development

#24
post #15
post #2

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 marke…

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?"

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.

Re: Popularity-driven development

#25
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.

Re: Popularity-driven development

#26
post #25

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.…

http://lhorie.github.io/mithril/

Re: Popularity-driven development

#27
post #2

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 marke…

This is the case in every industry right now, and has been since the beginning of time. Marketing is the ability to influence people. It seems obvious to say this, but people who can influence people are usually the people with the most successful products (see: politicians, Apple, pg, etc.).

Re: Popularity-driven development

#28
post #3

> _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.javascr…

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 acr…

What do you do with these sort of extremely specific selectors?

Re: Popularity-driven development

#29
post #14
post #12

Earlier quoted context omitted.

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 actuall…

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…

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.

Re: Popularity-driven development

#30

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 u…

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.

Recently, I've been questioning the exact value of using popular tools because it's easier to find developers (vs other reasons). So much of what a business is building and providing is bespoke. Even if you use a popular framework that makes your job posting buzzword compliant, that can end up being a relatively small portion of the knowledge required to actually be effective writing software for your business's industry. This goes doubly for organically created internal business processes, which are, nearly by definition, bespoke and won't be found in exact form anywhere else. Now, if you've got good, strong project managers who know your business's industry (rare, IME), then maybe the primary knowledge/experience the programmers need is only on specific frameworks.

Obviously there's a lot of wiggle room here. Both early stage and established companies and code bases could make use of people who are either wide breadth or deep depth, there is no one guiding principle. Are you really going to turn down the candidate who knows 15 languages and frameworks but doesn't know the one you use? Or is this just your bias because you don't feel you'd be able to effectively interview them because you don't know as much as they do?

Post reply on HN