Hear, hear and well said! On 7/19/18 11:53 AM, Ted Mielczarek wrote: > On Wed, Jul 18, 2018, at 12:45 PM, Botond Ballo wrote: >> Hi everyone, >> >> With the proposal for a standard 2D graphics library now on ice [1], >> members of the C++ standards committee have been investigating >> alternative ways of giving C++ programmers a standard way to write >> graphical and interactive applications, in a way that leverages >> existing standards and imposes a lower workload on the committee. >> >> A recent proposal along these lines is for a standard embedding >> facility called "web_view", inspired by existing embedding APIs like >> Android's WebView: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html >> >> As we have some experience in the embedding space here at Mozilla, I >> was wondering if anyone had feedback on this embedding library >> proposal. This is an early-stage proposal, so high-level feedback on >> the design and overall approach is likely to be welcome. > > I've joked about this a bit, but in seriousness: an API for web embedding is > a difficult thing to get right. We don't even have one currently for desktop > Firefox. The proposal references things like various WebKit bindings, but > glosses over the fact that Apple revamped WebKit APIs as WebKit2 to better > handle process separation. For all the buzz about WebKit being a popular web > embedding, most people seem to have switched to embedding Chromium in some > form these days, and even there the most popular projects are Chromium > Embedded Framework and Electron, neither of which is actually maintained by > Google and both of which have gone through significant API churn. That is all > to say that I don't have confidence that the C++ standards committee (or > maybe anyone, really) has the ability to spec a useful API for web embedding > that can both encompass the broad set of issues involved and also remain > useful over time as rendering engines evolve. > > I understand the committee's point of view--the C++ standard library does not > provide any facilities for writing applications that do more than console > input and output. I would submit that this is OK, because UI programming in > any form is a complicated topic and it's unlikely that the standard could > include anything that would actually be useful to most people. > > Honestly I think at this point growth of the C++ standard library is an > anti-feature. The committee should figure out how to get modules specified > (which I understand is a difficult thing, I'm not trying to minimize the work > there) so that tooling can be built to provide a first-class module ecosystem > for C++ like Rust and other languages have. The language should provide a > better means for extensibility and code reuse so that the standard library > doesn't have to solve everyone's problems. > > I would make this same argument if someone were to propose a similar API for > inclusion into the Rust standard library--it doesn't belong there, it belongs > on crates.io. > > -Ted > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
