Re: Food for thought (resurfacing)

On Mon, Jul 28, 2014 at 7:42 AM, Marc Fawzi <marc.fawzi@gmail.com> wrote:

> http://www.nidium.com/
>
> example of a new kind of browser engine that could have a much bigger
> marketshare if the major browsers (Chrome, IE, FF) were to allow loading of
> browsers engines based on the app developer's selection
>

Mainline browsers will not do this except with sandboxing requirements. See
NaCL (previously mentioned).

Instead, this group is focused on ensuring that the primitives needed to
render and run content are exposed to developers in standardised. That
level of primitive control will enable developers to only re-build the
portions of the experience that are necessary to deliver the experiences
they want to and it's the whole point of the Extensible Web Manifesto:
http://extensiblewebmanifesto.org/


> it's a monopoly market and so I understand that the vendors have no
> incentive to open up their platforms in this way,
>

It's clear that you fundamentally misunderstand the terms "monopoly" and
"market".


>  but the fact the Nidium exist and its developers have invested so much
> effort into it means that at some point someone will make the leap and do
> it.
>
> sorry, not meant to re-continue the discussion (I got all stated points :)
> , just a final bit of info
>
>
> On Thu, Jul 24, 2014 at 6:31 PM, Marc Fawzi <marc.fawzi@gmail.com> wrote:
>
>> I guess the pain is going to be lesser and lesser as more users move to
>> evergreen browsers, but for now we have users on IE8 and IE9 and they count
>> for about 20% of our users. The idea of "upgrading" external users is not
>> possible and sounds a little like "let them eat cake" in this instance;
>> they're simply stuck on those browsers. As the hardware dies and people
>> have to upgrade then we'll see more IE10 and IE11 users.
>>
>> But even in evergreen browsers there are still some differences if you're
>> working with newer technologies like IDB, Web Crypto, and several other
>> areas. I can make a list but I have to allocate sometime for that. Having
>> said that, there are libraries that dissolve most of those differences so
>> you can say that the web is finally working! But not for those of us who
>> are experiencing severe pain supporting older IE versions.
>>
>> Aside from all that, the idea of a browser that can switch between the
>> both the major rendering/JS engines as well as niche browser engines is
>> theoretically interesting, from various points of view, which means that
>> there may be room for deeper thinking, and so I'll keep exploring it.
>>
>> Very useful input. Thank you all.
>>
>> Sent from my iPhone
>>
>> On Jul 24, 2014, at 2:28 PM, Alex Russell <slightlyoff@google.com> wrote:
>>
>> +1 to what Marcos said. The important thing for organisations about
>> Chrome Frame was that it let them *out* of the world where their renderers
>> were stuck in time and weren't auto-updating.
>>
>> So yes, TAG members and (some) browser vendors have thought about this
>> problem at length and the current consensus is that auto-updating runtimes
>> and real competition deliver much of the value with fewer downsides. We're
>> not to a fully auto-updating world yet, but are closer than ever before and
>> the trend lines are good.
>> On 24 Jul 2014 13:08, "Marcos Caceres" <w3c@marcosc.com> wrote:
>>
>>>
>>> On July 24, 2014 at 5:13:45 PM, Marc Fawzi (marc.fawzi@gmail.com) wrote:
>>> > 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.
>>>
>>> It might be worth looking to see if it's really a Web platform problem,
>>> or development/developer problem, or a user problem (out of date browsers).
>>> There is a fairly stable and interoperable base across browsers, and if
>>> your cross-browser bugs are that significant it might be that the
>>> developers at your company are indeed using proprietary features/quirks
>>> rather than using core Web platform features. Otherwise, it might be that a
>>> subset of your users are stuck on some old browser version and upgrading
>>> them might fix the cross-browser issues.
>>>
>>> Calling for the ability to hot-swap engines doesn't address the core
>>> problem: interoperability. It actually makes things worst, because it no
>>> only means being able to hot-swap the engine, but probably target a
>>> particular version of that engine (e.g., IE7). Imagine now how many
>>> different engines would need to be bundled into a hot-swap browser. You
>>> would have - i.e., 6,7,8,9,10,11,12 + then every version of Gecko + every
>>> version of WebKit + every version of Blink. And it means supporting those
>>> versions and their bugs forever (which, through their quirks, expose
>>> security issues). That is, of course, unrealistic (ask Microsoft how that
>>> strategy worked out for them, as they tried to do this a few times over the
>>> years with just IE).
>>>
>>> No software is stable, and has to be maintained (this applies to both
>>> websites and browsers, obviously). On the Web, we (browser folks) try to
>>> support legacy content as much as possible where it makes sense (e.g.,
>>> silly tags like <blink>) - but we also often have to fix and correct issues
>>> to benefit/protect users, which sometimes breaks corporate apps, etc. It's
>>> why we have things like Chrome Canary and Firefox Nightly + beta versions
>>> of each browser, which allows folks that maintain applications to check
>>> that their apps won't break with each new release + gives devs time to fix
>>> any issues and test out new features. This buys developers on the ground
>>> about 3 months to make sure their apps will work well before users get
>>> their browser's automatically updated.
>>>
>>> So, my recommendations would be to review the development practices
>>> inside your organization + try to understand which browsers users are using
>>> (e.g., some users might be stuck on some old browser version - so actually
>>> just updating those users to a more modern browser would address the cross
>>> browser bugs without the need to fix the web application - which may be
>>> actually be fine).
>>>
>>> HTH!
>>>
>>>
>>>
>>>
>>>
>