PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?
belitsoft.com
belitsoft.com
Last time I launched a node app, it took me a full day of messing about in AWS. Last time I launched a PHP app, it took me less than a half hour at Siteground.
The performance characteristics of Node are completely irrelevant for most sites. The developments model's inherent complexity and the moving target, however, matters very much.
The vast majority of blogs that are build in Wordpress. Remove all the blogs and corporate websites and I bet that's not the case anymore.
And no, there's some pretty big, modern sites like Mailchimp which run on PHP.
There's literally no reason to use Node if you already have an effective backend with PHP because Node doesn't really bring anything new on the table, but it does bring along its own class of issues.
You can't write a production grade web socket server in PHP. and no ReactPHP isn't my definition of production grade. If your app is real time you just can't use PHP for that.
So yes, Node brings something new to the table.
You just said, Node brought nothing new to the table, obviously you were wrong.
I do concede that if PHP went away, WP would somehow survive, like some kind of post-nuclear cockroach.
You just lost a nontrivial percentage of PHP developers. Far and away the most compelling feature of PHP for a lot of their target audience is that the deploy model is "unzip this file in that folder". If I want to host my own web site but I don't want to "learn to program" there is no alternative.
it's more like "copy these files via ftp to this host" (p.s. that also includes your config.php with plain text passwords of course)
I got fed up with this a few years ago and started building http://bitmash.io (yes, shameless plug) which does some fancy filesystem manipulation to swap out the application's files during upgrades while otherwise looking like a perfectly ordinary PHP hosting provider. While I'm proud of this solution it still seems rather silly to have to jump through these sorts of hoops to handle deploys.
Tell me about it! It took me an entire day to figure out how to configure a WordPress install in order to allow it to self-update (without ftp). To do it by only granting owner and/or group write permissions, you have to figure out that you need to modify wp-config.php to define the "FS_METHOD" constant with the value "direct". Without this, WordPress code tries to be super clever with its umask settings, which only makes things worse.
It quite literally took an entire day to set up WordPress to self update. It's easy if you chmod 0777 nuke the entire install, but extremely complicated to set up with acceptable filesystem permissions. WordPress is designed to be sloppily dropped in a webroot, not to be installed by intermediate users who care about security. Well, as "secure" as WordPress can be. And to be honest, the most secure WordPress installation would be incapable of self-updating, as you're granting the web user write access to the entire installation - not just for updates, but for any vulnerability.
You can then disable wp cron, which saves network resources.
PHP:
$fruit = array('apple', 'banana', 'orange');
$fruit_colors = array(
'apple' => 'red',
'banana' => 'yellow',
'orange' => 'orange'
);
var fruits = [ 'apple', 'banana', 'orange' ],
fruit_colors = {
apple: 'red',
banana: 'yellow',
oranage: 'orange'
};
Even those less minimalistic than me, I think the draw to Node is the language, the consistency of having the same language front and back.
Much ado is made about which one is faster. But I would say roughly 99% of web apps are CRUD apps, with a few users per hour, and the bottleneck would be the database anyway.
For me what PHP has going for it is my familiarity with it. Plus, despite all the nitpicking articles, it is rock solid, especially compared to Node. And compared to Node, PHP is a hyper-organized library of everything you need, just an arm-length away.
$array = []Anonymous functions, closures, async calls, syntax short-hands... PHP has it all.
Node (and Rails, and Java and lots of others) use a declarative router. The app boots. Shit happens. Routes exist. Middleware is involved. There's no way to know what code is implicated in a given URL.
If you're a pro and you can afford to spend a year or so learning framework internals while not getting much done, you develop a sixth sense for where in the codebase an error is likely to be, but you need to spend many weeks and months scratching your head to get there.
PHP is much more beginner friendly in this way.
People should, Composer (with PSR autoloading) and nikic's FastRoute get you most of the way to a really nice, lightweight meta-framework barring anything else, for practically nothing. There really is no excuse for the "URL points to a file" model to be a thing anymore.
But a lot of legacy PHP code doesn't do that, and likely a lot of newbie code doesn't, because they follow old tutorials, and that model is faster and simpler.
Not even Wordpress uses routing AFAIK.
If it's just a small brochure site with a few pages then it's no problem, but forums and larger projects built like this can leak information and expose vulnerabilities when PHP files which weren't meant to be directly accessed are, such as pages that perform SQL queries expecting variables in context that don't exist when accessed directly, or old config files, text files, open directories, etc.
But "url=page" is still basically routing using the query string, and IMHO so is access control using .htaccess. Any system where URLs are validated and where they don't directly point to files on the server counts.
cough wp-config.php cough
Having a router may make it easier, but it's not the only way.
You can just put your libraries, passwords, etc., in some directory outside the document root.
/var/www/example.com/public
/var/www/example.com/lib
If you can keep it under control, though, of course it's no different than includes in C/C++ (it probably literally is a wrapper around the macros.) But modern PHP prefers using autoloaders, so you never actually have to use include statements to begin with. You could just as well define those directories and include them through a Composer setting.
Yeah, that's a pain. You have to exercise a little discipline. Of course none of my code has that ;)
With hand-typed routing, can't you accidentally define two routes that overlap, so some URLs could match both? The only reason it goes to one and not the other is something random like the order the routes are defined in the file? Like if you defined this route:
/a/b/c
/a/*/c
You can't do that with a filesystem, put two files in the same place.
To be fair, that's not random, that's pretty explicit. And if you're optimizing for speed, short circuiting at the first match is a good idea.
But if you're using a router, chances are you're passing the segments as arguments to some function or method anyway, so route /a/*/c and /a/b/c should both wind up returning the same content if the second segment in both cases is 'b'.
sure, if you're writing "Hello world", /index.php is great. For everything else? Not so much.
This reminds me of people saying "version control, that's too hard, I'll just make backups of the src dir regularly".
I think while it is easier to use files as routing first time you use php.. once you start learn how to program, simple router is much much easier to reason about. Simple router is not the problem when learning php. Problem is clunky language with lot of legacy stuff and that people start with something like laravel that has so much stuff in it that you have to learn 20 concepts at once.
WordPress is a perfect example of extremely poor code. Worth vomiting every time you think about it. No seasoned developer would put together a project the way they still have it. It has nothing to do with "backwards compatibility", or "easy to host with free/cheap hosts". It's not just "not modern", it's actually straight-up unacceptable. WordPress looks like it's put together by a group of php3 juniors writing their first script, having never held a professional job. That's not so much an opinion, as it is a factual assessment that any honest professional developer would give.
Now they shouldn't, but people jumping on JS often spin their wheels until they get pointed to a boilerplate project. It doesn't make for a fair comparison, but it doesn't matter.
Now they're trying to wrap their heads around six major libs with loosely overlapping concepts, four build and orchestration tools, and ten-plus scattered files... for "hello world." Then comes the generally miserable process of figuring out how to put it online.
Throughout this process the reference material is all at least three weeks old, making it hopelessly out-of-date.
I mean, this stuff is often referred to (even here) as a kind of dumpster fire. I can't imagine what a truly new person would think. So while I'm not starting any new PHP projects these days, it isn't hard to see the general appeal.
Apparently people are also happier using angular on the back-end. Which makes no sense. Also, pretty sure WP still runs PHP on the back-end. So much inaccuracy here.
Unlike normal node.js applications, the process is started and managed by the provider's web server and applications can be uploaded using a standard FTP application.
Here's a similar library: https://www.npmjs.com/package/node-fastcgi
Indeed from the last 6 years, companies are more willing to try out new technologies, like node, or even docker! But only places that can truly develop decoupled from the technology already used can jump on board for these things. The transition cost for adding other technology when decoupled is magnitudes lower than migrating an existing functioning production proven product.
I have my own opinion on NodeJS, but I give it credit for the tooling it has outside of production server uses.
PHP as a project includes a templating engine, a scripting language, and a lot of native code built without a modern approach.
node is a more scoped project. Doesn't implement its own scripting language, and doesn't include a templating engine and a lot of the stuff PHP does. It focus on doing a single thing well. The native part of it is libuv, which uses a consistent approach: non-blocking asynchronous I/O.
Many other projects also build on top of libuv and v8, and any improvements coming from those integrations ultimately benefit node.
In comparison, PHP is one large project encompassing everything. As a result, I won't expect PHP to move as fast. It's a larger project with lots of backward compatibility concerns to take care of.
I know that PHP has known large deployments but none of those run on the reference implementation. node.js does have large deployments running on its default implementation.
Node is great if you want shared state, there is no overhead to access state introduced by many users of your system. Making a game server of sorts seems like a good fit. It is also running on a proven technology which is battle tested by millions of users independently each day.
But, with the cost of trivial access to shared state, there is no isolation. A metaphor from the Erlang community is that it's tolerable to crash a one on one phone call, but not the entire switch and everyone connected through it. I have experienced existing software with space leaks which need to be restarted every week to remain operational in production with tolerable latency and resource footprint. It doesn't seem sane to me. (The example here is a channel pub sub server)
Indeed PHP for large deployments requires tuning or alternative implementations (e.g. HipHop) to be reliable and fast at scale. But one aspect PHP does that node does not is assume isolation. Isolation is not a guarantee, but if one page crashes, most of the time others are not directly impacted. If on PHP processes runs out of memory, same story. If one tries to starve the scheduler, it will eventually time out and be killed.
Your point on it having a legacy of many integrated parts is very true, and I share your conclusion on not expecting it to move fast.
Many developers are coming to the shared perspective that simple software should have simple extensible cores and it is okay to have multiple implementations for a class of features (e.g. templating). This model of independent reusable parts is where we will see fast moving technology grow.
Then, there are ways to mitigate the problems you describe. I know this first hand as someone who has been behind substantially large deployments.
While leaking resources like memory, file and connection handles is a problem, there are ways to find them and fix them. While a bit of discipline and rigor you can be safe. But a lot of people in the node community are usually disregard anything that cannot be sold and usually end up creating problems they cannot get out from. And usually make those problems worse by adding workarounds the problems they created.
With a little bit of good practices, unit testing, profiling, load testing, code reviewing, etc... something that you can achieve by still being able to have work/life balance, by thinking like an engineer instead of discarding every software engineering book you read at school, by paying attention to what you do and not allowing excessive complexity, you should be in a comfortable position to fix a bug related to leaks.
The problem are imprudent people that want to boost their careers by pushing features that do not implement non-functional requirements to get the favor of product stakeholders. That approach may work on frontend, may work on some contexts, but not on backend node software. That's the easiest way to have a cascading failure of servers on 100% CPU/100% memory usage beyond repair.
Usually those people come in one flavor: people that think that because they know JavaScript, they can write server software. That's not it. To write server software you need to know network protocols, operating systems, memory management, algorithms, databases, distributed systems, etc.