[HN Gopher] Introduction to WebAssembly Components
___________________________________________________________________
Introduction to WebAssembly Components
Author : pcr910303
Score : 94 points
Date : 2021-12-17 12:03 UTC (10 hours ago)
(HTM) web link (radu-matei.com)
(TXT) w3m dump (radu-matei.com)
| chaz6 wrote:
| I think this could be a massive step forward for computing.
| Imagine if you will an add-on ecosystem for image editors like
| Krita or video editors like KdenLive. Add-ons could be distruted
| as a single package and can be run anywhere regardless of the
| system architecture or software plugin architecture, even within
| web applications. Write once, run anywhere.
| [deleted]
| jcelerier wrote:
| i've been working on the "C++ API" side of this if you're
| interested :)
|
| - https://github.com/celtera/avendish
|
| - https://ossia.io/posts/reflection/
|
| coupled with the definition of a common ABI, the holy grail of
| reusability may start to be closer
| irq-1 wrote:
| Isn't the memory barrier a huge penalty? (WASM can only
| access it's own memory, never the hosts.) I've been thinking
| about how WebAssembly could work server side to host
| websites, but every step seems to be copy bytes into or out
| of the VM.
| PaulDavisThe1st wrote:
| > Write once, run anywhere
|
| Where have I heard this before ....
| kingcharles wrote:
| 1995 called; it wants its tag line back.
| iamricks wrote:
| I feel like Web Assembly is hard to understand if you don't have
| a background in systems programming.
|
| Coming from web dev what are some good resources to get me to a
| point where i can better bridge the gap?
|
| I just started learning Rust a few days ago (Doing adventofcode
| in Rust) but i don't really know what path to take to be able to
| build something useful with Web Assembly
| tyingq wrote:
| If you're coming from web dev, I would think of it as a
| "foreign function interface" from javascript. You're calling a
| function defined in some other language. Here's a function, in
| WAT format (Web Assembly Text), that returns the number 42:
| (module (func (result i32) (i32.const 42)
| ) (export "testfunction" (func 0)) )
|
| Go to https://mbebenita.github.io/WasmExplorer/ and paste that
| in the middle box, then click assemble, then download, and
| you'll have a local file called "test.wasm".
|
| Then, since you already do web dev, get that test.wasm file and
| a new page accessible from a local web server. The new page
| should have this in it: <script> //
| should log 42 to the console WebAssembly.instantiateStre
| aming(fetch('https://path/to/test.wasm')).then(prog => {
| console.log(prog.instance.exports.testfunction()); });
| </script>
|
| Everything else is facades, layers, and tools on top of that.
| But that should help clear up what's at the bottom from a web-
| dev/js perspective. And also what the "2 halves" are. One half
| being, in your case, that the Rust compiles down eventually to
| WASM that you host somewhere. The other half being that you
| need to be able to call into that generated code from your JS.
| TekMol wrote:
| This pretty much summarizes what a clusterfuck WebAssembly
| is.
|
| It should be possible to just paste the 6 wasm lines into a
| <script type=wasm> block. This is what made the web
| successful. Not having to have tooling to build things.
| todd3834 wrote:
| I understand where you are coming from and something like
| you just mentioned would be a nice feature. However, it
| does seem worth mentioning that most people are not going
| to want to write code in web assembly text format. The
| current tooling exists so you can load binary data which
| wouldn't embed well into a script tag. The primary use case
| is compiling code written in other languages that often
| have a runtime that comes with them. Because of that the
| payloads are often much larger than anything you would want
| in a script tag as well. There is also more to it than just
| loading a script. You get to have shared memory buffers and
| you have control over what to share between the JS and WASM
| env. This configuration is simplest with JS. It's a very
| small amount of code to load WASM and configure these
| things.
|
| If web assembly text format was just a more performant
| scripting language then I'd go with your proposal. Since it
| is meant to be a visual representation of WASM binary
| format and that binary code is more useful when it can be
| configured, I don't mind the current implementation.
| tyingq wrote:
| Yeah. You can use a base64 data uri, but that's not great
| either. There is a proposal for <script type="module">, but
| it looks untouched for several years:
| https://github.com/WebAssembly/proposals/issues/12
| pjmlp wrote:
| It is basically the same thing as JVM or CLR (specially in
| regards to the CLR), just with more marketing appeal.
| tyingq wrote:
| I think that's one of the things that confuses people. WASM
| is, in some respects, very similar to ASM. In other respects,
| it's very similar to a language VM, but has a name that makes
| that non-obvious. Will likely get more confusing as they add
| things that normal ASM doesn't do, like GC, direct JS call
| interop, more data types, etc.
| pjmlp wrote:
| I think that what actually confuses people is presenting
| WASM as something completely new, without even briefly
| discussing all the kinds of approaches to polyglot bytecode
| formats since the early 1960's.
|
| So those not versed into the matter fail to understand the
| overall picture as it isn't given to them.
| moron4hire wrote:
| I found going through the AssemblyScript setup and tutorials
| really helped me understand WASM without first having to wrap
| my head around C++ or Rust toolchains. AssemblyScript is a
| TypeScript dialect that compiles to WASM instead of JavaScript:
| https://www.assemblyscript.org/
|
| What I find really interesting about AssemblyScript is the
| potential for homographic code between JS and WASM. I'd prefer
| to see languages like AssemblyScript that are designed for WASM
| first, rather than shoe-horning existing languages like
| C++--and thus, their existing library ecosystems--into WASM.
| Yes, there is a lot of extant code that people are interested
| in porting, but that's not the end of the world and I'm not too
| keen on the bloat it creates or having to debug the teetering
| tower of tools that it represents if some impedence mismatch
| causes problems along the way.
|
| With homographic AssemblyScript and TypeScript, I start to
| imagine a time when you can run an app on your phone, serialize
| the whole state of it, push it off to another user or your PC
| or something, and pick up where you left off. Maybe you'd do it
| for more compute power. Maybe you'd do it to share state on a
| collaboration. I don't know. But it's a fascinating idea that
| I'd really like to see one day.
| todd3834 wrote:
| I found the book The Art Of Web Assembly [1] to really help me
| understand it better. A lot of other books seem to focus on a
| specific part of the tool chain. This one shows you all of the
| examples in web assembly text language. While I wouldn't want
| to write a program in it, reading it with the context provided
| by the author really helped me understand what is going on. It
| also helped me understand why so many things are the way they
| are in the current iteration of the WASM world.
|
| [1]https://www.amazon.com/dp/1718501447
| rikroots wrote:
| I had a look at both WebAssembly and Rust a few months back, in
| the hope they could help me write some nice, fast graphics
| filters that I could then compile out and use via Wasm in a 2d
| canvas. Entirely do-able, but beyond my limits of understanding
| and patience.
|
| Since then, I've stuck with what I know (Javascript) and
| branched instead into consuming Wasm written by others (in
| whatever language) on the frontend for my own experiments - for
| instance Rapier[1] which is a physics engine written in Rust,
| and some of the MediaPipe ML models[2].
|
| [1] - Rapier getting started page -
| https://rapier.rs/docs/user_guides/javascript/getting_starte...
|
| [2] - MediaPipe face mesh model getting started page -
| https://google.github.io/mediapipe/solutions/face_mesh#javas...
| pjmlp wrote:
| You are better off learning WebGL and Houdini for that.
| meheleventyone wrote:
| Rust has probably the most batteries included, with
| explanation, of most of the languages that compile to WASM
| right now. It has a lot of tooling that takes some of the
| underlying pain out of interfacing with JS. There's even an
| online guide for it:
|
| https://rustwasm.github.io/book/
| LeanderK wrote:
| isn't webassemly just a compile-target? Like JVM-bytecode or
| real x86 assembly?
|
| If so, then you are not really supposed to understand web
| assembly. Just like x86 assembly it's just what your language,
| like rust, compiles to. If you want to understand it, then I
| suppose it's hard unless you have a background in systems
| programming since it's so low-level. It's the nature of the
| game and web-dev is quite removed from low-level coding.
|
| I don't have an experience with web assembly, it's just how I
| understood the concept.
| krona wrote:
| Webassembly is like a virtual machine without any standard
| library but permits custom embedders. As you could imagine
| that makes it limiting and is in part what things like WASI
| and Webassembly Components are trying to address.
| mrkentutbabi wrote:
| You can use AssemblyScript instead of Rust
| galangalalgol wrote:
| If it helps, I have a couple decades experience as a systems
| programmer and I find it hard to understand how to interface my
| code with JS. Web dev with its constantly shifting frameworks
| is baffling to me.
| pjmlp wrote:
| Components in bytecode format with support for C++, where have I
| seen it?
|
| https://docs.microsoft.com/en-us/dotnet/standard/clr
|
| https://docs.microsoft.com/en-us/cpp/dotnet/dotnet-programmi...
| DonHopkins wrote:
| Oh it goes a lot further back than that!
|
| https://news.ycombinator.com/item?id=29593432
| pjmlp wrote:
| Indeed, very nice overview.
| DonHopkins wrote:
| Earlier I posted an article by Don Box comparing SOM and COM, and
| I mentioned that WebAssembly is going through a similar
| evolution, and might benefit from some of the lessons of COM and
| SOM:
|
| COM vs SOM: The Component Object Model and Some Other Model
| (1999) (archive.org)
|
| https://web.archive.org/web/19990127184653/http://www.develo...
|
| https://news.ycombinator.com/item?id=20266450
|
| https://news.ycombinator.com/item?id=20266627
|
| >DonHopkins on June 24, 2019 | prev | next [-]
|
| >This article comparing SOM and COM was written by Don Box.
| (first archived in January 1999, but doesn't say when published):
| The Component Object Model and Some Other Model: A comparison of
| technologies revisited yet again:
|
| https://web.archive.org/web/19990127184653/http://www.develo...
|
| https://en.wikipedia.org/wiki/Component_Object_Model
|
| >It was in response to IBM's somewhat misleading article
| comparing their SOM with Microsoft COM, last updated July 1994:
|
| >The System Object Model (SOM) and the Component Object Model
| (COM): A comparison of technologies summarized
|
| https://web.archive.org/web/19990117055950/http://www.develo...
|
| https://en.wikipedia.org/wiki/IBM_System_Object_Model
|
| >Don Box wrote an excellent in-depth book about COM: "Essential
| COM": "Nobody explains COM better than Don Box" -Charlie Kindel,
| COM Guy, Microsoft Corporation.
|
| https://en.wikipedia.org/wiki/Don_Box
|
| https://archive.org/details/essentialcom00boxd
|
| >Unfortunately COM had the most un-googlable name possible (even
| before there was a Google), so Microsoft renamed it ActiveX.
|
| >For more comtext, here are some notes I wrote about Win32, COM,
| OLE, OLE Controls, and ActiveX in 1996:
|
| https://donhopkins.com/home/interval/pluggers/win32.html
|
| https://donhopkins.com/home/interval/pluggers/com.html
|
| https://donhopkins.com/home/interval/pluggers/ole.html
|
| https://donhopkins.com/home/interval/pluggers/olecontrols.ht...
|
| https://donhopkins.com/home/interval/pluggers/activex.html
|
| >Here's a synopsis of COM I wrote in response to "Can someone
| link to a synopsis describing what "COM" is? It's hard to search
| for. (e.g. microsoft com visual studio)":
|
| https://news.ycombinator.com/item?id=12975257
|
| >Don't get me wrong: I'm not advocating everybody jump on the COM
| bandwagon! I just think it's interesting and useful to know where
| it came from, how it evolved, what different layers were built on
| top of it, and how it compared to the alternatives at the time it
| was designed. And it's still pretty widely used, and will
| probably never go away.
|
| >It certainly had a lot of problems and limitations, and
| OLE/ActiveX/DCOM/DirectX/etc took it way too far, then Mozilla
| XP/COM cloned it and also took it way too far (and then back
| again: see "decomification" and "decomtamination"), but it really
| was a pretty elegant and successful solution to the problems it
| was designed to address at the time.
|
| https://wiki.mozilla.org/Gecko:DeCOMtamination
|
| https://news.ycombinator.com/item?id=12968830
|
| https://bugzilla.mozilla.org/buglist.cgi?query_format=specif...
|
| >It's always good to study history to avoid repeating the
| mistakes of the past!
|
| >WebAssembly is going through a similar evolution, and might
| benefit from some of the lessons of COM and SOM.
|
| Also, here's a description of the origins of COM that I posted
| earlier:
|
| https://news.ycombinator.com/item?id=12975257
|
| >Glad you asked! One of my favorite topics. ;)
|
| >COM is essentially a formal way of using C++ vtables [1] from C
| and other languages, so you can create and consume components in
| any language, and call back and forth between them. It's a way of
| expressing a rational subset of how C++ classes work and format
| in memory, in a way that can be implemented in other languages.
|
| >It was the outcome of the C / C++ / Visual Basic language wars
| at Microsoft.
|
| >[...]
|
| Also some stuff about Netscape's Internet Foundation Classes:
|
| https://news.ycombinator.com/item?id=19837817
|
| >Wow, a blast from the past! 1996, what a year that was.
|
| >Sun was freaking out about Microsoft, and announced Java Beans
| as their vaporware "alternative" to ActiveX. JavaScript had just
| come onto the scene, then Netscape announced they were going to
| reimplement Navigator in Java, so they dove into the deep end and
| came up with IFC, which designed by NeXTStep programmers. A bunch
| of the original Java team left Sun and formed Marima, and
| developed the Castanet network push distribution system, and the
| Bongo user interface editor (like HyperCard for Java, calling the
| Java compiler incrementally to support dynamic script editing).
|
| >[...]
|
| There was also a previous discussion about Mozilla's WebAsembly
| System Interface:
|
| Mozilla announces WebAssembly System Interface, what JVM should
| have been (theregister.co.uk):
|
| https://news.ycombinator.com/item?id=19716179
|
| https://www.theregister.com/2019/03/29/mozilla_wasi_spec/
|
| https://news.ycombinator.com/item?id=19717416
|
| >DonHopkins on April 22, 2019 | parent | context | favorite | on:
| Mozilla announces WebAssembly System Interface, wh...
|
| >>"WebAssembly has been designed to scale from tiny devices to
| large server farms or CDNs..." What's ironic is that the "tiny
| devices" and even "high end professional desktop workstation and
| server devices" that Java was originally designed to run on when
| it was started in 1990 were MUCH tinier than the devices
| considered "tiny" today.
|
| >How many more times faster is a typical smartphone today
| (Raspberry Pi 3: 2,451 MIPS, ARM Cortex A73: 71,120 MIPS) that a
| 1990 SparcStation 2 pizzabox (28.5 MIPS, $15,000-$27,000)?
|
| http://www.wikiwand.com/en/Instructions_per_second
| matei_radu wrote:
| This is an excellent collection of SOM/COM resources, thanks a
| lot for that!
|
| Perhaps not surprising, but COM/DCOM has been a recurring
| reference when talking about the WebAssembly component model.
| Another useful resource from the past that influenced quite a
| few Wasm component discussions (h/t to Luke Wagner for sharing
| it) is one about Knit [1], which as intended as a _component
| definition and linking language_ for C.
|
| [1]: https://www.cs.utah.edu/flux/papers/knit-osdi00/
| sarahmike wrote:
| For all of dads and moms that love to stay home to take care of
| their loved ones, or rest of people on the search for an
| opportunity to pull in some extra income for their family month
| after month let me share a remarkable opportunity to explore.
| HERE ------ www.foxofficial1.com
| sarahmike wrote:
| I m making over 9-k dollars a month working part time. I kept
| hearing other people tell me how much money they can make online
| so I decided to look into it. Well, it was all true and has
| totally changed my life.. :) GOOD LUCK.:) <(") <(") HERE O---->>>
| foxofficial1.com
| matei_radu wrote:
| Hi, author of the article here. Happy to have a discussion about
| the WebAssembly component model and current implementations.
| PaulDavisThe1st wrote:
| So ... the Java model was: * define a VM, but
| not offer a public direct API * define a language that
| could be interpreted, compiled or JIT-compiled to the VM
| * implement the VM so that it could run standalone or in
| browsers * claim "write once, run anywhere"
|
| The WASM model appears to be almost identical, with the
| addition of: * offer compilation/translation
| from common existing languages
|
| Why should we prefer the WASM/WASI model to Java? Why should we
| believe it will be more successful?
|
| And perhaps more deeply, re-wrapping system APIs (e.g. POSIX)
| in WASM-specific modules seems incredibly time-inefficient (all
| those commitees, all that reimplemenation...). What if anything
| is going to be done to provide WASM/WASI with direct system
| access (outside the browser) ?
| panic wrote:
| If you could Applet.instantiate() as easily as
| WebAssembly.instantiate() and have Java methods immediately
| available from JavaScript, I have no doubt that it would be
| as successful as WASM is. The advantage of WASM is that it's
| already integrated with JavaScript VMs in a way that Java
| never was. Though I suppose it's possible if someone wants to
| get V8 running JVM bytecode!
| PaulDavisThe1st wrote:
| So your argument there is "well, I can access WASM from
| javascript more easily that I could access Java" ? That's
| it?
| panic wrote:
| Yes--in most cases the technology itself doesn't matter
| as much as how it can be deployed. The popularity of
| JavaScript itself is testament to that (though the
| technology has caught up quite a bit there).
| pjmlp wrote:
| Except it actually was, as there was an interop API for
| applets to interact with DOM and vice-versa.
| panic wrote:
| You're right, and not just the DOM: https://docs.oracle.c
| om/javase/tutorial/deployment/applet/in...
|
| Maybe the real reason has to do with security, then? That
| was the justification for removing Java support from
| browsers, leaving the door open for WASM to take its
| place.
| pjmlp wrote:
| Politics,
|
| https://en.m.wikipedia.org/wiki/Google_Native_Client
|
| https://adobe-flash.github.io/crossbridge/
|
| https://www.usenix.org/conference/usenixsecurity20/presen
| tat...
| pjmlp wrote:
| CLR and IBM TIMI already offered that one, among others older
| than Java.
| bno1 wrote:
| I get what components are supposed to do, but how does wasm
| currently talk with the browser and javascript code? Can it
| manipulate the DOM and execute asynchronously (like promises)
| or is it just a black box that receives some data and returns
| other data synchronously?
| matei_radu wrote:
| By default, a WebAssembly module has no access to any host
| APIs -- particularized for the web platform, a running module
| will have no way of accessing the DOM by default.
|
| When instantiating a module, it can use module imports [1],
| which can be used to access the DOM through JavaScript calls.
|
| [1]: https://webassembly.github.io/spec/core/syntax/modules.h
| tml#...
| The_rationalist wrote:
| It's time to admit webassembly is a mistake and that GraalVM is
| an order of magnitudes superior technology and browser
| developers shouldn't have to make humanity suffer for eternity
| because of NIH syndrome and technical mediocrity.
| panic wrote:
| WebAssembly's type system supports just a handful of numeric
| types and opaque external reference types. How does WIT map its
| richer type system (which includes things like strings and
| records) onto these underlying types in a language-agnostic
| way?
| pjmlp wrote:
| I guess they will need to rediscover the Common Language
| Subset of the Common Language Runtime and re-sell it as an
| invention.
| Asraelite wrote:
| From what I've seen of wit (called "witx" back when I last used
| it) it seems to be pretty skewed towards using Rust as
| inspiration for its design, even though it's meant to be language
| agnostic. The syntax is not far off from being a one-to-one copy
| of Rust.
|
| Some examples: `foo: bar` for type annotations, `->` for return
| types, `enum { a, b }` for C-style enums, `variant { a(b, c) }`
| for tagged unions, `type a = b` for type aliases, `_` for
| placeholder types. Its implementation of WASI even uses `->
| expected<_, errno>` for most of its return signatures, imitating
| Rust's Result.
|
| I really like Rust's type system and syntax, and none of these
| design decisions are bad in their own right, I just get the
| impression that other language communities are not having enough
| influence in the design of WebAssembly compared to Rust.
| matei_radu wrote:
| I think that is a really valid observation, and I would like to
| point out a couple of things:
|
| - the WIT language decisions will end up impacting people
| writing WIT syntax by hand. I am not sure how large that
| audience is right now (and I am not dismissing the initial
| comment), but I really hope we could get good enough tooling
| that could directly generate WIT (in its eventual binary
| format) based on annotated source code.
|
| - an equally valid observation here is that we need people from
| multiple programming languages looking at generating _idiomatic
| bindings_ based on the WIT format, which is what end users will
| interact with when using components. (Currently there are
| binding generators for Rust and C/C++, with hopefully Grain
| following soon enough.)
| dcode wrote:
| AssemblyScript maintainer here. Can confirm, other language
| communities have practically zero influence on the design. In
| fact, AS was present during "specification" and has been
| completely annihilated for disagreeing with what the chairing
| majority has come up with there. It's particularly ironic that
| the Component Model suddenly targets Web integration again, or
| that this is now coined "language neutral". In relation, the
| syntax is more of a minor detail.
___________________________________________________________________
(page generated 2021-12-17 23:02 UTC)