The comment you replied to was: "The only good products Google has ever built in-house are [...]"
I don't have enough information to judge how much of Chrome was original work and how much was pre-existing work. Though I guess by now, after nearly 20 years, Chrome's codebase looks absolutely nothing like KHTML.
To me your description is mythical reddit. Actual Reddit is every bit as hostile as stack overflow and unlike stack overflow, old questions can not be updated with new answers when existing answers get out of date.
Mixed on this. I rarely use a printer. Once or twice a year to print a sign or some government form required to be paper. Maybe you shouldn't encourage printing?
That said, I've gone out of my way to make my sites printable so ...shrug...
The thing that makes it "hard" is that it's all indirect. You compile a program for the GPU (a shader). Then you have to setup data (textures and buffers) for it. Then, you need to spend a bunch of time telling the GPU how to use that data, offsets where each piece of data is, what formats the data is in,, how to advance to the next piece of data, etc.. etc..
There are a few libraries that try to abstract over all this indirection but all the graphics APIs themselves are lower-level so you're left to do all of that yourself.
Personally I wouldn't teach OpenGL ES 3.0 or any OpenGL because its state machine (https://webgl2fundamentals.org/webgl/lessons/resources/webgl...) and horrible error system means tracking down bugs is hard. Instead I'd teach WebGPU as it's portable and has great error messaging.
I'm sure people will objected but I'd argue WebGPU is easier to understand, has better errors, has no state machine, works C++, Rust, JS/TS and other languages, and closer to modern GPU programming if you want to move to Metal or D3D12 or Vulkan later.
Further, OpenGL (and ES) are a nightmare of bugs and incompatibilities students might run into that WebGPU fixes.
That said, the article mentions Apple platforms where you can use ANGLE if you happened to have students stuck there.
I mostly agree regarding GL's programming model, but tbf some problems have been fixed by WebGL2 (much better validation and error reporting - e.g. very helpful error messages right on the browser console - and it's probably the least buggy and most portable 3D API implementation of them all, including the current state of WebGPU.
For teaching I would generally use the web browser via WebGL2 or WebGPU, just because those APIs require much less boilerplate in the browser environment to get to your first triangle and the edit-test-loop is pretty much instant.
In real life there’s lots of bugs around and difficult to read error messages.
Re. the boilerplate just have students clone a pre-fabbed repo with the boilerplate handled for them.
The real question should be whether you want students to know how to program in a low programming language or not. Whether they should see what the reality of programming is or not.
If they can’t program in C/C++ and debug the error messages how are they going to survive in the wild? I guess they’ll use an LLM.
> If they can’t program in C/C++ and debug the error messages how are they going to survive in the wild?
The problem is that you don't get *any* error messages from native GL in the first place (unless you wire up a debug-message callback via the optional KHR_debug extension which isn't available everywhere), and the builtin error system via glGetError() is pretty much completely useless.
Other APIs don't suffer from this problem, D3D, Vulkan and Metal all have excellent validation layers which give very helpful messages, and WebGL or WebGPU running in browsers basically implement such a validation layer out of the box.
small nit, that's not true, since GL4.3 the modern debug message callback is core so you can rely on it. Sure that won't save you on MacOS but if you can target modern OpenGL this isn't a problem in practice
WebGPU will however always suffer from being an API designed for the Web, and targeting 2015 thereabouts hardware.
Better than OpenGL, but don't expect that much improvements coming into their way, other than what the Chrome team might feel like pushing, as I doubt Firefox or Safari teams have much left to say about where it goes beyond version 1.0.
The rigid resource binding model via BindGroup objects in WebGPU is already outdated (and funny enough, an area where WebGPU is actually slower than WebGL2, at least when assuming that bindings need to change frequently and unpredictably).
This was a restriction of the Vulkan 1.0 API and modelling the WebGPU resource binding model around that was a quite predictable problem. It would have been better to come up with a slim abstraction that might cost some performance on Vulkan (which is only really relevant on Android phones and Linux desktops), but at least would not slow down WebGPU across all platforms.
And now even the Vulkan maintainers have realized the problem and are introducing the much more flexible descriptor-heap extension (about a decade late, but better late than never).
WebGPU is essentially the frozen cross-section of 3D APIs from about a decade ago, and the state of GPU hardware from about 15 to 20 years ago (but tbf, apart from the broken binding model there wasn't much that could be done, because most restrictions are coming from mobile GPUs which a browser 3D API simply must support).
1. monolithic pipelines, pretty much no hardware works like that, the hash-and-cache design makes your design inflexible and adds a ton of overhead
2. WGSL, like come on
3. Hilariously outdated feature set, no mesh shaders, no HWRT, cooperative matrices/tensors, etc.
4. It's security-focused because web untrusted code:tm: so most of the calls are hilariously slow. Yes even the desktop implementations. There's no good webGPU implementation out there
5. it's also not simple to either implement or use. it's basically vulkan's difficulty without any of the advantages....
I have never understood and will never understand why so many programming luminaries fell in love with OpenGL. It violates the most important engineering precept that I try to follow when I design a library: minimize hidden state. OpenGL is nothing but hidden state. You have no way to tell what a piece of code is going to render without seeing everything that set up the internal stack beforehand, perhaps thousands of lines away, or in entirely different modules that you might not even have access to.
The quip is that C++ is fool's gold; Flying around in code and getting all the little mechanical details right really feels like getting things done. (It's just wizard- or mastery-flavored busywork. Glitter.)
I've later come to suspect that this glittering is sometimes useful as… fuel? Feeling-of-progress hands-on motivation-fuel.
I disagree. Webgpu is completely useleless middleware that is already outdated, and it bugs me it killed compute shaders for WebGL proposal. In addition webgpu still does not work on browsers out of box.
Interacting with webgpu from wasm is also often slower than webgl because the api is lower level and causes more gc overhead on js side.
I genuinely can not understand how anyone with basic knowledge of economics could believe that government intervention is not responsible for the majority of rent price increases
The market, left to its own, will keep building because someone will see the prices people are willing to pay and think “I want in on that” but then the government comes in and blocks them from building. No building = supply lower than demand which always equals higher costs
Further, It would only have taken you one 5 second search to see the ways government regulations can cause unoccupied apartments
That’s another bad metric without more nuance. if I used to pay 30% and now pay 50% but the remaining 50% buys 2x what it used to then overall I’m still doing better
I’m not saying that’s the case. I’m only saying the metric “housing cost as percent of wages” isn’t enough to judge if people are doing worse or better
To take just one example: a 65inch tv costs just $700 compared to $4k just a few years ago
reply