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

Re: Food for thought (resurfacing)

From: Marc Fawzi <marc.fawzi@gmail.com>
Date: Thu, 24 Jul 2014 09:13:03 -0700
Message-ID: <CACioZiuxkv4S_Q-ddHwV3_6goBDjsZZCKN2aH2_Ag=f=TKSihw@mail.gmail.com>
To: Alex Russell <slightlyoff@google.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>
At my workplace we have a bunch of corporate apps that we use for HR,
sales, dev, etc. The dev apps work on every browser. The Sales apps do,
too. The HR apps, least sexy of all, are very particular about the browser
they work on. Some work best on FF, others are best on Chrome, and yet some
are designed primarily for IE/FF and break in certain places on Safari and
Chrome. These are real web apps used by millions.

Imagine if you had a browser where all apps work as expected and the app
developers spend all their time on actual feature development as opposed to
cross-browser testing, debugging and patching. A browser where the
developer of the app gets to decide the environment the app runs in while
the user get to decide on the browser UX and "value add" that may be part
of it

Maxthon seems to have the right approach in mind by focusing on the UX and
supporting multiple engines under the hood.Their "value add" seems to be
the cloud services bundled with the browser.

We're also a product centered company, so we have many dev teams, and on my
team we're paying thousands of dollars for saueclabs.com every quarter just
to be able to have automated test coverage across the 3-4 major browsers on
OS X and Windows, and we're ignoring iOS and Android for now since we have
native apps but we plan to extend our tests to mobile later on. I don't
think we can afford our own multi-browser test infrastructure. The company
is just under 1000 people.

90% of our bug reports are browser specific, and I just started this job,
so I'm working with a lot of sub optimal decisions and scenarios, until we
can get ahead of the defect backlog, which again is 90% cross browser
issues.

There's gotta be a way out other than App-ifying the Internet.

Thanks very much for all the insights.

Will keep thinking/exploring on the sideline :)

Marc










On Wed, Jul 23, 2014 at 12:50 PM, Alex Russell <slightlyoff@google.com>
wrote:

> 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 Thursday, 24 July 2014 16:14:15 UTC

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