PHP vs. Node.js: the Battle For Developer Mind Share
snydeq writes: Simplicity vs. closures, speed of coding vs. raw speed — InfoWorld's Peter Wayner takes a look at how PHP and Node.js stack up against each other. "It's a classic Hollywood plot: the battle between two old friends who went separate ways. Often the friction begins when one pal sparks an interest in what had always been the other pal's unspoken domain. In the programming language version of this movie, it's the introduction of Node.js that turns the buddy flick into a grudge match: PHP and JavaScript, two partners who once ruled the Internet together but now duke it out for the mind share of developers."
This would be the worst movie ever.
I actually RTFA and found it to be completely useless.
But so does PHP. In this battle, whoever wins, we lose.
PlusFive Slashdot reader for Android. Can post comments.
These two languages each have their own use, and to chose between them you should not ask which is better but which is closer to my use case.
PHP, for all its problems, is still a very useful language for developing web sites, if only for the quantity of tools (frameworks, cmss, etc) available and their quality (far from every php tool is good, but you can easily fond a quality tool for each category: symfony 2 is a very good oo framework, drupal and ez publish are good cms...).
Node is younger, and does not have such a toolset. Sailsjs is a good framework but far from mature.
But it does what php can’t: a nodejs application is its own server and runs continuously, instead of being a set of scripts that must reload everything with each request.
It makes it a very good language for real-time uses, like the back-end of a small multiplayer game.
PHP is far more available in cheap hosting solutions. The apps are simpler to deploy (simply put them along your static html files in a web server that supports its extension), and simple apps are simpler in php. The ecosystem around was not touched in the review, Compose vs npm, joyent vs the community behind php, the future of both platforms.
In the other hand, PHP is (or at least, used to be recently enough) a fractal of bad design
Man I've read articles where the author didn't know what they were talking about and was just stacking points, but they're made here with such assertiveness and surety that I started doubting reality. +1 great trip, no mushrooms required.
This isn't merely useless, nor just bad, it's completely misleading. For it may look like he's giving the high-level, the author appears to have no depth to draw on to say more than the shallowest things. As such, he's presenting pond scum, not the high points from an expert deep sea fisher.
And this is pretty bad, given that infoworld says about themselves:
while the TFA says about the author:
I'm loath to seek out his writing, in fact fairly convinced to stay well away, while at the same time morbidly curious just how bad his "more than 16 books" will misinform.
TFA is a bunch of blabbering from someone who has no idea what he's talking about - void of anything useful.
To get this out of the way:
Node.js is a serious contender to topple PHP off the server-side, for the simple fact that we would then have one PL less in the entire webstack, which is way to
complex anyway.
I myself have been pondering trying out Node for larger non-trivial projects. I'd be the first to switch if it were possible.
I haven't yet - Node is just not quite ready for prime-time.
Why?
1.) The tools don't exist yet and Node seems to gather the same problems Rails has: A bloated, instable and unreliable mumbo-jumbo of countless libs, tools and extensions - various package managers included, each built on a whim and powered by a neat logo and a 6-week fad that sweeps the community and adds to the mess already there. In short: The Rails problem of to much navel-gazing and not enough of solving real world problems.
2.) Callback hell.
In fact, its Node/JavaScripts callback hell that made me realise a thing that is so great about PHP: What you see is what has been made, for you, for that specific request. LAMP is such a bizar solution no one in his right mind would suspect it could work, yet most site on the internet run on it. The stack is so vertical it actually makes any Java solution look like an ADHD driven Visual Basic School projekt in comparsion. And I mean vertical right down to the way it actually works!
Try building anything like Joomla or Wordpress with other solutions such as JS and you'll end up with problems that completely leave the domain of your work. The simple fact that a PHP request is dead and gone when its finished sending its request reply and all the rest it offers is custom built around any strange problem the
Any concern you have right at the moment when developing for ther server side web PHP has neatly covered ... ok, forget I said neatly, ... but covered and everything else is put aside. PHP is born out of a template engine, and as bizar as it sounds, that's its advantage. Any problem the Web domain can come up with puts PHP in a very strong position. Serverside things PHP just shrugs of with some strange custom internal function has JS and Ruby tripping and falling flat on their face with no chance for rescue.
3.) PHP is 10 years ahead of the game. No joke.
Try finding a product like Typo3 or Wordpress in Java, Node, Rails or any other backend runtime you fancy. Won't happen. It take me 5 minutes to download Typo3, 2 hours to set up - mostly because configging Apache and setting up T3 is an arcane science unto itself - but then it's there. Everything I would ever want for a web product.
Joomla, Drupal, Wordpress and co. are even way easyer. The only other contender holding up is Pythons Zope/Plone. All else is a decade behind at least. Rails included.
Bottom line:
As soon as Node gets their shit sorted out and offers a serious upside vis-a-vis LAMP, PHP is going to continue to rule. It gets the job done. Node and Rails don't. End of Story.
We suffer more in our imagination than in reality. - Seneca
Any dynamically typed language that isn't just used for scripting (your perl is probably okay) should be taken out to pasture and shot. JavaScript used to be okay; then application development came and it should go die in a fire.
-SaNo
But seriously, PHP is a dying language. We should let their developers pass.
No no no, you did that wrong!
Kosh: It is a dying language. We should let it pass.
Sheridan: PHP, or Node.js?
Kosh: Yes.
"Python - No way in hell .. the language has to bend to my will, not me bending to its will."
Few languages bend to your will, some learning is always required. I'm not terribly convinced the learning curve for Python is less than for PHP/Javascript given that those two have so many dangerous nuances that it takes years to truly understand them and develop with them without falling victim to their countless pitfalls. If you don't like the syntax of Python that's fine, but it's hardly a compelling technical argument not to use it over PHP and Javascript.
"Java - Antiquated and full of perversions, along with the spectre of Oracle hanging over you."
Java is antiquated? It was first released in 1995. That's the same year that both PHP and Javascript turned up you realise?
As for perversions, what perversions exactly? It's a pure OO language and sticks to that properly. Compared to Javascript that really doesn't know what it is and has functionality that's basically broken like closures because it tried to do away with explicit pass by value and pass by reference meaning you need to do horrible hacks to force creation of a new scope if you want to pass by value into a closure rather than have a variable captured.
PHP? It's about as perverted as you can get. It started out basically like C for the web, but without the difficult stuff. Then it did exactly like C++ and tried to glue OO on top, only C++ kinda worked because it was done by a competent computer scientist whilst PHP had it's OO tacked on by a mob of wannabes.
Out of the 3, Java is no older, and is the only one that actually determined and stuck with a consistent and planned design philosophy. Your criticism therefore seems to be wholly nonsensical in the context of comparison against Javascript and PHP. The very fact that Javascript was rushed out with a similar name in the same year as Java to cash in on it's hype should at least tell you something about the quality of Javascript as a language if nothing else.
"C/C++ - I know it is done, but would you?"
It really depends what you're doing and how competent you are.
"C#/VBV.Net - Even with MS opening up things .. "It's a trap" /Ackbar"
If it's a trap then it's a pretty poor one because they keep on open sourcing more and more of it. First they go and make the language a real actual standard, and then they start open sourcing the framework whilst giving Mono their explicit blessing.
Microsoft now isn't Microsoft the 90s, it has realised that it needs C# to be runnable in as many places as possible like Java, hence why they opened up the core and plan to open up more and more of it. Nadella knows they lost the smartphone war, and he knows that Windows Server hasn't taken over the server world. He knows that the only way to get a foothold in these areas is to at least take what it does well there - development tools and technologies. The newest version of Visual Studio even supports Android development.
You seem to have pulled together a list of pretty weak criticisms of each language and pretended that's justification not to use them over PHP and Javascript despite PHP and Javascript both having glaring deficiencies that make the negative considerations you pass off as fact above wholly irrelevant in the grand scheme of things.
Each technology has it's merits, but saying I'm going to use a technology with 100 deficiencies because the alternative has 1 deficiency seems to me to be a bit short sighted (no zealots, please don't take the 100 to 1 literally, it's intentional hyperbole to make a point).
At the end of the day we're stuck with Javascript on the client for the foreseeable future and that doesn't bother me too much. But why use it or PHP on the server when there genuinely are just all around better alternatives for that particular case?
I don't even buy the Javascript on the server because you can share code with the client thing either - your server objects automat