re: PHP vs Node? VIEW POST


PHP lets you create bugs and security issues super easily. The only consistent thing about PHP is its inconsistency. It is so bad that Facebook created Hack to make it usable. The only powerful thing about PHP is that it's Turing-complete, buy hey so is brainfuck.

That summarily covers my opinion of PHP.


Your comment reminds me these words from Rasmus, I quote "PHP is perfectly consistent, just not in the way you expect".


PHP is not for beginners, it's true. All people I know that agree with you don't know PHP.

It requires a strong tooling to be effective and be confident with your code. But it's still a valuable choice for backend apps.


PHP was actually helpful when I was a beginner in 2003 but actually better options came out and kind of exposed the fact that PHP will encourage dangerous behaviors. In fact, I can specifically thank phpBB for teaching me all the common security mistakes you can imagine.

Last week I spent hours fixing potential remote code execution issues in a very popular piece of PHP and that makes me very sad. Because this kind of problem is VERY easy to have.

Of course you can artificially throw away 3/4 of the language and base everything upon more or less decent community-built tools while praying that none of your juniors will create a colossal hole in your code but knowing the alternatives that's really not the choice I'd make.

As I said, it's definitely not for juniors. As an experienced PHP developer, I'm responsible for delivering safe apps with secured Apache configuration, built with clean code and tested in a pipeline. It's more difficult in PHP than in any other language, but I learnt so much more than if I had chosen the last all-in-one ready-to-go JS framework.
But if I had to choose a programming language to start my career today, it wouldn't be PHP.


With a clear and valid example please illustrate strate your point cause it seems to me that bugs can introduced regardless of the language used used unless there is another valid point please state it and produce a valid example


I would be curious to know the details of this security issue you spent hours on, and why the same mistakes couldn't have been made in NodeJS.

In other words, are you judging php because of the poor quality code that was written by the community years ago?

How many popular npm packages have been known for having major security issues?


In short,



Of course that was hidden over several layers of call stack so it was not so obvious, and the hours were mostly spent making an assessment of the server to know if anybody used it.

I'm not particularly fan of NodeJS but it's just that this kind of mistakes are super-easy to make in PHP despite all the goodwill of frameworks.

My problem with PHP is that the PRNG is unsafe, the way weak typing works is unsafe, the absence of unicode handling is unsafe, the fact that PHP is a templating language is unsafe, the silent failures are unsafe, ... Everything in PHP is unsafe.

It's just an example within an ocean but let's compare JS and PHP on weak typing.

if (0 == "bonjour") {
    // Will be reached in PHP but not in JS

By converting strings to integers and not the opposite, the typing system removes information and possibly creates security issues (this specific thing was used in phpBB to become administrator by modifying your session ID).

Of course you can ban == in your code but what about dependencies? What about some things in the standard library which will keep on doing == instead of === because it's more within the philosophy of PHP?

Of course NPM is not perfect and there is tons of flaws in it but the fact is that PHP is fucking terrifying.

JavaScript has numerous similar oddities, that could lead to unwanted behaviour when the code is written by someone who doesn't know the language:


In what language is it a good practice to compare a string to 0 in order to prove that it's empty or null anyway?

I agree that PHP is weakly typed, but the main issue here is the developer. I work with PHP developers and no one writes this kind of code.

PHP's reputation is mainly due to the fact that in the past many php softwares were written by script kiddies. People I hear dismissing PHP as a whole have no experience of modern PHP development.

JS is a good comparison because it's a really strong amateur language as well. And I'm not saying that it has no issues but rather that PHP makes very dangerous things very easy to do.

Of course, PHP improved a lot and many low-hanging fruits have been fixed. However let's have a look at this security issue form phpBB back in 2005. Yes it's old and yes a linter would fix it. But if someone wrote that code today the issue would still be there.

If you take the code, it goes like this (in short):

$sessiondata = isset($HTTP_COOKIE_VARS[$cookiename . '_data']) ? unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();

$auto_login_key = $userdata['user_password'];

if( $sessiondata['autologinid'] == $auto_login_key )
    // You're admin

So yes the stripslashes() is a funny reminder of a time that is actually over since PHP managed to get rid of magic_quote_gpc but that's not the point.

Some raw data from the user goes through unserialize(). Which means that $sessiondata['autologinid'] is from any type that the user deems. On the other hand, $auto_login_key is a string.

To answer your question, who would compare 0 to a string? Well, some hacker using unforseen side-effects in some code that looks very reasonable otherwise. Putting 0 in autologinid is equivalent to writing:

// Before implicit cast
if( 0 == "somekey" )

// After implicit cast
if ( 0 == 0 )

You're going to tell me that now we have JSON and frameworks and many wonders that help us not do this kind of things. But if you never saw a junior write a $_GET in some Laravel/Symfony code then you have not been looking. And the same goes for all protections brought by these frameworks, they are just too easy to bypass.

Now to be honest I don't like PHP and I don't like JS (especially on the back-end) so that's really more of an anti-PHP argument than a pro-Node one.


I found it interesting how people bash on PHP and don't seem to realize they bash on not even the wrongest part of the language. I worked a lot with PHP, from 5 and a little with 7. PHP is a One to One prototype from the underlying C library, making as consistent as C and C++. Here is a video that explains why youtube.com/watch?v=wCZ5TJCBWMg. In summary, PHP came at the right place at the right time and grew at the right pace, leaving behind inter-module consistency.

It also explains that yes, PHP was not and is not the fastest, but their strategy at the time was way better than faster and more "thoroughly though" languages like Perl and Python. And please, Javascript has been developed in such a hurry that it is way more of a mess than PHP (in my opinion).

And I never used it, but I thought HipHop from Facebook was a PHP compiler (don't know about Hack!).

What is the worst part of PHP for me:

  • weak/strong comparator (such as == or ===) ;
  • method overloading only possible using arrays ;
  • the way it implies if something is a string or a number or whatever ;
  • the memory footprint (at least with 5) ;

So for me, any loosely typed language makes it easier to create bugs. In such a case, there is always linters.


I mostly agree with you! My main point would be: why keep on working on Frankenstein while there is so many straightforward alternatives.

For the record, in 2010 I strongly stepped in favor of PHP for my projects, but things changed so that PHP doesn't make sense anymore (in my opinion, everyone thinks whatever they want)

That is exactly why I left the Web for Embedded system. I don't know for you, but I was a little tired of doing the same thing over and over again (CRUD stuff). Challenges in Web development, IMHO, is not in the code anymore but in the infrastructure.

Dealing with the 5 desktop browsers, the 18 mobile device formats (plus many browsers) was for me the bigger pain. It has been 2 years since I didn't do any web development per se, so maybe it got better.

All the Web is "hurried development" such as PHP, Javascript and "hey look a new device lets put a browser in it!" (like a refrigerator O_o). Browser version comes out every what, 3-4 weeks. This is pure madness.

C and C++ are not perfect, but at least when I work on an STM32 there is only one place my code will run, for one purpose. And I came to realize that embedded system, even though challenging and low-level, can bring high-value quickly to a device.


You can create bugs and security issues super easily with nodejs too.

In modern backend environments php is not used naked anyway, most of the time your framework will be based on secure and field tested components (mostly coming from Symfony). Laravel is based on symfony for example, you can also very easily create your own custom and secure framework using symfony components.

I would say that PHP is still quite valid as a backend OOP programming language. Especially with PHP 7.

NodeJS can replace php for the best in many areas where php used to be chosen by default, for a lack of better alternative, but that doesn't make php irrelevant. Not everything needs to be a micro service, and many projects use both php and NodeJS.


Yes, i really felt that NodeJS can replace PHP, i have had failovers in PHP where my website was attacked and stuff, but as far as NodeJS is going its going pretty smooth but because i came from PHP, i really find that PHP is a good language to start with in making good programming concepts.


PHP is uniquely bad in that the people behind it continuously make bad choices in designing the language. T_PAAMAYIM_NEKUDOTAYIM has existed since PHP 3 and is still visible as part of parsing errors today. It should be renamed T_DOUBLE_COLON but somehow still hasn't been, and the manual entry makes it seem like it's a cute and quirky feature of the language. Oh look! You have to know a very specific subset of Hebrew to work your way around the code!


PHP doesn't abort execution and show a 500 on error. No. Instead it just sends the half-finished paged with an error at the top that is guarenteed to break the page.

PHP wasn't designed with you running a server process, and any framework that tries to use PHP this way undermines itself completely by having to spend 98% of its development time working against the fact that they're trying to run a modern 3D game on top of SNES-like architecture. PHP was made to be the OG serverless language, running per-requests instead of as a daemon process. But even that very core feature of PHP was butchered.

No attempt has been made to standardize the signatures of standard library functions. Sometimes snake_case, sometimes pascalCase, sometimes nocase, sometimes the verb is first, sometimes the noun is - and for array functions, sometimes the array goes in first, and sometimes last!

PHP is the only language with a configuration file assigned to it. Not a list of language features to turn on/off, no. Configuration that will change the way the language works. Which means you can't take the code from one server to the next and expect things to work. You also have to take into account the configuration of PHP itself.

While JavaScript has its share of "wat"s itself, comparison in PHP, and more generally type coersion in PHP is a PITA, and that's a huge euphemism. Oh, and while JavaScript's == is weird but understandable, PHP's ==, oh boy...

These aren't usage errors, where the developer wrongly assumes something about the code itself and unexpected behavior emerges. These are weirdness coming from the language itself, which makes it extra hard to wrap your head around how to use the language itself, and as a result makes you more prone to errors.

Finally, someone will say "oh but language X or Y also has these quirky features". Oh it's okay then, some other language is weird in this aspect, therefore it's okay to put it in PHP. Therefore PHP really is Frankenstein's Monster of programming languages.

Oh yes. That and more.

On a sidenote I thought that T_PAAMAYIM_NEKUDOTAYIM was fixed in recent versions but it seems that it was actually not. 🤦

I'm surprised there is no other languages in the error messages though

To be honest, I like this historic, cultural error message. Even though it should be accompanied by a clearer error message. It is a simple error and explained when searched for at nauseam. That being said, I would never go back to PHP after having switched to Node.js with Typescript.


Yes, for example:

myFunc() {
    setState({ "number" : 1 });

The code is right, it compiles but it ignores the fact that setState is async. So it will act randomly.

And it is a basic example and it is a REALLLLLY common mistake.

Lolx rules are rules we didnt make em so we gotta follow em... I think what you might be embarking is creation if a new language above a language...

The evolution of assembly to java and beyond now

Yes, although it's mostly a front-end issue. On the back-end if you try to access DB data in a non-async way you'll quickly realize that the data is simply not there. I've been handed large amounts of amateur JS and there was MANY issue but not really that one.

The kind of issues that PHP enables are more like "let's execute this unfiltered user input" which is way more dramatic than a randomly-bugged front-end component.

The kind of issues that PHP enables are more like "let's execute this unfiltered user input" which is way more dramatic than a randomly-bugged front-end component.

Validating the user input is anything but trivial. But I don't think Javascript is doing it better. AFAIK, MVC c# it does it right, we could validate the type, the long, if it is present or not and such.

There are some libraries that do this job but natively both languages don't do their duties.



Oh well, I assumed that frameworks would make sure that req.param('name') is a valid unicode string while $_GET['name'] can be any string of bytes but maybe I'm expecting too much?

In any case, you can write stupid code in all languages. But to be specific to the $_GET issue, it's so easy to break encapsulation using it (because it's global). Same thing with $_REQUEST, what is the point of this except getting X-whatever-scripting attacks from all sides?

PHP is just next-level compared to anything else in terms of possible misuses.

Code of Conduct Report abuse