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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
