7 ms·
PHP in a JavaScript world
- zer00eyz 11y agoWordpress, 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.
- k__ 11y agoPHP 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.
- audessuscest 11y agoI 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")
- sonnyp 11y agohttps://ghost.org/ https://ghost.org/
- audessuscest 11y agohttps://news.ycombinator.com/item?id=10127715 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."
- mellett68 11y agoI agree from my experience with Ghost but attribute it to being a young platform.
- delta9 11y agoIt's not open source, i cannot checkout it and start building something with it...
- joshuacc 11y agoPersonally, 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.
- audessuscest 11y agoThat's not true for a simple reason : Many people who use these front-end tools, still use PHP to build website (like I do)
- joshuacc 11y agoSure. 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."
- audessuscest 11y agoSorry 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.
- BrianDGLS 11y agoI 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.
- delta9 11y agoIt'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) ?
- maratd 11y agoPHP 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.
- debaserab2 11y agoVery 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.
- maratd 11y ago> 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.
- Killswitch 11y agoI disagree. Laravel is a huge community, and that's just a framework, lots of people writing things from scratch in PHP still.
- debaserab2 11y ago> 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.
- audessuscest 11y agowell, most node apps rely on many node lib, which is not very different than relying on a framework like symfony.
- deleted 11y ago[deleted]
- scriptproof 11y agoYou 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.
- zer00eyz 11y agoServer 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.
- untog 11y agowhat 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.
- xlm1717 11y agoPython 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.
- delta9 11y agoYeah I need my job !
- sheldor 11y agoNow, that's the attitude. Learn one language and pray not to be killed.
- audessuscest 11y agoGraphQL on Drupal https://www.youtube.com/watch?v=p3gMSnaZrp8&feature=youtu.be https://www.youtube.com/watch?v=p3gMSnaZrp8&feature=youtu.be
- pekk 11y agoWe'll always have PHP like we still have MUMPS.
- meritt 11y agoAnd 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.
- krapp 11y agoAs a server-side language, PHP has pretty much killed Perl, hasn't it?
- chucky_z 11y agoserver-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!
- stephenheron 11y agoI 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!
- Theodores 11y agoThis 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.
- Killswitch 11y agoI've been a PHP developer since 1997. December of 2014 I left PHP completely for NodeJS. Best decision of my life.
- wvenable 11y agoI'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.
- Killswitch 11y agoIt'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.
- wvenable 11y agoI'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.
- RossM 11y agoIt'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.
- imakesnowflakes 11y agoJavaScript or not, something has got to replace that abomination.
- greenleafjacob 11y ago> 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.
- ergothus 11y agoI 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.
- kenOfYugen 11y agoFrom 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 http://imgur.com/NnQ9M5v [1] http://link.springer.com/article/10.1007/s00607-014-0394-9 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"
- tnash 11y agoOne 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=peak&test=db https://www.techempower.com/benchmarks/#section=data-r10&hw=...
- cfv 11y agoMy biggest problems with the article a) He's talking about "PHP" and referring to old versions of plain vanilla PHP. He also talks about The Event Loop like it's a Node only thing: There exist such things as ReactPHP and Icicle which implement the concept. Modern PHP also comes with constructs to help with an async design b) Node doesn't include websockets support by default either, and the comparison is made against Ratchet when it could have been made agains hoa/websocket which is both more idiomatic and nicer. As a sidenote, check them out, they make nice things. And finally, the author marks an advantage in sharing environments when talking about languages, not runtimes. Which in and by itself is more of a curiosity. While it could be possible to inject a PHP runtime in the frontend (and some projects like the RippleSDK somehow did), it wouldn't make sense; they don't really have the same purpose or origin, one was born in the frontend and shoehorned into the backend, and the other was born in the backend and stood there. The way I see it, it's ultimately a matter of added value. Why doesn't anyone actually make an Icicle vs Koa comparison? Or maybe Symfony vs ROR? There is very little to learn from putting a toolkit (or even just the amount of tooling) against a bare language, and when people do it over and over and over it becomes clear it's just a disingenuous attempt to make the X in "PHP vs X" look good.