HTTP/2 and PHP?
With the advent of HTTP/2, the proposed specifications are very exciting. Most exciting of all is the ability for the server to push information out to a web browser without the web browser having to first ask for it. My question is: functions existing PHP to allow us to use the HTTP/2 capabilities? It seems to me, Ajax may no longer be required to perform many functions. Can much of what was previously done with Ajax be done with PHP now? Or will JavaScript be more important than ever because only it can control requests to the server from a user standpoint?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
For what it's worth, I don't think the push feature of HTTP/2 is intended to be a replacement for stateful sockets. While there may be some person out there that figures out how to make it work like that, my understanding is that the push feature is simply there to streamline data delivery, so if you have pageX.php that references CSS and Javascript and images, and someone's browser asks for pageX.php, the server can proactively deliver the CSS, Javascript, and images along with the original request, so the browser doesn't have to go back and make more requests for additional resources.
In other words, HTTP/1 is like ordering a build-your-own-robot kit from an online store. Once the kit arrives, it tells you that you need some special screws, wires, and batteries, and if you don't have them, you can request them for free from the store. So it can take a long time to get all the pieces together to be able to build your robot.
In HTTP/2, you order the same kit, but the online store sends the kit AND the screws, wires, and batteries all in the same shipment, so you don't need to go back and request anything more - you have everything you need in one request.
That's my understanding of the new push feature.
Again, you never know if someone will jerry-rig it to do something else that could keep the request open and allow long-living server pushes, but I don't think that's the intention. So if you're looking to replace AJAX with server pushes, then you're probably going to have to stick with sockets. You can try out WebSockets in HTML5 and see if that meets your expectations...
In other words, HTTP/1 is like ordering a build-your-own-robot kit from an online store. Once the kit arrives, it tells you that you need some special screws, wires, and batteries, and if you don't have them, you can request them for free from the store. So it can take a long time to get all the pieces together to be able to build your robot.
In HTTP/2, you order the same kit, but the online store sends the kit AND the screws, wires, and batteries all in the same shipment, so you don't need to go back and request anything more - you have everything you need in one request.
That's my understanding of the new push feature.
Again, you never know if someone will jerry-rig it to do something else that could keep the request open and allow long-living server pushes, but I don't think that's the intention. So if you're looking to replace AJAX with server pushes, then you're probably going to have to stick with sockets. You can try out WebSockets in HTML5 and see if that meets your expectations...
From the things you two are saying, it doesn't look like there will be much affect on PHP. While PHP generates content, things like CSS, javascript, and image files are outside of PHP. Unless of course you are using PHP to generate those also.
Even so, most of the new methods are between the web server and the browser it seems.
Even so, most of the new methods are between the web server and the browser it seems.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Here's the FAQ page from the working group that is developing it: https://http2.github.io/faq/
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This would make a cool bounty board request. "How will HTTP/2 affect web development?" is what I'm thinking of calling it. What do you guys think?
Yes!!!
It will kill sprite images (once HTTP/1.1 is in decline), I think rest is same...
It will kill sprite imagesWhy would that happen? When I read some of the articles and the FAQ, their entire intent is to keep everything backward compatible and not even touch the content. HTTP/2 is all about changing the communication between the server and the browser and Nothing else. It should be invisible to web designers except for improved speed.
I think gheist was referring to the speed optimizations that you can gain by using sprites (Nintendo-style). Basically, if you have a set of 50 icons that you use throughout the site (maybe 25 icons with enabled/disabled styles), you can either download 50 separate images or you can downloading one big image that contains all of them, side-by-side. Then you use that same image over and over again but tell the browser to only display 16x16 pixels at a specific offset (masking everything but the desired icon). With a large number of icons, there's a significant speed increase because you eliminate the network transfer overhead of all but one image (49 handshakes, 49 I/O saves, etc... - just 1 big, fast download).
With an HTTP/2 push implementation, you could keep all 50 icons as separate images and push them all to the browser in one big transfer, so you'd gain the benefits of the sprite methodology above and you'd eliminate all the screwiness of masking everything but the desired icon (which is usually a messy, hard-to-read bunch of CSS).
With an HTTP/2 push implementation, you could keep all 50 icons as separate images and push them all to the browser in one big transfer, so you'd gain the benefits of the sprite methodology above and you'd eliminate all the screwiness of masking everything but the desired icon (which is usually a messy, hard-to-read bunch of CSS).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Good discussion. Closing with equal points because my question (apparently) doesn't really have an answer, but everyone's contribution is appreciated.
Cross reference question https://www.experts-exchange.com/questions/28657374/What-will-HTTP-2-mean-for-DLP.html
ASKER
I was hoping I could forgo node.js. It's a solid framework for doing realtime communications, and we even have plans to integrate chat into one of our software products using node.js. But... if I could simplify life, I'd lke to.
@Dave:
As far as I know, the "push" works like this:
1. A single connection is established.
2. We can send multiplexed requests through that connection.
3. Those requests can contain priorities, so... a CSS stylesheet can be a lower priority than the page itself (for example).
What I'm not clear on is how the "push" works (thus the impetus for the question). Previously, we've always had to do a request to get stuff. AJAX works in the background, and looks for changes somewhere before showing the update on the page.
With the push, I'm hoping that a server event can cause a push event that would be sent to the browser. The most obvious use for this is chat, but I am thinking of it more in terms of updating a thread (like this question) in real time. Or, perhaps, allowing collaborative editing of a document using this technology.
If it works they way I read it, it could have vast implications for creating web applications - especially collaborative features.