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

Re: Food for thought (resurfacing)

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Wed, 23 Jul 2014 18:05:01 +0200
To: "Marcos Caceres" <w3c@marcosc.com>, "Marc Fawzi" <marc.fawzi@gmail.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>, "Domenic Denicola" <domenic@domenicdenicola.com>
Message-ID: <op.xjgkancpy3oazb@chaals.local>
On Sat, 12 Jul 2014 16:45:38 +0200, Marc Fawzi <marc.fawzi@gmail.com>  
wrote:

> Hi Marcos,
>
> Well, if someone with your knowledge thinks this is doable but still a  
> huge effort I'll have to drop my quest for now.

As well as the things Marcos noted, there are a number of chinese browsers  
that combine two engines - and projects that have done this beyond China.

One of the difficulties is that the pieces of a browser have pretty tight  
relationships if you want to get good performance - and the major browsers  
often want that.

>
> I'll keep watching the interwebs for similar thinking and efforts in  
> that direction.
>
> If vendors were willing to play a different kind of game, where the  
> browser acts as the OS thus allowing any other browser's JS and  
> rendering engine to run within >it, selectable by the developer, then I  
> think users, developers and vendors will all benefit. Only vendors who  
> will lose are those who lag behind in innovation.

I'm not so sure that it is a good idea even so. It assumes that a given  
browser is a relatively static target, but that actually isn't the case  
either. What happens when a browser makes a major change, e.g. to fix a  
security bug?

> The market has room for say 10 different browsers each with a major  
> share whereas right now we have 3 browsers that rule the market, all  
> from big companies, >and no room for special purpose browsers (the game  
> just doesn't scale)

I think there is room for smaller specialist browsers - and the fact that  
a lot of them exist suggests that isn't wrong. By definition they are  
unlikely to dominate, but they can certainly dominate their niche. Opera  
Mini is the example I know best, but it isn't the only one.

cheers

chaals

>
> I'll explain more in my next break.
> Thank you for your response.
>
> Marc
>
>
> On Fri, Jul 11, 2014 at 4: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.
>>
>> 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.
>> 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 :)
>>
>>
>>
>>
>>
>



-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
Received on Wednesday, 23 July 2014 16:05:35 UTC

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