- From: Alex Russell <slightlyoff@google.com>
- Date: Wed, 23 Jul 2014 15:50:56 -0400
- 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>
- Message-ID: <CANr5HFWAFHQc-rsiew2rgFh1V+=qg8TuQMZLPdMHYvwVYo-h9A@mail.gmail.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