What's impressive is that at no other company you could wake up one morning and say, "HTTP is slow, so let's change that." Google, amazingly, can do stuff like that, and I'd rather them ship early than not ship at all.
(Well I guess Microsoft could have done it but they would have screwed it up like every other net technology they introduce and then we'd have two internets or something worse.)
I'm not sure it's fair to say that Microsoft has "screwed up" every technology they've had a hand in. Ajax, notably, is a Microsoft invention. What I do think is a fair statement is that Microsoft has historically been slavishly backwards-compatible even with obvious design mistakes and implementation artifacts, whereas the other two 800-pound gorillas (Google and Apple) have a mantra of never keeping legacy tech around when it can safely be replaced. The latter results in cleaner technologies; the former results in longer-living technologies. As a programmer, I prefer the Google/Apple take, but it's worth noting that Microsoft's variant has a clear advantage for the user in at least the short-to-medium term.
>Microsoft's variant has a clear advantage for the user in at least the short-to-medium term.
The approach also often comes out on top when the client is a business and accounting considerations take the lead, as opposed to B2C situations.
When you divide the cost of a Microsoft license by 7 (number of years a business will be running XP on a workstation) it turns into a really great price.
The reverse compatibility mentality is universal in the enterprise.
To put that into proper context, XmlHttpRequest was a hack by a single person at Microsoft -- with zero input or coordination or working groups or long term planning -- on the MSXML team to do a favour to the Outlook team. Further it could only happen because of ActiveX, and paralleled various other light request tools that existed at the time.
XmlHttpRequest is a great demonstration of a hacker getting a solution out there.
EDIT: Downvotes? I am intimately aware of how XmlHttpRequest came into existence, having been closely involved with its birth, so if someone has some correction to add, please add it. But in no universe does XmlHttpRequest vindicate Microsoft on moving web standards along. Their contribution was unintentional and largely accidental.
During my interview with that team, one of the kids proudly took credit for the span tag. A weekend hack. Committed the code and shipped it. No review. SOP.
Being more standards-minded at the time, I wanted to throttle the kid.
With the benefit of hindsight, I see that all the jitter and experimentation was pretty much ideal. If a feature proves useful, other browsers may adopt it, and it may become a de facto standard.
Two internets looks like the direction Google are taking us, not Microsoft. No other company is so willing to bypass the standardization process so willingly, and force other browser vendors to use their technology or face compatibility issues.
SPDY, NaCl, Dart are among some of the examples. Developed behind closed doors where nobody else can have a say, then released as an "open standard", but at the same time slipped into the browser and promoted for use - thereby eliminating the option for others to propose an alternative, or any major (breaking) change.
I'm all for pushing forward with tehcnology, but google should open their doors earlier, or we'll end up in a situation where they're effectively dictating the direction of the web and other browser vendors are busy playing catch-up.
It'll only be impressive if Google actually take the advice from Opera et al, and adjust their SPDY protocol to suit everyone - not just Chrome users. (And the same for NaCl, Dart, and the next "new standard" Google push for).
… which has a clunky interface, annoying limitations and since release has been pushed forward by others (i.e. Mozilla).
Microsoft has had a few first-to-market ideas but they're horrible at continuous improvement because their core business is freezing an API and supporting it for a decade so enterprises feel comfortable using it.
HTTP wasn't, and isn't, broken. Google alone had the combination of a financial incentive to improve, engineers capable of improving, and few application-level opportunities to exploit instead. This is literally the last thing you should worry about optimizing. Very few of us are privileged enough to work at a place that is so short on real problems we can worry about one like this.
In this industry we have a 15-25 year rewrite cycle. The cycle always begins with something deceptively simple that wins wide support through being easy, and ends with multilayered nonsense of dizzying complexity. Efficiency was not a design goal of HTTP. "Changing" that isn't just insulting to the spirit of HTTP, it expresses a complete lack of regard for history.
I don't know how we're going to break the rewrite cycle, but I can tell you heaping complexity atop complexity appears to be exactly the engine driving it, and just when things reach the pinnacle of the absurd, someone comes along with a disruptive, simple alternative and takes over the world with it. SPDY is late-game technology. The end of this loop is near, and we'd be better served keeping an eye open for the start of the next one than trying to master the intricacies of one more difficult and unnecessary improvement.
This is only true if you narrowly define the scope to be what HTTP started as: synchronous, unidirectional, and only concerned with single files[1]. When you consider the problems many, many people - not just Google - are dealing with break at least one of those assumptions it's clear that HTTP is incomplete.
1. SPDY will be nice for anyone using much JS/CSS on their site
I don't think I could disagree with you more thoroughly than I do. Your argument amounts to saying the postal service is incomplete because mail trucks don't have jet engines on top.
First, HTTP pipelining exists.
Second, HTTP's inefficiencies establish a bounds on your performance. HTTP itself does not define your application's performance, unless you've already mined every optimization opportunity at the levels above. Do you ensure all your CSS and JavaScript assets are bundled into single files and minified? If the answer is "no," you have no business complaining about HTTP's performance—managing your assets better will improve performance far more than using SPDY alone will. What about your caching story? What about your database, is it indexed properly? These are tangible improvements that you can make in your application today that can and will improve performance for the end user.
At my work, there is a CGI app written in C that does some atmospheric calculations against a database. The old database was Oracle, the new one is PostgreSQL. The CGI now takes twice as long to run as it did before, which is noticeable because it used to take about 5 seconds, so now it's taking 10, for one day of calculations. Looking into the problem, we found a place where an index would be a good thing to add. So we added it, and the performance didn't change at all.
It turns out, the app is sending a separate SQL query for individual data points. The app needs hundreds of thousands of data points to do its work, so it's sending many thousands of queries on each request. One query can fetch all of the data this program needs in about 0.3 seconds. So this app is, in effect, not measuring the performance of the database itself at all; instead it's measuring the overhead of running an instantaneous query on Oracle and Postgres, multiplied by several thousand. It turns out that the overhead of setting up and performing a query is about twice as high with Postgres. This fact never matters in practice though, because when you notice it you're doing something stupid. Nobody ever says "you should switch to Oracle, because that Postgres's queries take 4 milliseconds to setup instead of 2." (The fact that this app is written in C and could easily be outperformed by a shell script is also telling.)
This is exactly why HTTP is in no sense incomplete or narrowly defined. Google is the one with the narrowing requirements: they know exactly how much money HTTP's inefficiencies are costing them and are in a position to throw engineering time and energy at that number to decrease it. They are also in a position to optimize every other corner of their stack, and presumably they have. This is not true anywhere else.
SPDY is somewhat beneficial for consumers. But it undermines the simplicity and clarity of HTTP. That's what makes this late-game technology. SPDY is SOAP and CORBA to HTTP's RPC. Is it a better definition? Probably. But it's also harder and the benefits are insignificant except at scale.
… and is not currently usable, nor as full-featured as SPDY even if correctly implemented by all vendors
> If the answer is "no," you have no business complaining about HTTP's performance—managing your assets better will improve performance far more than using SPDY alone will
Flat-out wrong: there are many use cases which require multiple requests (you only mentioned CSS/JS but images are significant, too) and this would be exhibit A for an HTTP deficiency: you've internalized the idea that a visitor to the site must download and process EVERYTHING you could ever use to avoid making multiple requests, wasting bandwidth and device CPU/memory because you're trying to use asset packaging as an end-run around protocol shortcomings.
As for databases, this was a fascinating and completely irrelevant digression.
What's impressive is that at no other company you could wake up one morning and say, "HTTP is slow, so let's change that." Google, amazingly, can do stuff like that, and I'd rather them ship early than not ship at all.
(Well I guess Microsoft could have done it but they would have screwed it up like every other net technology they introduce and then we'd have two internets or something worse.)