You can't do that easily in Java. You need to spend some time understanding the language, the ecosystem, how to bundle your code into an artifact, and then how to release and publish it; the barrier of entry is much higher because there is a lot more to learn and understand.

The article mentions Android - I haven't worked much with Android and so I'm not familiar with the libraries there. Is there the same sort of problem in the Android ecosystem that you see in Node? I wonder if he is talking about the fragmentation of Android implementations (flavors from different providers), which is a different thing entirely. Seeing as Android uses Java, I'm thinking the ecosystem is not like Node.

I don't agree with this at all. I think a good coder has complete mastery of their code and tools which is only possible by putting significant time to use one thing instead of jumping one thing to the next ever so often.

Imo the best way to become a better developer is not by using what others have created but trying to create libraries and frameworks yourselves to truly understand or at the very least think about the in and outs of the code to think throughly and produce a better architecture. It will open up your eye to differentiate good and bad code rather quickly.

I think we have to learn live with crap code and find ways to surface the diamonds. A rating system for packages would be great. Maybe based on developer ratings, amount of contributors/community interaction, and number of unresolved issues?

The bad part is that when the maintainers make unpopular decisions like disabling all functionality by default and relying on submodules, or not wanting to fix some obviously horrible bug because it's a 'feature', or abandoning the project for months at a time, often there is a cop out mentality that goes along the lines of "well it's my project and I didn't guarantee anything when you decided to use it so why don't you go make your own." There by taking credit for the project's successes but not responsibility for it's failures. So then people do go and write their own implementations and we end up with half a dozen half baked libraries.

An Example: Underscore and lodash are both very good, so are not examples of half-baked, but do we really need both of them? People will just say "well you only have to use one in your app... yada yada yada" but the problem is that if I want to rely on any other npm packages in my app, are they using lodash or underscore? I'll probably just end up with both of them shipping in the bundle because for whatever reason there couldn't just be one popular utility library, there had to be two that do basically the same thing. People will respond to this and say "well why don't you fork those modules that rely on underscore and make them use lodash?" My answer is no. I don't want to fork stuff. I just want to be able to find modules that I can rely on with a reasonable expectation of quality and maintenance. I'll even help maintain if it doesn't seem completely futile.

There may be some advantages of lodash over underscore in comparison to one another but those advantages are minor in comparison to what would be gained by having a single utility library that everyone is on board with.

Don't even get me started with routing libraries for React.

Why is Polymer on this list?

It would be useful if package management tools facilitated the process of understanding the liability imposed by a package, but the opposite is encouraged. Authors too often put up shiny marketing materials and make bold statements about the utility and vision of their software. It would be refreshing if authors were as open about the flaws, trade-offs, alternatives, etc. but few are.

Perhaps some kind of rating or feedback system that is qualitative in nature would help mitigate the salesmanship? I'd love to know who has been burned by a project and anecdotes about how packages are used by others. Ratings around issue resolutions would also be helpful, how often have we all had major bugs dismissively closed by maintainers?

TL;DR there are ways to develop a comprehensive assessment of a repo, but our tools are lacking and need much improvement in this regard.

I blame Github, in particular its "stars" feature. It makes putting out code a popularity contest.

"Why should I make someone else's project more popular? I'd rather spend my free time making myself popular."

</rant>

What this article is about? Snippets from SO answers are not as good as battle-tested code? It's obvious and it's same in all languages. You can't find library for any task in tracker you have? Same thing.

No, he envisioned Free Software.

https://www.gnu.org/philosophy/open-source-misses-the-point....

Is the author talking about the fragmentation of libraries and tools for Android, or the general "Android fragmentation"? If it's the former then I haven't experienced it, certainly not to the extent of the Node ecosystem. Yet...

> [...] because languages with smaller communities such as Go [...] don’t yet suffer from it

... I disagree, take for example the tons of different projects trying to "solve" the web framework problem, or the dependency problem, etc.

This is why I'm part of KDE. It's a large, diverse and productive community of people that want to bring Free Software forward. KDE exists 20 years this year and it's still growing and evolving. New developments come in, but they reviewed and nurtured in the community before being released under the KDE flag.

JavaScript could use a community like that where there is a common set of tools and values. The JavaScript that I see out there usually has very little quality control. It's easy to make something that looks nice and does not crash. But scaling up to an application that is complex and stable is hard. I learned this when developing the (now resting) library WebODF. Javascript comes with great tools like JSLint and Closure Compiler, and Jasmine but these are rarely used strictly.

Very few JavaScript developers have read 'JavaScript, the good parts' which is essential reading when writing non-trivial JS.

Node.JS promises the ability to reuse code on the server and the browser, but does not provide a module solution that makes that possible and works with the tools mentioned above.

Competition between KDE, GNOME and others on the Linux desktop exists because there is only one desktop on your computer. Javascript lacks such a focal point and JS framework developers can start new projects because it's easy to have a different half-baked framework in each browser tab.

You cannot build a cathedral out of market stalls. (KDE is the Sagrada Familia in this simile)

That's an interesting example cited by the author considering the behavior he desires isn't standard. There are multiple possible approaches to serializing an object tree to a query string (and reasons why, conceptually, you might not want to do this in the first place). Incidentally, when I searched for this on StackOverflow, the Q&A I found has a top answer that does deal with nested query strings [1].

[1] http://stackoverflow.com/questions/1714786/querystring-encod...

> Recently I needed a library to build query strings, just a small one so that I wouldn’t have to include jQuery just for that. After a couple of hours of research...

jQuery clearly is the best library to look to for a mature implementation. So why not just use it? Hours looking for alternatives is actually really expensive.

The justification is that jQuery is too big.

First It's probably not too big. CDNs and browser caching exist to optimize the problem upstream.

Next, the dynamic nature of JavaScript is to blame. You can't easily extract and compile just the functions you need.

Ideally we could all leverage bits of jQuery instead of poorly rewriting parts of it in the name of minimalism.

Seriously. I's been about nine months.

I use the exceptions feature to add in common sites where it is required.

I have been surprised over the course of this experiment by how little it is really needed for casual browsing.

And it has led to a decline in my consumption of garbage Internet by forcing me to take the time to add the exception which leads me to question whether this content is really worth the effort.

I think about building a feature that can do quick, single instance, javascript exceptions.

However, I fear it would undo the good done by the natural filter on my surfing.

And as a bonus, my data usage decreased considerably.

'Recently I needed a library to build query strings, just a small one so that I wouldn’t have to include jQuery just for that. After a couple of hours of research, I had found several candidates'

That right there is the problem, learn your language. You don't need to spend 2 hours looking through other peoples code to solve your (string!) problem. Learn the language and write it yourself, it's not 'rolling your own' when it's something so basic.

Is there a similar project for the javascript world?

A fantastic idea. There should be some social consequences for these sort of faithless and feckless types.

To the author: I believe that the node standard library has the query string tools you are looking for.

The query parser you want isn't able to handle nested objects and arrays easily - fork it, add your small piece of code (to what is hopefully an already small module), use it with a direct reference in your package.json, send a pull request upstream.

The fact that libraries don't handle your specific edge case/ special need is not unique to javascript, atleast you have an easy way out in node's mentality of small modules. Try getting a small change to work in spring or hibernate or any of the other massive frameworks that require days only to get familiar with their api and lifecycle hooks.

Consider this, I can easily go into the most popular framework in node (express.js) and change any part of the code within a few hours to match what I want, including adding tests, and there is non-zero chance that my changes will be pushed upstream. If I ever needed to do this to Spring MVC or even Racket, it will take me weeks, would most likely end up breaking dozen of other edge cases and would never be accepted by the Foundations managing those projects.

Also collaborating with others becomes much more challenging because you invendted everything.

With experience I can minimize self written code and I can skip plugins and libraries, but I feel better if I can rely on something solid.

It does not apply to all field of programming per se, but web developent is a perfect example.

That being said, there's practicing your craft and getting shit done. I'm going to be VERY unhappy with a developer that is writing their own take on an MVC framework from scratch for a production project. Unless of course the situation needs it.

IMO the premise of the article is that while this process is productive and educational, it's not something that you want to do all the time. Sooner or later you learn enough to be a world-class professional. At this point, checking what every kiddie with a keyboard and a monitor can code becomes a waste of time.

There's a long way until that point however and in the meantime it's very easy for one to become complacent and thinking they know it all.

In order to be professionals, we the programmers must periodically challenge our notions.

I very much enjoy working on open source, and have implemented some tricky but highly useful features over the past almost 1 1/2 years of my stewardship that users greatly appreciate. However, I also have a rich life outside of development as well, and I believe that each persons' choices with how they choose to use their time should be respected. If you are not paying or contributing your own time feature developing or assisting maintainance, complaining about maintainer absence is really poor. We are not on demand tech support.