> With regard to Servo: I’d recommend to request info about the Browser.html > project; it’s something that Paul Rouget bootstrapped, but I haven’t heard > anything about it in a long, long time.
Yeah. We've been busy migrating from Gecko to Servo. Now we have a chance to make decisions without code legacy or compatibility issues, and we will most likely implement an Electron-compatible runtime (Rust + Spidermonkey + Servo). What we really really want to avoid with Browser.html is to end up in the monoculture situation David is talking about. So instead of inventing something new, we will work on and with the existing established opensource projects (Electron and React). On Sun, Feb 28, 2016 at 2:47 PM, David Rajchenbach-Teller <dtel...@mozilla.com> wrote: > Let me second Justin. > > I remember a time, not so very long ago, when Gecko powered 4 or 5 > non-Mozilla browsers, as well as GPS devices, wysiwyg editors [1], the > UX of virus scanners, eBook readers [2], etc, as well as a host of > innovative add-ons. At some point, we started deprecating these use > cases for Gecko, because they were not the Web Platform. > > In terms of our long-term goals, this makes entire sense. We encouraged > developers to move from an open-source yet non-standardized library that > we knew we could not maintain forever (the Mozilla Platform, which for > some reason we sometimes equate with XUL) towards the standardized, > interoperable Web Platform. > > This strategy was based on the assumption that our preferences mattered. > Unfortunately for us, history has shown that the world doesn't care all > that much about what browser vendors want. > > In hindsight, I believe that, by turning Gecko into a monoculture, we > have done to ourselves what we fear will happen to the web if it turns > into a Chromium monoculture. We have gained some development agility, > but we have lost most of the innovations (and innovators) that were not > already on our roadmap. We have also lost the drive to provide clean > platform-level APIs, and separation of concerns between libraries, and > testing and feedback, all of which can only hurt our codebase. > > Somewhere else in the world, the ease of embedding first WebKit and now > Chromium (not Blink afaict) have considerably increased their > hackerbase. I haven't checked, but I suspect that this is only > beneficial at all levels. Speaking only for myself, if I were to enter > the field today with the same kind of technological needs I had 15 years > ago, I would head towards Chromium without giving it a second thought. I > find it a bit sad that my present self is somehow working against my > past self. > > Now, in Internet time, these choices were made generations ago, and I > suspect that it is too late to change them for Gecko, and that we need > to live with them. It would probably be possible to man and push forward > XULRunner or a variant thereof, but that would most likely be too > expensive, too little, too late. > > Again, hindsight is 20:20. I believe that the choices we made years ago > were wrong. I also suspect that changing the course of Gecko now would > be too expensive, too little, too late. > > On the other hand, I believe that we should draw lessons from the past, > for our younger projects: Rust, Servo, Connected Devices, ... > > CD are too young to be able to judge, but Rust and Servo have proved > very open to innovation so far, which is great. Thanks to this, both > have a chance of becoming the tool of choice in domains in which Mozilla > doesn't dabble. Again, the benefits to the projects would be immeasurable. > > Anyway, this starts to sound like a blog post (and hopefully not too > much like a rant), so I guess you'll see a refined version of this > message on Planet Mozilla one of these days. > > Cheers, > David > > [1] Yes, Glazou, I know that you're still active with Bluegriffon :) > [2] That was how I got started with Gecko, incidentally. > > On 28/02/16 06:26, Justin D'Arcangelo wrote: >> The question "what do I think we should do for the web of tomorrow?” is >> certainly important for us to ask. However, one of the reasons that so >> many have been interested in an “embedded Gecko” solution like >> Electron/NW.js/whatever is so that we *can* begin experimenting with new >> things that may be a part of “the web of tomorrow”. It is simply not >> efficient or practical for many of us to spend a significant amount of >> time prototyping experimental features *directly* within Gecko. >> Especially when, if you look to other solutions like Electron or NW.js, >> the same thing can be achieved in a fraction of the time. If there is no >> easy way to reuse Gecko outside of Firefox proper, then it is not as >> much of a platform as it is a part of a product. Before I get criticized >> for that last sentence, I should clarify that yes, Firefox *is* a >> platform in the way that the web and all browsers are a platform. >> However, if Gecko cannot trivially exist in a different context outside >> of Firefox, then *Gecko* itself is not a platform. >> >> The fact that WebKit/Chromium is embedded in a variety of different >> applications that are not web browsers means that it is also perceived >> by many as a platform in and of itself. However, this does not mean that >> these applications do not make use of or benefit the web. With Electron >> or NW.js, a developer can build cross-platform native applications using >> web technologies that integrate deeply with various OSes. >> Hypothetically, in cases where several Electron apps might use a >> specific NPM package for some sort of OS integration that is not >> available to ordinary web content, this may highlight gaps in the web >> platform that we should probably fill. >> >>> I wouldn’t feel any shame to use Electron for my next desktop app or >>> prototype thing. You can’t really build a browser with it (please, >>> spare me the Brave bravado, it’s saddeningly mediocre), but any other >>> thing would probably be fine. >> >> I believe many of us *will* start doing this since there doesn’t seem to >> be another option. However, I feel that it will reflect poorly on us if >> we start prototyping our ideas with a web platform implementation that >> we do not control. >> > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
