The Ajax renaissance, Web 2.0, maps.google.com, all of that came about due to multiple causes. Mozilla never claimed credit for more than Firefox, which took market share back from MS (not something you see much), caused MS to change its plan of record re: unbundled IE update prior to “Longhorn”, and helped accelerate the Ajax trend. As Karl points out, XHR took off after more than one browser supported it.

It’s simplistic to argue about what one cause turned things around. And yeah, my “big dumb company” generalization is (slightly) simplistic. There are smart people everywhere, including at big companies. Big companies do tend to suffer from O(n^2) communication overhead and worse political/human problems. The innovator’s dilemma is haunting even Microsoft, which is “the new IBM” according to some pundits.

I do believe that significant innovations in software come from individuals and small groups, and those generally operate outside of big companies, or via skunkworks projects within more enlightened big companies.

/be

Neither. It was MS not releasing a browser for 5 years. This allowed NN4 to die in peace and got everybody on the same verion of IE, the one post-browser-wars, so we pretty much got a clean start around 2002 or thereabouts (not that anybody noticed with the job market and whatnot).

This brings us to the dreaded “IE Effect” (or “NN4 Effect” if you’ve been around long enough). Specifically, you really can’t deploy a quirk unless you have a workable solution for 90%+ of the market, so you get the lowest common denominator.

I’ll note that XHR use didn’t really kick off till all the other vendors had implemented it in their browsers. Similarly, complicated canvas use is constrained by no native canvas in IE. Opera’s proposed video tag will be similarly constrained. For better or worse, Flash is the only real solution for deployable high speed canvas, video, and sound. The real problem with this is when you run into things like JavaScript 2, which I foresee becoming a major pain point because I haven’t heard anything about it from vendors besides Mozilla. JS2 fixes a whole lot of problems in JS, but I’m not sure how many years will pass before I can actually use it, if ever, which is depressing.

I would really love to see MS join the WHATWG. Unlike most standardistas, I ascribe more authority to the WHATWG than I do to the w3c. They seem to move quicker, generate more tractable APIs, and things actually seem to get implemented in a reasonable timeframe. I’m sympathetic to the various vendor efforts and don’t think that they should quit, but without MS (or a de-facto plugin for IE alongside PDF and Flash) I really can’t make use of this stuff. To be honest, I’m expecting to see Adobe take a significant chunk of the web app space starting from multimedia and working down. How much depends on how well Flex/Apollo works.

I’d say the more important innovation came from what Brendan refers to as the “big dumb company.”

I’ve been kind of getting that general feeling from the Moz folks. And yeah, wasn’t suggesting platform only. Focused product development is a necessity.

It will be interesting to see if Adobe Apollo succumbs to versionitis and under-use.

/be

Not saying it’s not without pitfalls and dangers.

we are not there yet, and Mozilla and other browser vendors are innovating

Straight up. And I’m not promoting one tech vendor over another.

But what you say here strikes on a good point. “Mozilla and other browser vendors”, Mozilla is not just a browser vendor. They have lots of cool projects, calendars, email clients. All outside of the browser! I like to view Mozilla more of a platform vendor.

But will Firefox 3 be distributed on XULRunner or not? That would be a slick runtime distribution scheme! I like XULRunner and have bult multiple apps with it. But on the Firefox3/Gecko Feature List, the “Firefox on XULRunner (and shipping XULRunner platform)” item is only given a P3 priority, and the comments read:
“In Progress; we can ship without it”

Ok, I overstate my case above. But so do you — in fact you assume your conclusion. There’s a trade-off between working in the browser and requiring a new runtime. It’s not all smiles and sunshine, for developers or for users, going the latter route. It may be winning or losing depending on a lot of factors.

If over time the browser remain too limiting and proprietary or other runtimes grow more popular, we’ll know the trade-off resolved in the way you assert. But we are not there yet, and Mozilla and other browser vendors are innovating. So the race goes on.

/be

Depends on a few factors:
1. Does the user already have the runtime?
2. Is the experience of obtaining the runtime streamlined? (Mechanism, download size, etc.)
3. Does the app make it worthwhile, does it provide enough value to the user?

if it can host your premium application

Thats the question, what determines that? The user experience, requirements, and specifications of the app, or the limited functionality of cross-browser support? Which ones give you greater freedom to design for the user?

(does that include gmail or greader? Yahoo! webmail?)
I use Mail.app for email/gmail. And since news reading is tightly related to browsing documents, I use Safari’s RSS reader.

That brings up a good point though. Do your users expect a version of your app to run in the browser? If so, can you reasonably provide the desired experience in the browser alone? If not, what features go into a “light” browser-based version, and which features go into the “full” version? And how can you best reuse development resources across the two? (.Mac provides a webmail interface, but it doesn’t provide everything I can get from Mail.app)

You use a browser because people already have it open when they visit your site and thus it provides the lowest barrier of entry. As a bonus, the browser provides a familiar environment for the user where they know that they’re in control. Until something comes out that replaces the browser (Apollo is trying…), the browser is the place to be.

Exactly! The browser has some serious limitations. We shouldn’t be limiting our thinking to just it. The barrier of entry question is answered above.

…that such control eliminates the opportunities that are created when application developers … are afforded the opportunity to affect the evolution of those platforms at the most basic levels…

I have to agree here with the point that John Dowdell made in comment #5. The nature of a single vendor control does not eliminate opportunity for community feedback and interaction. While it does keep individuals from direct source control, that is not the only way in which users “affect the evolution of those platforms.” The responsibility for development lies with the vendor, but these big companies don’t exist in a vacuum. Responsible vendors welcome user feedback and often poll or invite questions at conferences just for that purpose.

And sorry to say …, the big innovations don’t come from the big dumb companies.

In this quote (from Brendon Eich’s blog post) is what I fear to be the crux of the fallacy. The fact is, big dumb companies who are out to make money from their off-the-shelf software do make very big and valuable innovations that help not only to drive the open source community (in efforts to keep up with major features and interoperability) but also create an easy method for newcomers to the industry to break in quickly and easily by using simple packages with precise documentation.

Far from championing closed source development, I do defend it as a necessary method for revenue and a boon to the industry. On the same token, open source development is also completely necessary and welcomed. Without the dedicated efforts of this community, many bloated vendor applications would fall stagnant without competition or voiced criticism. The two methodologies are both quite vital to the development of the web today.

So, to answer your question of which is better for the web: both.

~tomasino