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

Re: Food for thought (resurfacing)

From: Alex Russell <slightlyoff@google.com>
Date: Wed, 23 Jul 2014 15:50:56 -0400
Message-ID: <CANr5HFWAFHQc-rsiew2rgFh1V+=qg8TuQMZLPdMHYvwVYo-h9A@mail.gmail.com>
To: Marc Fawzi <marc.fawzi@gmail.com>
Cc: Charles McCathie Nevile <chaals@yandex-team.ru>, Marcos Caceres <w3c@marcosc.com>, "www-tag@w3.org" <www-tag@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On Wed, Jul 23, 2014 at 1:23 PM, Marc Fawzi <marc.fawzi@gmail.com> wrote:

> <<
> 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.
> >>
>
> Hi Charles,
>
> Can you point me to some? I'd love to learn about those browsers. Being at
> Yandex I'm sure gives you a good view of what's out there internationally.
>

Maxthon <http://en.wikipedia.org/wiki/Maxthon> has traditionally been the
most successful multi-engine browser; embedding MSHTML and Webkit/Blink.


> <<
> 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?
> >>
>
> Well, the assumption is that the engines will be hot swappable and "hot
> pluggable" meaning that the browser will check on start to see if any of
> them have had updates and download the new version.
>
> I haven't done any work with C/C++ and no COM or .Net for a very long time
> (10+ years) so for me projects like Exo Browser are good way to explore the
> idea of building a special purpose browser.
>
> The reason I said that the current market does not have room for special
> purpose browsers is because I have not heard of any and I'm glued to web
> development news so even if some exist they are so obscure, and not
> cataloged anywhere. If you know of any, I'd be interested to read about
> them.
>

http://en.wikipedia.org/wiki/List_of_web_browsers

http://browsers.evolt.org/


> <<
> 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.
> >>
>
> Node-Webkit claim that Node + Webkit run in the same process.
>
> Thanks,
> Marc
>
>
>
>
>
>
> On Wed, Jul 23, 2014 at 9:05 AM, Charles McCathie Nevile <
> chaals@yandex-team.ru> wrote:
>
>>  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 19:51:53 UTC

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