W3C home > Mailing lists > Public > www-tag@w3.org > July 2014

Re: Food for thought (resurfacing)

From: Alex Russell <slightlyoff@google.com>
Date: Tue, 22 Jul 2014 11:30:48 -0400
Message-ID: <CANr5HFVLfJ1YV0M7PSNFXTJ9SQr1ux8GrQ91X4v+w-zpX+YZHQ@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Marc Fawzi <marc.fawzi@gmail.com>
On Fri, Jul 11, 2014 at 7:14 PM, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On July 11, 2014 at 6:54:36 PM, Domenic Denicola (
> domenic@domenicdenicola.com) wrote:
> > >
> > Hi Marc,
> > Happy to have your thoughts, and glad you felt welcome to contribute
> > :). That's what we're here for.
> >
> >
> > The immediate issue I see is, what is the incentive for browser
> > vendors to do this? There is none I can see. And the fact that they
> > haven't done so implies either their business strategists have
> > never come up with this idea, or have already decided it is not
> > worth the cost.
>

That's incorrect. We did do this with Chrome Frame, although admittedly it
was us at Google making IE's engine pluggable ;-)

It was absolutely worth the (high) cost to do, but the window of
opportunity. Auto-update and real competition deliver the same sort of
forward progress we'd hoped that Chrome Frame would enable.


>  So you are correct... but Servo does, for instance, implement WebKit's
> embedding API (on purpose, so it can be a drop in replacement... or at
> least, that's the dream). I assume Blink's embedding API is very similar to
> WebKit's (given they have the same provenance)... though I've never looked
> closely.
>

The deep differences in embedding strategy is perhaps the largest
difference between Blink and WebKit. Blink is "batteries-included", WebKit
is "BYO". And implementing an API is a WORLD different to ABI stability
which is what MSFT has done with Windows (to their enduring credit and
thanks to COM) and which no other browser I'm aware of does this. There's
some attempt at ABI stability with plugins, but even that is fraught.

You MIGHT get some distance down this path with something like Mojo, but
you'll want NaCL or some other sandboxing system to enable it and there
isn't agreement among vendors about any of the details of what or how to
enable this: http://www.chromium.org/developers/design-documents/mojo


> Remember also that Opera basically ripped out their engine and in a matter
> of months was again up and running with Blink inside. But yeah, there was a
> good year of pain for Opera to get their browser's features back to where
> they were with the Presto engine.
>
> And PhoneGap is essentially doing what Marc is kinda alluding to: it's
> basically like a jQuery for device APIs, in that it tries to provide a
> consistent base across a huge number of browser engines to access device
> APIs... with jQuery then doing much of the heavy lifting in getting a
> consistent DOM across all the engines.
>
> > And that cost is substantial---if you have ever
> > looked at the plumbing code between the UI layer, the rendering
> > engine, the JavaScript engine, the add-on system, the developer
> > tools, and all the other components of a browser, you'd find that
> > swapping in rendering engines or JS engines is not at all an easy
> > task.
>
> Yeah, it's pretty massive.
>
> > Which then transforms the question into, who is going to force
> > browser vendors to do this, despite it being against their best
> > interests? The W3C? They could try, but would be laughed into
> > obsolescence. The government? Unlikely.
> >
> > There is lots of other interesting points to address in your thread,
> > and I hope someone else can chime in with how browser game theory
> > governs the market, and the tenuous hold the W3C has on influence
> > even today. But let's start with the practicalities.
>
> Yeah, I wouldn't even know where to start.
>
> Marc, remember that the point of the Web (unlike other platforms) is that
> it's royalty free and open. If we are talking economics here: The "tax" you
> (Mark), as a developer, pay from having to deal with cross-browser introp
> problems is comparable to the "tax" that you would have to pay Apple (30%)
> to list your app in the apps store. However, we hope that it's less - and
> that the Web is giving you better value for money for a number of reasons.
>
> What you get in return from your tax contribution is that ability to
> publish whatever you want (freedom of speech), as often as you want (no
> need to go through an App Store review process), to a market way larger
> than iOS, Android, etc. put together. That's pretty awesome.
>
> The cost is, like I said, that you have to deal with cross browser introp
> issues. But the wins for society and the ability for you, as an individual
> to reach this audience, is massive. It cannot be understated. And you get
> it essentially for free. That's a pretty sweet deal - this Web thing :)
>
>
>
>
>
>
>
Received on Tuesday, 22 July 2014 15:31:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:03 UTC