PHP in a JavaScript world | Hacker News Reader

PHP in a JavaScript world

blonde.net

33 pointschrisshennan58 comments

One thing that I don't see in these kinds of articles, and what I think is most important: MySQL speed. When I was researching technology, I compared simple pages that read some data from a MySQL database and display it on an html5 page. I did this in Go, Node, Silk, and PHP. PHP blew everyone else away. Now, this was two years ago, and perhaps their MySQL client implementations have gotten better, but this test was the reason my startup is built using PHP. It's the fastest thing available that isn't Java or C++ based. Supported here: https://www.techempower.com/benchmarks/#section=data-r10&hw=...

Wordpress, drupal, magento, phabricator, mediawiki, sugarcrm...

These are vastly popular, feature rich out of the box tools in PHP, aka the "killer apps".

As I don't follow the node community, what are the killer apps on the node side? Im talking about a complete piece of software, where I would want to set up an environment not for development but for running an application.

PHP was cool in the pre-SaaS era, where the only "cloudy" thing was renting webspace or server. You had to install and manage your Wordpress and co. yourself.

I think >99% of the people who wanted a website (blog/forum/etc) had to call an IT guy to get this running.

Now they just have to register for a SaaS and the most technical they have to do, is linking their domain to it.

I think 99% of the people wanted to link a domain to it, had to call an IT guy.

Probably, but fact is, renting a server and installing Wordpress on it ranges on another level than using a custom domain on a SaaS.

I 100% agree. That's what keep PHP so popular.

Similarly, Rails made Ruby popular.

(I won't call phabricator a "vastly popular, feature rich out of the box tools")

https://ghost.org/

https://news.ycombinator.com/item?id=10127715

"I will be honest. I use ghost as my blogging platform for about a year, and in comparison to wordpress... it just doesn't hold up. Everything from stuff as big as upgrading, mid range as plugins, and even simple things like spell check were overlooked (at least in the version I have). It kind of reminds me of the Pepsi Vs. Coke test. Went to it for that initial appeal of simplicity.. and now am very dissatisfied due to how much its lacking."

I agree from my experience with Ghost but attribute it to being a young platform.

It's not open source, i cannot checkout it and start building something with it...

Ghost is open source.

http://github.com/tryghost/ghost

Oh thank you for correcting me. I just saw the free trial things.. that has remind me wordpress.. and I run out..

Personally, I'd say that the front-end tooling ecosystem constitutes the "killer app":

- Minification: Uglify

- Transpilation: Babel/TypeScript/CoffeeScript

- JS Module Systems: Require/Browserify/Webpack/JSPM

- CSS preprocessors: Less/Sass/Stylus

- Linting: JSHint/ESLint/CSSLint

If you're using a lot of front-end tools, you're using Node. And if you're using Node, you might as well use it to write your APIs.

That's not true for a simple reason : Many people who use these front-end tools, still use PHP to build website (like I do)

Sure. And lots of people that use Rails still use it to communicate with Java-based backend systems. That doesn't mean that Rails isn't Ruby's "killer app."

Sorry i wasn't clear. I don't deny these front tools are node's killer app (they obviously are). I deny it is enough to make node replace php.

I agree.

At this time Javascript's biggest strength is build tools. It may not be as mature as PHP on the server, but there is so much community growth that I don't think it will be long catching up.

It's like saying PHP as a great community, we will catching up JAVA soon.. non sense, as the topic said, I want to use node if there are some killer app that I want to use, like the one I know in other languages. Do you know any like drupal for example (multilingual, workflow, content management system, and more) ?

On the contrary.

The fact that there's at least 4 "mainstream" build tools and their popularity changes every 6 months is a sign of an ecosystem with little stability that is no good to build a solid foundation.

On Ruby and Python land, how long has it been since RoR and Django have been the dominant players?

> And if you're using Node, you might as well use it to write your APIs.

No, not when I have access to all kinds of other languages, frameworks, libraries, etc to choose from on the server side.

These are not apps. And none of these are meant to run on a server like Wordpress. If you run less or babel compiler on production servers to serve CSS or JS well , you're not a serious developer.

Cloud9 I guess would be a good example of a killer app ,but that's no CMS.

The reason why there is no serious CMS with node is that nodejs development is extremely hard, because async programming is hard. No matter how much layers one puts on top of it (promises,generators...) you can't abstract async programming in nodejs.

Look at Go, Go routines can be totally abstracted. IF I write that code:

   result := Object.DoNonBlocking()

As a client of Object I don't have to know whether it is run concurrently, or not , or blocking or not. In node I have to know whether I returns a promise or a value , IE hump into the event loop or not.

PHP has its share of problems though,just like Go, but their concurrency model(or lack of) make things way more easy.

I can't imagine writing something such as Magento or Drupal in nodejs (with the exact same features). It would be just insane. A great challenge though.

PHP today is overwhelmingly being used to augment/modify:

> Wordpress, drupal, magento, phabricator, mediawiki, sugarcrm...

Very few apps are built from scratch using PHP unless the intention is to share the application code like wordpress, drupal, etc.

On Node, you're almost always building from scratch, rather than creating plugins for an existing application.

Apples and oranges. Different use cases.

Very few? There's plenty of apps out there written in PHP. You can do the same thing in PHP as you can in node. Writing from scratch is no greater of a use case for using node than it is for PHP.

> There's plenty of apps out there written in PHP.

Yes, there are. I didn't say there weren't. I think PHP is great, relax.

In my professional experience, however, I don't see people start a codebase from scratch in PHP anymore. It's almost always based on Node.

I disagree. Laravel is a huge community, and that's just a framework, lots of people writing things from scratch in PHP still.

> Very few apps are built from scratch using PHP unless the intention is to share the application code like wordpress, drupal, etc.

Err.. that's exactly what you said, no?

Well, yeah, if you work in a shop where node is the goto solution on the server side, that's going to be your experience.

well, most node apps rely on many node lib, which is not very different than relying on a framework like symfony.

There's plenty being built new on PHP today. Language allegiance is highly dependent upon age and location of the programmers in question.

You are comparing Apples and Oranges, PHP is a language, Node is a platform. Actually, Node.js is the killer app for the JavaScript language, among others. Implementing Unreal engine in asm.js is another thing you can not imagine to make in PHP.

Server side JS VS php, Node vs Zend engine would be cleaner semantics, but not perfect (nothing ever is)

Unreal engine in asm.js <<< this would be a "killer app" for the platform as a whole.

what are the killer apps on the node side

There aren't any, really. Coupled with NPM it's great for building your own platform with custom requirements, but if you want to spin up an instance of something that already gets you 90% of the way there, PHP is a better choice.

> The event loop is one of Node.js strengths as it makes it blisteringly fast when dealing with many connections. However the event loop does pose some challenges. One of the most important things to consider is that you should never block the event loop. [...] Now some great tools do exist for monitoring the event loop and if you understand the event loop and take care not to block it, then everything will most likely be fine. However you should be mindful of its strengths and limitations while developing.

I think the concurrency model provided by green threads in Go and Erlang is orders of magnitude easier to reason about, where you can write blocking I/O and the scheduler itself will take care of making sure that your code runs fine. The last thing I need when writing concurrent code is yet another thing to think about at every step of the way. This is a hugely underrated flaw in my opinion of node.js servers. With languages like Haskell, Rust, and Go we are seeing a trend of having smarter compilers and language runtimes making programs much easier to write, where I am offloading lots of things from my mind onto the compiler. The whole point of pre-emptive multi-tasking is to relieve the burden of "taking care not to block [the event loop]," and I think in that respect node.js is a step back.

I can see your point, and while I'm not versed in Go or Erlang, moving to JS let me stop worrying about if a value ever changed - as long as I'm in my portion of code, I alone can change the values. That, in turn, means that I spend very little time worrying - much less than I did in, say, Java.
Sure, I need to not BLOCK stuff for long, but that comes about somewhat naturally as good code: Write small, discrete units.

Not knowing modern multithreaded languages may render my entire point moot. I'll have to fix that.

I've been a PHP developer since 1997. December of 2014 I left PHP completely for NodeJS. Best decision of my life.

I'd love to play more with Node but I have free PHP hosting. I control the server completely but I have to keep PHP running. I don't how to get NodeJS to play nicely alongside bog standard LAMP stack (and all the rest of the tech) so I haven't done anything with it.

It's easy, just install Node. I mean, what complications are you having that you can't get it to work correctly?

Edit:// Also Digita Ocean $5 VPS is cheap to play with Node on, or even use a Vagrant machine.

I'd like to have node respond to port 80 http requests for one virtual site and have Apache/PHP respond for other virtual sites so I can use the hardware I already have available. I can think of a few hacky was to make it work but it seems less than ideal.

Obviously I could pay for other hardware but I don't want to do that.

"It's easy, just install Node." funny.

It's a fairly common scenario. We're doing this with nginxbut docker'll be a good solution soon enough. The terms to search for are "reverse proxy".

Essentially you setup nginx to listen on port 80, Apache to listen on another port (say, 8080) and node to listen on a different port (say, 8081). Then have your nginx config differentiate between the two:

    upstream apache {
        server 127.0.0.1:8080;
    }   
    
    upstream nodeapp {
        server 127.0.0.1:8081;
    }   
    
    server {
        listen 80; 
        
        server_name myphpapp.example.com;
        
        location / { 
            proxy_pass http://apache;
            proxy_set_header Host $host;
        }   
    }   
    
    server {
        listen 80; 
        
        server_name mynodeapp.example.com;
        
        location / { 
            proxy_pass http://nodeapp;
            proxy_set_header Host $host;
        }   
    }

IMO this gets a little easier to think about if you substitute your Apache -(mod_php)-> PHP setup for Nginx -(fastcgi)-> php-fpm - handing off to an appserver rather than a webserver.

I'm concerned about adding ngnix to the system as that's a fairly significant change to a working system. There are a lot of variables and sites involved.

I've considered reverse-proxying entirely within Apache to avoid adding ngnix another layer. But this really hinders some of the advantages of node which makes me wonder if it's worth even doing. It seems like node is best when it can handle the requests directly.

Your advice here is pretty much the most common answer.

> It seems like node is best when it can handle the requests directly

What makes you believe that?

Node's single process event-loop model of handling requests seems in direct contrast to apache's one heavy-weight process/thread per request model.

Vagrant is best for setting up development environments, that way you can have as close to a production style environment as possible. Along with this you can set private IP's for each project, so 192.168.10.2 can be your LAMP stack project, and 192.168.10.3 can be your Node project.

Python was supposed to kill PHP. Ruby on Rails was supposed to kill PHP. Now Javascript is supposed to kill PHP? Not a chance, at least in the near future.

Yeah I need my job !

Now, that's the attitude. Learn one language and pray not to be killed.

GraphQL on Drupal

https://www.youtube.com/watch?v=p3gMSnaZrp8&feature=youtu.be

We'll always have PHP like we still have MUMPS.

And PHP was supposed to kill Perl.

At the end of the day, all of the languages being discussed here are all capable of achieving the same goals for 99% of the problems presented. Every language has its pros/cons and brings something new to the table that we usually see the others adopt.

As a server-side language, PHP has pretty much killed Perl, hasn't it?

server-side as in... shell scripts/daemons?

or server-side as in... cgi/fastcgi serving to a client?

because I would say 'yes' to cgi/fastcgi, but 'no' to shell scripts/daemons.

There are a handful of really cool newish Perl frameworks, but unfortunately I think Perl 5's stigma is so far out there it will never gain any real traction. It seems that Perl 6 has a lot of the same stigma attached to it. I almost wish they would name it something other than Perl so that a fresh perspective could be used, it seems like it's going to be quite nice!

I meant the cgi part.

Anecdotal: as a shared hoster engineer I would say yes. Ten years ago there were loads of Perl apps running on our shared Linux and Windows boxes, these days it's a novelty to bump into anything written in Perl.

PHP pretty much killed Perl if you ask me. Perl is nowhere near where it was in the 90's.

This article doesn't say that JS is supposed to kill PHP. The last paragraph actually states the complete opposite.

From a more academic approach [1], if you care about efficient concurrency and no context switching between frontend-backend, the node.js platform is an excellent choice.

Figure: http://imgur.com/NnQ9M5v

[1] http://link.springer.com/article/10.1007/s00607-014-0394-9 "Is Node.js a viable option for building modern web applications? A performance evaluation study"

I wrote this article so please don't too harsh ;) Crazy to see something I wrote for our company blog on the frontpage of HN this afternoon!

This is a good article if you are a backend PHP developer working closely with someone that looks after the front end.

Personally I like these working arrangements and being able to dish up HTML safe in the knowledge that your frontend developer is getting what he needs complete with expected class tags and other markup to be styled. In the future it will probably be better for me as I won't be doing template files with fiddly PHP tags, instead I will be json encoding the requested data, e.g. an array of products. There is a whole lot of logic to getting that array of products, this you need the server for. Presentation of that data? That can be done with the new stuff. From this article I have a better idea of what might be the future.

JavaScript or not, something has got to replace that abomination.

Reply on news.ycombinator.com