Using Node.js with Heroku to Create a Chat Server

Bandwidth is cheap. Time is not. I would suggest that if you are selling your software that you have the process as automated as possible, asking as few questions as possible, and have it "just work". Given this, 20mb isn't a lot and you're really looking at 20 seconds or less for most broadband connections. at least in my country.

Bundling the software also ensures that you distribute the version you've done your testing on so if node.js is 3 versions ahead in 5 years time, and there are breaking changes, you won't be having support issues.

Think about it from a users perspective. If you can get one package, that contains everything you need for something you bought, or you can get the software but then need to go find the dependencies online, you'd be frustrated.

1. If 10gen have said it's ok, and you have that in writing, you shouldn't have any problems. Node is MIT-licensed so I doubt there would be problems there. Also bare in mind most software that is designed to operate as a service, runtime or component does come with a redistribution policy and this is normal.

2. If you're always able to provide the files then you could go down this path, as I said above bandwidth is cheap. You might have more luck bundling the required files for a few reasons: offline installation, and in case your server goes down / you decide to stop selling software / etc.

3. You should install the correct architecture for the CPU, although there is unlikely to be problems.

The recent left-pad issue is a prime example of the problem with this tendency in Node. When you depend on too many things, all of them are prone to go ka-pow, make your project harder to debug and, for a newcomer, harder to grasp the workings of the language.

Now good Node.js programmers know to write minimalistic applications, where dependencies are concerned. The less things you depend on - the better. Need to pad strings to the left? Code it in a helper, it's 11 lines of code with the blanks. Need to number your string rows? Code it in, it's less than 100 lines of code.

Even for more complicated tasks, like project management, I'd suggest to stick to Makefiles while your project is simple enough - grunt and gulp are really, really useful for giant projects that have a lot of heavy-lifting to do. But for your SPA blog? Write a Makefile, it takes 5 minutes and you know how it works.

The temptation to just browse npm every time you need to write 3 lines of code is great, but should be resisted, whenever it's reasonable. Don't include jQuery if you have 3 DOM manipulations, don't use angular for that static promo page, do not use express for a simplistic server. But you're coding a CMS? You'd have to be crazy not to use packages like jQuery, underscore and what's not. Working with 10 collection types, 3 dbs and querying them all the time? You'd be insane not to use underscore and a few others. Just think 'do I save enough time by installing this package?' or 'Can't I just code this in for half an hour or so?'