[jenscow]

While I am on your side of the fence, there are a lot of those whose sole language is Javascript (learned from client-side) and have no time/motivation/ability to learn a new language. For them, wouldn't it be cool if they could use their existing knowledge and develop on the server?

I'm not saying it's a good or bad thing, I'm just saying that's how it is.

[gasping]

I don't think so. I'm all for lowering barriers to entry but there is a point where it becomes harmful to the ecosystem and to the developers themselves. Software development is, in my opinion, an engineering discipline, and so it's hugely important to use the right equipment for a specific task. If somebody truly can't learn how to do server-side development properly then they need to pass the job onto someone who can. Software development is hard. Not everyone can do it. This isn't a bad thing. Understanding that software development is hard allows us to move forward and gain a more broad knowledge of our field. Ignore that, and we end up repeating history. See: the templating syntax in node-cgi. There is no reason for that to exist in 2015. This is not how we advance a STEM field.

[danneu]

    > it's hugely important to use the right equipment for a specific task

Yet almost everything is built with a tool that's merely good enough for the task. Which usually makes it one of the right tools.

You mention that "software development is hard" and even manage to talk about advancing the STEM field, but we're talking about handling some http requests and someone's weekend project that managed to register a domain name.

What is the right tool anyways? PHP as a CGI? Haskell? Does it matter?

Bottom line is that you're getting wound up by a project that has 9 commits. The last one was 2 months ago. I think your PHP job security is safe for now, my friend. https://github.com/UeiRicho/cgi-node

[gasping]

> Yet almost everything is built with a tool that's merely good enough for the task. Which usually makes it one of the right tools.

I agree with you there so long as you understand which tools are good for which tasks.

> we're talking about handling some http requests and someone's weekend project that managed to register a domain name.

Node.js and cgi-node are not marketed as being strictly for weekend or toy projects. In fact, cgi-node is marketed as a tool that can do everything except cook your breakfast (see the last sentence of the cgi-node homepage). This just shows how badly over-marketed these products are.

> What is the right tool anyways

It's going to depend on the problem. Node.js's major failings are in the (arguably) poorly designed programming language and the continuous passing of callbacks. If your product can work within those constraints then Node.js might be the right choice. For most people Node.js will not be the right choice.

> Bottom line is that you're getting wound up by a project that has 9 commits

I don't care about how big or small the codebase is. I just care about it being marketed as a valid solution to most problems when it's really just a trap in most cases.

> I think your PHP job security is safe for now, my friend.

Pointless personal jab based on an incorrect assumption. I do not work in PHP and I don't see Node.js as a threat to the job security of any competent developer.

[jenscow]

But there is a big difference between "professional" (their work affects others) and "hobbyist" (simple tasks nobody uses).

Think about the hobbyist... The PHP/Razor like templating, since you mentioned it, gently mixes known (html document that they can see) with the unknown (magic code). Do they really need anything more advanced for the type of things they're trying to produce?