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

WebAssembly becomes a W3C Recommendation

w3.org

Post reply on HN
Print view View original

211–220 of 248 posts

Re: WebAssembly becomes a W3C Recommendation

#211

Post by zzzcpan »

JoshTriplett wrote: post #183
zzzcpan wrote: post #116

Earlier quoted context omitted.

What you are describing is more like __asm__("") in C, not an interface for application developers. Those are still required for every single target language because of the mismatch between the levels of abstractions between those languages, webassembly and actual logic exported.

That's not accurate, and people are not expected to write an API adapter for every target language. Please read https://hacks.mozilla.org/2019/08/webassembly-interface-type... . Interface Types are the mechanism for handling the different abstractions in different languages without having to write language-specific interfaces. WebAssembly prior to Interface Types is more akin to an exported C function than to inline…

I have read the article, when it came out actually, it's merely about type mapping rules to an intermediate common representation. And it absolutely doesn't imply that interface types give you everything for high level interfaces in any language. Not that it's even possible, as high level wasm another high level transformation cannot realistically be automated for an arbitrary high level language, what can be is just high level wasm wasm level looking code in another high level language. It's like decompiling, you can't produce high level code automatically, only low level looking code in high level languages.

Re: WebAssembly becomes a W3C Recommendation

#212

Post by fastball »

LessDmesg wrote: post #181
root_axis wrote: post #115

Earlier quoted context omitted.

Something with a static/strong type system.

I'd like that too, but it's not going to work with the web dev populace. They're used to a dynamically-typed sandbox and won't switch to a full statically typed language.

What about TypeScript?

Re: WebAssembly becomes a W3C Recommendation

#213

Post by drfuchs »

klodolph wrote: post #28
tenaciousDaniel wrote: post #22

Earlier quoted context omitted.

I'm a web dev and I don't know much about WASM. I've been wondering - will it be possible to render something to the screen without first going through the DOM? Or is the DOM literally the only way to display content? It's enticing to imagine being able to open a wasm file and seeing an application on the page. Kinda like how you can just open an image or a video in the browser, without rendering it via an html docum…

There is currently no path for any of that. No rendering without a DOM, and no opening WASM files by themselves. The same is true for JavaScript... if you open a JavaScript file, you just see the source code. Of course, why not just use a small HTML+JS shim for your WASM?

Because it slows things down by 3 or 4 orders of magnitude?

Re: WebAssembly becomes a W3C Recommendation

#214

Post by [deleted] »

sunseb wrote: post #147
LessDmesg wrote: post #15

Now if only we get a good web-oriented Python with a WASM backend, we'll finally be able to throw Javascript where it belongs: into the dustbin of history.

I think in the end we may have a subset of JavaScript that compiles to WebAssembly. Something like TypeScript. Something that cleans up the mess of JS and keeps the good parts.

[deleted]

Re: WebAssembly becomes a W3C Recommendation

#215

Post by xscott »

cbhl wrote: post #139
dwohnitmok wrote: post #111

Earlier quoted context omitted.

I think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights. The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it. Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages c…

> Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance. I interpreted that part of the talk as hyperbole and sarcasm. It was saying that programmers will be so far removed from how computers work that they'll happily program against a model that has five layers of abstraction that simply serve to provide the original interface of the bottom layer. By…

Around 1999, HP had a project called Dynamo where they implemented a JIT PA-RISC virtual machine on actual PA-RISC hardware. In some cases, they got better performance than native because the JIT would recognize hot paths at run time. I only bring it up to show that it's not 100% certain VMs can't win over conventional native. When I compile with GCC or CLang, I don't think my executable is tracing the hot paths and rewriting itself as it runs.

https://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

Re: WebAssembly becomes a W3C Recommendation

#216

Post by hackcasual »

kllrnohj wrote: post #79

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

I work for Tableau, we've been using it for over a year to handle local map interactions, and soon it'll be powering our animation system on the web.

Re: WebAssembly becomes a W3C Recommendation

#217

Post by dboreham »

kllrnohj wrote: post #79

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

I work on a project that has used it in a few places such as: running graphviz in the browser, and using various cryptography libraries cross compiled from C in the browser. In my experience it's early days still. Tooling is fragile and runtime memory management rudimentary.

Re: WebAssembly becomes a W3C Recommendation

#218

Post by discreteevent »

mark_thompson wrote: post #193
shantly wrote: post #184

Earlier quoted context omitted.

Since Java relies on the JVM I think I'd avoid it, and any other languages that'd require running another VM on top of the WASM VM. Seems like useless stacking of technology that serves basically the same purpose. Not saying it wouldn't work and that it won't be done, but just seems kinda gross and missing-the-point. Personally I'd also avoid anything with a fatter runtime than maybe Go or C#. If it doesn't already,…

Thanks! I'm still thinking if I should need to learn a 'learning language' first (Java or Python) and then move on to a low-level language or go directly to C++. I've been on Linux for years and feel quite comfortable with it, BTW. Can C++ be learned/used on Linux?

I wouldn't start with C++. I did and then programmed in it for about 15 years. I liked it but looking back you spend a lot of time thinking about things that have nothing to do with the real world problems you are solving. And there are still far too many ways to do one thing. Despite modern guides etc you will still come across all these styles and they will distract you. Python is a great start. Virtually no bs, just programming. If you want static types then java or go or c# it doesn't matter. Stick to gc'd languages at the start.

Re: WebAssembly becomes a W3C Recommendation

#219

Post by azakai »

echeese wrote: post #145
alaaf wrote: post #143

Earlier quoted context omitted.

Figma uses Emscripten which is technically not Webassembly (to my knowledge)

Emscripten has been able to compile to WASM since before WASM was implemented in browsers. It became the default output earlier this year.

Some more detail: Emscripten has defaulted to emit wasm even earlier, in May 2018. The change this year was to switch how that wasm is emitted, from the old fastcomp+asm2wasm path to the new LLVM wasm backend.

Re: WebAssembly becomes a W3C Recommendation

#220

Post by chubot »

dwohnitmok wrote: post #111
chubot wrote: post #37

Earlier quoted context omitted.

Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which is a CPU emulator written in JavaScript that runs the Linux kernel (using typed arrays and relying on fast JITs). That's just a way of saying that "the best way to predict the future is to invent it" (and do so before people who were "predicting" it). If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's nothing surp…

I think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights. The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it. Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages c…

OK, yeah the "metal" part is fair. He showed asm.js and then posited that there would be something called "metal" that causes JavaScript to die and enables application written in more languages. And major apps could be ported to it.

Originally my conception of the video was more like this commenter below: It’s been a while since I’ve watched the video but its more about JavaScript becoming the universal assembly language.

I guess a lot of people are saying "he predicted this" without referring what specifically he is predicting.

FWIW it's not clear to me that WASM is going to do that. Everything I've heard from the team says that WASM and JS are complementary. Not that WASM will cause JavaScript to die.

I think there's some possibility of that happening in the distant future, but it's far from obvious. I think JS VMs will always be better at running JS than WASM VMs running JS engines, and all the JS out there will exist for a long time.

Also, JS is at a pretty good level of abstraction to manipulate the DOM, whereas C, C++ and Rust aren't. And it has some good syntactic shortcuts. Despite being a Python person, I would probably even argue that JS is better to manipulate the DOM, despite JS and Python being very similar otherwise. Function literals might be one reason.

So when people say "he predicted this", it would be nice to be specific about what the prediction was. WASM is a step in that direction but I would argue it's also fairly clear given that asm.js existed and he showed it. The real question is if WASM can handle all these use cases. Working on a language has made me appreciate many reasons that it's hard to make a polyglot VM. Tiny changes can bias your VM towards one compilation source vs. another.

Post reply on HN