This is a pretty cool project. Does anyone know if a copy of the node binary is made for each request? My concern is that if it's ~10MB on every request that could become problematic.
It looks from the code that it runs your JS through it's own virtual machine, though. I can't imagine funnelling Javascript through Javascript through Node being worth while.
I've been using XHP at work and love the improvements it has made to the new code we are writing.
Posting this might not seem relevant, but the examples of "replacing php with javascript" show one of the ugliest parts of PHP, and that is when presentation becomes super tangled with business logic.
XHP is really really nice for outputting the contents of an array into HTML (for example..it has many other really nice uses), and it would be very cool to see them do something like that.
I was under the impression Node.js could already be used to run back end code? Could someone explain to me (who is new to the industry) the difference between what this does and what Node.js already did?
This is designed to run without shell access, and without installing Node.js. Users on shared hosting cannot normally install Node.js, so are restricted to the usual LAMP stack, however this allows users to bypass this and process everything with Node.js.
> This is designed to run without shell access, and without installing Node.js.
How can you run that without installing node itself? the godaddy tutorial specifically says one needs to upload nodejs on the server.Whether you are running apt-get install node or uploading it,you are still installing node on the server
Most node modules are simply js files that host js functions. You can install those by ftp'ing over the files. Modules with bindings are a different story though.
It allows you to run NodeJS code in a shared server, the ones you buy when you're developing PHP apps, which are cheap and easily findable. Normally, you need a VPS, a dedicated or a cloud to host your NodeJS apps.
That's right, because it lacked Node's expansive set of robust modules. Now you can use iisnode [1] which allows IIS to host Node apps while also acting as the static file server and optionally also serving up ASP.NET/MVC/WebAPI requests.
In the past I wouldn't have considered running Javascript on IIS but with iisnode, it opens up a whole new world of possibilities that can be mixed into the .NET world.
Anyone have any ideas on the performance impact of this vs a typical NodeJS installation? I imagine there's a lot more overhead from starting up the process each time. A pretty cool idea but seems like this loses the benefits of NodeJS, speed and scalability.
It would have been better if implemented under FastCGI which solves the one-process-per-request problem. I guess the intended benefit of the project isn't really the Node eventloop, it's that it allows developers to use the same language on the frontend and backend.
Yes, but don't underestimate the value of penetration into cheaper hosts like DreamHost and Godaddy. PHP has always had quality issues, but survives on its eternal ubiquity, which is in no small part because of the CGI model.
Um, I would say it's mostly cause of mod_php support in apache, not cgi mode. Also, the fact that 5 minutes gets you AMP installed on just about any OS.
On the topic of this site though, 3 exclamation marks on the title? Really???
Strange, 22 year old technology is resurrected for javascript? cgi is an expensive technology because it execs full application on every request. It would be a bit more
sane if it was implemented with fast-cgi.
Sometimes, I wish people did not hack for the sake of hacking.
I agree with you and have the skill and facilities to run a VM with node as most of the HN audience does, but this doesnt represent the majority of little nobody sites that litter the web.
This looks useful. HostGator will host a web site for $3.96 a month. You can't have any long-running processes. You're limited to CGI, PHP, and static pages. For low-traffic web sites that need some modest amount of host-side processing, that's an effective solution. There's nothing wrong with running a Javascript engine instead of the usual Perl or Python engines under CGI.
If your e-commerce site does one sale a minute, you don't need Docker containers running on AWS instances behind a content delivery network.
I'm not familiar with the benefits of HostGator but how is this better than spinning up a free Heroku dyno to serve your node.js app?
That's also a very effective solution for low-traffic sites with a modest amount of host-side processing and more than enough for one sale a minute.
It's got great options for 3rd-party service integration too (e.g. free MongoDB hosting for < 512mb with MongoLab), and a very node.js friendly environment / deployment workflow.
Not trolling, genuinely curious what the benefit of this would be as an alternative.
Free dynos shutdown every hour when it's not active.Starting up can take next to 10 seconds.Furthermore it's a free service,I don't think people should abuse their generous offer meant for testing purpose. There is no guarantee they will continue offering free dynos forever.
Some people got burned recently hosting mongodb servers on a popular Saas that used to provide free mongodb hosting.Now that Saas is paid only,and though they aren't deleting existing test dbs,they could choose to do it at anytime.
One shouldn't consider free offers fit for any production purpose.
Like you wouldn't use free domains for a production app would you ?
I don't think it's just meant for testing. They choose to make the first dyno free so people will build on their platform. I have a couple of low traffic production apps that run fine at one dyno. If these apps ever get more traffic then maybe I'll scale them up and Heroku will get some money. I think that's the deal that Heroku is offering. I don't think I'm abusing their "generous offer". It's just business, from both sides.
How is this better than spinning up a free Heroku dyno to serve your node.js app?
Heroku's free service is more limited than it was in 2012. Current policy: "Heroku comes with 750 free dyno hours for development use. Beyond that you must pay for what you use."
It's crazy how some people in this thread get so emotional and negative about a new tool. If you don't like it, just don't use it. Yes, we know that CGI is slow and that you don't like Javascript.
This might be a really bad question that is just as applicable to Node.js in general, but doesn't this get confusing distinguishing between the server-side and client-side aspects?
Not really. Compared to using separate languages on the server and client, I feel that using the same language makes it a bit easier because I don't need to switch "mode" when jumping back and forth in the code. Like, when working on iOS apps, I sometimes write `self` instead of `this`.
I have sometime seen the argument for Node of using the same code on client and backend simultaneously, but in practice I haven't found any use for that. The only big thing I can think of is form/model validation, but if you do ajax, you can just as well do all that on the server anyway.
Isomorphic apps. I've been playing around with React+Flux, and it's perfect. You can write your API in any language you want (even keeping it as part of node if you wish!), but the client is React. This means you can re-use almost exactly the same code for the frontend and backend. You get server-side rendering that delegates to the client once it has loaded.
I could see that with node-cgi if you're mixing html+server side+client side in a single file.. that would be confusing.
In practice though (and if you're using the nodejs), you would have better organization... for ex, all of your nodejs code for in a directory, and then a directory with your templates (which is also where the inline client side js would go). Making it much easier to think about them separately.
PHP in JavaScript? Node.js itself is much more versatile and often easier than PHP (in my experience anyway), so I can only assume this is so Node.js can be used as a drop in replacement.
I think the only thing missing would be automaticly including PHP.js
I don't see why "replace PHP" is needed in the title other than linkbait. This is just a CGI dealy for Node. Even the article says "It can run along side PHP."
Agreed, headline is for marketing purposes, but it means that folk stuck with an environment where they'd otherwise be forced to use PHP have a choice not to use it.
Cheap shared hosting that costs a few dollars a month and comes with managed support. In this market a LOT of folks are largely non-technical, and want to pay for a managed system. DigitalOcean is great for people like you and me, but if I'm a mom and pop shop with a simple site, I probably just want to FTP some PHP files to a folder and call it a decade, and be sure there's someone to call if something goes wrong.
See: GoDaddy hosting, BlueHost/DreamHost/Hostgator, etc.
I thought PHP didn't run as CGI, shelling to a separate program with every request. It runs, in nearly all installations, as a plugin, saving the overhead of spawning a new program.
That's just one of the many reasons it did so well back it the day because it allowed a server to handle far more requests than CGI based stuff.
This is why Node.js is receiving an enormous backlash from the programming community. People keep peddling it as a solution to all problems when in reality it has very limited utility in all but a few use cases. Pushing this thing over old CGI technology and adding a hideous spaghetti-code HTML interleaving syntax is akin to shoving it further down the throats of the masses who don't want or need Node.js. The best thing to do is leave Node.js in its corner of the ecosystem and let people find it if they need it. Why are we even talking about CGI? It's 2015. This does nothing good for the developer ecosystem.
I've got a running theory for the next 10 or so years of development. Node.js's sole purpose was to lower the barrier to entry of server-side development. With the barrier to entry lowered, inexperienced developers with no knowledge of proper tooling are beginning to reinvent the wheel and make the same mistakes we did 10 or fifteen years ago. We're going to see a tragic repeat of the worst decisions made over the past few decades only this time they'll be running on what is arguably one of the most poorly designed programming languages, Javascript. Those who are too inexperienced to understand history are doomed to repeat it.
You're quite right. Node.js is more like a trap for inexperienced developers who probably won't even understand why Node.js is an awful tool when used to solve the wrong problem because they have no real experience (I believe Node.js is the wrong answer to the wrong problem in all but a very few exceptional circumstances).
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.
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.
> 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
> 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.
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?
I agree that Node.js is pretty good for thin REST APIs, it's one of the few scenarios that Node.js actually works quite well. It's the other 99% of use cases that I take issue with.
They aren't use cases. They are company names. Which parts of their product runs on Node.js? And have you spoken to their developers about their projects? Just because a big company deployed something doesn't make it viable.
I don't understand what you mean by "shoving it further down the throats of the masses". Are people being ordered to use Node.JS against their will somewhere?
Yes, usually by their manager. Things like Node.js get over-marketed to the public, managers are fooled into thinking it's a valid solution to their problem, then they force developers to use it against their will. node-cgi increases the number of scenarios where Node.js can be inappropriately forced down the throats of otherwise competent developers.
And there's also the long tail of inexperienced developers who made their own decision to use it and left a broken application that an experienced developer is called in to fix.
I also prefixed my statement with "akin to", which is to say it's not literally being shoved down the throats of developers but the effect is similar.
Well, if that is the case, maybe the issue is that such a person works in a bad environment? If you have a boss foisting technical decisions on you that are not suitable for the project, I'd expect that is a messed up environment in a lot of other ways. Is that Node's--or it's practitioners'--fault?
