CGI Using Node.js
cgi-node.org
cgi-node.org
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
(It was terribly unstable, by the way.)
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.
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.
You seen jsx?
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)
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
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.
On the topic of this site though, 3 exclamation marks on the title? Really???
Sometimes, I wish people did not hack for the sake of hacking.
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.
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.
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 ?
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."
https://devcenter.heroku.com/articles/usage-and-billing#750-...
Does anyone know if there is something similar to this but with FastCGI?
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 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.
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.
I think the only thing missing would be automaticly including PHP.js
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.
console.log(amount + " problems.");
}
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'm not saying it's a good or bad thing, I'm just saying that's how it is.
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?
> 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
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 I agree that this project fixes a non-existing problem.
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?
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.