Comment by magicalist | Hacker News Reader

Comment by magicalist | Hacker News Reader

Parent Full thread

> We see more of this fragmentation every day

I'd be curious to see this backed up. Certainly with a long enough timeline we are not at a maximum of "works only in x", and -- ignoring those beleaguered Opera users still subjected to crappy UA sniffing -- I can't think of the last time I came across a site that blocked me for whatever my choice of browser (I'm a Chrome and Firefox user as well).

If, on the other hand, you're talking about fancy new CSS3 or WebGL (or whatever) demos leaving out some browser due to neglecting to add a particular prefixed property (or whatever), I don't really see that as a problem. Prototype then standardize, right? Yes, not feature detecting and prefixing properly is poor web development practice and yes, they are cutting out part of their audience, but using an experimental feature inherently means that it may break at some point, and almost certainly isn't supported in all browsers.

When 3d CSS transforms land in Firefox soon, there are going to be a whole lot of demos out there that won't work. I would say that's an education and library problem, not a fragmentation one.

I was explicit about the problem, which is not new features that come to some browsers first, advertised in a browser-agnostic way. That is ok, provided the features are on a standards track. What I cited is fragmentation due to capital-C Chrome as a requirement.

Google is doing deals and marketing web apps and add-ons as "Chrome". This is showing up all over the place, most recently in my experience on the Starbucks free wireless service agreement page.

Major content publishers Mozilla has talked to are surprised that we can host their Chrome-targeted web apps and HTML5-based extensions. They think such things are exclusive to Chrome. If they use Dart and need native performance, then that'll be true. There is a slippery slope, especially when more and more of the differentiation is not on a standards track (Dart, NaCl, WebSQL).

Nevertheless most of the current differentiation is bogus and any modern browser will do. There's certainly some "WebKit required" fragmentation. We saw this with Amazon's kindle web app, which is specifically built to WebSQL and not IndexedDB. But I do not believe any big player is pushing "WebKit required" as an agenda or marketing program. In contrast, Google is clearly pushing "Chrome" as a requirement or works-best-in brand.

The Chrome experiments, most recently

http://www.allisnotlo.st/index_en.html

are obvious, maybe too obvious. Defenders can always play up the "experiment" hedge. That helps but only so much, especially when many of these experiments could work in other browsers with trivial changes.

I'm told that people have run chrome.angrybirds.com in Firefox. So it should be html5.angrybirds.com but -- no surprise from a marketing angle -- the domain name starts with C not H.

Brendan,

First, I'm a huge fan. :)

... and I was with you until the WebSQL vs IndexedDB thing.

IndexedDB is a horrible, horrible thing. It should be put out of its misery and replaced with WebSQL in Firefox.

Mozilla is singlehandedly holding back offline web apps with the insistance on a slow and hard to program -- yet buzzword friendly -- technology that no one actually wants to use. There's no reason what so ever to stick with a dumbed down K/V store when you're not trying to replicate data across data centers.

So, IMHO, you've bought this bit of "WebKit required" onto yourselves. WebSQL is the only production ready offline web app technology available today.

Take it from someone who offline enabled one of the biggest web apps on the web: I'd rather leave out offline entirely than code IndexedDB.

Considering that Apple will never support it, it's pretty much dead. And I feel that Mozilla is really on the losing end of this particular battle.

TL:DR; Please support WebSQL in Firefox. :)

The first step would be for WebSQL to be a W3C/WHATWG approved standard & recommendation. Until that happens, no browser should implement it.

Maybe IndexedDB is bad. I'm withholding judgment. That's not the point, and your demurral on that particular example should not make you reject my entire argument. WebSQL is not standards-track, period. Whether it should somehow get back on the standards track, let's debate elsewhere.

We could go awry on H.264 vs. VP8 too (I'm not religious), but note how Chrome has best of both worlds, including paying the gangster fee (MPEG-LA license). Not exactly "open".

The minor point for this discussion is that works-in-WebKit happens, but mostly unintentionally or out of rank laziness on content authors' parts. It may even (as you suggest and I agree) provide a big clue-stick to repair a standardization mistake or pox-on-both-houses-try-again situation.

Meanwhile, and this is the major point: works-best/only-in-Chrome looks like an intentional marketing game, backed by a nine-figure budget. Big difference there.

How should we deal with the mandatory dependency on a particular major/minor/patchlevel version of SQLite? That seems bad to standardize on.

I personally think there's definitely room for a SQL database API built into the browser, but Mozilla did have a point. It should be something a little bit better specified than that.

Also, it's not singlehanded -- IE refused to support Web SQL as well IIRC, and they aren't going away anytime soon.

Thanks, that's worth reiterating: IE wasn't buying. Alas they didn't get IndexedDB done for IE9. And, just because WebSQL wouldn't fly does not make IndexedDB the one and only winner. We need to revisit this whole messy area.

MongoDB for everyone!

did anyone on the standard bodies (from MSFT?) suggest LINQ framework as a WebSQL "replacement" ?

it makes a lot of sense IMHO. it abstracts away dependency on exact SQLite version, but preserves a familiar SQL-like mental model. it is stable, mature, well understood and widely deployed/used (god i sound like a shill.. ;)

and has the added benefit that it can be implemented in two different flavours: as a standard JavaScript (ES3) library on top of WebSQL (or SQLite in Gecko), or as a first-class language extension with syntax sugar similar/related to array comprehensions (from JS1.7/Harmony/ES6)..

check out the two code samples, and a list of language extension (all feeling right at home in JS): http://en.wikipedia.org/wiki/Language_Integrated_Query#Langu...

if it wasn't proposed, can someone from WHATWG (like you Brendan ;) politely ask Microsoft to "contribute" any related intellectual property to W3C? how likely do you think would it be for AAPL/GOOG to accept it? (and if not, it could simply be implemented as a thin layer above WebSQL ;)

I agree with many of the points you have made in this thread, it is indeed a worrying trend.

Howver, I am not sure it is fair to tar WebSQL with the same brush as these other technologies. WebSQL was on the standards track, and in fact started there. The main reason it isn't any more is that Mozilla representatives insisted on kicking it off the standards track instead of fleshing out the spec to be truly independently implementable.

The most common use of SQL you see is in iOS/Android-targeted Web apps, because WebSQL has been around there fore a few years while IndexedDB is new and isn't shipping in production quality anywhere.

Google is actually pretty sanguine about replacing WebSQL with IndexedDB.

Better examples of this trend would be:

SPDY as a replacement for HTTP, actually used in production by Chrome talking to Google servers, not a hint of it on any standards track.

VP8, where Google's single-source implementation is more authoritative than their spec, and no hint of it on any standards track. No apparent interest in putting it there.

(I realize Mozilla is on board with VP8 due to the patent licensing issues with MPEG, but consider the risk of giving Google total unilateral control of video codec design. I would have hoped that Mozilla insisted on taking VP8 through a real standards process before signing on wholeheartedly.)

Maciej, why do you write as if Mozilla doesn't ask for (not "insist" on) things with Google and fail to prevail? We do that all the time. Some in Mozilla are still waiting for the good thing to happen.

In VP8's case, what alternative do we have that isn't OS-dependent? We can't afford the gangster fee.

I am wholeheartedly convinced that you asked privately. It might have made a difference if Mozilla had publicly asked for an open standards commitment. As things stand, Google got PR cover for a power grab. I also think it was a reasonable choice for Mozilla to sign onto VP8 anyway, given the lack of better alternatives for you. However, I think VP8 is still a better example of the phenomenon of Google's increasing promotion of purely Google-controlled technologies than WebSQL is.

The video codec situation is really quite sad. There is no technology option that is all of an open standard, RF licensed and sufficient quality. Vendors all have to make their choices out of the imperfect options we have.

https://chrome.google.com/webstore/detail/ejidjjhkpiempkbhmp... and https://chrome.google.com/webstore/detail/ejjicmeblgpmajnghn... if you want two most recent examples of Chromium-only applications, where nobody gave a damn whether they follow agreed upon standards.

I agree that gmail only having offline for certain browsers is suboptimal for the web (though they claim, like amazon with their kindle app, that they will expand support), but it's worth noting that at least the gmail app includes an installable component equivalent to an extension...and there are plenty of single-browser extensions for every browser.

Reply on news.ycombinator.com