Re: Food for thought (resurfacing)

a rendering engine, a JS VM and a UX shell walk into a bar .... (todo:
funny scenario)

since I'm a JS guy the Exo-Browser project looks more manageable as a
learning medium and to help me play with ideas such as "special purpose
browsers" ... and leaving the ABI fun to multi-platform C++ folks ...

"The ExoBrowser exposes its API (parts of the Chromium Content API + a
Simple View Model) in Javascript and enables the implementation of a fully
functional browser entirely out of it (as a Javascript/HTML/CSS app). The
ExoBrowser is a scriptable platform designed to ease the experimentation
with new concepts for the Web Browser."

[Chromium Architecture]

  (Platform)        #   (Browser Implementation)
+----------------+  #  +-----------------------+
|  Content API   +-----+     Chrome (C++)      |
+----+-----------+  #  +-----------------------+
     |              #     |       |        |
+----+---+  +----+  #  +-----+ +-----+ +-------+
| Webkit +--+ v8 |  #  | GTK | | Win | | Cocoa |
+--------+  +----+  #  +-----+ +-----+ +-------+

`vs.`

[ExoBrowser Architecture]

             (Platform)                  #   (Browser Implementation)
                                         #
                   +------------------+  #
                   |  Cocoa/Win/GTK+  |  #
                   +---------+--------+  #
                             |           #
+----------------+ +---------+--------+  #  +-----------------------+
|  Content API   +-+ ExoBrowser (C++) |  #  |  Web Views (HTML/JS)  |
+----+-----------+ +--------------+---+  #  +-----------------------+
     |                   (JS API) |      #             | (TCP)
+----+---+  +----+ +--------------|---+  #  +-----------------------+
| Webkit +--+ v8 +-+    NodeJS    +---+-----+   Local Server (JS)   |
+--------+  +----+ +------------------+  #  +-----------------------+

https://github.com/breach/exo_browser





On Tue, Jul 22, 2014 at 8:30 AM, Alex Russell <slightlyoff@google.com>
wrote:

> On Fri, Jul 11, 2014 at 7: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.
>>
>
> That's incorrect. We did do this with Chrome Frame, although admittedly it
> was us at Google making IE's engine pluggable ;-)
>
>  It was absolutely worth the (high) cost to do, but the window of
> opportunity. Auto-update and real competition deliver the same sort of
> forward progress we'd hoped that Chrome Frame would enable.
>
>
>>  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.
>>
>
> The deep differences in embedding strategy is perhaps the largest
> difference between Blink and WebKit. Blink is "batteries-included", WebKit
> is "BYO". And implementing an API is a WORLD different to ABI stability
> which is what MSFT has done with Windows (to their enduring credit and
> thanks to COM) and which no other browser I'm aware of does this. There's
> some attempt at ABI stability with plugins, but even that is fraught.
>
> You MIGHT get some distance down this path with something like Mojo, but
> you'll want NaCL or some other sandboxing system to enable it and there
> isn't agreement among vendors about any of the details of what or how to
> enable this: http://www.chromium.org/developers/design-documents/mojo
>
>
>> 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 :)
>>
>>
>>
>>
>>
>>
>>
>