Google discontinues support for IE7 in Google Apps
google.com
google.com
As small players, dropping support for older browsers kind of pulls us into the morass of a Nash equilibrium. Everyone would benefit if all web developers could agree on requiring modern browsers. We'd all be saved the pain of supporting old browsers, and users would upgrade because every site forces them to. But as an individual web developer, I can't very well just make that call and hope others will follow suit. Because until everyone else does the same, I'm stuck telling my clients they're giving up visitors with older browsers "for the greater good." Not workable. So my current best strategy is to support older browsers, and the same is true for each other developer. Yet as a whole industry, we'd be way better off dropping old browsers.
But a huge player like Google can afford to do it unilaterally. And when they do, they create an opportunity for countless small developers like me to do the same.
I'm not going to jump on the bandwagon just yet. I plan to embrace this cautiously. We still don't know when it will be safe for freelancers and small companies to drop IE 7 and other dinosaurs. But I predict that day will come much sooner thanks to Google.
If that's all it was, then you'd be right. You can't do geolocation, local storage, audio/video, canvas/svg/webgl, etc. etc. on old browsers. It's not about making things pretty. It's about creating software that can compete with desktop alternatives.
Personally, I can't think of a single desktop application that I use that is better done in a browser with the possible exception of Google Maps, and I say "possible" because I haven't seen a desktop contender.
I use GMail's web interface solely because I can't stand any of the Mac clients (at work) and Outlook isn't available on Linux (which a couple of my PCs at home run). It is cross-platform, which is a plus; it is painfully ugly and slower than a desktop alternative, which is an overwhelming minus.
I greatly prefer my web browser to be for browsing the web. While I'm all for standards in HTML/CSS/JS, I find the "web browser as your OS!" crap to be disheartening. I like things that work, and for the most part, web applications don't.
Imagine if a person at your job said they had just made a new client app for your business users workflow. When you ask how it's implemented the person says that the GUI itself is just a skin that reads everything from the database. The GUI layout, how the buttons behave, all of it is stored in the database and the actual GUI is nothing more than a kind of platform for what's in the database. I've actually seen this done and the team who did it were sacked, their application deprecated. As far as I know it's still running because the team in charge of replacing it still doesn't completely understand it. But this is what web apps are. Model, view, presenter, they're all stored in the same place.
Personally, I prefer having a back end RESTful server with native... shall we say "fit" clients (not fat but not thin either) using it. The browser gets a simplified, default version of the app which has a link to the appropriate native client somewhere visible.
Less choices and fewer features translate to a negative for the user.
On top of that, native desktop apps are compiled ... the web is open, with html/css/javascript/etc. and this creates an open environment that encourages free software.
Free is always good for the user.
Anyway, re-arguing this sort of thing is pointless. The desktop is in a death spiral. All this stuff has already been set in stone. It's a question of when, not if.
What?
But today JS frameworks like jQuery give us the means to do anything we want javascript-related, in any browser that half-supports javascript. By deprecating IE7 they're just saying they're going to drop all of the extra hacks they had to use to keep IE7 working.
A lot of what newer browsers give us is just better rendering. You can replace a mess of tables and nested divs with things like border-radius, which means less client-side html to wade through.
Try looking at Freebase or DBpedia and tell me where did you have such a huge amount of easily parsable, semantic content in the 90s.
Service architecture have also been moving from stuff like SOAP to REST, which is definitively more open and accessible.
And even Ajax-ladden webpages are still just a Firebug Network tab away since they all run over HTTP, and then you have a nicely structured data format instead of having to deal with messy HTML pages.
At the time, we were talking about developing all sorts of agents. Things that would shop for you. Things that would find parts for you. Thinks that would remember what web sites you visited, and let you search them. Things that would track where in a long set of pages you were (blog, comic, etc.), and let you keep reading from there. It happened for a while, and then it died when the web became too damn hard. Writing anything that can reasonably see and parse web pages now takes many, many web years. There are only four or five organizations with that kind of resources (WebKit, Mozilla, Opera, IE, and internally, Google). There are countless things we just didn't even imagine.
It's like the DMCA. You notice all the innovations that happen, but you miss all the innovations it made impossible.
You won't need to write a complete JavaScript library. Look at all the testing suites that automate browser instances, Selenium being the most well-known.
That's not what the web is and that is not the web environment that I want.
No, 15 years ago you could reasonably write a search engine for 15 years ago. It would suck by today's standards.
You want to handle Javascript? Easy! There are plenty of tools to choose from now. Run a browser as your crawler, visit the sites, and read the generated source instead of the static source. Shove that into your 15-years-ago search engine, and there's no difference.
>Things that would track where in a long set of pages you were
You mean bookmarks? Add a scroll %, assuming they're not nice enough to use anchor tags / IDs meaningfully, and you're golden.
>Writing anything that can reasonably see and parse web pages...
has become a community effort, instead of a bunch of isolated silos where people reinvented the wheel out of necessity.
The resources required aren't so large just because it's so much more complex, it's large because it's so much faster, and you won't survive if you can't compete. How long did we languish with crappy Javascript engines? How much would you need to know to actively compete in that section alone now? It's easy to make a slow-but-functional browser, and if you looked around you'd see some people doing just that. Making a fast-and-resilient one is as hard as making a fast-and-resilient anything, especially where human input (ie, HTML) is expected to be consumed.
Bookmarks in books work okay. You move them. Book marks in browsers don't. You have to remove the old one, add the new one, and the overall process is too cumbersome to be useful for the application I mentioned.
As to the auto-updating bookmarks, would it resolve the issue if I made an extension to do that for you? I can see the use, honestly, and I like it. (seriously, I'm offering, and I'd probably use it myself. It'd be an interesting project. Even if it doesn't resolve the issue - we might just fundamentally disagree here, I'm OK with that.)
But why should that be part of the browser, when modern browsers allow you to do damn near anything by simply leveraging it? Why should we rely on browser makers to tell us what's possible, when we can do it ourselves, because of the changes in the past 15 years?
As to what should and shouldn't be part of the browser -- the way to figure that out is experimentation and competition. When you make technologies and standards simple and easy, people will make independent implementations and try things. The vast majority will be dumb, but some (often unanticipated ones) will turn out to be useful, clever, or brilliant. That's how the technology improves.
When you make standards big and cumbersome, progress stops.
If you want to read through a site's archives, what I do is keep it open in a tab. It is restored when I reopen my browser, saved if I reboot, etc. It's not as handy as a bookmark, but it comes close.
I think you (and most people here) underestimate what the "old web" could imagine, though. We had all sort of ideas for agents that would go out and grab and analyze data for us in all sorts of clever and interesting ways. Search engines got built, as did one or two other things, and then the web just got too complex.
Hell, even I had a simple app that went out and grabbed all my favorite comics and showed them to me, nicely formatted, and without ads.
While the web gets more complex, the tools at hand get better. Much better.
What about JS frameworks like JavascriptMVC or Sammy [1]? Google even created a spec [2] for crawling such sites.
[1] http://sammyjs.org/ [2] http://code.google.com/web/ajaxcrawling/docs/getting-started...
The drive toward semantic markup in HTML5 is supposed to help the web get back to those original ideals. Over time, we'll increasingly expect web developers to conform to a subset of possible HTML arrangements, much like book publishers conform to a subset of the possible random arrangements and orientations of letters on a page (odd poetry excepted).
Have you taken a look recently at the plethora of web APIs for just about every purpose? The modern way of collecting machine-friendly data from a server is through APIs and semantic content (RDFa, microformats, etc.).
Not through HTML / CSS / Javascript formatted pages which are made primarily for human consumption.
Again, read the literature on agents from the nineties, and see how diverse a technology tree was killed....
Are you serious? Have you heard of the canvas element? It allows modern browsers to do things that were only possible 2 years ago in Flash. Have you noticed how there are actual web applications, not just a collection of linked pages these days? Have you noticed how with ubiquitous JavaScript, the usability and ease of websites has improved greatly?
Usability is not up. Each web site has its own, custom, non-standard user interface. I could teach my mom to use the web circa '96. I cannot teach her to use it today. It's too damn complex.
Usability would be up if the browser knew more about what to expect. You can look at things like Readability. The browser ought to know more about the content, and be able to present it in a coherent, usable way. The server-side shouldn't dictate presentation.
Yes, the proliferation of web apps has created a diversity of user interface paradigms. Some would say this is a good thing, however, since the web has spurred all kinds of new UI philosophies, and the fact that JavaScript and HTML isn't compiled allows people to examine and re-work others' code, so good ideas spread very quickly. I for one don't intend on waiting for the HTML5 group to invent every new <input type=""> that I could conceivably need, and then wait some more for browser vendors to implement them all consistently. With JavaScript, you can currently build and deploy just about any kind of 2D client-side interaction imaginable.
In short, the vast majority of users on the internet probably have a different idea of usability than yours, and the numbers tell the rest of that story. You only need to look at the gross casserole of UI paradigms within the applications installed on your mom's PC to see how much users really care about UI standardization.
The applications on my mom's PC do have much better UI standardization than the web does. Microsoft releases UI guidelines. alt-f4 does the same thing in every application I've used, and the menu structure is roughly the same too. Apple is even better.
Microsoft releases UI guidelines
the menu structure is roughly the same too
So I'm sorry for your mom, but unless she never upgrades, then she's going to have to learn new things.
Yes, and I was dissecting why you may have found it useful, because the same principle applies to hundreds of other situations that you may not have recognized.
> The applications on my mom's PC do have much better UI standardization than the web does. Microsoft releases UI guidelines. alt-f4 does the same thing in every application I've used
Questionable. About the only key shortcuts you can rely on are the ones that will work in your browser too. Alt-F4 will close your browser--that's what you wanted, right? Cut/copy/paste, print, etc. all work there as well...
> the menu structure is roughly the same too
Ha, you mean the invisible menus on Explorer and IE>8, the mega "office button" menu in Office 2007, the delightfully inconsistent menu bars in WMP>9...
Today a lot more software and websites have broken the mold and come up with some really different(not siding better or worse because both exist out there) UX patterns. There aren't standards for web UI anymore that are practiced across the board.
I do disagree with your statement that the client should dictate how a site is presented, not the server. The browser should display the content in a standards compliant way. The days of buttons looking like windows buttons in IE and Mac buttons in Safari should be a thing of the past never to return.
For the most part, the bulk of the web's content is as easily accessible as it was years ago. You make a request and you get a blob of HTML back. If you have special requirements and need to get into all the nooks and crannies you create a DOM implementation and embed a JavaScript engine. Then you parse the page into a DOM and start firing off events. There are quality open source JavaScript engines available. JavaScript and AJAX are a breeze.
Flash is a different story. If you have any requirement to follow links or process content in a Flash movie (you'd be surprised how many sites still have Flash nav) you pretty much have to write your own runtime. Unless you are big enough to have Adobe do it for you.
Depending on what you are doing with the data that your spider collects, chances are writing a spider is far easier than writing a browser. There are at least 4 widely used browser engines and plenty more toy browsers floating around.
I can guarantee that writing a spider that can deal with AJAX is not the biggest challenge of developing a search engine. Scaling it, fighting SPAM, understanding the content, indexing and then being able to provide quick lookups are much, much harder.
Seemingly you argument could be made for cars "15 years ago cars were easy to fix and understand. Now they are not, so wake me up when they are like the cars of the mid-nineties."
JS/Ajax help programmers tremendously. Helps speed. Helps functionality.
To view these things through the lense of "I can't write a crawler for them" is a pretty limited view of what today's technology offers.
In transportation:
It used to be that everyone could buy a horse and build a buggy and get around. Then cars came along and it got a lot more complicated and expensive to build a vehicle that was state-of-the-art, but tinkerers could still do it.
Now there are only a few big players who are capable of innovating and building the best and newest vehicles.
Now that I think about it though, there is still space for tinkerers and inventors in the automobile space. But You can't expect those automobiles to compete with those made by, e.g., Toyota.
In the same way, it's still possible to write a spider without a javascript renderer. It just won't be able to compete with Google.
One last point: the state of the web is based on the collective decisions of all internet users. Ultimately, people building things on the web decided more often than not that ajax-ifying things benefited their users.
If users had wanted a web client that would spider the web and shop for them, they would have latched onto it during the time of great innovation that you think is now gone. But they didn't. The things that users wanted are the things we see today, assuming that there isn't some horrible inefficiency in the feedback loop between web-builders and their users.
You say "I don't think having more pixel-perfect control or slightly faster JavaScript makes the web any better." But--no disrespect--you probably only feel that way because you're already benefitting from the huge amounts of effort invested in supporting multiple, incompatible browsers. The web looks OK for you now because, without you noticing it, web developers have slaved to make it look OK for your unique combination of OS and browser.
It may seem like that's just a cost we web developers have to bear, with little effect on you. But that's not so. The fact that we have to spend time supporting old browsers increases the cost of everything that's created on the web. And when innovation is more expensive, it happens more slowly. The costs imposed on our industry by older browsers do effect ordinary web users, because those costs translate into a slower pace of innovation.
I think the point for making ie7 deprecated legacy is more about its hideous bugs in the parsing, internal document representation and rendering bugs.
It is the things that makes proper code unable to be displayed properly without the tedious work of understanding the dysfunctions to circumvent them properly. To me, the old IE rendering engines alone has slowed web innovation for at least several years all by themselves.
Wake me up when Google is dropping GMail support for IE7. Now that would be a story.
It is no secret. MS themselves have gone as far as putting up "anti"-IE6 sites and not supporting IE6 in their own online office apps. IE7 can't be far behind. IE prior to version 9 is an embarrassment to them compared to IE9 and versions of other browsers from three (or more) years ago and they'd like to sweep them under the carpet and get users running IE9+ ASAP.
MS will draw the line at IE8 which Google (and anyone following a similar pattern) may not (they may drop IE8 support soon after IE10 is released if sticking with a "current and previous only" model), as MS won't want to lock off XP+IE8 users (at least until April 2014 when XP with SP3 completely falls out of extended support anyway) because that might further encourage shifting to Firefox or Chrom{e|ium} as an upgrade to IE9 is not possible on XP.
Small freelancers make up a greater percentage than bigger firms as developers. At very least you should make it known that supporting old browsers is not a standard service and will incur extra costs to the client. There is plenty of literature to point your clients to in order to back up your point. If we all do this one by one it will have a greater impact than this move by Google.
FF 4 was released 3 months ago. It's just now looking confidence-inspiring enough that I'm considering upgrading to it on my Mac this week. But now Google is going to drop support for it when FF 6 is released in a couple of months???
Another issue: if I'm not mistaken, the fact that Ubuntu releases stick with a particular browser version, means that the LTS releases (and 10.04 in particular) will stay with a version of FF long after Google Apps has stopped supporting it.
Both of these strike me as serious problems. Perhaps the Google Apps people have not really thought through the ramifications of this policy?
I'm reasonably certain by that by "Two Major Versions" they are referring to "Versions that alter how the platform interacts with the Web." - So, as long as FF 5 and FF 6 behave reasonably similarly, they'll be treated as the same major version, and Google will support FF4 and FF5/6.
Or, it may be the case, after some review, that FF4/FF5/FF6 will all be treated as the same major version, and official support on August, 2011 will be for FF3.6 and FF4/5/6. Time will tell.
Well, hopefully. But they've officially announced the dropping of support, so I have to wonder.
> I'm reasonably certain by that by "Two Major Versions" they are referring to "Versions that alter how the platform interacts with the Web."
That might be. But that makes me wonder about FF. Apparently the changes from 3.5 to 3.6 are more significant than those from 4 to 6. What's the deal with that?
This is the best reference I could find with a 30-second search (non-authoritative): http://ubuntuforums.org/showthread.php?t=1551527
Time based support would be better.
Of course, "not supported" isn't the same as "not working". For Firefox (just like Chrome), I doubt there will be changes breaking enough to cause a problem. The real question is if they'll start using features (e.g. canvas or newer selectors) not available in those earlier browsers for major functionality in their apps.
I guess it's because they don't know for sure what versions of Chrome will be the two most recent released, but it's still kind of funny.
More likely, since the versions of FFx, IE, and Safari they support are the versions of another company's product--unlike their own--they feel like they have to be more upfront.
The current stable release of Chrome the the version before it.
Do you feel the need to upgrade your house's plumbing system and electrical each time an innovation happens? That's how most people feel about software.
The key point is that Google Apps are tied to browser versions, and browser versions are tied to OS versions, and OS versions aren't exactly consistent in their support or end-user coverage. Users who figured their current setup works well enough for now, and who for many years haven't had any reason to upgrade will now be forced to if they want to make use of those Google Apps -- or, they can take the much less costly route and simply not use Google Apps, or deal with "simple HTML mode" or whatever.
The worst part about this that irritates me most, though, is that many of these systems simply don't have anything wrong with them except that someone, somewhere, arbitrarily decided they were "too old". So perfectly functional pieces of equipment now lack functionality because enough people have arbitrarily decided that they "don't have" that functionality anymore, even where it might actually be possible.
On the plus side, it does mean that no one has to support old browsers' quirky and always-varied interpretations of the same chunk of code...
This would cause problems for anyone on Debian squeeze.
Of course its a matter of choice, but if you stick to Debian Stable for your desktop, such issues are to be expected.
Debian unstable and testing are a bit more unstable, of course, but they are still good enough for desktop.
http://blog.chromium.org/2010/07/release-early-release-often...
I think people are putting too much/too little thought in to this version number thing. With Firefox's six-weekly release schedule now they'll define a major release differently from the version number.
Plus, your FF 4 users will know exactly when FF support will be dropped - the day FF 6 is released. Simple.
Of course, it's not a problem if every upgrade is backwards-compatible with every add-on and intranet app, but that's tough to pull off.
I notice there is a lack of effective major version numbering in Google. When does Google stop supporting it's own browser?
It'd also be interesting to see what they intend to do about mobile browsers. How long will an old OpenWave XHTML browser be supported? How long will an Android 1.5 browser?
and despite a lack of official support, there aren't any huge changes between these versions so things will probably still work fine. it just means they aren't testing for it.
Ballmersoft? Notsomuch.
Microsoft would just say they are responding to Chrome's accelerated release schedule and redefining what a "major" release is.
It really doesn't feel like it should be the hard for Google to have some infrastructure where the user can control version transitions. Google makes a new version, but barring security issues, keeps all old versions in their cloud. At that point, you transition when you're ready.
In essence, upgrades are not as simple as you may think due to forced platform incompatibility/vendor lock-in. Forcing an upgrade like this can cost users a non-trivial sum of money on top of what you're already charging for the service!
So while I appreciate the moving into the future, I feel bad for the people whose wallets are going to feel the pain of such a move.
I recently acquired a Macbook Pro from work, but I'm using Windows 7 on it full-time. I'm far too wary of being forced to upgrade when Apple stops providing security updates to the version of OS X currently installed on it.