[HN Gopher] Why WebAssembly is innovative even outside the browser
___________________________________________________________________
Why WebAssembly is innovative even outside the browser
Author : abc_tkys
Score : 74 points
Date : 2021-08-08 16:30 UTC (6 hours ago)
(HTM) web link (www.tetrate.io)
(TXT) w3m dump (www.tetrate.io)
| still_grokking wrote:
| How this "comparison" could miss the elephants in the room?
|
| Java is mentioned, but not the JVM, or .NET (core)?
|
| Therefore this reads once again like an ad...
|
| But that actually fits a scheme: Most things one can read
| currently about WASM are highly over-promising this technology.
| It's nowhere close to the established VM Runtimes until now!
|
| Does WASM really need dishonest marketing posts so badly?
|
| Who is actually throwing money after that marketing efforts? Who
| doesn't like the JVM anymore, and isn't using .NET either?
| jokoon wrote:
| Please bring more toolchains to target WASM, and please have some
| options to interact with the dom!
| CephalopodMD wrote:
| shouldn't the JVM be considered polyglot?
| linkpuff wrote:
| Uhh, how is it polyglot if it only accepts one language (Java)?
| neilalexander wrote:
| It accepts _Java bytecode_ , but various programming
| languages (Java, Kotlin, Scala, Clojure to name a few) are
| built on top of that.
| dkersten wrote:
| Java, Kotlin, Clojure, Scala, Groovy
|
| More here:
| https://en.wikipedia.org/wiki/List_of_JVM_languages
|
| It accepts any language that compiles to JVM bytecode. Java
| is just one of them. Just like an x86 processor accepts any
| language that compiles to x86 instructions.
| linkpuff wrote:
| Doesn't that require a language to be engineered to output
| java bytecode? For example, rust can't be compiled to java
| bytecode because it does things that jvm can't do. A real
| polyglot can't only understand a language by requiring it
| to speak its native language Wasm supports languages that
| weren't created with wasm in mind, just by requiring a
| compiler with the right output, without restraining the
| language.
| [deleted]
| pjmlp wrote:
| Naturally it had to leave out CLR, TIMI, z/OS language
| environment, BREW, TenDRA, Amsterdam Compiler Toolkit as examples
| of bytecode formats that support multiple languages, including C
| and C++.
|
| The only innovation is being more marketable.
| brundolf wrote:
| If history tells us anything, it's that marketability is really
| important when it comes to getting minimum-viable-adoption for
| a technology.
| loxs wrote:
| How easy/practical is it to ship a WASM binary to run on all
| major platforms?
| krapp wrote:
| Numerous native runtimes for webassembly already exist[0], with
| the current popular choices apparently being Wasmer[1] and
| Wasmtime[2].
|
| All one would need to do (AFAIK) is ship a client for all major
| platforms, as is done with Electron (and web browsers
| themselves, and everything else.)
|
| [0]https://github.com/appcypher/awesome-wasm-runtimes
|
| [1]https://github.com/wasmerio/wasmer
|
| [2]https://github.com/bytecodealliance/wasmtime
| ampdepolymerase wrote:
| You still need a browser if you want to do anything GUI
| related.
| kitsunesoba wrote:
| Would it not be adequate to supply a minimal implementation
| of canvas and develop with a UI framework that draws to
| canvas?
|
| Or perhaps something like React Native, with WASM standing in
| for the JS runtime?
| SahAssar wrote:
| Why? Other languages running in similar environments like
| Lua/Java don't need a browser. WASM does not need to run
| within a browser, and there are a couple of runtimes that run
| it outside of a browser, in that case why wouldn't something
| like SDL be able to be used?
| flohofwoe wrote:
| The most important feature of WASM is that it provides a
| secure sandbox, and all APIs that talk to the underlying
| host platforms must be designed with security in mind (see
| all the considerations that went into WebGL vs vanilla
| OpenGL).
| pjmlp wrote:
| As secure as an OS process.
|
| There are proofs of concept using shaders for security
| attacks.
| SahAssar wrote:
| In a browser environment, sure because browsers need to
| sandbox webpages. But WASM runs on different environments
| too.
| flohofwoe wrote:
| It's also important outside the browser, WASM could be
| the solution for running untrusted code without a walled-
| garden app distribution model, but only if the sandbox
| actually works.
| pjmlp wrote:
| As long as the internal memory doesn't get corrupted due
| to lack of bounds checking inside linear memory internal
| accesses.
|
| Corruption that can then be used to subvert the behaviour
| of functions being called.
| flohofwoe wrote:
| WASI could be extended by "media APIs" to communicate with a
| host platform window system, rendering- and audio-API. The
| only question is "where to stop?", because at the end of that
| road lies a complete browser runtime (I still think it makes
| sense to extend WASI with a small number of media APIs
| though).
| follower wrote:
| While a "host" application (for the WASM runtime used) is
| required to enable access to graphical output (or user input)
| it doesn't _have_ to be a browser.
|
| At the (almost) most basic level a chunk of memory can be
| used as a framebuffer--the host application would read the
| pixel data which the WASM bytecode wrote and then write it to
| the host display via OS-level routines.
|
| There are some plans/experiments at making a framebuffer
| "device" available as part of WASI.
|
| I've written a couple of graphical WASM host applications
| that aren't browsers (and which don't use memory for pixel
| data transfer just integer values returned from a function):
|
| The "WebAssembly Calling Card (WACC) Viewer" is implemented
| via the Godot game engine and an addon that integrates the
| Wasmtime WASM runtime with the engine:
| https://wacc.rancidbacon.com
|
| (Also implemented a WACC Viewer in Rust:
| https://gitlab.com/RancidBacon/rusty-wacc-viewer)
|
| WACC specifies how to transform three integer values
| (returned from a function in a WASM module) into a coloured
| triangle in order to render it on screen.
|
| Another "host application" I implemented was a libretro
| compatible plugin that loads a WASM module and then feeds the
| module with input from libretro & retrieves framebuffer pixel
| data (one pixel at a time :D ) via a WASM function call &
| writes it to the libretro framebuffer for display.
| edgyquant wrote:
| You it be faster though? E.g. as a replacement for electron
| (please note I've never worked with electron so I'm using
| anecdata)
| imbnwa wrote:
| If I understand correctly, the consequence is that,
| Electron being a wrapper around a fully capable browser
| engine, Electron users are free to use WASM modules so long
| as they expose a JS interface to interact with Electron's
| API where neccessary but until WASM gets DOM bindings I
| presume that Electron itself won't use WASM to implement
| internal behavior.
| andrekandre wrote:
| does wasm support more than 1 program counter (more than 1
| virtual cpu?) or is it stuck in "single thread" model?
|
| if so, are there any plans to change that?
| magila wrote:
| With the current state of things WASM is if anything _more_
| interesting outside of the browser than in it. Having to shim
| through JS to interact with browser APIs makes interacting with
| the outside world sufficiently slow and cumbersome that WASM in
| the browser usually only makes sense if you have some large
| computation which requires little-to-no I /O.
|
| Outside of the browser you at least have a chance of interacting
| with the underlying APIs in a performant enough manner to enable
| a wide variety of applications.
| lcnmrn wrote:
| WASM is to Node what C/C++ extensions are to Python.
| [deleted]
| [deleted]
| tasogare wrote:
| Genuine question: What does it bring new to the table?
| follower wrote:
| For me, the most interesting potential of WASM is it provides
| a platform-independent sandboxed way to run untrusted code
| written in multiple programming languages.
|
| This means it's in theory possible to run the same code on an
| embedded hardware platform, a desktop app or in the browser.
|
| And while I'm sure there's "serious" business uses for that
| capability :) I'm most interested in what it enables in terms
| of user customisation/modding of games.
|
| Which was my main motivation for creating a Wasmtime WASM
| runtime add-on for the Godot game engine:
| https://gitlab.com/RancidBacon/godot-wasm-engine
|
| And also designing the "WebAssembly Calling Card"
| specification as a way of demonstrating how the same code
| could produce graphical output that is then used in 2D or 3D
| environments: https://wacc.rancidbacon.com
| jsd1982 wrote:
| This is exactly what I'm doing right now with SNES
| emulators, bsnes-plus specifically. The idea is to be able
| to extend certain games and give wasm module the ability to
| read/write the emulated memory and send/receive messages
| over a network connection to another process, among other
| things.
| still_grokking wrote:
| > This means it's in theory possible to run the same code
| on an embedded hardware platform, a desktop app or in the
| browser.
|
| Maybe want to talk to the Java guys, and ask them why this
| doesn't work out in practice? ;-)
|
| Just having a common byte-code interpreter isn't enough for
| portability of applications.
| wtetzner wrote:
| I think the main thing it brings is a portable compiler
| target that actually _stands a chance at being widely
| adopted_.
| GranularRecipe wrote:
| Solomon Hykes, author of Docker: If WASM+WASI existed in
| 2008, we wouldn't have needed to created Docker. That's how
| important it is. Webassembly on the server is the future of
| computing. A standardized system interface was the missing
| link. Let's hope WASI is up to the task! cf https://twitter.c
| om/solomonstre/status/1111004913222324225?l...
| junon wrote:
| This is strange. WASM can't handle half the things Docker
| needs to run. I'm genuinely confused as to how he can say
| the two are equivalent in any way, despite being the author
| of docker.
|
| VMs existed at the time. Java was one of them, probably the
| most prolific of them all, and certainly had a standardized
| system interface.
|
| Further WASI is a nightmare. Most projects I've personally
| seen disregard it completely.
| pjmlp wrote:
| He should have gone talk to Microsoft and learn about MSIL.
| nomaxx117 wrote:
| WASM has far more potential for serverless usage than it does in
| the browser.
|
| I think Cloudflare's Workers are a good example of where things
| might be going with the tech, but there is room for a lot more. I
| would love to see something like coroutines adopted for WASM that
| allow for asynchronous WASM computation.
| flohofwoe wrote:
| Coroutines are usually a language level construct (syntax sugar
| for a switch-case statemachine). Machine code doesn't have
| "coroutine support" either yet all languages with coroutine
| support run just fine on regular CPUs.
| nomaxx117 wrote:
| Coroutines are present at the language and runtime level.
| Most languages with coroutines have runtimes baked in that
| handle them behind the scenes (think of JS), but some (like
| Rust) require you to provide your own. Async executors are
| quite large in terms of code size, so I think it would be
| useful for WASM to expose a coroutine interface for compilers
| to target. I think that not having to ship your asynchronous
| runtime would be very beneficial.
| DaiPlusPlus wrote:
| > Machine code doesn't have "coroutine support" either yet
| all languages with coroutine support run just fine on regular
| CPUs.
|
| Yes and no.
|
| Some ISAs do have real "co-instructions" that would be
| executed concurrently to the "main" program, for example Lisp
| Machines use this approach for executing bounds-checking
| concurrently, as well as other kinds of validation/assertions
| (and even had a limited form of hardware time-travel to jump-
| back to before a co-processor exception occurred).
|
| This approach died out due to the complexity of
| implementation.
| rini17 wrote:
| Usually a syntax sugar? Not true, unless you give up ability
| to call function and switch/resume coroutine seamlessly
| inside it. You need the ability to manipulate call stack.
| Regular CPUs have no problem with that but wasm expressly
| disallows it. So any language with coroutines needs to avoid
| using wasm stack.
| cxr wrote:
| In many ways, WebAssembly was a poor choice in naming. I propose
| that "WASM" be retroactively associated with the phrase "world-
| wide assembly".
|
| (Serious proposal. Please consider adopting this in your own
| usage, even if informally; think of it as guerilla rebranding.)
| flohofwoe wrote:
| WASM isn't "assembly" either though but bytecode ;)
| krapp wrote:
| If we can accept Javascript as bytecode we can accept this as
| assembly...
| Grimm1 wrote:
| At the risk of stumbling into something terrible, who
| accepts Javascript as bytecode?
| krapp wrote:
| Javascript as bytecode (or Javascript as assembly) is a
| paradigm that comes from compile-to-js languages like
| Typescript and asm.js[0], considering such "compiled"
| javascript as equivalent to a universal bytecode. Here's
| an old HN thread about it [1,2] and if you look around
| you can find it being asserted[3] as often as
| criticised[4,5].
|
| Ironically, many of the arguments against the use of JS
| as bytecode just got transplanted into arguments against
| WASM, but one common argument against WASM is "why do we
| need this when we can already compile to javascript?"
|
| [0]https://news.ycombinator.com/item?id=5227274
|
| [1]https://www.hanselman.com/blog/javascript-is-web-
| assembly-la...
|
| [2]https://news.ycombinator.com/item?id=5762183
|
| [3]https://news.ycombinator.com/item?id=3708919
|
| [4]https://blog.izs.me/2011/09/javascript-is-not-web-
| assembly/
|
| [5]https://news.ycombinator.com/item?id=5469310
| Grimm1 wrote:
| Oh but that's not really bytecode is it? I'd say that's
| language transpilation. Which is a different topic, a
| contentious one for sure, but I don't think I'd qualify
| compiling down to another language as a form of bytecode,
| perhaps I'm splitting hairs though. My understanding is
| with bytecode that would then be read during execution on
| a vm or some such like Java, or Python bytecode during
| execution. JS is still a high level language which V8
| then turns into it's own type of bytecode before being
| able to execute it.
| krapp wrote:
| Yes, I would agree completely... but I've gotten into
| enough arguments about it on HN and been downvoted hard
| enough for disagreeing with the premise to know how
| seriously a lot of people take it.
| imbnwa wrote:
| IIRC V8 generates bytecode from the AST and compiles that
| bytecode
| junon wrote:
| That's an implementation detail.
| theta_d wrote:
| Yes but that is converting JavaScript to bytecode, not
| using JavaScript as bytecode.
| ridiculous_fish wrote:
| The Hermes JavaScript engine statically compiles JS to
| bytecode. https://github.com/facebook/hermes
| k__ wrote:
| But who does that?
|
| Serious question.
|
| I read it often, but besides minified JS, most "to js
| compilers" try to emit readable JS and I didn't have the
| impression that the goal of bytecode was to be readable.
| hardwaregeek wrote:
| Well it's fitting in that JavaScript is a pretty poor name too
| oblak wrote:
| serious question: what would wide WASM adoption mean for js
| developers? is my obsolescence imminent?
| brundolf wrote:
| Never pin your career to just one
| language/framework/technology; otherwise you'll become obsolete
| at some point no matter which one it is.
|
| That said: I don't think you need to worry about JS receding
| for at least another decade, maybe two.
| azakai wrote:
| While WebAssembly is better for some things than JS, for most
| code you run in a browser, it's no improvement and actually
| worse.
|
| When you _do_ need wasm, though, then it opens up entire new
| possibilities, things you really couldn 't do before. I like to
| compare wasm to the video element: not every site should use
| it, and it won't replace JS or CSS or HTML, but its existence
| makes things like YouTube and Netflix possible.
|
| The future of code on the web is JS + wasm.
| AkshitGarg wrote:
| WebAssembly in the browser currently can't manipulate the DOM
| directly. Neither can it make HTTP requests. You need to use a
| JS bridge to do that. That has some overhead. So I don't think
| webassembly will replace JavaScript anytime soon. It might be
| reserved for high-performance compute, or maybe canvas based
| rendering for the time being.
| runawaybottle wrote:
| I think the nail in the coffin will only happen when the DOM
| is killed. If someone can write a rendering engine in WASM
| that renders to canvas (maybe even render apps with webgl),
| then can just create a new api for browser apps.
|
| That'll be the end of frontend as we know it, and everyone
| will have to learn this new api. The benefits are obvious,
| we'll finally have a rendering engine for apps. I suppose
| document-based html pages can stick around, but the rest of
| us can move on.
| rini17 wrote:
| And it will be exactly as infuriating as Flash was (except
| for the artist). Change my mind.
| dccoolgai wrote:
| The "grant capabilities" model of WASI is such a "how did they
| not think of this before?" thing. I need to play around with it
| some more, but WASMtime, etc. is really fun.
| bryanrasmussen wrote:
| Capability Computation
| http://www.erights.org/elib/capability/index.html
___________________________________________________________________
(page generated 2021-08-08 23:01 UTC)