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

Attachment: signature.asc
Description: OpenPGP digital signature

dev-platform mailing list

Reply via email to