Hacker News Reader

Comment by potch | Hacker News Reader

I work for Mozilla, but I speak for me.

Supporting a monoculture is trading future potential in the name of short-term convenience. This doesn't just apply to rendering engines, or even just technology. Wishing you could wave a magic wand and make everyone use the same tools, language, conventions, or coding style is something every engineer wishes from time to time, but the world would be worse off without diversity.

Wishing one rendering engine "wins" over the others is a reasonable thing to say, and WebKit is a very fine engine. But the moment we start treating the Web as a zero-sum game and stop collaborating on the vision of a better online experience, nobody wins.

View on HN

I'd prefer multiple vendor collaboration on a 1 spec > reference impl, than 1 spec > multiple incompatible impls. Innovation and experimentation could happen in "feature branches" of a master repo, and accepted once a majority of vendors are satisfied.

IMO supporting and testing against multiple rendering engines is the biggest PITA / productivity loss in web dev today. Being unproductive takes the joy out of developing software and having to support multiple impls is a sunk cost that creates no end-user value. Knowing about quirks of each rendering engine increases the cognitive overhead developers need to know when developing for the web, further stifling productivity and reducing the end-result quality of websites.

I'd rather only have to know and develop against a single implementation in the same way I prefer there is a primary UI SDK/toolkit for each OS.

I can understand where your argument comes from but in my experience with the web developing for webkit+gecko+(whatever powers opera) is pretty painless. It's only adding IE in the mix where things get hairy. I generally just build solely in chrome, and things end up fine when i test in firefox/opera. In the rare case where something is different, the dev tools help narrow down the issue quickly. Contrast this with IE which often breaks and has horrible tools. If we could get rid of IE, I really would not mind having to support the remaining browsers.

Agreed. My current project is focused on mobile, so I do the development using Chrome and Safari.

That said, I do test it on Firefox periodically and when something breaks it's usually an easy fix.

I'm not even attempting to make it work on IE.

The irony being that 10 years ago you'd be saying the exact opposite. Most shops supported IE only.

IE's tools aren't "horrible" either, they're just different and pretty much have the exact same functionality. In fact they were much better than Chrome's tools until about 2 years ago. Chrome's tools still even have some annoying features that are better in IE. Yes, I'm looking at you watch variables. Also much prefer their 'trace styles' over Chrome's massive list of every selector ever.

With all that said, Chrome's my development browser of choice these days. The right click inspect element is the killer feature over IE's dev tools. For some reason I've never got on with Firebug. For a long time I'd actually be using all 3 at once due to needing different logins, but Chrome's multi-profile support has stopped that.

Yes, it is a PITA. But if we didn't, we'd end up with a massive amount of code that was relying not on spec, but on quirks of implementation of that single implementation. This is the real benefit of multiple independent implementations. One implementation does not just lock in users, but it also locks that implementation into a far more rigid situation, where far smaller changer can break massive amount of code.

Exactly. I understand where the article is coming from, but I couldn't disagree more. Competition is both inevitable and a force for innovation.

Even if we were all to rally behind Webkit (unlikely), what happens when a significant portion of the community decide they don't like the direction of the project (and they will, sooner or later) - we'll get a fork, and be back to square one, only with a huge amount of damage done to the open ecosystem we have now.

[The] moment we start treating the Web as a zero-sum game and stop collaborating on the vision of a better online experience, nobody wins.

WebSQL[0] is an example where Mozilla (and their enabler in the HTML 5 standard, Ian Hickson) actively hurt users and developers by supposedly avoiding a monoculture by demanding multiple implementations. WebSQL should have been part of HTML 5, and we, as a community, have failed both users and developers since it's not. We failed because of an ideology that is hurting us in this instance.

Some history:

The lack of multiple implementations of SQL (the language) is the "reason" the WebSQL standard is in maintenance mode. But here's the deal: all WebSQL implementations today (e.g. WebKit, Google Gears) are based on SQLite, which is public domain software.

Specifying that SQLite[1] itself be used in the WebSQL standard, along with a WebSQL API for querying the actual SQLite version (e.g. "SQLite 3.7.15.2"), would directly solve literally every actual objection someone might have about WebSQL, except the multi-implementation/monoculture objection.

But the "multi-implementation/monoculture" objection should not be an objection at all since we're talking about SQLite: public domain software that every browser vendor can just use directly, and interested parties can check out the code and study if they want to know what is supported, and what, if any, "quirks" are present (the usual reason why codebases are not used as "standards", which is a valid complaint).

SQLite is just pure awesome and WebSQL makes it possible to do some really great things in the browser. Ideology here is just hurting everyone, for no actual benefit: instead of a monoculture, we have no culture at all.

[0] http://www.w3.org/TR/webdatabase/

[1] http://sqlite.org/

WebSQL as implemented was a terrible idea. Simply exposing SQLite's dialect of SQL to the web was always a non-starter in terms of web standards. You will quickly find (as you always do on the web) that pages would depend on bugs and other quirks in a particular version of SQLite, so trying to update the version you ship would be painful. You could ship multiple versions, or some sort of IE-like compatibility hell, or you could expose the version number and force web developers to test for ever possible version of SQLite so they can handle quirks themselves (protip: they won't).

The only way it was ever going to get off the ground was if someone fully spec'ed out a dialect of SQL that browsers could implement without being tied to the specifics of how SQLite works. Nobody stepped up to do that (and browser vendors weren't exactly foaming at the mouth to write their own SQL engine), so it died. You'd be better off writing a JS SQL engine that worked on top of IndexedDB these days, given that that's shipping in all major browsers.

Your opinion is no more than empty rhetoric.

A working implementation is better than nothing.

SQLite is public domain for Asimov sake!

Everyone can step up and fix it if it has problems, much easier than whatever you propose.

In fact, what you propose is a standard in the spirit of XHTML, with lots of text and good intentions and no practical use.

  > WebSQL is an example where Mozilla (and their enabler 
  > in the HTML 5 standard, Ian Hickson) [...]

Ian Hickson has been an employee of Google, not Mozilla, for as long as I can remember. What are you trying to imply here?

At least Gecko is open source, but he's got a point about IE being closed source. I mean it's still good in the sense that it provides "competition", but for the Internet it's still very bad that it's closed source. The more open source stuff the Internet relies on, the better it will be, and the faster the progress. Closed source and patent encumbered technologies are just slowing it down.

I agree with this, but have a (maybe related) comment/question.

This may be naive, but having used various WebKit browsers as well as Firefox, one aspect of the discussion that seems to be missing is end user extensibility. I notice that none the WebKit browsers support the customization that is present in Firefox (or other Gecko browsers, for that matter). This has mattered a lot to me for features like those provided by KeySnail (giving Firefox a very Emacs-like set of keybindings), Firebug, Greasemonkey and Stylish.

I suspect, though I haven't confirmed, that WebKit simply doesn't support certain kinds of extensibility along these lines. Regardless, I think advocating a monoculture where such a situation might arise is myopic. In fact, I doubt Chrome would be what it is today without Firefox...it seems that its extension system is clearly based on Greasemonkey and its development tools were inspired by Firebug.

Completely agree. First it is bad for the field in general to have only one approach. Currently rendering HTML5 and its transformations is a complex subject, without competition we don't know if there are better ways to accomplish this task.

>urrently rendering HTML5 and its transformations is a complex subject, without competition we don't know if there are better ways to accomplish this task.

Why, did anyone told you that the various engines differ in how the go about those in any real way that matters?

It's mostly duplicated code and similar approaches.

And even if it wasn't you can have different approaches in the ONE AND SAME codebase easily. Test alternatives out and see what works better. It's even easier when everybody is using the same engine, because you don't have to also implement EVERYTHING else yourself in order to implement one thing differently.

I think completely different. I want more approaches on web rendering like I want more operating systems, even if they are attacking niche applications or playing "fantasy" games. I don't care.

You are talking about how currently HTML5 is implemented, but there is a long road of optimizations, HTML is a new technology and HTML5 is not yet here (try it on your mobile phone).

Do you remember anyone talking about hard javascript engine optimization until Google Chrome "attacked" with their implementation and anybody tried to catch up.

>You are talking about how currently HTML5 is implemented, but there is a long road of optimizations, HTML is a new technology and HTML5 is not yet here

What exactly makes a "long road of optimizations" incompatible with having one engine? As a matter of fact I don't expect any competing engine to disrupt of surpass Webkit in overall speed for the next 10 years (except maybe by some inconsequential amount in some neglected area).

>Do you remember anyone talking about hard javascript engine optimization until Google Chrome "attacked" with their implementation and anybody tried to catch up.

Yes. In fact SquirrelFish was the first new gen Javascript engine, started long before Google Chrome came out. Plus "two weeks after Chrome's launch, the WebKit team announced a new JavaScript engine, SquirrelFish Extreme, citing a 36% speed improvement over Chrome's V8 engine."

Metric system

The metric system is equivalent to web standards, which (almost) everyone agrees is good. His argument is like saying "we should only have one set of weighing scales or one type of tape-measure to measure metric things".

Web standards are like the metric system. Rendering engines are like measuring tools.

Other measurement systems definitely have their uses though. Many older measurements still exist due to them being easier to estimate with; e.g. an acre being the amount of land you could plow in a day.

And you'll never have the British drinking from litre glasses, I'm afraid. It's pints or nothing.

"an acre being the amount of land you could plow in a day" isn't that an extremely subjective way to measure something? And to almost everyone even modern farmer is that actually a good basis considering a modern farmer can most likely plow much more than an acre in a day with machinery?

Oh absolutely, if they updated it to be based on modern farming then everyone would have significantly less acreage :D

But you'll find that with most imperial measurements; they're based on physical objects or systems of measuring which make less sense today. One of my favourites being the traditional way of counting sheep in the north of England: http://www.fellpony.f9.co.uk/country/wool/count.htm (and here's a great explanation and song by the late Jake Thackeray: http://youtu.be/TiXINuf5nbI).

Sure, not from litre ones, there's too much binge drinking already :) But the half-a-litre glasses, common in metric countries, are a very close replacement to pints in terms of volume.

But not quite! ;) Somehow that extra 68.3ml makes all the difference.

Laws of Physics.

>Supporting a monoculture is trading future potential in the name of short-term convenience.

By supporting lots of rendering engines to do the exact same thing in various degrees of brokeness we haven't seen any "future potential" and we also lost the short-term convenience.

>Wishing you could wave a magic wand and make everyone use the same tools, language, conventions, or coding style is something every engineer wishes from time to time, but the world would be worse off without diversity.

I'm not sure. I see a lot of examples where diversity has fucked things up:

1) Linux fragmentation for example killed it as a platform for proprietary apps, 2) Gnome/KDE/... fragmentation killed the Linux desktop mass adoption, 3) Tons of C++ compilers make cross platform C++ code more difficult (it's a little better nowadays)

I also see many examples where lack of diversity has made things better:

1) Ruby web frameworks? 99% of the people go with Rails, and it gets all the improvements and stuff (compare with Java/PHP web frameworks).

2) Mobile rendering engine? 99% of companies go with Webkit and free lots of their resources up plus contribute to the betterment of the project.

>But the moment we start treating the Web as a zero-sum game and stop collaborating on the vision of a better online experience, nobody wins.

How about solving the "collaborating" problem by working on the same engine?

Reply on news.ycombinator.com