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.

dev-platform mailing list

Reply via email to