This is a really flawed way at looking at the market. Including tablets and smartphones in the PC market doesn't work because most people have a PC and a table and a phone.
This could really use a lot of editing. Far too much of it is whining about slow internet that doesn't reach a meaningful conclusion, but instead generalizes from his anecdote.
If anyone is reading comments before reading the article, I recommend scanning it quickly. You won't miss anything.
It seems like it's really getting killed under the load. This also isn't the first node project demo I've seen deployed that gets destroyed by a bunch of people visiting it to check it out. Anyone have some tips for deploying Node in a manner that your server won't just get destroyed? What's the point of supporting 1000's of users in say, socket.io if most people's deployment schemes allow for a max of say, 250 concurrent connections?
Be sure to use Node's cluster API (http://nodejs.org/docs/v0.6.0/api/cluster.html) so each core on your server gets utilized. Doesn't look like this, looking at the source, is doing that so unless they're manually running an app instance on each core and load balancing between them then they may be underutilizing their hardware.
At ClassDojo we support many thousands of concurrent users on node.js using cluster to create multiple worker processes and using multiple boxes with Amazon ELB in front of them. All static assets are served from the CDN.
Handling your state in memory is fine for examples such as this, but in general you should defer all state to the database layer or use something like redis. That way your app server will remain entirely stateless so any node.js process on any box can serve a request identically - you can just scale up by adding additional boxes.
A very fine way is to have multiple processes and connect to any at random. Now, use a message queue, say like redis, or rabbit mq to read messages and delete from queue. Since a client is only connected to only one of the servers, it eliminates the chances of sending the same message more than once to the same client. This helps in splitting the incoming messages and the outgoing(which is usually far bigger, since one message is delivered to all others in a chat room).
While I don't disagree that its a little bit far fetched to say the two are equal, I don't think it is as far off as you say. 3 points:
- you are comparing a GP or specialist surgeon (average age... maybe 45-50) with a 'plumber I' (average age... maybe 25).
- Plumbers do a lot of cash-in-hand work that will never be declared as 'salary'
- Pay for tradespeople can vary enormously from place to place. I have noticed living in the UK for instance that tradespeople there earn far less than they do on average in the USA or Australia.
>> Execution of course matters but there is also value in being first and taking the right marketing approach.
I absolutely agree with you. I think for a lot of people, including myself, however, the best marketing approach would have been to say "check this out, I did something cool, and I've open sourced it." This is what dcurtis probably should have done. He didn't do any groundbreaking rails code, and there was very little value in having a new workflow of blogging exist only on his servers. I think the value of Nate open sourcing it is much higher than if he had just built a clone and kept it to himself.
Basically, the community response supporting Nate is strong because he did something that benefits the community as a whole, where as dcurtis did something that benefited only himself and then shouted about it.
That's my (pretty myopic and polemic) take on all this.
