5 ms·

I completely appreciate what you're saying. Then I look at the level of crazy complexity and backward compatibility in html/css/js/wasm processing. And then I

I completely appreciate what you're saying. Then I look at the level of crazy complexity and backward compatibility in html/css/js/wasm processing. And then I wonder: what are you actually proposing here?

taftster 1y ago
Going back to gopher as a starting point maybe. Let's innovate from there.
- yjftsjthsd-h 1y ago
  That's a thing, in the form of https://en.wikipedia.org/wiki/Gemini_(protocol) https://en.wikipedia.org/wiki/Gemini_(protocol)
photonthug 1y ago
This is going to be unpopular but.. just to illustrate that we didn’t have to be stuck here. Using things like xpra/xephyr to serve a whole x11 gui over web is surprisingly easy and awesome and like 1/100th the complexity of a modern web stack. This might not be cheap to serve, but it’s cheap to build, and it makes you wonder about the intersection and inflection of those cost curves. And of course we haven’t spent decades optimizing for it. Don't get me wrong.. REST APIs, HTTP, HTML5, all wonderful. But as a user, the cost/benefits of ubiquitous JavaScript in depth simply to win interactivity and single page apps at the cost of um, everything wrong with the web (and by extension much of the world economy via surveillance capitalism) are a bit suspect.
fsloth 1y ago
The crazy complexity is stupid. It’s mostly lasagna engineering where the effort is spent to fix the design mistakes in earlier levels. Practically at this point it’s configuring a Skia render context. This gives a known api to target for the graphics stuff. There is near 0 value for designers to pain themselves over this. The design interface should be 85% graphical. The implementation should be a runtime for a configurable context and it should be configurable with code. The ui given to designers should be a graphical tool. There could be many, many such tools! I’m writing this as a graphics engineer who has followed this for over 20 years. I would love to hear engineering based counter arguments to this pov.
postepowanieadm 1y ago
We may need to ask some hard questions like: do browsers really need wasm in the first place?
- AndyKelley 1y ago
  I would ask the question the other way around: do browsers really need JavaScript? It's a lot easier to maintain a WebAssembly engine than a JavaScript engine.
  - hardwaresofton 1y ago
    Really interesting to hear you say that — Thanks for the WASM impl in Zig! On the do-browsers-need-js point, you might be interested in: https://github.com/wasi-gfx/webidl2wit https://github.com/wasi-gfx/webidl2wit
- melodyogonna 1y ago
  WASM came about as a result of demand, not because people had too much free time. Browsers were being used for more complex things, which resulted in companies adopting hacky solutions to enable more performance. WASM is seeking to develop a consistent standard for these use cases.
- nasso_dev 1y ago
  iirc WASM bytecode closely resembles V8 IR. If you're writing a JS engine, might as well provide a more direct frontend to it... I don't think it adds much.
JumpCrisscross 1y ago
> the level of crazy complexity and backward compatibility in html/css/js/wasm processing Most people don't need insane levels of backwards compatibility or intense PWA support. That's just cruft that slows everything down and increases the attack surface for, to the user, no real gain. Perhaps what we need is a lot of lightweight general-use browsers (based on a small number of engines) and then some heavyweight power-user browsers that can WASM to their hearts' content.
- sebmellen 1y ago
  We use WASM in web apps that are used by a very large number of “regular” consumers. It would be stupid to kill that off.
  - JumpCrisscross 1y ago
    > We use WASM in web apps that are used by a very large number of “regular” consumers. It would be stupid to kill that off. Large numbers of users use lots of features. That doesn't change that most of them use none of them. WASM would continue to exist. It just doesn't need to be in every browser.
  - sitkack 1y ago
    Who said we have to kill off Wasm, Wasm (minus SIMD) is extremely simple and allows the user (the webdev) to ship the complexity, and not build the complexity into the browser itself.
- akdor1154 1y ago
  > Most people don't need No, what you mean is 'most greenfield web dev projects don't need...'. Most people do need those things, because assuming there's no civilisation spanning project to literally rewrite 90% of the web, without them their sites would break.
  - JumpCrisscross 1y ago
    > Most people do need those things, because assuming there's no civilisation spanning project to literally rewrite 90% of the web, without them their sites would break Sites most people visit do not require backwards compatiblity. And aside from like Google Docs, I doubt most folk are doing anything with WASM (outside plugins). Look, in a world where Google subsidises browser development, this isn't an issue. We don't need to compromise. But if that funding stream disappears, you do have to compromise. And I'd argue a simple browser doing away with some of the more-complicated stuff would be (a) maintainable and (b) popular enough to pay itself back.
jeroenhd 1y ago
I'm assuming people with such a hatred for browser complexity absolutely love the way those Delphi programs worked back before Web 2.0 made browsers a viable GUI platform, because that's the direction we're going in if browser start dying. Browsers have become the de-facto way to work for most people, and it's a major why Microsoft has been losing market share. People say HTML/CSS/JS/WASM is complex, but the Ladybird team is proving that a very small team can make a working browser in a few years. Thanks to the efforts of dedicated developers behind browsers, most of the web API, including rendering algorithms and such, has been painstakingly written out in detail.
TacticalCoder 1y ago
[dead]
sitkack 1y ago
I never advocated for removing Wasm, Wasm itself allows the webdev to subsume complexity that would normally be built into the browser. Browser complexity is made more tractable by Wasm, not less. Maybe remove JS now that Wasm exists.

taftster 1y ago

Going back to gopher as a starting point maybe. Let's innovate from there.

yjftsjthsd-h 1y ago
That's a thing, in the form of https://en.wikipedia.org/wiki/Gemini_(protocol) https://en.wikipedia.org/wiki/Gemini_(protocol)

photonthug 1y ago

This is going to be unpopular but.. just to illustrate that we didn’t have to be stuck here. Using things like xpra/xephyr to serve a whole x11 gui over web is surprisingly easy and awesome and like 1/100th the complexity of a modern web stack. This might not be cheap to serve, but it’s cheap to build, and it makes you wonder about the intersection and inflection of those cost curves. And of course we haven’t spent decades optimizing for it. Don't get me wrong.. REST APIs, HTTP, HTML5, all wonderful. But as a user, the cost/benefits of ubiquitous JavaScript in depth simply to win interactivity and single page apps at the cost of um, everything wrong with the web (and by extension much of the world economy via surveillance capitalism) are a bit suspect.

fsloth 1y ago

The crazy complexity is stupid. It’s mostly lasagna engineering where the effort is spent to fix the design mistakes in earlier levels. Practically at this point it’s configuring a Skia render context. This gives a known api to target for the graphics stuff. There is near 0 value for designers to pain themselves over this. The design interface should be 85% graphical. The implementation should be a runtime for a configurable context and it should be configurable with code. The ui given to designers should be a graphical tool. There could be many, many such tools! I’m writing this as a graphics engineer who has followed this for over 20 years. I would love to hear engineering based counter arguments to this pov.

postepowanieadm 1y ago

We may need to ask some hard questions like: do browsers really need wasm in the first place?

AndyKelley 1y ago
I would ask the question the other way around: do browsers really need JavaScript? It's a lot easier to maintain a WebAssembly engine than a JavaScript engine.
- hardwaresofton 1y ago
  Really interesting to hear you say that — Thanks for the WASM impl in Zig! On the do-browsers-need-js point, you might be interested in: https://github.com/wasi-gfx/webidl2wit https://github.com/wasi-gfx/webidl2wit
melodyogonna 1y ago
WASM came about as a result of demand, not because people had too much free time. Browsers were being used for more complex things, which resulted in companies adopting hacky solutions to enable more performance. WASM is seeking to develop a consistent standard for these use cases.
nasso_dev 1y ago
iirc WASM bytecode closely resembles V8 IR. If you're writing a JS engine, might as well provide a more direct frontend to it... I don't think it adds much.

JumpCrisscross 1y ago

> the level of crazy complexity and backward compatibility in html/css/js/wasm processing Most people don't need insane levels of backwards compatibility or intense PWA support. That's just cruft that slows everything down and increases the attack surface for, to the user, no real gain. Perhaps what we need is a lot of lightweight general-use browsers (based on a small number of engines) and then some heavyweight power-user browsers that can WASM to their hearts' content.

sebmellen 1y ago
We use WASM in web apps that are used by a very large number of “regular” consumers. It would be stupid to kill that off.
- JumpCrisscross 1y ago
  > We use WASM in web apps that are used by a very large number of “regular” consumers. It would be stupid to kill that off. Large numbers of users use lots of features. That doesn't change that most of them use none of them. WASM would continue to exist. It just doesn't need to be in every browser.
- sitkack 1y ago
  Who said we have to kill off Wasm, Wasm (minus SIMD) is extremely simple and allows the user (the webdev) to ship the complexity, and not build the complexity into the browser itself.
akdor1154 1y ago
> Most people don't need No, what you mean is 'most greenfield web dev projects don't need...'. Most people do need those things, because assuming there's no civilisation spanning project to literally rewrite 90% of the web, without them their sites would break.
- JumpCrisscross 1y ago
  > Most people do need those things, because assuming there's no civilisation spanning project to literally rewrite 90% of the web, without them their sites would break Sites most people visit do not require backwards compatiblity. And aside from like Google Docs, I doubt most folk are doing anything with WASM (outside plugins). Look, in a world where Google subsidises browser development, this isn't an issue. We don't need to compromise. But if that funding stream disappears, you do have to compromise. And I'd argue a simple browser doing away with some of the more-complicated stuff would be (a) maintainable and (b) popular enough to pay itself back.

jeroenhd 1y ago

I'm assuming people with such a hatred for browser complexity absolutely love the way those Delphi programs worked back before Web 2.0 made browsers a viable GUI platform, because that's the direction we're going in if browser start dying. Browsers have become the de-facto way to work for most people, and it's a major why Microsoft has been losing market share. People say HTML/CSS/JS/WASM is complex, but the Ladybird team is proving that a very small team can make a working browser in a few years. Thanks to the efforts of dedicated developers behind browsers, most of the web API, including rendering algorithms and such, has been painstakingly written out in detail.

TacticalCoder 1y ago

[dead]

sitkack 1y ago

I never advocated for removing Wasm, Wasm itself allows the webdev to subsume complexity that would normally be built into the browser. Browser complexity is made more tractable by Wasm, not less. Maybe remove JS now that Wasm exists.