There’s a War on Developers, and We’re Leading It

There’s been an implicit declaration of war hidden within the confines of social conduct in the open source community. It’s not a new discovery nor should it come as a shock to anyone in the JS community. It’s unfortunate but we’re not too kind on our own. Developers are quite unhappy with each other and there’s this unsaid hostility constantly developing between various open source tools with similar niches.

One of the problems that is both a source and a byproduct of this war is the constant reinventing of the wheel. Don’t get me wrong, I love reinventing the wheel when it is done with the right intentions. But developers are remaking products for very little reasoning. The JavaScript community now features a collection of linters, build systems, unit testing frameworks, assertion libraries, and just about any other thing that exists you will find a plethora of.

There’s a few reasons this is happening. The first being the resistance of open source authors to implement particular changes in their features or roadmap. Every author wants to retain control over their project and only implement what is in their vision. But this is leading users to feel turned off when they have particular needs from a project. The growth of crowd-frustration inspires a brand new project to be created that is one feature and a name away from the original project.

This isn’t always true, for instance the evolution from Grunt to Gulp. This change was much needed and it wasn’t just about one feature or an API — it was about an entire infrastructure and community change. To be honest, I’m not even sure how grunt survived this long. It had quite a painful and lengthy API. Just compare a simple Gruntfile.js and gulpfile.js and you’ll see. It was always just simpler to use the npm task runner along with the CLIs of the tools you wish to use.

Back to the point: some changes come as much needed and are much welcomed by the community. However, other changes only split the community. For instance, much of the community was unhappy with Douglas Crockford’s attitude towards open source and so JSLint was abandoned and JSHint happened. JSHint is an awesome product but now there’s a huge divide between JSLint and JSHint. This split is still very much justifiable though because JSLint took the “open” out of “open source”.

But was ESLint really needed? Honestly? Really? The main reasons I see people jumping to ESLint instead of JSHint is because they believe it to have improved ESNext support or because of its new pluggable and customizable system. The freedom is enticing but also dangerous. Linting tools were created to allow for standardization amongst the community rather than allow people to justify their own opinions.

Bob: “My linter says I wrote good code so it must be good.”

Alice: “But all of the features are turned off. Including eval.”

Bob: “But my linter says it’s okay.”

I tend to stick to JSLint for ES5 (or lower) projects because it tends to be very strict by default. It encourages me to seek answers for errors that confuse me and doesn’t let “small differences” pass. I always felt like the constant jump between the freedom of linters was captured by this saying:

“We will free when we escape — even from the frying pan into the fire.”

Don’t think there’s a problem? Have a look at this gist by substack. Substack is a fantastic developer and one that would be very much fawned over at any JS conference. His project, browserify, is an incredible innovation for the JS community.

However, webpack just had to happen. It’s a rival project that does everything browserify does but also adds the ability to extend dependencies beyond JS code and onto other static assets. The thing that irks me is that it would have been very much possible to create the static asset dependencies portion as a plugin to browserify or as a separate project dedicated towards static asset management.

Although some tools are not necessarily needed, there should still not be such hostility floating in the air amongst tools solving similar issues. Some of this is created through misinformation around a project or wrongful usage of it. As users, we should evaluate the need for particular tools in a proper manner.

There are always many factors to be considered when choosing a tool and often simply by creating a list of what features your project needs most, you’ll realize that one tool is clearly a better fit for this particular code base. It is important to create that differentiation between the fact that tools vary per code base rather than per user. Sometimes users who are unfamiliar with these tools tend to ask: “which of these two should I be using?”

I think that some of the hostility between projects can be lowered if instead we begin to ask: “which of these two fits better over here?” This will not create an exclusive rivalry between projects where authors are split between two eternal memberships. Rather, it’ll create a divide that allows each project to find its specific niche (and therefore allow its authors to better focus on that niche).

What do we do about it though?

Whether you are an open source developer or a user of open source software, you’ve got the power to influence what happens.

  • As a developer of an open source project, please be more open minded towards changes to the roadmaps of your projects. You never know how one idea could cause a revolution.
  • As a developer seeking to create a new open source project, search around to see if there’s an existing project solving the problem you are trying to solve and see if you can add to it.
  • As a user, decide on your tools properly. You may find yourself using different tools that solve the same niche in different projects. This is perfectly okay because the different tools tend to have more comfortable applications under certain conditions that may fit one project more than another.

That’s all, folks. Happy JavaScripting!

Click here to see the full publication where this article is included.

Help me keep things free by using flattr.