Live data from Hacker News

WebAssembly becomes a W3C Recommendation

w3.org

91–100 of 248 posts

Re: WebAssembly becomes a W3C Recommendation

#91

Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...

Good questions. WASM at this point seems more a locus of JS hate than anything practical. To create something cool, novel, and useful should be the goal, not avoid or use a certain language.

Yeah, we should all write js on the web and cobol on the server. Think about how good cobol could have become.

Re: WebAssembly becomes a W3C Recommendation

#92
post #14

Earlier quoted context omitted.

WASM is angling to break out of the web and become a cross-platform runtime. Its main competition for this space is Java.

Show me a WASM VM that approaches the OpenJDK JVM in maturity and capabilities. Until such a creation comes to be, the OpenJDK JVM will continue to thrive.

Ironically, GraalVM might end up being one of the better WASM VM: https://medium.com/graalvm/announcing-graalwasm-a-webassembl...

Re: WebAssembly becomes a W3C Recommendation

#93

Earlier quoted context omitted.

> there will be a major accessibility problem The modern web already burned that bridge and loudly declared that it doesn't give two shits about accessibility. There are plenty of companies that gladly sacrifice accessibility to have "beautiful" interfaces designed by some self-important jackass.

That argument sucks. Yes there are sites with poor accessibility, but there's also a lot of sites that are fine. It would be a huge step backwards if they switched from DOM to Canvas.

I don't disagree that it'd be bad, I disagree that a lot of sites won't do it anyway.

Re: WebAssembly becomes a W3C Recommendation

#94

Earlier quoted context omitted.

Off-topic, but I wish Markdown had a proper "multi line" block quote syntax like this. The current standard of ">" is open to too much interpretation around paragraph breaks. Similar to how fenced code blocks with ``` are a major improvement over prefixing the line with 4 spaces.

In Markdown you can generally produce a single block quote with paragraph breaks by including quoted empty lines: > Paragraph 1 > > Paragraph 2 Whereas you'd get two sequential quote blocks by using an unquoted empty line: > Quote 1 > Quote 2

That doesn't work here

> because if you have multiple lines not separated by an empty line, > > even with a "quoted" extra line, it's not formatted on hn as such, and everything collapses into a single line.

Re: WebAssembly becomes a W3C Recommendation

#95

Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...

Good questions. WASM at this point seems more a locus of JS hate than anything practical. To create something cool, novel, and useful should be the goal, not avoid or use a certain language.

WASM isn’t very practical yet because it isn’t fully formed. There isn’t support for DOM access or parallelism, never mind the ecosystem. It’s a really ambitious project, and writing it off as “locus of JS hate” because it hasn’t completely changed the game in such a short time frame is really short sighted. It would be a fairer test to give it 5 years.

Re: WebAssembly becomes a W3C Recommendation

#96

Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...

Figma uses it for their design editor. PSPDFKit uses it for their pdf editor. Unreal Engine/Unity uses it for their browser support. It's used in production in many places either as modules or entire apps.

1password recently moved their browser plugin too https://blog.1password.com/1password-x-may-2019-update/

Re: WebAssembly becomes a W3C Recommendation

#97
post #81

Earlier quoted context omitted.

Yup. In addition to JavaScript runtimes that have added WebAssembly support, such as Node, there are dedicated WebAssembly runtimes, like wasmtime: https://github.com/bytecodealliance/wasmtime If you want to provide a plugin or extension interface, and want to give those plugins a limited interface rather than making them all-powerful, embedding a WebAssembly runtime gives you all of that plus the ability for people…

> embedding a WebAssembly runtime gives you all of that plus the ability for people to easily write plugins in any language No, you would still have to provide an application programming interface for every target language you want to support.

No, you don't.

If you export functions to WebAssembly, any language that can run in WebAssembly can call those functions.

And if you define WebAssembly Interface Types for your exported functions (note: still in development), any language that handles interface types can automatically handle things like "how does this language represent a string safely".

Either way, you don't need to define a new API for every language.

Re: WebAssembly becomes a W3C Recommendation

#98

Earlier quoted context omitted.

As in, JS development for browser? You'll still need JS to run WebAssembly in the browser. It'll bury JS in the sense that you are able to develop in any other language like C++, and compile your program to JS+WebAssembly, so you don't need to develop in JS anymore. But JS itself (under the hood) is probably to stay for longer.

And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem. Unless screen readers can now dive down into the canvas layer?

> And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem.

There will also be performance problems. The web is already slow using the heavily optimized DOM. It's going to be so much slower when things try to use a fullscreen Canvas instead. That breaks all sorts of optimization opportunities browsers currently leverage.

But sadly it'll probably happen. We'll all end up downloading forks of browsers in various states on each site we go to as each site decides to re-invent the DOM & all the rendering optimizations that go along with it.

Re: WebAssembly becomes a W3C Recommendation

#99

Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...

Good questions. WASM at this point seems more a locus of JS hate than anything practical. To create something cool, novel, and useful should be the goal, not avoid or use a certain language.

There's a pretty stark difference between those working in and with WASM, and people commenting on the sidelines. Almost everyone involved with WASM itself sees it as complimentary, and explicitly is not trying to "kill javascript." Random commenters on the internet do say this a lot though.

Re: WebAssembly becomes a W3C Recommendation

#100

Earlier quoted context omitted.

And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem. Unless screen readers can now dive down into the canvas layer?

"if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem" As a web-development near illiterate, this equals to me as pages that aren't auditable before they're shown, which would pretty much translate into unblockable ads. Please someone tell me I am wrong.

Yes/no.

If you switch off javascript then the WASM files won't be able to be loaded.

Then on top of that I guess you could just filter for all `canvas` elements. That will cripple some [biased edit: worthwhile] uses at the same time, though.

Post reply on HN