Re: Food for thought (resurfacing)

Not an economist,

but "Monopoly" to me means the market is dominated by 2-3 players

and "Market" to me means some place for goods and services

It's a casual interpretation ... the idea is that Nidium and other such
browsers, if they were accessible as plugins in major browsers, would be
selected by many developers and would have a bigger share than if they were
offered directly as a competing alternative to the major browsers... Just
like the Flash strategy in the past. So many developers opted to use Flash
instead of HTML/JS/CSS and so if engines of browsers like Nidium were
available as plugins for major browsers, assuming that's possible with NaCL
or whatever standard, then more developers will choose them and users will
have more choice in terms of their web app experience








On Mon, Jul 28, 2014 at 11:55 AM, Alex Russell <slightlyoff@google.com>
wrote:

> 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!
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>