Hacker News Reader

Comment by gjsman-1000 | Hacker News Reader

In the future, we’ll decide HTML, CSS, and JS are too much of an inconsistent burden; so every website will bundle their own renderers into a <canvas> tag running off a WASM blob. Accessibility will be figured out later - just like it was for the early JavaScript frontends.

I am looking forward to the HTML Frameworks explosion. You thought there were too many JS options? Imagine when anyone can fork HTML.

View on HN

<canvas> is already a middle finger in the direction of accessibility. You don't need wasm to put blind people at an extra disadvantage. SVG Accessibility anyone? No? What a surprise. Classical web accessibility has basically ended. We (blind people) are only using sites which are sufficiently old to be still usable.

I'm genuinely trying to do something about <canvas> element accessibility. Whether it's enough ...? Probably not. But if I can do the work to try and show that <canvas> elements can be made more accessible, then there's no excuse for developers working on far more popular JS canvas libraries from making an attempt to better my efforts.

I do strongly agree that <canvas> elements should not be used to replace HTML/CSS! My personal web hierarchy is 1. HTML/CSS/images; 2. Add (accessibility-friendly) JS if some fancy interaction is useful; 3. More complex - try SVG/CSS; 4. use <canvas> only if nothing else meets the project requirements.

https://github.com/KaliedaRik/Scrawl-canvas

Deaf person here working full time to try and make some consumer websites not terrible at the least.

Great, thanks. Keep up the good work, we need everybody motivated!

There has been some exploration around developing a JavaScript API for accessibility. If implemented, that would allow <canvas> renderers to be accessible. I hope people will consider that blocking for shipping canvas renderers, but we'll see.

You are blind? Could you perhaps point me to a good resource to make my websites or apps more accessible, perhaps even to test it in these regards?

I’ve found some resources but when I look at them I also hear stories of blind people saying these guidelines only make things worse.

Well, I am not a web dev... At least, my know-how ends when SPAs begin. All I can point you to are the WCAG, but I am sure you already know about them...

Regarding the vague criticism you mention, I'd need something more concrete to tell you if the rumors are truish...

Ah my bad. Yes I was aware of the WCAG, but I also read some criticisms regarding them. I guess it’s still a good starting point then, thanks!

Why stop there? LLMs will free us from the shackles of having to ship actual code, instead we'll ship natural language descriptions and JIT them at runtime. It may use orders of magnitude more resources and only work half of the time but imagine the Developer Velocity™

In fact, with AI becoming more powerful, the <canvas> tag might soon become even more viable; because nobody will need ARIA tags or similar to tell them what’s on screen. The AI screen reader will look at the website as a whole and talk to the user. With accessibility no longer required, and with any UI being just a dumb framebuffer, we’ll finally see perfect chaos.

And blind people will be the first test subjects for the "we see everything you read" project. Sweet. A small enough group that has no way out. Besides, after the initial giveaways, imagine the revenue if you can charge for every single pageview.

can't wait for all the imaginary features

You can hallucinate them right now already. Just ask WebGPT.

The LLM created code will then be consumed by my AI agent which will rewrite the application to filter all of the bullshit and be fit for my minimalist preferences like a Reader Mode for CRUD apps.

The state of web deployment in 2025 is the universe punishing me for calling java applets and other java web deployment tech "heavyweight" back in the day.

What would we dev areas are important to you?

> every website will bundle their own renderers into a <canvas> tag running off a WASM blob

Isn't that Flutter?

Not that I intend to scale this in any way, but I'm working on an in-game UI rendered on the canvas, and I am thinking I might be able to hack something together based on this youtuber's library and excellent explainer video[0]. The thought had definitely occurred to me that if someone wanted to really roll up their sleeves and maintain a js port of the library, it would provide a translate-able UI from native C to native JS and back. At least, I can imagine a vite/webpack-like cli that reads the C implementation and spits out a js implementation.

Of course, I could also imagine one that reads the C and provides the equivalent html/css/js. And others might scoff "why not just compile the whole C app into wasm", which would certainly be plenty performant in a lot of cases. So I guess I don't know why it isn't already being done, and that usually means I don't know enough about the problems to have any clue what it would actually take to make such things.

In any case, I'm also looking forward to a quantum leap in web app UI! I'm not quite as optimistic that it's ever going to happen, I guess, but I can see a lot of benefit, if it did.

[0]https://www.youtube.com/watch?v=by9lQvpvMIc

I'm thinking about this space now. Ideally, I want a new browser like platform with stricter security properties than browsers but better rendering out of the box capabilities.

You jest, but isn't this Web Components? Or alternately, Flutter

Web Components was too verbose and nobody could figure it out. Flutter is just the beginning of the newest scheme by RAM manufacturers to bloat our RAM usage. We’ve stagnated at 8GB on midrange computers for too long.

Web Components aren't that bad, but they could definitely use a DX makeover.

For simple components, I much prefer them to firing up the React ecosystem.

Soon it'll be all 3D content anyway... the old world of a graph of documents is going away. The web breathed a sigh of relief when Apple's Vision Pro bombed.

Reply on news.ycombinator.com