4 ms·

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

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.

singinwhale 1y ago
Thinking about user seeing pixels is seeing just a part of the picture. As all software projects you don't optimize just for immediate user experience but also development time. Time to first draw rarely coincides with development time.
- redwall_hp 1y ago
  And I don't care about pixels; I want to see structured documents. How I choose to view those is my business.
  - osigurdson 1y ago
    Got it, you don't care about how the sausage is made. That's totally fine.
    - networked 1y ago
      It doesn't sound like this is what redwall_hp meant; it sounds like what they meant was that pixels are the wrong level of abstraction. If so, I agree: the web is about marked-up text. When you break it down to the very basics, what you get is a teletype, not raster.
      - osigurdson 1y ago
        I'd say that is more like a terminal than a browser. Regardless, what I really mean is some data is needed for the pixels (or whatever abstraction you want above that). You don't need data for anything other than the current viewport and whatever is likely needed next. No less, no more. No over or under fetching. This would be much better imo.
- osigurdson 1y ago
  Dealing with over-fetch / under-fetch most certainly does chew up development time. Creating endless api endpoints that are only used by the web UI is also very time consuming (the industry is finally recognizing how dumb this is and moving back to older SSR approaches). How about, "the user is allowed to access this information on the server - system you figure out what / when to fetch portions of this information for viewing"?
timschmidt 1y ago
In https://github.com/timschmidt/alumina-ui 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.
- sneak 1y ago
  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.
  - timschmidt 1y ago
    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.
    - sneak 1y ago
      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.
deleted 1y ago
[deleted]

singinwhale 1y ago

Thinking about user seeing pixels is seeing just a part of the picture. As all software projects you don't optimize just for immediate user experience but also development time. Time to first draw rarely coincides with development time.

redwall_hp 1y ago
And I don't care about pixels; I want to see structured documents. How I choose to view those is my business.
- osigurdson 1y ago
  Got it, you don't care about how the sausage is made. That's totally fine.
  - networked 1y ago
    It doesn't sound like this is what redwall_hp meant; it sounds like what they meant was that pixels are the wrong level of abstraction. If so, I agree: the web is about marked-up text. When you break it down to the very basics, what you get is a teletype, not raster.
    - osigurdson 1y ago
      I'd say that is more like a terminal than a browser. Regardless, what I really mean is some data is needed for the pixels (or whatever abstraction you want above that). You don't need data for anything other than the current viewport and whatever is likely needed next. No less, no more. No over or under fetching. This would be much better imo.
osigurdson 1y ago
Dealing with over-fetch / under-fetch most certainly does chew up development time. Creating endless api endpoints that are only used by the web UI is also very time consuming (the industry is finally recognizing how dumb this is and moving back to older SSR approaches). How about, "the user is allowed to access this information on the server - system you figure out what / when to fetch portions of this information for viewing"?

timschmidt 1y ago

In https://github.com/timschmidt/alumina-ui 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.

sneak 1y ago
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.
- timschmidt 1y ago
  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.
  - sneak 1y ago
    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.

deleted 1y ago

[deleted]