Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 7 Virtual Machine

nikic.github.io

Post reply on HN
Print view View original

41–50 of 128 posts

Re: PHP 7 Virtual Machine

#41

Post by sbarre »

krick wrote: post #16
nodesocket wrote: post #4

Earlier quoted context omitted.

HHVM was released in 2011, while PHP 7 was released in 2015. So perhaps in that extra time there was additional techniques, optimizations, and technology that allowed PHP 7 to stay comparable in terms of performance to HHVM.

FWIW, I had to deal with HHVM a year ago, when PHP7 was recently released, and while PHP7 was already quite stable, HHVM (and especially Hack) was misbehaving in seemingly common situations.

I had a similar experience to this.

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.

Re: PHP 7 Virtual Machine

#42

Post by tannhaeuser »

sbarre wrote: post #40
tannhaeuser wrote: post #22

Earlier quoted context omitted.

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…

> 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 happily into generated HTML (eg. XSS attacks). > PHP apps typically also build up dynamic SQL from user…

Reading through it, my comment came about too much as a rant against PHP, though I actually like parts of the PHP community for their sense of practicality.

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.

Re: PHP 7 Virtual Machine

#43

Post by bpicolo »

matsemann wrote: post #38
Dibes wrote: post #15

Earlier quoted context omitted.

out of pure ignorance -- what are the correct domains that either fit into?

One thing I like about PHP for quick prototyping or one-off projects is that an error doesn't bring the whole server down. 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…

Every web framework out there (express + nodejs included) will handle exceptions properly and not blow up the server on exception.

Re: PHP 7 Virtual Machine

#44

Post by bpicolo »

kijin wrote: post #28
tyingq wrote: post #5

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.

They broke an unusual number of things in 7.1, a couple somewhat annoying e.g. defaulting DateTime('now') to including microseconds, without a single builtin function available that can strip/change microseconds on a datetime.

Re: PHP 7 Virtual Machine

#45

Post by matsemann »

bpicolo wrote: post #43
matsemann wrote: post #38

Earlier quoted context omitted.

One thing I like about PHP for quick prototyping or one-off projects is that an error doesn't bring the whole server down. 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…

Every web framework out there (express + nodejs included) will handle exceptions properly and not blow up the server on exception.

You're not refusing my point by insisting on adding more complexity (a huge framework), when simplicity and rapid prototyping of a small script was the goal.

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.

Re: PHP 7 Virtual Machine

#46

Post by captn3m0 »

bpicolo wrote: post #44
kijin wrote: post #28

Earlier quoted context omitted.

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.

They broke an unusual number of things in 7.1, a couple somewhat annoying e.g. defaulting DateTime('now') to including microseconds, without a single builtin function available that can strip/change microseconds on a datetime.

Yes, but they decided to keep it to 7.1, not 7.0, which meant the majority of the perf upgrades were available to most users who migrated to 7.0 _easily_.

7.1 was where all the breaking changes got pushed as a result.

Re: PHP 7 Virtual Machine

#47

Post by sbarre »

tannhaeuser wrote: post #42
sbarre wrote: post #40

Earlier quoted context omitted.

> 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 happily into generated HTML (eg. XSS attacks). > PHP apps typically also build up dynamic SQL from user…

Reading through it, my comment came about too much as a rant against PHP, though I actually like parts of the PHP community for their sense of practicality. 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…

You're calling out problems that are common to all programming languages on the web, and I think you're just focused on PHP because it was one of the first languages to run into those problems (and to solve them as well - HTML escaping functions are part of PHP's core, it's not a library) due to it's early widespread popularity and adoption.

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.

Re: PHP 7 Virtual Machine

#48

Post by nathan_f77 »

DenisM wrote: post #10
improv32 wrote: post #8

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…

If you just need formatting without logic, then you could use something like Markdown.

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.

[1] https://github.com/groue/GRMustache

[2] https://github.com/Shopify/liquid

Re: PHP 7 Virtual Machine

#49

Post by ssharp »

tannhaeuser wrote: post #42
sbarre wrote: post #40

Earlier quoted context omitted.

> 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 happily into generated HTML (eg. XSS attacks). > PHP apps typically also build up dynamic SQL from user…

Reading through it, my comment came about too much as a rant against PHP, though I actually like parts of the PHP community for their sense of practicality. 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…

PHP made it way too simple to go from a basic installation -> serving web pages, just using it's standard library. You're right -- that was it's intended use-case and while it made for a dead-easy user experience, it also planted lots of traps that users fell into in droves.

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.

Re: PHP 7 Virtual Machine

#50

Post by bpicolo »

matsemann wrote: post #45
bpicolo wrote: post #43

Earlier quoted context omitted.

Every web framework out there (express + nodejs included) will handle exceptions properly and not blow up the server on exception.

You're not refusing my point by insisting on adding more complexity (a huge framework), when simplicity and rapid prototyping of a small script was the goal. 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.

> a huge framework

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.

Post reply on HN