CGI Using Node.js(cgi-node.org)
cgi-node.org
CGI Using Node.js
http://www.cgi-node.org/home
26 comments
We had this 21 years ago:
http://en.wikipedia.org/wiki/Netscape_Enterprise_Server
Yes, I remember this. It had Netscape Livewire (I think that's what it was called?) that let you write very PHP-like server-side JS.
(It was terribly unstable, by the way.)
(It was terribly unstable, by the way.)
That was before async was discovered, an innovation by the Node development team.
Irony does not work well on the interweb, my friend.
To clear things up:
a) the Node team did not invent async programming
b) you kill the event loop, if you spawn it per request using CGI
To clear things up:
a) the Node team did not invent async programming
b) you kill the event loop, if you spawn it per request using CGI
Yes, let's discredit everything the Node community has done.
I only remember the server supporting Java servlets and Perl/sh/etc. CGI. Was there a JavaScript interpreter/runtime built into it, too?
I am actually just 2 years older than this thing, but Wikipedia said so, yes.
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.
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.
Does it actually use a new node.js process for every request? I thought that node was kinda slow to start up because of the JIT and so forth.
Using '<?' for embedded code is generally a bad idea since it conflicts with xml. PHP has had it disabled by default and not recommended for years.
This might be a good time to post the link to Facebook's XHP
https://www.facebook.com/notes/facebook-engineering/xhp-a-ne...
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.
https://www.facebook.com/notes/facebook-engineering/xhp-a-ne...
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.
> show one of the ugliest parts of PHP, and that is when presentation becomes super tangled with business logic
You seen jsx?
You seen jsx?
Have you heard Pete Hunt's angle on "Separation of Concerns" vs. "Separation of Technologies"?
imo JSX doesn't fall into this trap, it just looks like it should.
His JSConf EU talk is worth a watch if you're interested: http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be... (slides: http://www.slideshare.net/floydophone/react-preso-v2)
imo JSX doesn't fall into this trap, it just looks like it should.
His JSConf EU talk is worth a watch if you're interested: http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be... (slides: http://www.slideshare.net/floydophone/react-preso-v2)
Oh, I love JSX.
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
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
apt-get requires root and can set up an http service as part of the installation. uploading it doesn't do that.
Thanks for the clear explanation!
how would you install node modules though?
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.
Is there a real use-case for this? IIS has run server-side JS for years, and nobody's really using it.
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.
[1] - https://github.com/tjanczuk/iisnode
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.
[1] - https://github.com/tjanczuk/iisnode
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???
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.
Sometimes, I wish people did not hack for the sake of hacking.
This is wrong way.
Keep Node.js where it has to be
Diversity is a good thing.
Using 90s technologies with node is not really diversity, it's punishing yourself on purpose ...
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.
On the garbage bin?
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.
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.
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 ?
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."
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."
That's 750 per month (a nice round number to cover a 31 day month):
https://devcenter.heroku.com/articles/usage-and-billing#750-...
https://devcenter.heroku.com/articles/usage-and-billing#750-...
How is that different from 2012 (or earlier)? I've had stuff on Heroku for years, never had a problem with this.
I like this idea, especially for a replacement if you want a quick, single file script online and don't want to use PHP.
Does anyone know if there is something similar to this but with FastCGI?
Does anyone know if there is something similar to this but with FastCGI?
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.
Did a Node module a while back to include PHP scripts in a node environment. https://github.com/digplan/php-node
I still prefer PyHP: http://www.ccraig.org/software/pyhp/manual/sample.html
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.
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 recently re-wrote my blog (https://blog.cesarandreu.com/) to take this approach. Repo: https://github.com/cesarandreu/trois-blog
The client bootstrap code that's used on the server is in client/middleware.js. Aside from that it reuses the exact same code.
I recently re-wrote my blog (https://blog.cesarandreu.com/) to take this approach. Repo: https://github.com/cesarandreu/trois-blog
The client bootstrap code that's used on the server is in client/middleware.js. Aside from that it reuses the exact same code.
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.
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 think the only thing missing would be automaticly including PHP.js
I much prefer meteors approach to all this.
AddHandler bugs again?
[deleted]
[deleted]
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."
We replaced that with "CGI" in the title.
Because a large section of the php ecosystem is cgi and inline HTML. That was part of the original appeal and the reason it endures on budget hosts.
What's considered a budget host in 2015 when I can get a digital ocean server to do with as I please for 60$ / year
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.
See: GoDaddy hosting, BlueHost/DreamHost/Hostgator, etc.
I guess budget would imply a skill level as well, good point.
This doesn't seem to replace PHP whatsoever.
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.
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.
PHP can run as CGI, original Apache deployments ended up being that way. Then everyone switched to mod_php/fcgi deployments.
Now you have function(amount){
console.log(amount + " problems.");
}
console.log(amount + " problems.");
}
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.
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.
Node.js's sole purpose was to lower the barrier to entry of server-side development.
async nature of nodejs, prototype based OO, callback hells and scope chain make JS harder than Ruby and Python, IMHO.
I dont think nodejs lowers the barrier. Or am I mistaken?
async nature of nodejs, prototype based OO, callback hells and scope chain make JS harder than Ruby and Python, IMHO.
I dont think nodejs lowers the barrier. Or am I mistaken?
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'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
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.
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.
[deleted]
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?
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?
Node.js is great for REST API development but hey who's using those these days right ?
But I agree that this project fixes a non-existing problem.
But I agree that this project fixes a non-existing problem.
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.
Use cases like Walmart, LinkedIn, Paypal, Ebay, the New York Times, Uber, Voxer, Microsoft and Yahoo?
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.
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?
I think we have a nomination for the best troll of the year already. :-)