Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

belitsoft.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#51

Post by camus2 »

Daishiman wrote: post #49
camus2 wrote: post #34

Earlier quoted context omitted.

> The vast majority of web sites run PHP for better or worse and that code ain't going nowhere. 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.

You're saying that as if blogs and corporate websites weren't a humongous proportion of the internet. 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.

> because Node doesn't really bring anything new on the table

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.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#52

Post by cordite »

badminton1 wrote: post #33
cordite wrote: post #29

Earlier quoted context omitted.

Faced VB6 professionally, there are viable alternatives, but end users don't buy your software because of what technology you made it with, or originally made it with. They buy it if it works and does what they need. It comes down to viable transitions and the resources needed to make it happen. Indeed from the last 6 years, companies are more willing to try out new technologies, like node, or even docker! But only p…

You can imply node.js is not a viable production server solution. But you should rather be more explicit why. I am curious about your perspective. 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 do…

This perspective is only from my limited experiences with Node in writing and interacting with existing node software.

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.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#53

Post by wolfgang42 »

developer2 wrote: post #31
wolfgang42 wrote: post #28

Earlier quoted context omitted.

The problem with the "copy these files" approach, even more than dealing with FTP, is that the upgrade process winds up being "copy these files, but be careful not to overwrite any changes you made". Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself. I got fed up with this a few years ago and started b…

>> Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself 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 m…

The fact that doing a filesystem-level end run around is simpler and more reliable boggles my mind. When I started experimenting with it I thought "this will never work, there's all sorts of things that can go wrong" but I eventually wound up migrating all of my PHP-based applications (WordPress, Piwik, and PMWiki) to it because it was so much easier to work with (even with maintaining the control software) than doing it the standard way.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#54

Post by Daishiman »

camus2 wrote: post #51
Daishiman wrote: post #49

Earlier quoted context omitted.

You're saying that as if blogs and corporate websites weren't a humongous proportion of the internet. 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.

> because Node doesn't really bring anything new on the table 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.

Which is trivially compartmentalized through a Node proxy server that takes up at most 1000 lines of code. Nobody's throwing out their code for that.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#55

Post by combatentropy »

krapp wrote: post #50
combatentropy wrote: post #38

Earlier quoted context omitted.

> Having a router allows you to not have all of your files be web accessible 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 Then you use "include" to get them.

Having worked on projects with includes within includes within includes, and dealing with global variables defined in one file, used in another and reused elsewhere, it's definitely not the best way and it seems to destroy encapsulation. 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 auto…

> includes within includes . . . global variables

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
Then you slept, added a bunch of code, came back in three months and put this in:

  /a/*/c
Now you have two routes that match the same URL. And maybe they're separated by several lines of code, so that the mistake is hard to spot.

You can't do that with a filesystem, put two files in the same place.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#56

Post by camus2 »

Daishiman wrote: post #54
camus2 wrote: post #51

Earlier quoted context omitted.

> because Node doesn't really bring anything new on the table 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.

Which is trivially compartmentalized through a Node proxy server that takes up at most 1000 lines of code. Nobody's throwing out their code for that.

> Which is trivially compartmentalized through a Node proxy server that takes up at most 1000 lines of code. Nobody's throwing out their code for that.

You just said, Node brought nothing new to the table, obviously you were wrong.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#57

Post by krapp »

combatentropy wrote: post #55
krapp wrote: post #50

Earlier quoted context omitted.

Having worked on projects with includes within includes within includes, and dealing with global variables defined in one file, used in another and reused elsewhere, it's definitely not the best way and it seems to destroy encapsulation. 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 auto…

> includes within includes . . . global variables 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…

> The only reason it goes to one and not the other is something random like the order the routes are defined in the file?

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'.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#58

Post by badminton1 »

cordite wrote: post #52
badminton1 wrote: post #33

Earlier quoted context omitted.

You can imply node.js is not a viable production server solution. But you should rather be more explicit why. I am curious about your perspective. 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 do…

This perspective is only from my limited experiences with Node in writing and interacting with existing node software. 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 o…

First of all, what you seem to be criticizing are server frameworks such as express, rather than node. node does not impose a paradigm for how requests are handled in a web server. It only provides the building blocks for a web server framework. In theory it is possible to create a library that forks the process for each request, if so you prefer. I personally think that might bit a be inefficient.

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.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#59

Post by erikpukinskis »

jayflux wrote: post #12
erikpukinskis wrote: post #6

PHP uses an imperative programming model and has a very clear URL->source file mapping. This means you can look at the URL, find the source file, start at the top and trace your way to the problem. 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…

When's the last time PHP has been used in this way? Don't people use frameworks these days such as symfony, silex and laravel etc? And then point the web server to the entry point like with any other language?

I believe WordPress and Drupal still work this way by default? I'm not a PHP dev anymore.

Re: PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

#60

Post by developer2 »

deckiedan wrote: post #41
developer2 wrote: post #31

Earlier quoted context omitted.

>> Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself 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 m…

Use two users, and wp-cli. I've been doing this for years now. Php runs as a less privileged user, without​ write permission. If they want to install plugins, they need to enter the FTP name and password of the site dir owner user. Since the FTP connection is localhost, no passwords go over the wire in plaintext. Next, you install wp-cli, and add a real system cron job to 'wp core update', and 'wp plugins update' eve…

Personally I find ftp as an unacceptable protocol for this purpose. Doesn't matter that it's localhost. It just goes to show WordPress is truly aimed at the lowest common denominator.
Post reply on HN