31–40 of 128 posts
It's always pleasant to see PHP occasionally get a positive moment in the limelight on HN. It's oft scorned yet powers a very large chunk of the web. With the work done on 7 it's also one of the fastest scripting languages around and deserves a little more credit if I'm honest.
Earlier quoted context omitted.
out of pure ignorance -- what are the correct domains that either fit into?
nodejs is imho best suited for two groups of tasks: 1) APIs/programs relying on high concurrency and parallelism, especially where the handler(s) have to wait a lot for stuff like DB accesses 2) streaming (in the sense of websockets servers), PHP iirc can't even be used as a websocket server 3) Any API that can be implemented without needing too many async calls - you'll end up in callback hell or promise hell otherw…
And come on, for "job control" type scripts you should be fired for using PHP over Bash. Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, objects an methods that are called just one time etc, 1000+LOC PHP.
Earlier quoted context omitted.
There was a long time to catch up, yes. But HHVM did several big improvements to their JIT tech between then and now. PHP7 also rolled out with very little noise about stability, migration issues, etc. Not knocking FB at all, just noting the PHP folks did a nice job.
The PHP team is absolutely obsessed with backward compatibility. They broke surprisingly few things with PHP 7, and everything they broke was clearly documented. You don't get to power a significant fraction of the world's most important websites if you break backward compatibility every few months.
One thing that broke badly was phpunit and related libs for mocking etc.
This was a very vanilla PHP project by the way, no frameworks etc.
Earlier quoted context omitted.
It is also quite interesting the PHP introduced many (or at least some of us) to the ideas of server-less computing already 20 years ago. That's how I got started. I paid some small money for local ISP and got in exchange FTP user account and account on their shared MySQL Server. I would write my code and deploy via FTP. I believe some companies ran a cluster of servers, providing cloud like scalability for these dep…
That's not what the server-less idea is about. You're describing a standard shared hosting.
> Serverless computing, also known as function as a service (FaaS), is a cloud computing code execution model in which the cloud provider fully manages starting and stopping of a function's container platform as a service (PaaS) as necessary to serve requests, and requests are billed by an abstract measure of the resources required to satisfy the request, rather than per virtual machine, per hour.[1]
> Despite the name, it does not actually involve running code without servers.[1] The name "serverless computing" is used because the business or person that owns the system does not have to purchase, rent or provision servers or virtual machines for the back-end code to run on.
For example, nearlyfreespeech.net neatly fits even the pay-for-what-you-use billing definition here
Earlier quoted context omitted.
There is a project called ReactPHP [1] which provides a nodejs-like event loop and async execution. However, I think the power of PHP is that it is not designed to be its own server, to run forever in the background and handle all kinds of complex async flow. Execution stops when a request is done: no memory and data leaks between requests and easy to reason about. In practice you don't really need async, except for…
I am by no means an expert on the subject but use Ratchet ( http://socketo.me/ ) with proxying through nginx for my limited websocket needs. Works well.
I'm no expert either, but I just leave a note regarding Pushpin (http://pushpin.org/) here as an option to have a websocket server together with PHP. It's not a PHP project, but a good tool to have in the toolbox :)
It's always pleasant to see PHP occasionally get a positive moment in the limelight on HN. It's oft scorned yet powers a very large chunk of the web. With the work done on 7 it's also one of the fastest scripting languages around and deserves a little more credit if I'm honest.
Earlier quoted context omitted.
nodejs is imho best suited for two groups of tasks: 1) APIs/programs relying on high concurrency and parallelism, especially where the handler(s) have to wait a lot for stuff like DB accesses 2) streaming (in the sense of websockets servers), PHP iirc can't even be used as a websocket server 3) Any API that can be implemented without needing too many async calls - you'll end up in callback hell or promise hell otherw…
> PHP iirc can't even be used as a websocket server True, if you run it behind a web server like 99.999% of all users. If you run it as a cli script, you can implement pretty much anything. I saw a ftp server once. Crazy. Still, even on a normal web server, php can do long polling perfectly fine, which is often enough. > being able to write program flows without dozens of promises is a breeze It is a breeze with asyn…
Earlier quoted context omitted.
I wholeheartedly agree. I've seen many cases of PHP being scorned in favour of Node.js in problem domains where PHP is a clear fit (I've been guilty of this myself). It's not at all a bad language in the hands the right person.
out of pure ignorance -- what are the correct domains that either fit into?
For instance, I held a workshop where I hosted a server the students were to do some requests to. I had written a simple Node application that read the json they sent and returned a result. What I didn't anticipate was that them sending malformed json would bring the whole server down. So then I had to add error handling and stuff. Of course one should normally do that, but in PHP the malformed requests would just fail, leaving other requests unharmed, which would be acceptable for this kind of project.
Earlier quoted context omitted.
PHP is a whole lot more than just a templating engine. I think you would find that much more effort than is required just to make some templates.
Perhaps you can send me down the righ path? I want my users to be able to send emails from their iPads, and those emails would be generated based on templates. There will be many such templates built in, and eventually users will be able to hire web developer-type person to make custom templates. My thinking was that PHP is the most popular language for that sort of thing, so it would be nice if could support that. M…
Earlier quoted context omitted.
out of pure ignorance -- what are the correct domains that either fit into?
PHP started out as a language you could embed into otherwise static HTML via SGML processing instructions. While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious tags and PHP placing it…
> PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks.
You can make these beginner mistakes in any language that outputs HTML to the browser, and accepts user input via the browser.
I'm not specifically defending PHP here, but I hope you're not implying that these problems don't exist in Ruby, Python, Java or even Node for that matter...
The issues you are describing are unsafe coding practices and have nothing specifically to do with how PHP works, and it's "trivially easy" to make those mistakes in almost all web programming languages.
It's also not true that PHP "can't escape the strings it injects into HTML". There are standard library functions to do this (and have been for probably 10+ years, since the late PHP 4 days), as well as many well-tested community packages to do this at the framework or application level.
Also your explanation of "plugins" and "themes" is a concept tied to applications such as Wordpress, Joomla, and other CMS products (and again are not concepts specific to PHP).
It's certainly true that PHP's low barrier to entry has led to many badly coded websites getting onto the Internet, but I think it's ignorant to claim that PHP can't be used correctly and safely to develop web applications, or that most of the problems you describe are not easily avoidable.
All languages and frameworks have their pros and cons, and their caveats, but it helps no one when people spread FUD and outdated (or straight-up false) facts about web development.
Whether you code in it or not, you should probably refresh your knowledge of the PHP language and ecosystem if you're going to make public statements about how it works and what it can and can't do.