141–150 of 231 posts
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…
The "Create New Project" dialog has serious accessibility problems when used with a screen reader. The buttons are clickable divs, not actual HTML buttons or even marked up with proper ARIA. I haven't yet ventured any further into the app. Given that the app is a WebAssembly development environment, my first guess was that it was built in WebAssembly itself, with a custom UI framework. But in fact, it's plain React,…
> It breaks my heart This is all a little dramatic, no? It's a cool app that can be easily updated to fix button accessibility.
Well… no, not really, because it’s not just about the buttons. I invariably find that things like this are systemic, so that individual symptoms may be fixed fairly easily, but that there are just lots of basic problems with the markup employed, all of which need to be fixed, and some of which are actually hard to fix because of bad assumptions.
Earlier quoted context omitted.
I'm guilty of this more often than I should be. I think the reason I sometimes reach for divs over buttons or other semantic elements is because I've been burned by default browser behavior treating them special when I just want a dumb box with a dumb click handler - no default styling that I need to override, no need to call .preventDefault(), no need to worry about the matrix of OS+browser+device that each treats a…
Interesting - I would have expected the reverse to be true, i.e. if you often reach for divs first, you'd often be burned by e.g. enter-to-submit not working, or the wrong keyboard showing up on mobile, etc.
But if you have things like “I put my button inside a form, and now when I click on it the page reloads” (because it’s now a submit button, so you need to either change it to type=button or add event.preventDefault() to your click handler or form submit handler, according to taste), that’ll affect everyone, and thus you’ll notice it immediately, and thus it’s you as a developer being burned by it, and so you notice it.
It would be nice if there was a no-javascript fallback - at least a message saying "This site only works with javascript enabled." If you have noscript, this site is completely blank until you enable a couple of things and reload.
You thought a web page webasm ide would work without javascript?
Obviously once I realize it has loaded, but it's blank, I assume it's because it requires javascript. So I enable it and reload, and it works as expected.
Jokes about the [Birth and Death of JavaScript]( https://www.destroyallsoftware.com/talks/the-birth-and-death... ) aside, I love the concept of WASM and that we're making the web a more robust compile target. One of the big limitations in my mind is that I still don't know of that many people using it in production at scale. Is there a list, or well known set of examples (other than Figma), who are using WASM in prod…
The problem is that it's hard to use as a primary language because of a lack of direct Web API access. So basically right now it's not a casual decision to say "I prefer X over JS, so I'll just use that instead because it targets WASM!" Because there's this enormous cost of crossing that API barrier (which means you'll be using some JS regardless, directly or indirectly). So for now the value-proposition only really…
Earlier quoted context omitted.
The problem is that it's hard to use as a primary language because of a lack of direct Web API access. So basically right now it's not a casual decision to say "I prefer X over JS, so I'll just use that instead because it targets WASM!" Because there's this enormous cost of crossing that API barrier (which means you'll be using some JS regardless, directly or indirectly). So for now the value-proposition only really…
Direct access seems improbable and even undesirable. Libraries can be written and shared to expose what you want to the wasm you need to run.
That said, I tried just now to find where I read that this was on the long-term roadmap and I'm having trouble finding it. So maybe you're right that it isn't currently planned.
Earlier quoted context omitted.
Why assume ignorance/difficulty when the reality is not everyone is going to focus on adding/maintaining accessibility when they haven't even built out their beta MIT licensed side project? It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet (getting anything to automagically work in UI is a pain still). As far as what we can do about it I suppose outside of some…
Exactly this. Yes, accessibility is very important, but as of right now, it takes non-zero effort to implement correctly. So you must balance that with other priorities depending on the goals of the project.
The "Create New Project" dialog has serious accessibility problems when used with a screen reader. The buttons are clickable divs, not actual HTML buttons or even marked up with proper ARIA. I haven't yet ventured any further into the app. Given that the app is a WebAssembly development environment, my first guess was that it was built in WebAssembly itself, with a custom UI framework. But in fact, it's plain React,…
Why assume ignorance/difficulty when the reality is not everyone is going to focus on adding/maintaining accessibility when they haven't even built out their beta MIT licensed side project? It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet (getting anything to automagically work in UI is a pain still). As far as what we can do about it I suppose outside of some…
Yep as someone who's done a significant amount of front-end development ARIA and accessibility is more billable hours, more time involved into project, and more testing. When it's my own consulting I literally add it as a line-item to the bill and let customers take it off if they want to save cost, and when it's for professional work the only industry that has actual regulation around it is education/government.
Truth is most companies are pushing the cost of development down however they can, and to cater to the accessibility market you're sinking significant dev/testing time into doing it right. Also, you can't blame me in a capitalist society for dropping this on the floor when my customer/employer wants me to... in most situations the hours invested into accessibility will never turn around into profit.
The other problem is I do accessibility right. And most devs don't... I'll actually go through and do UIX experiences on-screen, then replicate it "blind" using a screen reader. This testing/tuning takes real time. Like - I can go through and do best practices with ARIA tags, well thought out HTML5, etc and still it's a total cluster once you actually use the application.
It very much may not be "ignorance/difficult" - looking at what this dev has accomplished with this editor I'm going to give them the benefit of the doubt and say it was just extra time for a tiny fraction of their audience that they haven't invested yet. Harsh reality is they may not have that budget of time to go the extra steps for something as complex as this.
Question for anyone with real WASM experience: what are your top recommended entry points / reference materials? AssemblyScript seems pretty approachable at 1st glance...
Rust has the best tooling for wasm and is easiest to get started with, in my opinion. `rustup target add wasm32-unknown-unknown` `cargo build --target=wasm32-unknown-unknown` Is all you need to compile a Rust library to a `.wasm` file. (almost, you also need a setting in Cargo.toml: [lib] crate-type = ["cdylib", "rlib"] ) In the browser you can get access to DOM apis via web-sys. The documentation has quite a lot of…
Wow! The last time I looked, doing anything remotely like this was a gigantic pain, in any language.
I guess it's finally time for me to get around to learning Rust.
Earlier quoted context omitted.
AssemblyScript is one of the best options, because if the only thing you care about is some high level language that outputs WebAssembly, then you are still using Web related tools. Then D is quite easy to use (LDC alongside betterC mode, runtime is still not fully ported). Followed by TinyGo, Rust, C#, Nim. I would leave Emscripten, C and C++, only for porting existing code into the Web, as even with the sandbox mem…
> corruptions of data allocated in the linear memory blocks are susceptible to occur I don't know if I quite understand this. Is this a web-assembly specific thing, or just the standard C / C++ are "unsafe by default" languages which can cause memory corruption etc because e.g. of off by one errors in pointer arithmetic and so on.
WebAssembly doesn't do bounds checking, besides being in bounds of a linear memory segment.
Basically the access is still in bounds of the allocated memory, but not the cells that one actually wanted to access.
From security point of view, while the WebAssembly module is sandboxes, such corruptions can be triggered from the outside, changing the behaviour of the public API.