Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM Wayland Web (WWW)

joeyh.name

Post reply on HN
Print view View original

91–100 of 226 posts

Re: WASM Wayland Web (WWW)

#91

Post by JimDabell »

zfg wrote: post #62
JimDabell wrote: post #36

The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. They treated the web browser like it was just a way to run executables in a window. Nothing worked right. Bookmarks, search engines, command-line tools, user preferences for font size, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links……

> The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. WebAssembly is different. WebAssembly brings every language to the web. Flash didn't. WebAssembly can render to canvas and enable applications that compile to desktop, mobile, and the web. UI libraries like Avalonia do this: https://avaloniaui.net/ For example, here's C# implementation of Visual Basic 6 compiled to WebAs…

> WebAssembly is different. WebAssembly brings every language to the web. Flash didn't.

The problem with Flash was not that it only supported a single language. The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into.

> But WebAssembly applications can also manipulate the DOM like JavaScript.

Flash could do that too. Virtually nobody bothered.

Re: WASM Wayland Web (WWW)

#92

Post by Philpax »

zfg wrote: post #62
JimDabell wrote: post #36

The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. They treated the web browser like it was just a way to run executables in a window. Nothing worked right. Bookmarks, search engines, command-line tools, user preferences for font size, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links……

> The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. WebAssembly is different. WebAssembly brings every language to the web. Flash didn't. WebAssembly can render to canvas and enable applications that compile to desktop, mobile, and the web. UI libraries like Avalonia do this: https://avaloniaui.net/ For example, here's C# implementation of Visual Basic 6 compiled to WebAs…

The issue isn't the scripting language, it's having a common interface for users, especially for those who can't use standard browsers. Rendering the application yourself will break every accessibility tool that relies on being able to interact with a programmatic view of the website.

Re: WASM Wayland Web (WWW)

#93

Post by DannyBee »

neuroelectron wrote: post #22
jillesvangurp wrote: post #9

> So there are only 2 web browser engines, and it seems likely there will soon only be 1, and making a whole new web browser from the ground up is effectively impossible because the browsers vendors have weaponized web standards complexity against any newcomers. Maybe eventually someone will succeed and there will be 2 again. Best case. What a situation. The premise of this article seems completely wrong. Chromium, S…

The "weaponization of complexity" is real—modern web standards are an endless labyrinth of APIs, performance optimizations, and security requirements. Large players like Google have the resources to dictate how the web evolves, while any newcomer faces insurmountable hurdles in achieving compatibility, security, and speed. Even major tech companies have tried and failed (e.g., Microsoft ditching EdgeHTML for Chromium…

The "weaponization of complexity" as you call it is simply "work is done by those who show up".

Google, Microsoft, Mozilla, Apple, etc took the horribly dastardly approach of "participating" and then "doing the work".

The horror.

Microsoft gave up because it wasn't worth it when someone else was willing to do the work. It was not something that was adding value to them by them doing it themselves anymore.

It's hilarious to try to pain this as some evil dastardly thing where they badly tried to keep up and just failed because it's just so hard and costly vs something where it just wasn't worth them paying for because they didn't derive enough value from it.

Remind me which earnings call it was where they were saying "you know, we are going to issue rough q4 guidance because we think it's going to be really hard to implement these next 3 CSS features"

The cost of keeping up for them, even now, if they started again, would be a rounding error in any MS VP's overall equity refresh budget (IE the money they are giving out in stock per year to employees in their org). So please, let's not pretend it's too "hard" or "expensive" for them.

In the end, the world is 99% built by those who show up and do it. That's how this "weaponization of complexity" happened - people showed up and tried to solve problems. The world evolved. They tried to keep moving forward as that happened.

If you think you can do it better, or that it doesn't need to be this complex, or whatever, awesome. show up and do it, like everyone else did.

The world has never been built by those throwing rocks from the sidelines, no matter how much they want it to be, and no matter how much they try to paint the hard problem-solving work of others as "weaponization of complexity".

Calling it that is just plain lazy. Almost all improvements and backwards compatibility shims make it harder for someone else to implement from scratch. That's because the primary goal is usually to help users.

I mean, why stop with the web with this argument?

How come the Go folks weaponized the Go language by adding generics? By making it harder for me to implement my own, they've weaponized it against me!

I can't believe nobody has stopped their dastardly deeds.

Re: WASM Wayland Web (WWW)

#94

Post by zfg »

JimDabell wrote: post #91
zfg wrote: post #62

Earlier quoted context omitted.

> The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. WebAssembly is different. WebAssembly brings every language to the web. Flash didn't. WebAssembly can render to canvas and enable applications that compile to desktop, mobile, and the web. UI libraries like Avalonia do this: https://avaloniaui.net/ For example, here's C# implementation of Visual Basic 6 compiled to WebAs…

> WebAssembly is different. WebAssembly brings every language to the web. Flash didn't. The problem with Flash was not that it only supported a single language. The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into. > But WebAssembly applications can also manipulate the DOM like JavaScript. Flash could do that to…

> The problem with Flash is that it opted out of the web architecture

WebAssembly doesn't. WebAssembly is part of the web's architecture. It has been for 8 years. You've doubtless run WebAssembly without even realizing it.

Google Sheets for example uses WebAssembly: https://web.dev/case-studies/google-sheets-wasmgc

Amazon Prime Video uses WebAssembly: https://www.amazon.science/blog/how-prime-video-updates-its-...

> Flash could do that too. Virtually nobody bothered.

But virtually somebody is bothering with WebAssembly.

Re: WASM Wayland Web (WWW)

#95

Post by berkes »

jfoster wrote: post #88
neuroelectron wrote: post #22

Earlier quoted context omitted.

The "weaponization of complexity" is real—modern web standards are an endless labyrinth of APIs, performance optimizations, and security requirements. Large players like Google have the resources to dictate how the web evolves, while any newcomer faces insurmountable hurdles in achieving compatibility, security, and speed. Even major tech companies have tried and failed (e.g., Microsoft ditching EdgeHTML for Chromium…

With the way that AI is unfolding right now, this might be an outdated problem fairly soon. In 2026 if you can just tell your AI to build a new full-featured browser before you go to sleep, you might have something in the morning.

AI might be heading towards a situation where you can "tell it to build a full featured browser".

But this narrative is naive at best, and frankly, getting annoying too. Especially because it gets repeated by people who know even less about "programming" than those who start this idea in the first place.

That AI cannot maintain this browser. It cannot monitor and fix performance issues. It won't be able to refactor stuff when the umpteenth web-api changes or lands. It cannot architecture the modules so that it can actually do this maintainance either.

Generative AI is fantastic at generating stuff. It's terrible at maintaining, changing, tweaking. It's even worse at understanding what you mean with "It must have want a way to disable cookie popups" because that's both ambiguous, and actually the wrong instruction to begin with - for example.

We must stop repeating "AI will be able to program our software for us very soon" because "programming software" is very little about churning out new code. As every programmer with a few years under their belt will know.

What AI is good at, though, is enabling those programmers to be far more effective, efficient. To lower the barrier of entry. etc. But I'm 101% confident that no AI will "write a full-featured browser" that will continue to run for over half a month and/or one OS update.

Re: WASM Wayland Web (WWW)

#96

Post by _bent »

chrismorgan wrote: post #86
brabel wrote: post #71

Earlier quoted context omitted.

They still seem to have something, from this page: https://docs.flutter.dev/ui/accessibility-and-internationali... * Inspect the HTML tree containing the ARIA attributes generated by Flutter. Wouldn't that help with SEO as well?

That gives you a distinct accessibility tree in the DOM, which is kinda dumb as an approach. One of the reasons for going pure-canvas on the web was supposed to be performance (I don’t think it was ever true, though—only if comparing with a bad DOM implementation), and if you have to enable this accessibility DOM, you’re guaranteeing you’re doing double work. And no, on the web you can’t just do it when you need it:…

No, performance and fidelity are definitely better with the canvas renderers, especially skwasm. Flutter is very inspired by React, but instead of React which does tree diffing to minimize rebuilds, Flutter tries to make rebuilds as cheap as possible instead - for example through its single pass layout algorithm. The issue is that this doesn't map well to the DOM. You can't rebuild cheaply on the DOM because you'd be constantly updating the DOM. And you don't profit from your simpler layout, because you have to implement it in JavaScript and use absolute positioning on all DOM Elements to lay them out.

I do agree that this all absolutely sucks for websites, but if you're building an App that is supposed to run in the browser like Rive or Figma, where you're going to override all click handlers anyways, or where where what you're rendering would be too much for the DOM, Flutter Web is pretty ok.

Re: WASM Wayland Web (WWW)

#97

Post by aredox »

kreddor wrote: post #44
aredox wrote: post #12

Earlier quoted context omitted.

What is ladybug's marketshare? Does it work flawlessly with "This webpage works better with Chrome" webpages? It is not even mentioned on https://caniuse.com/?search=web%20components

It's not really meant for end users currently. Your only option is to build from source. But it has made a lot of progress in a relatively short time.

>But it has made a lot of progress in a relatively short time.

That's always the case at the beginning. And then it stalls. That's exactly the gripe with fast-moving web standards: the churn kills browser diversity by exhaustion.

Re: WASM Wayland Web (WWW)

#98

Post by JimDabell »

zfg wrote: post #94
JimDabell wrote: post #91

Earlier quoted context omitted.

> WebAssembly is different. WebAssembly brings every language to the web. Flash didn't. The problem with Flash was not that it only supported a single language. The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into. > But WebAssembly applications can also manipulate the DOM like JavaScript. Flash could do that to…

> The problem with Flash is that it opted out of the web architecture WebAssembly doesn't. WebAssembly is part of the web's architecture. It has been for 8 years. You've doubtless run WebAssembly without even realizing it. Google Sheets for example uses WebAssembly: https://web.dev/case-studies/google-sheets-wasmgc Amazon Prime Video uses WebAssembly: https://www.amazon.science/blog/how-prime-video-updates-its-... >…

I know how WebAssembly works. You don’t need to explain it to me.

Take a look at the article. It’s specifically advocating for:

> So throw out all the web standards. Make a browser that just runs WASM blobs, and gives them a surface to use

And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a different way, all I found was an SVG for the logo and a JavaScript file to load the binary. When I inspected the DOM, all I found was a `` the executable code draws into.

This is exactly what I was complaining about:

> The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into.

Re: WASM Wayland Web (WWW)

#99

Post by eadmund »

JimDabell wrote: post #36

The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. They treated the web browser like it was just a way to run executables in a window. Nothing worked right. Bookmarks, search engines, command-line tools, user preferences for font size, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links……

The difference between now and then is that people back then wanted bookmarks, search engines, CLIs, user preferences, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links and so forth. While some of us still do, the great mass of web users now just want TV on their smartphones: they want an attention-consumption device to distract them from real life.

Flash never took over because a lot of us then wanted our computers to work for us; Javascript and the read-only web are succeeding because so many now don’t mind being farmed for their attention.

Re: WASM Wayland Web (WWW)

#100

Post by zfg »

JimDabell wrote: post #98
zfg wrote: post #94

Earlier quoted context omitted.

> The problem with Flash is that it opted out of the web architecture WebAssembly doesn't. WebAssembly is part of the web's architecture. It has been for 8 years. You've doubtless run WebAssembly without even realizing it. Google Sheets for example uses WebAssembly: https://web.dev/case-studies/google-sheets-wasmgc Amazon Prime Video uses WebAssembly: https://www.amazon.science/blog/how-prime-video-updates-its-... >…

I know how WebAssembly works. You don’t need to explain it to me. Take a look at the article. It’s specifically advocating for: > So throw out all the web standards. Make a browser that just runs WASM blobs, and gives them a surface to use And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a dif…

> And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a different way, all I found was an SVG for the logo and a JavaScript file to load the binary. When I inspected the DOM, all I found was a `` the executable code draws into.

What does that have to do with running the application? What user is going to inspect the elements of a web page? No end user will. Developers will, but that's got nothing to do with running the application.

You can always go ahead and disassemble the .wasm file just like any other executable format. Here are some tools: https://github.com/WebAssembly/wabt

If you're worried about understanding how an application works, remember that most of it is on the server side anyway. You won't have access to that. And if anything, WebAssembly puts more of it on the client side.

Post reply on HN