Live data from Hacker News

PHP in a JavaScript world

blonde.net

41–50 of 61 posts

Re: PHP in a JavaScript world

#41
post #2

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.

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.

Re: PHP in a JavaScript world

#42

> 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 like…

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.

Re: PHP in a JavaScript world

#43
post #2

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.

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.

Re: PHP in a JavaScript world

#44
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"

Re: PHP in a JavaScript world

#45

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.

Re: PHP in a JavaScript world

#46
post #2

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.

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.

Re: PHP in a JavaScript world

#47
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=...

Re: PHP in a JavaScript world

#48
post #7
post #2

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.

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.

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.

Re: PHP in a JavaScript world

#49
post #31
post #20

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.

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.

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

Re: PHP in a JavaScript world

#50
post #35
post #31

Earlier quoted context omitted.

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!

Post reply on HN