from Hacker News

W3C recommends WebAssembly

by lottamus on 12/6/19, 3:12 PM with 338 comments

• by 6gvONxR4sf7o on 12/6/19, 4:12 PM

  Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model?

  That could mean we lose hackability and the ability to write extensions or even scrape the web without a BigCo webcrawler's level of infra investment. Is everything going to turn into an opaque single page app? Technically, webassembly is really cool, but I worry about where the browser is headed.

• by nojvek on 12/6/19, 8:31 PM

  The design goals of WebAssembly are the following:

  Fast, safe, and portable semantics:

  * Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.

  * Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.

  * Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.

  * Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.

  * Language-independent: does not privilege any particular language, programming model, or object model.

  * Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.

  * Open: programs can interoperate with their environment in a simple and universal manner.

  Efficient and portable representation:

  * Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.

  * Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.

  * Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.

  * Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.

  * Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.

  * Portable: makes no architectural assumptions that are not broadly supported across modern hardware.

  If webassembly is truly able to meet this goals, together with good debugging and tools, it will become the the universal way to represent computation across devices and platforms.

  Really cool.

• by duxup on 12/6/19, 3:45 PM

  Does anyone have any good intro resources for WebAssembly for noobs?

  I've read articles here and there seen some in person demos, and honestly struggle to understand what it is / how it would / works relative to the current state of JavaScript frameworks.

  Often I'm approaching it from a JavaScript framework (React/Vue/Angular) approach as I'm a bit of a noob to the industry and that's generally my day job working on web applications.... and while I read about WebAssembly I wonder about state management and someone tells me "oh you still need to something to do that" and I'm a bit lost on ... how that would work / why I would or wouldn't use one of those frameworks anyway, etc. So many examples I've seen are one off simplified (and for good reason I like those for demos) widgets but ... I'm not sure I've seen them as an application / understand how that would work.

  Obviously I'm missing a lot here and feel like on HN I'm often talking to folks who aren't so much front end web devs who are excited about the efficiencies and such but ... not sure how this plays out in a practical sense / relative to the state of web applications as they are now.

• by dmvinson on 12/6/19, 3:40 PM

  This feels like another step away from the free and open web many people are clamoring for. Distributing opaque binaries with websites instead of Javascript is a step past even the obfuscated minified javascript files meant to be confusing. At least those can still be debugged, stepped through, and explored freely by the end user if they want to learn or reverse engineer. Is there any tool or standard being worked on to make .wasm files coherent for users who have to run the code to view websites? This feels like a step backwards in so many ways, even if it is a technological marvel.

• by Unit-336 on 12/6/19, 3:51 PM

  For those who are asking themselves what WASM does differently than Java, .NET or other native extensions like ActiveX or NaCl, here's the best rationale doc I found on this topic: https://github.com/WebAssembly/spec/blob/master/papers/pldi2...

• by magsnus on 12/6/19, 3:57 PM

  I really hope this can become a viable alternative to the JS-frameworks we have today for webapps and that more apps can be served via the web.

• by smattiso on 12/6/19, 5:31 PM

  Good. Javascript needs to die. It was far simpler to build performant multi-device UIs 15 years ago than it is today. Building UIs natively on iOS and Android is so much simpler than building for the web.

  Technical question: 1.) What is the speed of WebAssembly on iOS WebKit and Android WebView? 2.) Is it feasible to write an entire app UI in something like Qt and target WebAssembly? 3.) Android, iOS, Windows versions of the app are Qt apps natively or possibly through the device's WebKit.

  Is this possible today? Is there a better UI library than Qt for this?

• by arghwhat on 12/6/19, 5:32 PM

  W3C endorsing it has nothing at all to do with whether or not it is here to stay.

• by Crontab on 12/6/19, 4:43 PM

  This sounds interesting, but personally, I am worried that this will just turn into yet another browser technology that will be used to abuse and track users. I really hope I am wrong.

• by cylon13 on 12/6/19, 4:32 PM

  What's the debugging situation like for developing WASM apps? I'm doing a lot of TypeScript+WebGL work right now, and though TS is fairly nice, my use case requires being aware of not allocating too many new objects frequently, and that kind of control would be easier in something like C++ or Rust. I've been thinking of hacking together a small test project with WASM+WebGL to see what it's like, but I get the sense it might still be more hassle than it's worth to use in production. Currently I can easily set breakpoints in my TS code, I can see how much memory is allocated by which functions, how much time is spent in each function, etc. very easily. If there's a way to do these kinds of things with WASM in another language, that would be fantastic.

• by dmitriid on 12/6/19, 3:51 PM

  Ok. It's here to stay. What's the progress on the two dozen post-MVP features?

  The "arrival" of WebAsm to w3c only means that w3c had finally woken up from eternal slumber and realized that everyone has already implemented The listed features.

• by bogwog on 12/6/19, 3:47 PM

  Hopefully this also means that Javascript is going away for good

• by chx on 12/6/19, 5:16 PM

  How's the DOM manipulation coming along?

• by postit on 12/6/19, 4:17 PM

  It amuses me we're circle backing to have applets all over again.

• by utf985 on 12/6/19, 4:33 PM

  I'm interested in how will WebAssembly affect the functionality of browser addons such as ad and script blockers?

• by mrandish on 12/6/19, 5:58 PM

  Does WebAssembly threaten app store business models by allowing devs to distribute apps directly via browser (thereby saving the app store 'tax')?

  For example, if Adobe delivers its new mobile Photoshop directly via iPad Safari will Apple have a way of 'nerfing' WebAssembly to stop them?

• by markstos on 12/6/19, 3:37 PM

  This is bad for frontend JavaScript being "open" for review, right?

  Companies will ask their developers to deliver WASM resources in the name of performance. As a notable side-effect, it will become harder to review how websites work.

  Yes, I'm sure there will be reverse-compilation tools for WASM, but still.

• by cryptozeus on 12/6/19, 4:08 PM

  Why are people saying with wasm coming JavaScript will have tough time ? Think about it as flash vs JavaScript. They can happily co exist or u can choose one of the other. Don’t assume that wasm is the hammer for every nail.

• by apatheticonion on 12/7/19, 2:30 AM

  <script type="module" src="app.wasm"></script>

  Please

• by tmountain on 12/6/19, 3:30 PM

  What's the horizon for WebAssembly capable browsers gaining enough marketshare that it becomes a viable compilation target?

• by shiado on 12/6/19, 4:43 PM

  Does anybody know the state of the art for wasm tooling? I have used emscripten but are there any excellent 'higher level' tools? The worst part was writing the interface between the wasm and JS.

• by dm33tri on 12/6/19, 4:42 PM

  What I'm thrilled to see is an optimization of binary sizes in compilers and libraries. Maybe <1MB native apps will become common (or few MB of code for single webpage will become standard)

• by dm33tri on 12/6/19, 3:30 PM

  Write once, run everywhere.

  I bet in few years we will run wasm natively on processor.

• by dang on 12/6/19, 5:47 PM

  The submitted title was "It's official, WebAssembly is here to stay". That broke the site guidelines by editorializing. Please don't do that.

• by batterystd on 12/6/19, 5:10 PM

  So what was webassemnly until now?