Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

The Web Doesn’t Suck. Browsers Are Innovating.

This week saw a flurry of back-and-forth about the future of the web platform. In the “web sucks” camp were Sachin Agarwal of Posterous (The Web Sucks. Browsers need to innovate) and Joe Hewitt (Sachin summarized some of his tweets at @joehewitt agrees with me).

Chris Blizzard responded with a few narrow examples of what Firefox has been doing lately (geolocation, orientation, WebGL).

On Hacker News, most of the comments took Sachin to task for his argument that standards don’t matter, pointing people back to the “bad old days” of the browser wars.

In my opinion, both camps kind of miss the point.

Sachin made some very pointed factual claims which are just complete, pure hokum. Close to the top of his post, he says:

Web applications don’t have threading, GPU acceleration, drag and drop, copy and paste of rich media, true offline access, or persistence. Are you kidding me?

Really? Are you kidding me. In fact, browsers have implemented, and the WHAT-WG has been busily standardizing, all of these things for quite a number of years now. Threading? Check. GPU acceleration? Check and check. Drag and drop? Check. Offline access and persistence? Check and check.

Almost universally, these features, which exist in shipping browsers today, were based on experiments conducted years ago by browsers (notably Firefox and Safari, more recently Chrome), and did not wait for approval from the standards bodies to begin implementing.

In fact, large swaths of HTML5 are based on proposals from browsers, who have either already implemented the feature (CSS-based animations and transitions) or who then build the feature without waiting for final approval. And this is transparently obvious to anyone, since HTML5 has not not yet been approved, and some parts are the subject of internal W3C debate, yet the browsers are implementing the parts they like and innovating in other areas.

You can see this explicitly in the features prefixed with -moz or -webkit, because they’re going ahead and implementing features that have not gotten consensus yet.

In 2010, the WHAT-WG is a functioning place to bring a proposal for further review once you’re conducting some experiments or have a working implementation. Nobody is sitting on their hands waiting for final approval of HTML5. Don’t confuse the fact that people are submitting their ideas to the standards bodies with the misguided idea that only approved standards are being implemented.

And in fact, this is basically never how it’s worked. Apple implemented the <canvas> tag and <input type="search" /> in 2004 (here’s a 2004 rant from the editor of the then-brand-new HTML5 spec). Opera and Apple worked on the <video> tag in 2007. The new CSS flexible box model is based on XUL, which Firefox has had for over a decade. HTML5 drag and drop support is based on implementations shipped by the IE team over a decade ago. Firefox has been extending JavaScript for almost its entire history (most recently with JavaScript 1.8).

CSS transition, transforms and animations were built by Apple for the iPhone before they were a spec, and only later ported to the desktop. Firefox did the initial experimentation on WebGL in 2006, back when they were calling it Canvas 3d (here‘s a working add-on by Mozilla developer Vladimir Vukićević).

Google Gears shipped what would become the Application Cache, Web Storage, and Web Workers, proving out the concepts. It also shipped geolocation, which is now part of the HTML5 spec.

@font-face originally shipped in Internet Explorer 5.5. Apple has added new mobile events (touchstart, touchmove, touchend, onorientationchange) with accompanying JavaScript APIs (Apple developer account needed) without any spec activity that I can discern. Firefox, at the same time, added support for hardware accelerometers.

Even Microsoft bucked the standards bodies by shipping its own implementation of the W3C’s “cross-origin-resource-sharing” spec called Cross domain request, and shipped it in IE8.

It’s perfectly understandable that people who haven’t been following along for the past few years might have missed all of this. But the fact remains that browser vendors have been moving at a very rapid clip, implementing all kinds of interesting features, and then sharing them with other browsers for feedback, and, one hopes, consensus.

Some of these implementations suck (I’ve heard some people say not-nice things about WebGL and drag-and-drop, for instance). But that’s quite a bit different from saying that browsers are sitting on their hands waiting for the W3C or WHAT-WG to tell them what to do.

18 Responses to “The Web Doesn’t Suck. Browsers Are Innovating.”

Browsers are innovating. I love developing for mobile because I get to use all the cool css3 webkit stuff.

However i think his point still stands that you can do more stuff with cocoa than you will be able to do with browsers for a long time, at least across all browsers at a decent performance clip.

The web doesn’t suck, but it’s way behind where it should be.

@bob you may be right, but it’s not what Joe or Sachin are arguing. They’re arguing for a particular solution (which, btw, would *not* result in “across all browsers”) that is ignoring the reality on the ground.

I’d also tend to disagree about the gap between Cocoa and the capabilities of mobile browsers. The biggest parts of the gap are with regard to new features in native platforms that don’t yet have an analogue in the browser. I’m excited to see Fennec adding support for the accelerometer, and am particularly excited about the possibility of a Fennec/Webkit battle on the Android platform.

Joe does argue a solution, but he also talks about the disparity between the two.

I’m less excited about other mobile browsers showing up on the mobile market, and again i have to fragment my code to try and reproduce similar things on different browsers. Take opera mini on the iPhone. It basically doesn’t support anything us developers have been relying on for mobile dev. I don’t think it’s going to be a big player, but now I’m that jerk not supporting all browsers.

It’s a difficult situation. I want browser vendors to innovate, but I want to USE those innovations. So i either do different things for different browsers where they haven’t adopted each others ideas yet (see transitions and transforms) or i have to type it multiple times, and pretend that IE isn’t an important user base (see border-radius, box-shadow).

That’s brutal. It means that even in this day, we still have to be part web developer, part magician. And you still won’t get the same wonderful experience everywhere. In that respect, the web still sucks.

There is also still a performance gap between safari mobile rendering, and compiled obj-c. Users do notice this, even if your web app looks like an iPhone ipad app. Not that you can’t get away with it. You also only have to write it once and deliver a consistent experience to all, not write fractured code and deliver varying experiences.

I have developed in both arenas, and i understand both sides. I love the web, but I’m just afraid that this large number of rendering engines will continue to drag the progress of web apps for a long time. Was praying ie would adopt webkit. Can’t understand what they gain from maintaining their own rendering engine when they are so far behind.

@bob I’ll just reiterate that what you want here is quite the opposite of what Joe and Sachin want. Joe said (“Yes, exactly. I’d rather developers had forced users to launch different browsers instead of making watered down x-browser sites.”). In other words, he thinks the solution to your problem is to –yes– ignore IE. And if you like what Safari is doing but not Gecko, he thinks you should just ignore Gecko. Sachin made much the same argument.

With regard to the CSS3 inconsistencies, I’d check out Compass’ new CSS3 mixins, which let you just write +border-radius(5px) and be done.

I guess i was referring mostly to his final advice to some developers which was to use cocoa, because it can do way more right now. I’m not sold on his solution for the web world, as i fear the results of fractured development for different browsers. And i hope we’ve left the “this site only works with Internet explorer” days in the dust, which was exactly the result of relying on one browsers “innovative” (cough activex) technologies.

You’re right, I missed a lot of those developments in browser technology.

So why are web apps so inferior to native apps then?

You can write software frameworks until the cows come home to fill in the gaps, check the boxes. But if it sucks, it sucks. And i’m not really seeing these technologies being used to write apps that are even half as cool as iPad apps.

My teammate @twoism said it well: when i started iphone dev. it was amazing to have everything work the way the docs said it would

@sachin web apps that are written targeting Mobile Webkit often kick ass. It’s not fair to compare web apps that are designed to appeal to a mass audience (and like it or not, ABC is not going to write off Internet Explorer) with web apps that are targeted at the iPhone. If you narrow your scope, you’ll see that while there are some bad apples, iPhone targeted web apps are usually kind of good.

I’d also agree that the existing tools aren’t great (I don’t think that’s because web people use text editors) but I expect that to change a lot over the next year.

Mostly very true, although a few statements bother the pedant in me.

Firefox has not been extending JavaScript. The Mozilla Foundation defines JavaScript. JavaScript 1.8 is whatever the Mozilla Foundation says it is. This comes directly from Netscape developing the JavaScript language in the first place.

The simple fact is that not all browsers implement JavaScript. They all implement some other dialect of ECMAScript that is mostly, but not completely JavaScript compatible. Most still call theirs JavaScript, although Microsoft wisely gave a separate name to their variant: JScript.

There is unfortunately no name for ECMAScript plus the extensions universally supported in all browsers, which is what most people incorrectly call “JavaScript”.


“Take opera mini on the iPhone. It basically doesn’t support anything us developers have been relying on for mobile dev. I don’t think it’s going to be a big player”

Eh, you are aware that Opera is the #1 mobile browser, with a market share of nearly 30%, right? Yes, ahead of the iPhone.

@wami I think he’s confusing Opera Mini with Opera Mobile. Opera Mini isn’t much of a browser at all (it does most of the processing on the server-side and using a custom binary protocol to serve the results). On the other hand, Opera Mobile is a pretty nice modern mobile browser.

My point was that Opera Mini already is a big player :)

And this is a lesson learned:

As a web developer, your site is supposed to degrade gracefully.

You are not supposed to rely on any specific browser for mobile web development.

Write decent code that degrades gracefully, so that your content is easily accessible from any browser.

That’s what a competent web developer will do.

@wami, degrading gracefully is nice in principal, but there are times where you have to draw a line. For example, I have no interest in supporting ie6, even to degrade gracefully. My time is a rare commodity and I’m much more interested in spending it on things tha interest me, and old broken technology is not interesting.

Also if you want to innovate using these browser specific api’s (as suggested in the blog), the only way to degrade gracefully is to say to let your users know that it requires a different browser for it to work.

How to handle this issue depends largely on your current and expected userbase, what you think you can get away with, and how tolerant your userbase is of the requirements you are placing on them. If your userbase is largely mac users, then using more webkit specific features would probably be ok. If they are largely IE7 users, then they would likely be less tolerant.


Ouch. Saying I’m not a competent web developer eh?

Yes I’m well aware of how to degrade gracefully, although I’m not sure there’s a rule that says you are ‘supposed to’. Its a nice responsible thing to do for your users. I’ve been doing it for IE6 for a long time now.

Yes my mobile sites will work in crappier browsers. But when we’re talking about something to replace native apps, I’m largely developing for the huge portion of webkit browsers out there that are actually somewhat powerful.

Opera mini (the server side one) is basically useless. Its got rendering errors all over the place for old school css2.1 sites, limited to no javascript support, and essentially no support for html5/css3.

There is also some responsibility to the developer to help move the web forward when possible. I see the Opera stats are slightly higher in Europe, and then way high in other regions, but I’m hoping that’s Opera Mobile (the decent browser) and not Mini. Mini I’m guessing is usually more prevalent on cheap phones on slower connections. For now that’s not my target audience anyway. Not being the jerk American, just stating a fact. My sites will look ok for them, but great for those running a modern mobile browser.

@Mark Carey, you don’t have to actively support IE6. You just need to make sure your code degrades gracefully.

@Bob, frankly, I have no idea about your competence. However, I would expect someone who is competent to know about graceful degradation, and apply it.

Opera Mini is far from useless. Not everyone has the luxury of unlimited bandwidth and the latest phones ;)

Just had to note: you’re all talking about “graceful degradation”, rather than “progressive enhancement”. It’s a semantic argument, but one that informs the way we design sites.

I’d rather build a better user experience for a webkit user, than un-ruin an IE user’s experience.


Progressive Enhancement and Graceful Degradation are not the same thing – it’s not just semantic. I suspect that when we’re referring to graceful degradation here, we mean it. There is a level of complexity in webapps beyond which you have to switch from building the lowest common denominator, then enhancing it as far as it will go, to building things that are designed to do everything the app needs them to do, and then providing fallbacks where you can for the less capable.

PE is how websites should be built. Webapps are another story… if it is possible, then do – but at the cutting edge it is not always possible.

An example – I’m going to use SVG. Wait, no, I’m going to start with images and progressively enhance to SVG. But the whole point was to enable vector editing. There’s no point in having images in my app unless I can drag the lines around. Aww, well, you can’t do that. You can’t edit images. Let’s not build the app then, as it won’t actually do anything.

However, if I gracefully degrade – I’m going to use SVG. Tell you what, Those people who don’t have SVG – let’s feed them rendered images of the SVGs, that way they can at least they get to see the content of the site, even if they can’t edit it. Cool, let’s build the app.

You see? In webapp land PE is not always a useful paradigm.

I always thought that: As long as the content is relevant (within the given context), it doesn’t matter what’s the technology gonna look like. I would rather asked the question if the website (or browser) as a destination for content can still deliver great user experiences? – … try to answer that question from a user perspective, not from a developer perspective.



Great summary. I personally was getting a bit worried when GD was introduced into this thread and then it quickly jumped the tracks on top of that.

Then adding in the extra layer of this being a Web Apps discussion vs Web Sites and how we who build websites wholeheartedly (or hopefully should) use PE as a governing principle in our projects.

You did a great job of defining the differences btw all 4 paradigms and how they relate and intersect with each other and why PE potentially isn’t well positioned for WebApps.


Leave a Reply