←back to thread

133 points avan1 | 1 comments | | HN request time: 0s | source
Show context
osigurdson ◴[] No.45078470[source]
Sometimes I think we should go back to basics: pixels, data, latency / bandwidth. The web is an optimization problem in the sense that we want to render correct pixels at perceptual speed given latency and bandwidth constraints.

It should be more like: what pixels is the user about to see? What data is need to set the the pixels? What data is likely needed next and optimistically pre-fetch - something like that.

replies(3): >>45078683 #>>45078991 #>>45080169 #
timschmidt ◴[] No.45078991[source]
In https://github.com/timschmidt/alumina-ui I've been building for WASM using the egui toolkit which just accepts an HTML canvas the size of the browser and starts shouting WebGL at it.

I get to forget about HTML and Javascript, CSS, most of the complication of the browser and web, and just write an application in my favorite language which will run fast and deliver GL accelerated graphics to it's users.

I am really happy with WASM / WebGL for being abstractions which allows for this.

replies(2): >>45079828 #>>45079872 #
sneak ◴[] No.45079828[source]
I was wondering how long it would take for the web to get to this point. It seemed inevitable once canvas became a thing. You don’t even technically need gl or wasm to rewrite an entire rendering engine in js that can just blast pixels at the full-size canvas.

Cool that you’re creating an actual desktop-style gl app with it.

replies(1): >>45079909 #
timschmidt ◴[] No.45079909[source]
I'm looking forward to the day when Javascript can be just another WASM polyfill loaded with the page with a well-defined, portable, and fast API to the DOM. Also can't wait for WebGPU to be adopted in more places. Right now I rely on WebGL2 because WebGPU isn't available in Firefox/Linux stable by default.

Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to fix up the native build to make use of that sort of analysis, which I'd like, because I serve the whole application from microcontroller flash where I only have 4 - 16mb to hold application and firmware, including the http server and network stack.

replies(1): >>45079951 #
sneak ◴[] No.45079951[source]
I don't. I don't want the web to become just a runtime for opaque binary applications. Right now we still maintain some semblance of user control over the DOM and the application; when everything is WASM and WebGPU using its own custom renderer, the ability of people to casually inspect, modify, hack, tinker, and tweak will be completely over.

I learned how to build for the web by looking at webpages and seeing how they worked. What you're describing is the switch from circuit boards of discrete components to everything in a single microscopic IC under a blob of epoxy.

replies(2): >>45080049 #>>45080100 #
1. osigurdson ◴[] No.45080049{3}[source]
If you look at a typical next.js type app with all of the build steps, minification, post-css, tree-shaking, client side / server side, etc., it isn't exactly optimized for reverse engineering. Maybe that ship has already sailed.