Hacker News Reader

Comment by octo_t | Hacker News Reader

>> Node.js has over 30,000 modules available

how many of these are over a year old? how well maintained are they? how battle proven? how well is v8 going to be maintained 10, 15 years from now? can we buy an extended support contract for v8 from Google?

these are also questions people in enterprise want to know. how well does it interact with our existing CLR/JVM stack that we've used for the last 10 years?

I have never been convinced by the "writing server side and client side code in the same language is good" argument, different jobs require different tools. Someone once said of this:

'you know how to use a knife, so you bring a knife to a modern war fought with guns, tanks, and missiles while shouting "at least I can use the same tools when I eat and when I fight! I save so much time!" before somehow managing to shoot yourself in the foot anyway.'

View on HN

The top used module in npm was written for the browser (underscore)

A huge amount of code can / is be shared between the server and client, I wrote a database designed to work in browsers, a pull request away and it works in node.js using a different storage engine, 90% of the code is shared[1], the only people that arent convinced that sharing code between the server / client isnt useful just arent paying attention.

[1] https://github.com/daleharvey/pouchdb

The number of modules don't matter, but what does matter is that NVM and NPM are incredible tools. I've never used any package or version manager that comes close to their polish, ease of use, and simplicity. They make a huge difference. I think the true success story of node.js lies in those tools. The deployment and project building process is not just easy, it's actually enjoyable, and exciting. I cannot say that about any other build tool.

I do think having the templating portion of the web stack being in a client side language is important, as there's typically lots of overlap and interoperability that can happen at that layer between the client and server. As for the rest, I don't buy into the whole having a single language is better for understanding and hiring. Picking the right language that has the right metaphors for the problem will make things easier than having the same language everywhere.

I like your metaphor up to the point where I manage to shoot myself in the foot with a knife.

haha. didn't catch that one. english idioms...

I thought it was a deliberate non sequitur.

It comes off as pretty funny that way, and helps make the point.

"He could shoot himself in the foot with a knife."

It is a very fancy knife.

Using Firebase (https://www.firebase.com/index.html) as your backend, you can write entire applications in JavaScript without any server code. It also provides a Node module if you want to run your own servers: https://www.firebase.com/docs/nodejs-quickstart.html

Yeah right , so your app doesnt have business objects ? validation ? complex business rules that need to be enforced server side ? server-side queued processes and middlewares ? what kind of app are you talking about ?

Firebase has security rules for reading, writing and validating data. As I mentioned before, you can use the Node module to run your own servers.

Well of course we can expect that a scripting language designed for manipulating text-document markup into pretending to be a full GUI application in a nonstandard browser-specific way will be an excellent language for general-purpose backend computing.

Not to defend JavaScript specifically, but almost all scripting language can be used for general-purpose computing. That's what scripts are for.

(Although JavaScript in particular is not an excellent language for anything.)

Reply on news.ycombinator.com