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

WebAssembly Studio

webassembly.studio

Post reply on HN
Print view View original

111–120 of 231 posts

Re: WebAssembly Studio

#111

Post by gregmac »

thwarted wrote: post #72
spicybright wrote: post #54

Earlier quoted context omitted.

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 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.

There are about 100 ways to do any given thing when building web apps, and it's a constantly shifting landscape where "the way" you do a bunch of things is different every time you start a new app (at least it feels that way to me).

Being really good at front-end (to the point you know when to use a native control or not, which "standard" features you can rely on, how to think about accessibility+responsive+dark mode+ad blockers+low bandwidth+seo etc) is an entire discipline that takes a lot of effort to stay current in.

If you use pure, standard html with default styling you still end up with a page using bad colors and Times New Roman that looks straight out of the 90s. If that's not the look you're going for, you need to do some customization (via CSS) and the difference between "some" and "to the nines" is not exactly a clear line -- even to people that have specialized their careers in front-end dev.

Re: WebAssembly Studio

#112

Post by simonh »

zamadatix wrote: post #93
simonh wrote: post #86

Earlier quoted context omitted.

What does being MIT licensed have to do with it? And please, don't anyone dare chime in with the the standard "if people want a feature in open source they can 'simply' implement it themselves". UI technologies that don't include accessibility are simply not good enough. It's not like accessible options don't exist.

> What does being MIT licensed have to do with it It's a non commercial non government project. > And please, don't anyone dare chime in with the the standard "if people want a feature in open source they can 'simply' implement it themselves". Already talked about it in the parent comment, would be interesting if you could respond to that instead of asking nobody mention it. > UI technologies that don't include acces…

>It's a non commercial non government project.

Yes I know that, what's that got to do with not having accessibility?

And no it doesn't have to be perfect, it comes down to what we consider acceptable.

Re: WebAssembly Studio

#113

Post by corytheboyd »

ddevault wrote: post #59
bavell wrote: post #24

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…

You should fix this attitude, becuase it's making your applications worse. The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. If the browser can do something for you, you ought to let it do that for you. If you insist on writing your own controls, its behavior will differ from how the browser's own UI works in subtle ways, repeated indefinitely for e…

I didn’t downvote because I can agree to a certain extent. Are you suggesting a completely unstyled web or something? Maybe if you fleshed out that idea you would be met with less criticism.

There is a good lesson here though, native browser controls should ALWAYS be your first consideration when building UI for the web. Try everything under the sun to stick as close to these as possible before you give up. You will thank yourself for having less code in which something can break. Your users will thank you for already knowing how to use the controls.

An example that drives me crazy is when dropdowns that could have been a select/option group of controls are not. Because most of the time the subtle but insanely helpful keyboard controls are completely missing. Being able to type with the menu selected to jump to items is insanely helpful when the creator insists on jamming too many options into it. Think about that, it’s not exactly trivial to implement, and by the time you have the dozens of lines of JavaScript to implement it correctly... pretty hard not to ask yourself “what the hell am I doing...”

Re: WebAssembly Studio

#114

Post by codeflo »

dboreham wrote: post #70
tomasreimers wrote: post #2

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…

I'm also intrigued by the possibilities of WebAssembly. However I also have a nagging feeling "didn't we already do this with Java, 20 years ago?". Wondering what's different this time, or is this just a MySpace vs Facebook second-times-the-charm thing.

I’m not sure either. There are some technical differences. WASM is more low-level than JVM bytecode, which is important for some applications and makes it a more normal compiler target. It’s more integrated with the rest of the browser: it doesn’t come with its own rectangle like Flash and Java did, but instead manipulates the DOM just like (or at the moment, only through) JavaScript. And it’s a true open standard, not a corporate-controlled platform.

Do these differences really matter, or is it mostly just the timing?

Re: WebAssembly Studio

#115

Post by hobby-coder-guy »

mwcampbell wrote: post #10

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,…

“Hey, here are some tips on making your site more accessible”

Re: WebAssembly Studio

#116

Post by Closi »

WalterGR wrote: post #94
tadfisher wrote: post #88

Earlier quoted context omitted.

The difference is that wasm is designed to be sandboxed, instead of the JVM which was designed to normalize disparate computing environments. In practice, this entails a lot of work to create runtimes to do anything interesting in wasm, but the behavior is secure by default (ignoring side-channel attacks, of course). Java applets run in a sandbox by default, of course, but the JRE itself has unmitigated access to the…

> the JRE itself has unmitigated access to the host system As does the browser in which WebAssembly executes. > Users can also be tricked to trust malicious applets But the ability of applets to be trusted could have been eliminated entirely. To rewrite OP's question, then: "If we had entirely gotten rid of trusted applets, couldn't we already do this with Java, 20 years ago?" Of course, we didn't get rid of them, bu…

Can't we just do this in sandboxed regular assembly running inside a virtual machine?!

/s

Re: WebAssembly Studio

#117

Post by thwarted »

gregmac wrote: post #111
thwarted wrote: post #72

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.

There are about 100 ways to do any given thing when building web apps, and it's a constantly shifting landscape where "the way" you do a bunch of things is different every time you start a new app (at least it feels that way to me). Being really good at front-end (to the point you know when to use a native control or not, which "standard" features you can rely on, how to think about accessibility+responsive+dark mode…

If the decision comes down to "I can't get the exact shade of cornflower blue I want on this button unless I make it a div, but that will hurt accessibility" and you chose the exact shade of cornflower blue, your priorities are wrong. And not just because you hurt accessibility, but because you probably made more work for yourself.

We went through this 15 years ago with custom scroll bars that didn't look like scroll bars, didn't operate like scroll bars and didn't interact like scroll bars, all because it could happen. An Ian Malcom quote comes to mind.

Re: WebAssembly Studio

#118

Post by codeflo »

WalterGR wrote: post #94
tadfisher wrote: post #88

Earlier quoted context omitted.

The difference is that wasm is designed to be sandboxed, instead of the JVM which was designed to normalize disparate computing environments. In practice, this entails a lot of work to create runtimes to do anything interesting in wasm, but the behavior is secure by default (ignoring side-channel attacks, of course). Java applets run in a sandbox by default, of course, but the JRE itself has unmitigated access to the…

> the JRE itself has unmitigated access to the host system As does the browser in which WebAssembly executes. > Users can also be tricked to trust malicious applets But the ability of applets to be trusted could have been eliminated entirely. To rewrite OP's question, then: "If we had entirely gotten rid of trusted applets, couldn't we already do this with Java, 20 years ago?" Of course, we didn't get rid of them, bu…

Interesting thought experiment. However, you have to realize that Sun wasn’t a charity. At the time, platform vendors were were hoping to target intranet applications for the enterprise. Microsoft had a similar concept for trusted applications with IE’s “Active Scripting”, with very similar results in terms of (non)security.

Re: WebAssembly Studio

#119

Post by novok »

dboreham wrote: post #70
tomasreimers wrote: post #2

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…

I'm also intrigued by the possibilities of WebAssembly. However I also have a nagging feeling "didn't we already do this with Java, 20 years ago?". Wondering what's different this time, or is this just a MySpace vs Facebook second-times-the-charm thing.

It starts immediately, while any embedded java applet took forever and looked really ugly. We've also done this with flash apps

Re: WebAssembly Studio

#120

Post by gregmac »

thwarted wrote: post #117
gregmac wrote: post #111

Earlier quoted context omitted.

There are about 100 ways to do any given thing when building web apps, and it's a constantly shifting landscape where "the way" you do a bunch of things is different every time you start a new app (at least it feels that way to me). Being really good at front-end (to the point you know when to use a native control or not, which "standard" features you can rely on, how to think about accessibility+responsive+dark mode…

If the decision comes down to "I can't get the exact shade of cornflower blue I want on this button unless I make it a div, but that will hurt accessibility" and you chose the exact shade of cornflower blue, your priorities are wrong. And not just because you hurt accessibility, but because you probably made more work for yourself. We went through this 15 years ago with custom scroll bars that didn't look like scroll…

I don't think that's a conscious decision though. What happens is:

- I can't get this exact shade of cornflower blue

- Oh, here's a solution that works! Oh, it doesn't work in all browsers

- Hmm, here's a stack overflow answer that says use a div. It's 5 years old, is that current? Dunno but it has 457 up votes and works

Some people are concerned about accessibility but the JavaScript doesn't work in iOS. Others have iOS support but they screwed up cache headers and it's super slow on any low bandwidth connection.

Balancing all those things (and that's a very incomplete list) is hard and it's not fair to expect side/hobby/oss projects to do it 100%.

Post reply on HN