PHP 7 Virtual Machine
nikic.github.io
nikic.github.io
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 otherwise
PHP on the other hand has other use cases:
1) stuff that needs to be massively and easily deployed - you can grab PHP/MySQL/Apache hosting everywhere for either dead cheap or totally free. Examples include Wordpress, Drupal and MediaWiki
2) stuff that is highly complex in its flow. If your API requires dozens of DB calls, filesystem access, networking or just involves thousands of SLOC, you're better off writing it in PHP as it (since PHP5) carries a solid OOP stack - and even if you're not writing OOP code, being able to write program flows without dozens of promises is a breeze.
3) stuff that requires weird extensions to PHP. Basically there are bindings for everything and it's trivial to write your own binding to a library if it does not exist yet. For example, I have used PC/SC to interface with crypto smartcards, and it works surprisingly well.
4) shell scripts. PHP interpreters are widespread - OS X includes PHP by default and it's a $package_manager install php away on most Linux distributions. Perl and bash have their own strengths but honestly, Perl is outdated and PHP abstracts a load of stuff away, so you can write shellscripts that work on all major platforms without having to account for stuff like "does the OS have GNU grep, busybox grep or BSD grep".
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 async/await too.
PHP is in any case a better choice, performance-wise, than Python or, god forbid, Java.
All just to make PHP a little faster. I think you are making my case.
Many websites don't ever get to 350M users, so it's safe to say that plain PHP will satisfy your startup for a long time. Also, PHP7 is pretty much on par with HHVM in real-world scenarios: https://kinsta.com/blog/the-definitive-php-7-final-version-h...
[Maybe it was just a joke and I did not get it... or I did get it but did not identify it as a joke... however... I would like to see some beef...]
Yeah, I implemented a simple ircd once. Funny days... but I don't know of any library/framework that could help you with the websocket protocol level, and I'm too old for writing my own ;)
But you could use something like websocketd, which spawns a process of your chioce for each client and pipes the websocket to stdin and vice versa.
https://github.com/joewalnes/websocketd
Each PHP process looks like it takes about 5 MB of ram on my laptop, so probably not the best method for 5000+ concurrent users if you use PHP, but still.
FYI - http://socketo.me/
There might be a better way but I'd effectively added support for server push from our PHP app in a morning, with great results.
The other thing it provided me was clear evidence of the "best tool for the job" in a shop that demanded PHP.
The problem I have with PHP is what is usually touted as it's benefit. It's easy to find PHP developers. The problem: most of them are not very good.
To close, there are many more PHP RFCs that internals should approve, e.g arrow lambdas with automatic variable closure, design by contract, etc. These could really bring the language into it's own.
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 stuff like sending emails and heavy IO. Laravel simply handles this by pushing jobs on a message queue and handling it via a worker process, but you can use any microservice of course (in particular a simple node app).
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 :)
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.
Next to no one uses Perl any more. You won't find people to maintain your homegrown stuff - and aside from maintaining an OTRS instance I have not seen Perl code in a decade.
> 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.
Well good luck with Bash if your batch script involves stuff like parsing JSON/XML or interacting with databases. I prefer to write quick one-offs in PHP than wasting hours with Bash scripting; and even if it's no one-off but a script that needs to be run regularly (e.g. via cron), you'll find a competent PHP programmer for maintenance way easier than a competent Bash programmer.
> And come on, for "job control" type scripts you should be fired for using PHP over Bash.
For plain job control, like an initscript, I fully agree with you. But not for anything more complex, for the reasons outlined above.
On the plus side, PHP really owns managed hosting. You can install WP etc. via "panels" even without any admin experience and go from there by installing a mess of "plugins" and "themes" (which, due to lack of modularity, can do all kind of things to your site).
Node.js generally requires your own VM (there is no managed hosting) and due to it being run in a single process (or process cluster) generally requires that you know what you're doing so that a single error doesn't bring down your whole site. Its attractiveness comes from the fact that you can use JavaScript both server- and client-side (unlike PHP which runs server-side only). While Node.js has the edge in web apps, the options for content-driven sites are limited on Node.js; there's nothing like WP or Drupal for Node.js, and some say Node.js also lacks a canonical framework for rapid creation of database-driven web apps such as Rails or Django.
> 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.
I know there are libraries for HTML escaping, but I stand behind my statement that PHP's lack of HTML escaping is a fatal and unforgivable (almost criminal) design flaw when PHP's original use case, and distinguished feature vs. other general-purpose languages is dynamic HTML templating. In my opinion, PHP has gone the "get something quick out there and fix it later to become the dominant web runtime" route (which kind of worked), but without doing the actual hard work, and as such deserves to be called out.
Trailblazers often bear the brunt of learning through trial and error, and later adopters benefit from all those lessons learned. This includes the PHP language and ecosystem of today, that looks nothing like what you describe.
Also: show me a popular web programming language that prevents the problems you called out (at the language level, not the framework level). You can output unescaped input, or create SQL injections, in any language if you don't know what you're doing, or if you're using the wrong tools.
Again if you want to keep speaking on the topic, I encourage you to refresh your knowledge on the PHP programming language (and probably also on web development in general if you think other languages don't also have the same pitfalls).
Your concerns and opinions are literally 10+ years out of date.
Where languages like Ruby had Rails and Python had Django, PHP was able to do things quickly without having a framework on top of it. That, coupled with clear design flaws and a standard library that lacked, well, standardization, made it an easy and deserving target for criticism. PHP was also slow to adopt objects, namespaces, package management and other things developers came to expect.
Just try pulling data from a database and inserting it into a page on a way that is vulnerable to XSS in Django, Jinja, or Rails. You obviously can do it, but I bet you'll need to spend half an hour reading the documentation before you succeed.
The same happens for SQL injection, and session management issues, and a huge amount of other problems.
Your argument is valid too for any PHP framework, it's hard to do XSS in laravel, symfony or zend framework.
I think tpetry was pointing out the difference between a language and a framework built on that language.
(Replace language with whatever you think it is, it's still a subset just like Ruby on Rails is a subset of Ruby)
Correct me if I am wrong, but so does Node, Ruby, Python, etc...
Sure it was built for the web, in simpler times, but everything has to start somewhere. Now days, PHP is a completely different beast.
> Just not a very good one.
An opinion if fine, but it seems like you are deriving this opinion from old experiences (or maybe the old PHP hate bandwagon)
I think Node is also a framework, although there seems to be some controversy about this[1]. Ruby and Python give you standard libraries from which you can build a web server or templating engine or whatever, but it would be weird to say that made them Web Frameworks. Maybe things have changed, but last I knew PHP had a command line switch that tells it to not act like a web framework, because that is its default mode of operation. But you're right that it's been a few years.
I don't think I'm jumping on a hate bandwagon, but I am succumbing to someone-is-wrong-on-the-internet syndrome, which I know to be a mistake.
Although I can't resist asking - are you saying PHP is a good web framework? How does that fit with the idea that PHP is not a web framework?
[1] https://softwareengineering.stackexchange.com/questions/2991...
I think we have different definitions of frameworks. So no point in arguing over that.
> Maybe things have changed, but last I knew PHP had a command line switch that tells it to not act like a web framework
I honestly don't even know about a command line switch. I just write my script and execute it with the CLI (php test.php)
> I am succumbing to someone-is-wrong-on-the-internet syndrome
Please tell me this has a name
> Although I can't resist asking - are you saying PHP is a good web framework? How does that fit with the idea that PHP is not a web framework?
Not sure you exact intent, but as far as PHP being a good language to write a web application in, sure, it can be. IMO, it depends on the application and use of the application.
> PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.
I would focus on the core statement of the sentence which is "is a widely-used open source general-purpose scripting language". Comparing PHP to other HTML generators (re re re? parent: Django, Jinja, Rails) leaves out the entire concept of "general-purpose scripting language" and only focuses on "embedded into HTML" which while a main feature isn't the whole of it.
Besides, there's more to security than SQL injections and XSS. The PHP tooling is overflowing with bad practices.
For example PHP's PDO library makes it less convenient to supply parameters to a query the safe way than it is to do it the unsafe way. This is not necessary as can be seen from the excellent Ruby library called Sequel where it is just as easy to do things the safe way.
Another example is PHP itself being a template language, but which lack of automatic escaping makes it very dangerous to use. Since just one missing escape call in the wrong place can fuck up your day. To be fair PHP is not the only one who has fucked up here. This is also an issue with Ruby's ERB templates in the standard library, but fortunately Rails has added automatic escaping to its ERB templates.
One important thing about designing safe software is to make it easy for the end users to do things the right way, and here I think PHP has done a pretty poor job.
Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache. But you don't have to use it that way, and probably shouldn't. While PHP started as a template language, it has clearly moved past that.
Sequel's right way:
user = db['SELECT name FROM users WHERE id = ?', id].first
user = db["SELECT name FROM users WHERE id = #{id}"].first
$stmt = $db->prepare('SELECT name FROM users WHERE id = ?');
$stmt->execute([$id]);
$user = $stmt->fecth();
$user = $db->query("SELECT name FROM users WHERE id = $id")->fetch();
> Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache.
That is simply not true. Look at Twig which by default escapes everything automatically, or Rails's patched ERB which keeps track of escaped an unescaped strings based on data types and makes sure everything is automatically escaped in the end. In those template languages you need the explicitly do something unsafe to get an unescaped value. While in PHP you need to audit all places where echo can be called directly or indirectly.
$user = $db->find('user', 'first_name = ?', ['Name']);
PDO isn't "optimized" to do them the wrong way or the right way. Yes, it's less code to do it the wrong way, but that isn't a true definition of easier.
As for the escaping, I would expect Twig to escape things, it's want it's meant for (and the reason you use it instead of just vanilla PHP). And Rails is a subset of Ruby correct? So not a true comparison again.
I think anyone can show anecdotes to support "coding in [language you don't like] is bad".
Replace "unsafe" with "non-performant" and go back to early Rails days and you'll have plenty of examples where naive framework implementation led to programmers shooting themselves in the foot with the "easy way" in a different context..
Like I said, all languages and frameworks have their caveats and learning to code properly is the developer's job, and the "right way" or "best way" is often a work in progress that evolves as the community develops best practices..
Completely true, but for years PHP made it extraordinarily easy to shoot yourself in the foot right out of the box. register_globals for example...
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.
This question is what I mean, extra stuff one has to keep in mind: http://stackoverflow.com/q/5999373/923847 Does it matter for a real project? Probably not, just some boilerplate. Does it matter when I want something quick up and running? Yes.
I contest the idea that sinatra-style frameworks are "huge".
Python + flask is about as low-overhead as one can get. No need to set up any extra (apache || nginx).
PHP's model of "just chug along returning null" by disabling most relevant errors is a massive antipattern in production code.
It seems to be a bit light on advice in places. e.g. the section on comparison operators lightly mentions the difference between == and === but doesn't say anything about when they should be used. As that's one of the traditional PHP gotchas I would have expected more there.
Anyway, thanks; I'll check it out.
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 deployments.
> 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
Payment per month not per usage. Normally there are usage tiers and a "you reached your limit" page rather than scaling.
No versioning beyond standard file operations.
No routing. You get all traffic in a single endpoint.
Only web traffic, no integration. Serverless in many cases is FaaS, with multiple event sources, not web-request-handler-aaS.
Sure, there are some similarities. But the use cases are completely different. Nobody is seriously considering "should I use AWS lambda, or GoDaddy shared PHP hosting?"
IIRC it's after that time that PHP saw very important changes vm and language.
Ah, you mean good old PHP 4294967289?
Some of the nightmarish build configurations to get some Javascript projects going are just beyond belief.
Now I'm willing to believe that it's improved a lot since then, but it's got a very bad reputation to overcome, and it's deserved. The languages seems headed in the right direction at least, maybe in a few years we'll forget what PHP used to be.
I'm a long time PHP developer (well, was until recently - my current position is in the javascript/nodejs stack arena), and have been using it since the v3 days (so not there from the beginning, but close enough). There were some truly awful examples and code practices out there.
That isn't to say you couldn't write quality procedural PHP back in the day (had you configured your server properly and stuck with "best practices") - it's just that the majority of people hacking on PHP didn't. I'm sure there were a few that did, though - but I'm hard-pressed to recall any at the moment.
Today's PHP is a much different beast than yesterday's. The OOP model and other advancements makes things so much better, provided they are all used properly and followed. Now - could you make PHP 7 as ugly as 3? Sure. But you'd be insane to do so unless you had no other choice...
It's entirely, 100% possible to write good, clean, tested, maintainable code in PHP. But most people working with PHP, for whatever reason (and I'm sure there are many reasons), simply don't bother.
I suppose the same can be said of all languages, but PHP devs are the worst offenders IME.
This is the same quality of vapid criticism that is often levied against PHP, just in reverse, all that's missing is a link to a 'fractal of bad design' type of post. I'm guessing you're going to try and justify your comment with some version of "well my criticisms are actually valid", but hopefully I'm wrong.
Supposedly it's better now. I'm skeptical.
Compare PHP with say, Python. Tell me which one you would rather refer to.
I assume they are working with significantly fewer advantages and resources than Facebook, so that's a pretty nice result.
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.
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.
7.1 was where all the breaking changes got pushed as a result.
I think the difference is that FB was really focused on making sure HHVM ran for their internal use cases specifically, and broad compatibility was a secondary concern in the early days (and perhaps still is? I haven't looked at HHVM in a while).
To be fair, they were quite transparent about this, and published quite a bit of documentation around what worked and what didn't work when running PHP on HHVM so that was good.
Another note: if I ever catch you using these cute "finally ... interesting edge-cases" described in this article, your PR will be refused. Yes, yes, it's very smart, and you might win an obfuscation contest but in a professional environment we like code that can be understood even when the emergency phone kicks us out of bed. If it's five times as long, I care not, but if it requires me to think hard on the code, I do.
I need a templating engine in my app, and php seems like the most popular one.
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. My second choice is handlebars. I'm not sure if JSX would do the job?
Any thoughts appreciated.
You could use PHP but then you have a whole host of other stuff that you don't want or need in a templating language.
If your app is in swift or objective-c, look into template libraries for those languages. Simple Google search tells me there's a couple of options including one using handlebar's format.
<?php
for ($x = 0; $x <= 10; $x++) {
echo "The number is: $x <br>";
} same syntax
Someone else already mentioned GRMustache [1], and that looks pretty good.
I'm not sure if there is an iOS version, but you could look for something like liquid [2]. I think liquid is usually a better choice for user-controlled templates, especially when you're rendering on a server. But if they're just compiling the templates on their own device, then handlebars (GRMustache) would be the right way to go.