To start, this blog title isn't the name of Rick's wedding singer band which, by the way, will travel virtually anywhere and perform at your wedding for free.
Rather, I started forwarding 2 links to the OC crew with 1 thought. It became an ode, sans poetry, to Rick Harris on his last day at OrangeCoat. It also turned into a brain dump of the next iteration of the web, and beyond. I had to cut the "beyond" portions out for my sanity and yours.
Rick came to OrangeCoat a few years back as a fresh front-end programmer and a hell of a nice guy with a knack for teaching himself. He's moving on from OC as a quality back-end developer with mad front-end coding skillz. He's now a solid "Coder of the Web", as printed on his remaining 997 of 1000 business cards.
I'll miss having Rick around for the occasional technology debate, and to back me up when Evan has a "what if we" idea. Hopefully he's not too cool for school and we can still find time for beers and idears, talking about which technologies are best fit for the next iteration web technology.
Here are a couple examples of how the big guys are delivering different doctypes, compression, etc, based on the particulars of a device.
Nothing shocked me in these links, but it got me thinking. It's interesting to take a step back and remember that developing and supporting N different devices, and their associated mobile apps and web browsers, is going to require extra work. This being the same variety of extra work front-end developer's have been tackling for years due to browser dependencies introduced by IE vs Firefox vs Safari vs Chome.
It used to be your back-end web server delivered HTML, CSS, JS and images, and maybe XML if you had an API to expose. Lately, mobile operating systems like iOS and Andriod have come on the scene with no standard to hold them back. It's the wild wild west out there, like when IE6 would decide to do its own thing in an attempt to innovate at the expense of standardization.
The resulting innovation of the last few years has been very fast and raises the big question of what to do if you, or a client, want a web service accessible by as many means as possible? All of a sudden there are a lot more front-end options on the new devices side of the curve. At the same time, there is still the various web browsers in the middle, and aging devices on the other end. Where do you draw the line on either end of the bell curve?
On top of that, the ever growing list of new devices, like smartphones, tablets, TV consoles, gaming consoles, and e-readers, have brought even more considerations to the table. Now we add media attributes, like different screen sizes, and new hardware components, like GPS.
What would appear to be front-end problems are quickly manifesting into opportunities for back-end solutions which browser specific CSS/JS hacks and responsive design aren't likely to solve, especially since not everything is a web browser anymore.
How does this change your back-end? What does a web server back-end look like if it's servering up the pieces of various front-ends?
Oh, and how long before the server-side needs to adapt to the ever growing number of components within the ever growing types of devices?
Given all of this, should we make all back-ends into an API that responds to CRUD requests and shift more logic to the front-end, like the days of thick-clients and desktop applications?
I don't have it all figured up, but I surely don't want to develop, let alone support, X front-ends and Y backends. However, it's increasingly clear that the web standards aren't going to move fast enough to be a one-size fits all solution.
On a positive note, at least we have MVC frameworks like FuelPHP, media queries, and responsive design already making these changes more managable.
In the long term, I can see the line between web browser and mobile OS blurring until we circle back to a world of competing OS super cloud brOwSer A vs super cloud brOwSer B, likening to the days of IE6 vs Firefox or Windows vs Mac.
Perhaps I can go ahead and coin the name web brOSer. That could actually be a useful term if these Google Glasses, and such immersive technologies, don't leepfrog everything by combining life + browsing + OS and tap directly into our brain's visual cortex.
The future of the web is going to need more Rick Harris's. As much as I hate to see Rick go, I hope Treehouse is able to produce more folks like him to help iron out the ever changing details.
Regarding the findings of the earlier Google and Facebook links, it looks like media queries are not used, presumably because 2 of the 3 devices tested are not likely to support them. I'm curious to see whether the big guys are using media queries and responsive design on the front-end when network transfer speeds are not a concern, like on tablets and smartphones.