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

41–50 of 61 posts

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

#41

Post by deckiedan »

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…

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' every hour. You can also do things like transient cleaning once a month, or whatever else, and running the WordPress fake cron.

You can then disable wp cron, which saves network resources.

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

#42

Post by lioeters »

Due to the ubiquity and ease of hosting PHP, and the current shift to full-stack JavaScript frameworks, I predict a long transition period where various "bridges" will be made to interface between the two. Mainly I'm thinking of PHP-side exposing content via REST APIs, with a more modern frontend written all in JS.

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

#43

Post by jbrooksuk »

lioeters wrote: post #42

Due to the ubiquity and ease of hosting PHP, and the current shift to full-stack JavaScript frameworks, I predict a long transition period where various "bridges" will be made to interface between the two. Mainly I'm thinking of PHP-side exposing content via REST APIs, with a more modern frontend written all in JS.

Where I work we use PHP 7.0/7.1 with the Laravel framework and Vue.js as the front end. Works well for us!

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

#44

Post by jbrooksuk »

combatentropy wrote: post #39

I maintain a mountain of PHP. What attracts me to JavaScript is its syntax: PHP: $fruit = array('apple', 'banana', 'orange'); $fruit_colors = array( 'apple' => 'red', 'banana' => 'yellow', 'orange' => 'orange' ); JavaScript: var fruits = [ 'apple', 'banana', 'orange' ], fruit_colors = { apple: 'red', banana: 'yellow', oranage: 'orange' }; That's like 20,000 fewer keystrokes and much easier to read. My favorite new fe…

PHP has had square brackets for arrays since 5.4.0

    $array = []

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

#46

Post by dagn »

combatentropy wrote: post #39

I maintain a mountain of PHP. What attracts me to JavaScript is its syntax: PHP: $fruit = array('apple', 'banana', 'orange'); $fruit_colors = array( 'apple' => 'red', 'banana' => 'yellow', 'orange' => 'orange' ); JavaScript: var fruits = [ 'apple', 'banana', 'orange' ], fruit_colors = { apple: 'red', banana: 'yellow', oranage: 'orange' }; That's like 20,000 fewer keystrokes and much easier to read. My favorite new fe…

A few months ago I was tasked with porting an internally used Node.js script to PHP 5.6. The code made heavy use of nested async callbacks and other patterns frequently only seen in Javascript codebases. I thought I'd have to rewrite most of it from scratch, but the PHP code ended up nearly identical to the original Javascript. Line-for-line, ignoring minor syntactical differences (like the $ in vars), these two ~400 line scripts ended up being 98% identical.

Anonymous functions, closures, async calls, syntax short-hands... PHP has it all.

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

#47

Post by omnimus »

mysterydip wrote: post #22
krapp wrote: post #15

Earlier quoted context omitted.

>Don't people use frameworks these days such as symfony, silex and laravel etc 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 ne…

Honest/naive question: why not? Plenty of mvp or weekend projects can get by easily with url=page. If it's faster and simpler, what's wrong with doing it? Surely there's room for both on the intetnet.

Ive read somewhere interview with original author of PHP and he was very strongly against routers and one point of entry index.php . Saying that they are doing webservers job again. Router makes php slower.

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.

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

#48

Post by mysterydip »

colemickens wrote: post #30
mysterydip wrote: post #22

Earlier quoted context omitted.

Honest/naive question: why not? Plenty of mvp or weekend projects can get by easily with url=page. If it's faster and simpler, what's wrong with doing it? Surely there's room for both on the intetnet.

How exactly is it either faster or simpler...? Especially when any of the frameworks just come with it configured out of the box? 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".

krapp said so in the comment I replied to, I was roundabout quoting that.

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

#49

Post by Daishiman »

camus2 wrote: post #34
Daishiman wrote: post #16

Earlier quoted context omitted.

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

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

#50

Post by krapp »

combatentropy wrote: post #38
krapp wrote: post #23

Earlier quoted context omitted.

Having a router allows you to not have all of your files be web accessible, by using a single point of entry and a whitelist for all possible paths. Most projects which map PHP files to URLs have everything in the web root. 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'…

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

Post reply on HN