The Node.js Community Could Use Some TLC

01-22-2011 12:25 AM  permalink

I think everyone here can agree that Node.js is awesome. Along with the commonjs effort, it has intensified the interest in javascript as a server-side language. The combination of asynchronous I/O by default and strong support for easy networking code has proven to be what lots of developers want in a platform. It's exciting and the community is growing every day.

But with growth comes growing pains. Node has matured as a project. It has a direction and a vision. This has happened organically and not everyone is aware that things are different. And I think we need to start broadcasting that direction and protecting that vision. I got motivated to write this blog post to offer some suggestions that could help ease some of the pain points of the community.

Most of the node community is centered around the mailing lists (nodejs and nodejs-dev). I've been following the lists since the beginning. First as a lurker, then a more and more frequent contributor. There is lots of activity and some very smart people hang out there and respond frequently to questions. What's even nicer is that Ryan Dahl and other core members actually post frequently to give good info on what's happening with node. In short, it supports the growing node community pretty well in my opinion. At least until recently.

The most recent influx of newcomers is excited about node too. But they're not exactly satisfied with it's current state. They want to discuss possible "improvements", and they're pretty vocal about it. They want to make it "easier" to write asynchronous code. They start talking about threads and continuations and forking the v8 engine. But these things don't fit the current vision for node. And it's creating lots of static.

I think node is at a point where the community could really benefit from some light curation. The primary thing that is necessary for node to take over the world is adoption. But node is growing really fast and this means more time spent helping people get started or helping them understand why things are borked when they did it wrong. We should be making it as easy as possible to get into node and smooth any rough edges.

Right now one of those edges is lack of info about the project itself. When people get involved with node it starts their imagination going. This is partly because it's so different from other server environments. It's a joy to work with compared to others, like certain Pretty Horrible Palindrome languages we won't mention. And also because javascript doesn't come saddled with all of the baggage these other languages have. We can rethink I/O entirely because it has very few preconceived notions about it (XHR being a minor counterpoint). Couple that with the rapid pace of innovation in javascript engines and it's easy to get excited about "a better programming experience".

This is how node started. Ry was fed up with how slow other platforms were when it came to networking and I/O. So he set out to change things with some different ideas. But it feels like we're past that phase of innovation now. People want to rethink everything. Even stuff that ain't broken. These days the node team is focused on stability and completeness. And it doesn't pay to keep blue-skying about javascript features that don't exist. That time will come around again, but for now it's on the back burner.

This is NOT a bad thing. Node has a pretty solid foundation built on some really nice ideas. The next step to world domination is making sure you can rely on that foundation working correctly and consistently. And filling in the holes. But this needs to be made clear to folks early on. For example:

Most people are surprised to learn that SSL/TLS is still pretty spotty in the current branch of node. I think most would readily agree that this task trumps unnecessary things like exploring other concurrency models. But the point is, there's no way they could know because it's not written down anywhere. Or maybe it is and I just haven't seen it. That's telling in an of itself because I try to stay pretty abreast of node updates.

There are several things that could be done to help people learn about the state of the project:

A Roadmap

Nothing fancy, just a semi-linear list of things that Ry and the group are prioritizing for node development. Something like this only updated more frequently and not buried in the list. Or like this, but with more context and some notes about direction. Put "forking v8" way at the bottom right after "Add support for making breakfast". Then at least people know where they stand if they want to propose that.

Maintain a site with more persistent info

The roadmap linked above shouldn't be a random post on the list. It could be linked there for sure. But it shoud be on the home page. Then when people wonder if "anyone has thought about adding threads", they can see that they shouldn't hold thier breath, because it's not on the roadmap. They can see what is on the list though. And they might even decide to help out :) Open source ftw.

Make resources more prominent

I went looking around for node info in anticipation of this post. I found a ton of stuff on the wiki that never gets mentioned to newcomers:

• [https://github.com/ry/node/wiki/Community]
• [https://github.com/ry/node/wiki/ECMA-5-Mozilla-Features-Implemented-in-V8]
• [https://github.com/ry/node/wiki/Hosting]
• [https://github.com/ry/node/wiki/Streams] (how current is this?)

These are not linked directly from the wiki home page. Instead when you go there, you get a long list of projects, many in various states of abandonment, and companies using node. Interesting, but only for a second. Then I want to know what it can do for me. I wanna know how to get started. Which leads to...

Embrace NPM

NPM is the default node package manager. That's a statement that some are reluctant to make. But it's true. There was a brief period where there were lots of options for getting node packages. They all had wildly different opinions and It was a glorious battle. But npm emerged victorious, and it is now ubiquitous. Except to newcomers. They hear about it pretty quickly, but it's not clear that they should be using it all the time. Instead it's relegated to third party modules and lumped in with a bunch of other "nice to haves". No sir. Put npm on the home page. Put it in the getting started tutorial. If something better comes along, we'll all promise to stay open to change. But for now, done deal.

Write a Getting Started Tutorial

Seriously, where is this? Oh it's buried somewhere on the unofficial blog and usually outdated. To be clear, the getting started tutorial should have installation, the module system, basic async conventions, npm and an http Hello World all in one place.

Talk About Why Node Is What It Is

Many people would like to know more about some of the design decisions made in node. There's been a lot of good talk about different concurrency models, how to handle I/O better, how to handle async code. There are lots of videos of tech talks and meetup discussions. Lots of slide presentations. But the fundamentals should be distilled down on a few pages for everyone to see. Kind of a mission statement for folks who can't catch up on all that stuff. The About section on the node home page is a good start but some of it could definitely be expanded upon.

Maintain an FAQ

This is related to the above, and perhaps a better alternative. Right now the only place to go to get answers is the list. Even for questions that have been asked and answered several times. No wonder certain core people are starting to go nuts. Some things to include:

• why node chose the event loop model
• explain the node callback convention
• the philosophy behind streams
• why we're sticking with standard v8

These are the questions that get rehashed on the list on average once a week. We should be able to link this and just move on.

Get a Handle on The Mailing Lists.

Node is only going to keep growing in popularity. The lists will get more and more traffic, and it will become impossible to keep the signal to noise ratio high. Unless we get out in front and plan for that. See the lists for rails, django, etc. Awful. It doesn't have to be the iron fist type of moderation. But give people multiple outlets and let them know what's appropriate. I propose something like:

• node-users - Questions and comments about using node, announcements and that type of thing. Most of what the nodejs list is now. This should stay focused on productivity in regards to producing working code. This is where newbs start and where gurus can do the most good spending time.

• node-discuss - Anything. Literally anything folks want to talk about. It can be about node, related to node, inspired by node. Who cares. The upside is that it still feels like part of the node community. And no one will tell you to Please Stop. Node enthusiasts can chat until they're blue in the face. And if you're overwhelmed by the volume of chatter, it's your own fault. You should probably block it from your mail client.

• node-dev - Concrete talk about development of node itself. This includes patches, bug reports, discussions of roadmap features, etc. The node core guys will hang out here a lot so it needs to stay pretty focused. That means actual moderation. It's not evil to restrict or moderate, and it's doesn't inherently restrict openness. It's just practical. Let's use it so Ry and company can get some work done.

The trick to all this is gently nudging folks to the right list. In my opinion this doesn't usually require being rude or laying the smackdown. And besides, that almost never works. It creates more noise as people start arguing about internet etiquette (guilty). It's simply a matter of pointing people to where they can read the list guidelines and then forwarding the post to the other list. No need to reply further. If someone decides to continue on that topic, they should be talking to themselves.

Note:I purposely haven't mentioned the irc channel before now, #node.js on irc.freenode.net. It's a great resource but not everyone is inclined to venture there. Plus the number of users has seemed to plateau which suggests that it's not growing as quickly as the mailing list.

Identify the Community Leaders

This is perhaps the most controversial suggestion I've pushed before. Ry has been crowned BDFL of node. And he's pretty awesome at guiding the development. But the man doesn't like to talk (no offense). I like to think he's a man of action and few words. His posts on the list are usually short, to the point and impactful (see here).

There are others who have been big promotors of node from the beginning. They have lots of influence on the way things go. They talk to Ry frequently and can often relay his thoughts. They make prodigious contributions in both code and knowledge. These people frequently try to guide the community even right now. They should be the ones doing the gentle nudging I mentioned before. But they can't do the best job of it because they haven't been given the authority. Or they won't accept it.

I won't say more on this topic because it's really something that should be discussed between the core guys. But I'd like to see it happen.

So ...

I hope at least some of this is helpful. I plan to try and do some of it, like the Tutorial or FAQ, myself in the coming weeks when I find time. Considering how long this post ended up being, I'm sure I can find a minute or two.