Live data from Hacker News

WebAssembly Studio

webassembly.studio

181–190 of 231 posts

Re: WebAssembly Studio

#181
post #26

Anyone have a guess as to when WebAssembly will be able to directly access the DOM?

Despite all the hype, I don't think this will ever realistically happen. interface-types is (supposedly) here but it can't really hold onto DOM objects, it can only reference them, and nobody has made DOM bindings for interface-types yet. GC is an extraordinarily hard problem, and they've talked about scoping out "mini-mini-MVPs" for about a year now, with basically no progress.

I wrote an essay about this a few years ago but never decided to publish it because I felt it was too harsh, but I think it gives a better overview of the challenges involved: https://gist.github.com/magcius/8959ca1f5bbde4bd66b98b6d5dc7...

Re: WebAssembly Studio

#182

Something similar but also totally different is https://makepad.nl/ - a graphics programming IDE in Rust, for Rust, targeting the browser. It's a totally different use case but there's some similarities, somehow, anyway. Unlike this app, its actually all WASM and the author frequently tweets about how he feels more productive building a web UI in Rust than he would HTML+CSS+JS. And you can say what you want, the thin…

Curious whether source maps and breakpoints still work?

Re: WebAssembly Studio

#183

Something similar but also totally different is https://makepad.nl/ - a graphics programming IDE in Rust, for Rust, targeting the browser. It's a totally different use case but there's some similarities, somehow, anyway. Unlike this app, its actually all WASM and the author frequently tweets about how he feels more productive building a web UI in Rust than he would HTML+CSS+JS. And you can say what you want, the thin…

> And you can say what you want, the thing is damn snappy.

It's horribly slow on my computer, animations and scrolling happen at like 5fps. It also sends my cpu usage through the roof.

Re: WebAssembly Studio

#184

Something similar but also totally different is https://makepad.nl/ - a graphics programming IDE in Rust, for Rust, targeting the browser. It's a totally different use case but there's some similarities, somehow, anyway. Unlike this app, its actually all WASM and the author frequently tweets about how he feels more productive building a web UI in Rust than he would HTML+CSS+JS. And you can say what you want, the thin…

> And you can say what you want, the thing is damn snappy. It's horribly slow on my computer, animations and scrolling happen at like 5fps. It also sends my cpu usage through the roof.

I think it's all WebGL UIs. Maybe somehow your WebGL gets simulated on the CPU?

Re: WebAssembly Studio

#185

Something similar but also totally different is https://makepad.nl/ - a graphics programming IDE in Rust, for Rust, targeting the browser. It's a totally different use case but there's some similarities, somehow, anyway. Unlike this app, its actually all WASM and the author frequently tweets about how he feels more productive building a web UI in Rust than he would HTML+CSS+JS. And you can say what you want, the thin…

EDIT-but-can't-edit-anymore:

I just noticed that https://makepad.dev/ hosts a different version that I think is newer. Skip the .nl one.

Re: WebAssembly Studio

#186

Something similar but also totally different is https://makepad.nl/ - a graphics programming IDE in Rust, for Rust, targeting the browser. It's a totally different use case but there's some similarities, somehow, anyway. Unlike this app, its actually all WASM and the author frequently tweets about how he feels more productive building a web UI in Rust than he would HTML+CSS+JS. And you can say what you want, the thin…

Curious whether source maps and breakpoints still work?

Yes that's a possibility actually the experience should be even better than with sourcemapped JS. There was a demo of Wasm debugger on HN frontpage not a long time ago.

Re: WebAssembly Studio

#187

Earlier quoted context omitted.

Bikeshedding about the best approach to making it accessible aside I think we all agree there was no out of the box button with the exact functionality and styling the project needed. Many ways to build such a thing but all of which require someone actually making the software that way as part of the project scope. Difficult? Not really. Priority to implement from day 1 in this project? Well that's what started the c…

> I think we all agree there was no out of the box button with the exact functionality and styling the project needed We don't agree on that. Styling a real button to look the same way this does would require basically the same amount of work as styling a div. The only difference for most people is that you would need to search for a style clear for buttons, which will be the first result in DuckDuckGo: https://css-t…

I'm REALLY not looking for a debate on what technical changes are needed to make this accessible but I tried changing it to a button in the page (with border: none;) and immediately I notice it's larger and the underline hover effect is broken. It's also floating verically by a pixel. I'm sure there are other effects I haven't noticed immediately. This is exactly what I'm talking about on how it's not just free, there is work to making it work exactly the way the developer wanted it for the project.

Maybe you think a button shouldn't look like that. Maybe you think a button should prioritize before style. Maybe you just like to do something your own way. That's great, go ahead on your own project or hire this person for it. None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility.

Re: WebAssembly Studio

#188

Earlier quoted context omitted.

The goals of the project includes "custom buttons"? There's so much functionality that you get for free/low effort if you don't feel the need to customize everything to the nines.

When I decided to make myself a personal website this summer, my goals were: • It has to have lots of custom animations, because animations are fun. • It has to work well in weird text-based browsers like Links, because being able to load my site up in those feels cool. • It has to support Safari 6, because that's the last version of Safari that works in Snow Leopard. If it's a non-commercial project, the goals can b…

Right? One of my peeves with a lot of developers is when they treat every programming project like it's a commercial start up. There's no reason "learning to implement custom buttons" can't be on your list of goals.

Re: WebAssembly Studio

#189

Earlier quoted context omitted.

> I think we all agree there was no out of the box button with the exact functionality and styling the project needed We don't agree on that. Styling a real button to look the same way this does would require basically the same amount of work as styling a div. The only difference for most people is that you would need to search for a style clear for buttons, which will be the first result in DuckDuckGo: https://css-t…

I'm REALLY not looking for a debate on what technical changes are needed to make this accessible but I tried changing it to a button in the page (with border: none;) and immediately I notice it's larger and the underline hover effect is broken. It's also floating verically by a pixel. I'm sure there are other effects I haven't noticed immediately. This is exactly what I'm talking about on how it's not just free, ther…

Are you setting it as an actual style under the `.button` class or are you attaching it to the element?

I don't see any of the effects you're talking about. Size is the same, no pixel offset. If you change the div (not the selected SVG, but the div itself) into a button and then add `border: none` to the .button class, there should be no visual changes at all. I'm checking both the Firefox and Chrome dev tools, it's a 24 px high button with 8 pixels of padding.

If there's some other visual change that goes along with that, I can't find it.

----

> None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility.

There's another side to this though which is that it is genuinely helpful to tell people that there are very simple changes they could make to increase accessibility on a platform that we have a vested interest in making accessible.

It's not helpful to be a jerk about it, but I'm not going to act like there's no right way to build something like this. I understand why someone might cut some corners on a quick project, or why they might not know everything there is to know about accessibility. I don't fault any developer over that. But there is a correct engineering answer to the question of how a button should be designed, and it actually does genuinely impact real people in the real world.

Part of what we're doing here is trying to as much as possible without being jerks get across the idea that accessibility matters. We're trying to get across the point that it's not OK to have the web mostly not work for blind people and to say, "there aren't enough of them to care about."

And especially in an area where fixing the problem is genuinely way less work than even having this conversation, and where fixing it would have zero downsides for the finished project, it is genuinely disheartening to see people putting forward the idea that literally any extra work at all means that accessibility has to be optional.

How far are you going to take that? Is it unreasonable for me to ask people to spend an extra minute captioning the photos they upload to Twitter? There are categories of things where it reasonable to ask people to put in a tiny bit of extra work so that the web doesn't completely fail in its mission to be a universally accessible platform. We ask developers (even Open Source developers) to put in far more work over way more trivial, meaningless things than this.

So yes, maybe it would have required an extra minute or two of work to style this as a button. And if the developer didn't know how to do that, fine, I'm not here to shame people for not knowing things, I have no ill will towards the developer for making that mistake. But I am here to shame people who say that one extra minute of work is too much for accessibility advocates to expect, and that asking developers to even think about accessibility is inherently unreasonable. We want developers to care about accessibility, we aren't neutral on that. We want developers to have a code of ethics and values that prioritizes equal access for everyone. That's part of the value ethos of the web as a platform.

We spend so much time as advocates trying to dance around that issue and trying to make it easier for people to be 'accidentally' accessible when they build on the web, and to add tools and features that make accessibility the easier, natural engineering path. All of that is good, and we should keep doing that, and the accessible path here is the easier path, but on the other hand at some point we also have to be willing to say, "no, we expect you to genuinely care about blind people at least a little bit."

Re: WebAssembly Studio

#190

Something similar but also totally different is https://makepad.nl/ - a graphics programming IDE in Rust, for Rust, targeting the browser. It's a totally different use case but there's some similarities, somehow, anyway. Unlike this app, its actually all WASM and the author frequently tweets about how he feels more productive building a web UI in Rust than he would HTML+CSS+JS. And you can say what you want, the thin…

Is it just me that finds all the text rendering on this page really bad?

What has good text rendering?
Post reply on HN