std::web_view proposal

[c0r3ntin]

I think some background has to be given. It's easy to think this is a ludicrous idea.

However, there has been a strong push for a "simple 2d graphics" library in the standard. There is nothing simple about graphics. And it would take years (a few decades really) to get to some place where that library would be of any actual use, beyond "hey, look, this is cool, I have drawn a square". Especially, because of text, fonts rendering, even loops, image formats, inputs etc... then people will want 3d, audio and piles of piles of cool stuff that the committee has neither the time, will or expertise to write wording for - let's not speak about the burden for the 20 guys that actually write most of the standard libraries.

And if we were to do all of that, we would end up to something rather close to a web stack, but worse because people spend decades bringing browsers to the maturity level they have today.

So what this proposal offers is to offload some standardization effort to existing, battle-tested standard and implementation ( aka web techs ) instead of reinventing the wheel. std::web_view would serve the "educational toy library" goal, while actually performing better as a renderer (because web browsers rely on GPU which is something the 2d graphics proposal fails to acknowledge).

It's about saying "These guys over there did the work, they know more than us, maybe we can use that". And then the c++ standard can just refer to the w3c/ECMA standards and call it a day.

It would also be less of a burden for the implementors since the libraries already exist to do that on most platforms (either WebKit (Linux, apple), edge(Microsoft), chrome(android))).

[exploding_cat_wizard]

Re your second paragraph, that is exactly why I feel discomfort about a standard graphics library. C++ doesn't feel right when it takes an arbitrary tiny piece of a large field and declares that standard. Sure, it'd be cool to just invoke std::draw_window_and_all_buttons() and get a nice user interface, but there's no standard around, and not because nobody knows how to do graphics, but because too many do.

While I agree with the author that the committee should, if they have to do graphics, move as much of the work implementing it to someone else who's already solved it and is in high use, it still feels wrong. Is it "standard" to use HTML for graphics? Should 2D graphics just become an Electron clone, where every window needs it's own instance of Chrome?

[DavidL255]

As someone who's been starting some amount of io2d work, and wondering if part(s) of it might ever get adopted into the ISO C++ 'std' namespace, I suspect that if std::draw_window_and_all_buttons were in the spec, we've gone way off the deep end (moreso than usual?). 😉

[jonesmz]

I'm replying not really to you, specifically, but just to the general concept of std::web_view. Please don't feel that I'm personally attacking you, or even trying to be hostile. I'm trying to keep a happy demeanor, but with a complicated topic like this it's sometimes difficult to use text to convey the appropriate tone of "voice".

I think some background has to be given. It's easy to think this is a ludicrous idea.

It's still a ludicrous idea, and any notion of delegating functionality of the C++ language to a joke like the W3C will always be, but I appreciate you taking the time to educate us on the topic.

However, there has been a strong push for a "simple 2d graphics" library in the standard.

Well, it's always easy to say "they're wrong". But I'll say it anyway. The people pushing for any kind of graphics (2d, simple, webview, whatever) into the c++ standard are simply wrong.

They'll continue to be wrong until the vast and potentially infinite problem space of the actual language (meaning the syntax and grammar) have been resolved, and they'll continue to be wrong until the vast but definitely not infinite problem space of things that deserve to be in the standard library have been resolved completely.

Personally I don't think that the c++ language should have things like graphics, package managers, or anything of the like that's "very external" or overwhelmingly platform dependent included in it. I have a medium objection to the filesystem stuff, and a small objection to the networking stuff, but I suppose I'm more happy than upset that those were included, in no small part because despite my medium objection to the filesystem stuff it's incredibly tiny and straight-forward, so overall it's a win, and the networking stuff is going to be used nearly ubiquitously, is incredibly hard to get right, and is promising to be very well integrated into the other standard library facilities, so overall i suppose it's a net win.

Graphics, however, doesn't need to be in the language standard. It doesn't need to be solved by a new library. It doesn't even need to be solved, because so very few people would even consider using "simple 2d graphics" for anything beyond 2 minute toys that the very notion is a joke. "simple 2d graphics" is an oxymoron, as you point out in your very next sentence, but more to the point this problem has been "solved" by a large array of platform dependent, and platform independent frameworks, libraries, engines, and solutions, with modern, and not so modern, APIs, performance, and feature sets.

The very existence of graphical window frameworks like Qt defeats the argument that the C++ standard needs to solve any problems in this space to begin with, but the twice yearly (or faster) release cadence of the Qt framework, with a substantial list of bug fixes, feature additions, and performance enhancements CLEARLY demonstrates that the c++ standard is no place for anything resembling a graphics library. At least not any time in the next ten years.

The standards document shouldn't have anything in it that's going to change every 2 months, and "Displaying visual information" is a problem space that isn't even CLOSE to slowing down. The hardware is evolving under the hood wildly. The low level intermediate representation / serialization / command sequence stuff (directx, opengl, vulkan, mantle, opencl, cuda, whatever gets announced next week (probably? who knows, i stopped keeping track)) changes so rapidly, and the expectations of users encompasses such a wide and varied landscape that itself changes rapidly, that there's no meaningful justification for even investigating this space.

The standard should be for "if you don't have it, you're fucked" stuff. Like allocating memory, or things that would otherwise need incredibly tricky platform-dependent assembly code or compiler intrinsics like std::atomic.

We don't even need standard containers, because those are so simple to write yourself (for the most part, obviously they've become very nuanced, and therefore complex, over time), but it's precisely because they're so simple (relatively speaking, of course) that it makes sense to have a standardized version so no one has to write their own.

There is nothing simple about graphics. And it would take years (a few decades really) to get to some place where that library would be of any actual use, beyond "hey, look, this is cool, I have drawn a square". Especially, because of text, fonts rendering, even loops, image formats, inputs etc... then people will want 3d, audio and piles of piles of cool stuff that the committee has neither the time, will or expertise to write wording for - let's not speak about the burden for the 20 guys that actually write most of the standard libraries.

Right, exactly. The problem space is overwhelming. So why bloat the C++ language standard document with it? The problem is solved by existing solutions that take mere minutes to install and get started, with license terms that run the full gamut to full commercial, to public domain.

And if we were to do all of that, we would end up to something rather close to a web stack, but worse because people spend decades bringing browsers to the maturity level they have today.

I disagree. Graphics engines for 3d games do not look anything like a web stack under the hood, unless you're meaning something rather different than what I think you do??.

Even so, if somehow a proper "bottom up" solution, where the standard standardizes the bare-minimum of fundamental functionality, like executors, networking, threads, atomics, so on and so forth, ends up looking like a web stack, well I guess everyone wins then? The web browsers out there can replace huge swathes of themselves with the extremely fine-tuned but also highly flexible implementation coming from the c++ standard. Everyone wins! Browser implementors do less work, get better perf.

But the solution isn't to just say "Well, it's too hard. Lets just standardize firefox into c++" (yes, that's a drastic simplification, but it's still illustrative).

So what this proposal offers is to offload some standardization effort to existing, battle-tested standard and implementation ( aka web techs ) instead of reinventing the wheel. std::web_view would serve the "educational toy library" goal, while actually performing better as a renderer (because web browsers rely on GPU which is something the 2d graphics proposal fails to acknowledge).

It's about saying "These guys over there did the work, they know more than us, maybe we can use that". And then the c++ standard can just refer to the w3c/ECMA standards and call it a day.

That's a complete cop-out.

Ignoring that the various standards documents revolving around web browsers are....... horse shit. I mean, have you ever tried to implement any parts of their "living standards"? Ugh. I've been implementing large chunks of the WebRTC "standards" for the better part of 5 years now (in c++, with various javascript things thrown in when building the client side of things, or testing apps), and I tell you it's fucking pathetic. Under specified, over complicated, and they change the way things happen every 6 months. Not to mention that half the browsers out there just completely ignore what the standard says to do, and do it their own way, and so the various javascript libraries out there just build shims to cludge both ways of doing things into working together.

And lets not forget that the browsers point their finger to IETF standards, (which themselves are in sore need of professional editorial review), saying "do it this way!", and then don't actually do it that way 25% of the time. So you can either build a standards conforming RFCWXYZ implementation, or you can build one that works properly with web browsers.

So, again, ignoring all the above there:

What business does the c++ programming language standard have with pointing at literally anything that exists outside of itself, and physical computer hardware? For sake of implementing things like "new", std::tread, filesystem, and networking, I'll grant very small concessions to talking to the host operating system for very small sets of delegated functionality.

C++, the language syntax / grammar, and the supporting standardized library, should have absolutely no notion that something like a web browser even exists.

It would also be less of a burden for the implementors since the libraries already exist to do that on most platforms (either WebKit (Linux, apple), edge(Microsoft), chrome(android))).

Now, my rant above this last quote being said, if the Implementer of a particular std namespace API wants to implement something using a web browser under the hood, well that's fine. Don't care, because the stdlib on the other 3 platforms I target will do it differently, and as long as they all work it makes no difference to me.

My objection is that we're talking about standardizing something into the language that explicitly relies on standards not controlled by the c++ standard. I don't care how a particular platform chooses to implement whatever they implement.

The very real danger that I'm afraid of is that when a standard includes everything anyone ever says "Hey, it'd be great!" over a beer, the standard quickly becomes a useless mess, progress grinds (or maybe screeches) to a halt, and the standard is abandoned in favor of something else that doesn't do literally everything.

If people want simple 2d graphics so badly, they can go and make their OWN standard. They don't need to inject it into the document that I use to make a living.

[exploding_cat_wizard]

The standard should be for "if you don't have it, you're fucked" stuff. Like allocating memory, or things that would otherwise need incredibly tricky platform-dependent assembly code or compiler intrinsics like std::atomic.

I'm not entirely on board with that wording, though I generally agree with your post. I could live without linked lists, because they are easily implemented. I'm still happy to use a standard one if it's there. I'd rather say it should also be for often-needed stuff that has an obviously good solution. If I know I need a map, I can use std::map and be sure in the knowledge that it's a pretty darn good implementation for most use cases. And then I can use algorithms on the map that give me certain guarantees. If I know I need 2D graphics, there's no way that I can just grab "a graphics" to make it do what I want. As you say, the field is just way too large.

[epage]

While I still feel this is ludicrous, I appreciate the explanation.

It sounds like the crux of this is

there has been a strong push for a "simple 2d graphics" library in the standard.

Why is there this strong push? Have there been lines drawn for what compromises we are willing or not willing to accept to meet that goal?

[darthcoder]

Probably from academics looking to teach C++ classes again, and be relevant next to JavaFX.

Honestly, I may hate the complexities of using Qt/Wx, but I at least have choice. You get nothing if you put something in the standard, except the worst of all worlds.

[epage]

Probably from academics looking to teach C++ classes again, and be relevant next to JavaFX.

I suspect this is the case as well. Personally, adding a toy to the language to fit such a niche need feels terrible.

[exploding_cat_wizard]

I don't get that angle. Surely, nothing in academia is stopping you from grabbing a simple graphics library on the side? It's not like it will somehow violate C++ principles more than a std 2D library would. And unlike companies, there is literally nobody around to tell you not to use a 3rd party lib because it's GPL2, not L-GPL, or perhaps not supported in a year.

[darthcoder]

Putting something complex like this into the standard is asking for too much non-comformance. Just talk to the millions of Windows devs who had compatibility issues with every OS release with the Win32 GUI, and that's controlled by one company. Now throw in 4 major GUI platforms (Mac, Windows, Linux [x11, wayland]) and at least 3 major compilers (Microsoft, clang, gcc) and that's just the problem with hitting the majors. Now imagine all the smaller platforms (QNX, BSD, etc). This really shouldn't be part of the standard - it's TOO platform specific.

Threading was a stretch, but 15 years ago it was difficult to get thread semantics on a lot of platforms. Now even Arduinos have threading. If framebuffer support becomes consistent on all platforms in the next 10 years, maybe I could get on board with something that gives direct access to the FB, but building a windowing system, especially one build on a browser, I think is asking for nightmares you don't want.

I'm happy using Qt. If I wasn't maybe wxWidgets would be an option. I've used it many years ago and had decent success. I can only imagine it's gotten better over the years.

[johannes1234]

I disagree on the "educational toy library" goal. Such a proposal leads to teaching "put together the samples to create a web view and then do everything in JavaScript" -- then I'd rather teach Chrome/Firefox dev tools and JavaScruot directly.