<i>> So launch a different browser. Not a big deal.</i><p><i>> […]</i><p><i>> As someone who has tried to do both cutting edge native and web iPhone apps, iPhone Safari is a joke compared to iPhone Cocoa</i><p>What he is basically saying is developing natively instead of for the web can give a better result, and he would prefer to drop cross-browser compatibility and just have users launch whatever browser he developed the app for.<p>The question is why develop for the web at all if your apps only run in a certain browser? He seems to make the assumption that while his app can’t run in all browsers, the browser it does run in is available “on all platforms”.<p>I think he needs to rethink what the purpose is with HTML, semantic markup, and having a standard.
I know for a fact that my grandparents would find it a big deal to have to launch different browsers for different sites, and I'd venture to suggest that the majority of web users feel the same.
WebKit is already doing this. They constantly implement new features that are later imported into HTML5 or CSS specs. For example, canvas, shadows, CSS transforms and CSS transitions were all things that WebKit introduced in its nightly builds and the standards groups later adopted specs for them. Just Google any of these technologies and you'll see the posts introducing them on the Surfin' Safari blog years before the initial version of the respective standards.
I disagree that the app stores are successful because of superior APIs, they are successful because you can charge for apps and make money.<p>But he is correct about Microsoft and web standards committees.
A great rant by a practitioner who wants progress to go faster, ideologies and committees be-damned.<p>But, a little revisionist about why browser innovation slowed. It wasn't Microsoft yielding to standards demands that slowed their pace; it was Microsoft's de facto victory in (for a time) neutralizing the business possibilities of competitive browser development.<p>It took a while for alternate models that could sustain further browser evolution -- the Google placement payments to Mozilla, Apple's sponsorship as a complement to their other platforms -- to grow to take the place of the original Netscape dreams.<p>Hewitt's prescription seems right, though: a bit of healthy disdain for waiting for standards bodies before deploying new things, and some added respect for even those proprietary offerings -- like Flash -- that kept expanding capabilities and user expectations when browsers didn't.
I think the real solution is not to provide more advanced features in the browser, but to provide more primitives. Lots of programming languages over the years have, at least for a while, compiled to C. C is an almost universal primitive. The web doesn't have a universal primitive. HTML, CSS, and JavaScript are high level languages. If you try to use a high level language without ever accessing lower level functions, you will eventually run into something you can't do. The web has hit that point. We need a way to fall back to lower level languages when the abstractions become too leaky. The web needs a C: a language which can do anything if you put in the time and energy to make it work, which is blazing fast, and which is available everywhere.
Overall some very interesting points, but as I remember it, MS stopped innovating in IE when the competition died off. Netscape was in the gutter and went OSS, which ended up meaning a massive gap in releases while they rewrote the thing, and Opera was still for-pay. The DOJ intervention was too late to have any impact.<p>Hence, IE6 remained stagnant until MS started feeling some heat from Firefox.
These people liked IE, the worst browser ever?!? They reject standardization?<p>If they really want a history lesson, then return to the pre-browser days -- yeah, you had to #ifdef and port your code over and over and over, always chasing the latest APIs (the time of origin of that horrible phrase, in fact).<p>Standardization fixed that.