[HN Gopher] Missing the Point of WebAssembly
___________________________________________________________________
Missing the Point of WebAssembly
Author : ryukafalz
Score : 100 points
Date : 2024-01-09 16:25 UTC (6 hours ago)
(HTM) web link (wingolog.org)
(TXT) w3m dump (wingolog.org)
| gwbas1c wrote:
| _WebAssembly allows you to program web pages in a language other
| than Javascript._
|
| The above statement might gloss over a lot of very important
| details: But that mindset also misses the point: The critical use
| case of WebAssembly, and the problem it attempted to solve, right
| now, is to creating a webpage in a language other than
| JavaScript.
|
| Everything else that the article mentions is an impressive feat
| on its own, but what WebAssembly _could do_ is very different
| than _what it does now._ And the fact that now you can program a
| website in a language other than Javascript (or TypeScript) is a
| very tangible accomplishment that people who aren 't enamored
| with computer science can appreciate, understand, and repeat.
| bryanlarsen wrote:
| There are many places that have been using WASM for purposes
| similar to the ones in the article for quite a while now. For
| example, Cloudflare workers have been using WASM for a year and
| a half.
| steveklabnik wrote:
| Workers has supported WASM since 2018:
| https://blog.cloudflare.com/webassembly-on-cloudflare-
| worker...
| jauntywundrkind wrote:
| I'm both excited about cross-language but also I think the
| people you describe as potential beneficiaries are those most
| apt to suffer under the new (anti-)regime.
|
| > _And the fact that now you can program a website in a
| language other than Javascript (or TypeScript) is a very
| tangible accomplishment that people who aren 't enamored with
| computer science can appreciate, understand, and repeat._
|
| Industrial software dev has resulted in gross difficult
| minified bundles & absurdities like vdom that are hard to view-
| source hack. But there's pretty ok un-minifying & it's
| surprisingly possible to get really far, if a user wants to
| seize the power & do some userscripting.
|
| And many in the webdev world have steadily been trying to push
| back against this rampant industrialization. HTTP2 and ESM were
| hopefully going to make unbundling more viable, but that's
| still long suffering (ex: import-maps don't work for workers,
| https://github.com/WICG/import-maps/issues/2), and now that the
| http cache doesn't work cross-site many of the possible re-use
| upsides are dead. Still a goal for many though. WebComponents
| is still a vast un-frameworking potential; in many
| implementations it unravels the descent into abstraction that
| React framework begat. Classic web devs have a lot of heart to
| make the web pro-user, to un-framework things, but the
| industrial demands are hard to re-satisfy on these better paths
| & so much momentum is elsewhere.
|
| Now compare to the wasm world. We have basically pure machine
| code running our web in wasm. It's utterly unintelligible.
| There's dozens of hundred of kb libraries that languages bring
| in to userland just to do the language thing. I think people
| will have an _incredibly poor_ time learning the web, think the
| worst risk wasm has is in scaring people off from view-source,
| from casually observing & learning anything. Wasm is god
| smiting the tower of Babel, is a one language breaking & being
| cast down & a hundred different tribes speaking their own
| language. So much good will come from this diversity, we'll see
| so many different styles & tries from so many camps, and that
| will be a benefit, but it will in my view be drastically harder
| for those _" who aren't enamored with computer science can
| appreciate, understand, and repeat."_ Intelligibility is the
| loser, when Babel falls.
| gwbas1c wrote:
| > We have basically pure machine code running our web in
| wasm. It's utterly unintelligible.
|
| Whenever technology changes there's always an argument
| against the new thing.
|
| In this case, I don't think that argument has merit. We've
| been running various flavors of compiled code since (almost)
| the beginning of computers, and the merits and drawbacks of
| that approach are well understood.
| jauntywundrkind wrote:
| The web has been distinct & unique & closer to "the
| language of the gods" for being much better, more pro-user
| than the old industrial-computing compiled ways. Many
| webdevs got their start from view-source (and many would
| have been lost to computing if we were just another
| compiled blackbox). The aliveness of the web contrasts to
| the dead programming variety. The erosion of this aliveness
| & legibility has been mourned, and should be. It is worth
| _fighting for the user._
|
| I don't think your argument has merit, that merits can be
| ignored because this is how computers always used to be.
| Wasm's return to the dark times of industrialized blackbox
| computing will cut off the best users from the joy of being
| closer to the machine that they had on the web, and that
| return to darkness is a sad plight for mankind, even if
| that's how it always used to be. I treasure the light of
| the open alive web, and hope somehow it can survive this
| voyage into shadow.
| ryukafalz wrote:
| We can and should provide a "view source" equivalent for
| native code as well. Package managers like Guix that know
| where to find the source and how to build it are a good
| step forward there.
|
| Text formats can be minified and obfuscated, binary
| formats can include mechanisms to see and experiment with
| the source. It's all about the tooling you have, what
| that tooling makes easy, and what it makes hard.
| kccqzy wrote:
| I'd argue that's actually besides the point. Before WebAssembly
| there were plenty of good ways to write web apps in a language
| other than JavaScript. Some for example integrate it into the
| language tooling (like ClojureScript which I have used and have
| fond memories of), some simply directly used asm.js (which I
| have also used).
|
| So if the only use case of WebAssembly is to enable that, it is
| an utterly unexciting piece of incremental improvement.
|
| Everything that's exciting about WebAssembly comes from where
| it can be used besides replacing JavaScript in a browser. It's
| a point I've repeatedly argued on this forum since two years
| ago (see https://news.ycombinator.com/item?id=30156799 and
| https://news.ycombinator.com/item?id=38138739)
| trgn wrote:
| Maybe we're just splitting hairs on what it means to be "a
| webpage", but I feel like people are _not_ writing webpages in
| WebAssembly. Instead, you get video games, interactive
| animations, photo editing apps, ... Basically, desktop-app like
| things, but generally without a DOM, without CSS. The look and
| feel diverges quite strongly, a user kind of intuits they're no
| longer in a regular web-app.
|
| To my frustration, WebAssembly is not replacing JS/TS and it's
| abominable toolchains, it ends up delivering a new suite of
| experiences, by adding another layer of abominable toolchains.
|
| There's also low level "helper"-libraries getting developed in
| WASM, e.g. a database implementation, but wondering if that
| ever takes off, managing bindings is rough and library
| size/bootstrapping can end up bloated. And it certainly does't
| get us out of JS/TS-dev land.
| davexunit wrote:
| Wasm GC makes it much more practical to write DOM-based web
| applications now. I think we'll start to see more examples of
| them now that Chrome and Firefox are both shipping Wasm GC in
| stable releases.
| neilalexander wrote:
| It is strange to me to see so much talk about all of the places
| WebAssembly could live, like IoT devices and edge lambdas and
| cross-architecture binaries, places that don't really need these
| problems to be solved, and yet so little talk about whether or
| not it can finally unshackle the web from the mess that is
| JavaScript. As I understand it, it's not even really possible
| today to make WebAssembly do anything meaningful in the browser
| without trampolining back out to JavaScript anyway, which seems
| like a remarkable missed opportunity.
| danielvaughn wrote:
| It can perform a lot of computational work, but yeah it can't
| yet interface directly with the DOM. I'm not sure about whether
| it can access the network or other things, but I don't believe
| that it can.
| edgyquant wrote:
| Are there plans to add DOM support? That seems pretty
| critical for what I had thought wasm was supposed to be
| myself.
| danielvaughn wrote:
| I'm not sure. All I know is that there are some hurdles to
| get past. One of them is that several DOM APIs were created
| specifically for JavaScript, which is...really
| disheartening.
| davexunit wrote:
| Wasm allows for importing host functions. Those host
| functions could provide DOM access. With Wasm GC it is
| possible to pass external references (DOM nodes, promises,
| etc.) to and from Wasm. What this looks like in practice is
| that a thin JS bootstrap script instantiates the Wasm
| module, passing along a set of JS functions that map to the
| declared Wasm imports and then the program is effectively
| driven from Wasm at that point.
| ryukafalz wrote:
| > but yeah it can't yet interface directly with the DOM
|
| The Spritely folks are doing DOM manipulation from Scheme in
| Wasm, is there something beyond this that you're referring
| to? https://spritely.institute/news/building-interactive-web-
| pag...
| steveklabnik wrote:
| When people say "can't yet interface directly with the
| DOM," the "directly" is the key bit. Projects in
| webassembly have been able to interact with the DOM
| forever, but they need to do it via JavaScript shims. I am
| not intimately familiar with Spritely, but from reading the
| post briefly, it appears this is exactly what they're
| doing: Scheme.load_main("hello.wasm", {}, {
| document: { body() { return document.body; },
| createTextNode:
| Document.prototype.createTextNode.bind(document)
|
| This requires boilerplate and adds overhead that would not
| exist if it were able to be done "directly."
| davexunit wrote:
| I suspect as time goes on we'll see more and more of this
| become direct through optimization. My understanding is
| that this already happens for certain well-known methods,
| like if you import Math.sin or something V8 is going to
| optimize it to a direct call when it compiles the Wasm
| module that imports it. And maybe a non-JS interface will
| emerge, but there needs to be some kind of layer that
| preserves capability security. You wouldn't want any and
| every Wasm module to have access to the entire browser
| API. You will still want the ability to omit
| capabilities, attenuate them, etc. and for that a full
| programming language seems necessary and well... JS is
| already there.
| jauntywundrkind wrote:
| While I don't necessarily agree with the unnecessary,
| unsupported, casual, & cheap (provided with zero
| substantiating/contestable support) contempt culture here ( _"
| unshackle the web from the mess that is JavaScript"_, _" places
| that don't really need these problems to be solved"_)...
|
| WebAssembly _component-model_ is being developed to allow
| referring to and passing complex objects between different
| modules and the outside world, by establishing WebAssembly
| Interface Types (WIT). It 's basically a ABI layer for wasm.
| This is a pre-requisite for host-object bridging, bringing in
| things like DOM elements.
|
| Long running effort, but it's hard work and there's just not
| that many hands available for this deep work. Some assorted
| links with more: https://github.com/WebAssembly/component-model
| https://www.fermyon.com/blog/webassembly-component-model
| https://thenewstack.io/can-webassembly-get-its-act-together-...
|
| A preview-2 should be arriving sometime somewhat soon.
|
| It's just hard work. It's happening. And I think the advantages
| Andy talks to here illuminate very real reasons why this tech
| can be useful broadly. The ability to have plugins to a system
| that can be safely sandboxed is a huge win. That it's in any
| language allows much wider ecosystem of interests to
| participate, versus everyone interested in extending your work
| also having to be a java or c++ or rust developer.
| davexunit wrote:
| The type system introduced in Wasm GC allows sharing data
| between the host and other modules and is usable right now.
| DOM access is possible and being demonstrated in several
| language implementations.
| singularity2001 wrote:
| are you sure? the last time I checked JavaScript was NOT
| able to access Wasm/GC objects
| paroneayea wrote:
| Yes, we have made use of JS invoking WASM-GC managed
| Scheme objects in our Hoot demos at Spritely.
| singularity2001 wrote:
| In Chrome 120 I still get:
|
| TypeError: WebAssembly objects are opaque
|
| When trying to read/write WASM-GC objects in JS.
| schemescape wrote:
| I saw you mention this in a previous post, but I can't find
| an example. Do you have one handy? What are the
| limitations?
|
| Edit: is this it?
| https://www.spritely.institute/news/building-interactive-
| web...
|
| Edit again: apparently I _had_ seen this before, since I
| upvoted its HN submission. Oops!
| https://news.ycombinator.com/item?id=38477602
| davexunit wrote:
| Yup, that's one of the examples! And here's another:
| https://spritely.institute/news/scheme-in-scheme-on-wasm-
| in-...
| titzer wrote:
| Wasm modules have been able traffic in (opaque) host
| references since the reference-types proposal landed
| several years back.
| davexunit wrote:
| But GC ref types have made it practical.
| evrimoztamur wrote:
| Yep, we are still generating bindings, but I don't think that's
| going to change anytime soon. WebAssembly to JavaScript is what
| the C ABI is to Python, with an additional bounce back to
| JavaScript land.
| CharlesW wrote:
| Wasm isn't a replacement for JavaScript. I think it's clever to
| leverage JavaScript as an interface to an ever-changing and
| extremely broad suite of native browser APIs, and keep Wasm
| small, fast, and secure.
| josephg wrote:
| > Wasm isn't a replacement for JavaScript
|
| I think a lot of people want it to be a replacement for
| JavaScript. And I think that makes sense, if for no other
| reason than learning JavaScript is a hassle. Lots of folks
| think of themselves as a C# developer, or a Python developer
| or whatever. A lot of developers would rather make websites
| in their language of choice than learn JavaScript. (And who
| can blame them?). Webassembly (with GC bindings) should be
| able to make that possible.
| JoshTriplett wrote:
| Indeed. node.js was popular in part because you can use the
| same language on the client and the server. All-WebAssembly
| no-JavaScript sites would allow the same thing with other
| languages.
| bmoxb wrote:
| Learning new languages may be component of it, but I think
| more generally, different languages are suitable for
| different problems and different developers. Being free to
| use the most suitable or preferred tool for a task is
| undoubtedly desirable, rather than having JavaScript as the
| only option.
|
| And, while more of a personal opinion, JavaScript is not a
| well designed language - permanently shackling the web to
| it prevents progress forward.
| ern wrote:
| As much as many people want alternatives to JavaScript,
| there are also people who consider themselves JavaScript
| experts (or the various related languages like TypeScript).
| They've invested a ton of time and effort into getting to
| where they are.
|
| There's a balance between disruptive change and keeping
| these folks on board. Get it wrong and you'll end up with
| it strangled in its cradle.
|
| My own take is that low-code platforms will continue
| aggressively moving into this space, especially in the
| enterprise space. They come with their own problems and are
| often aggressively overhyped, but they will put pressure on
| "traditional" developers to move faster and look for better
| solutions.
| holoduke wrote:
| How can a language be a mess? I hear lots of personal
| frustrations. But saying a language is a mess is too short
| sighted I believe.
| solardev wrote:
| Correct me if I'm wrong, but aren't most languages designed
| and controlled by some relatively centralized organization,
| whether a company or a nonprofit?
|
| Javascript, on the other hand, is a loose standard that
| different companies kinda sorta adhere to. It was a rushed
| one man project put out to compete with Java back in the 90s,
| then every browser tried to do their own somewhat compatible
| implementation. Javascript became the lowest common
| denominator, winning out not because it was better than say
| Java or ActiveX or Flash or whatever. It was just commonly
| available.
|
| Fast forward a couple decades, the situation is both better
| and worse. We at least have ECMAScript now, and the core
| language has certainly gotten better and more dev-friendly.
|
| Unfortunately, what ECMAScript covers is so limited and the
| standard lib is still so poor that lodash and similar are
| common just for basic data manipulation, not to mention the
| hundred DOM abstractions like React or Vue or Svelte, and
| occasionally Angular. And client-side state is its own
| nightmare, and then persisting things into
| cookies/localstorage/indexedDB is a whole other can of worms,
| along with different ways to do pub sub. Being tethered to
| file-based HTTP and HTML means that even basic routing is a
| hack on top of a hack.
|
| There is no standard package manager, and npm is a third
| party project, which can't agree on which module format to
| use. Libs from like 2 or 3 years ago will often be
| incompatible with new code.
|
| And that's just assuming you're using a browser. Outside of
| that there's not even a standard runtime, between Node, Deno,
| Bun, etc.
|
| Typescript is yet another third party add on, not something
| baked into the language.
|
| Eslint, prettier, etc. are all third party things.
|
| In the old days a lot of this used to just be baked into the
| language itself, or at least an official IDE . If you ever
| had a chance to use Visual Studio (Not VSCode) in the old
| days, everything was so well designed and integrated, from
| code organization to the standard libs to the UI editor.
|
| Nowadays there's 300 ways from 200 companies to do anything
| in Javascript, none of it particularly good or secure or
| performant or easy to read.
|
| In a way it's natural selection, I guess, with different
| implementations all competing for supremacy, but it
| definitely is messy. Every time I use JS (which is every
| workday) I can't help but wish some other, more coherent,
| language won out.
| gear54rus wrote:
| That's exactly what makes it powerful and ensures it's
| bright future. It is not controlled by one entity and non-
| working approaches die out by themselves and there's
| constant innovation. Calling that a mess is just personal
| problems.
| stevage wrote:
| These are...weird criticisms. You basically seem to wish
| you were coding within a monopoly, for a single platform
| controlled by a single corporation. Perhaps Swift is where
| you would like to be?
|
| JavaScript does incredibly well for the constraints it
| operates within. The fact that Node and Deno etc even exist
| is pretty remarkable given the primary purpose of JS.
|
| The fact we even have ES modules is in large part because
| the third party NPM worked so well. Things start out messy
| then they gain traction and get standardised. JS isn't a
| loose standard at all, it's incredibly well defined, and
| few of its original Netscape origins really remain.
|
| You have a bit of a point about TypeScript. It'd definitely
| be nicer if this was part of the language and didn't
| require so much third party tooling. It seems plausible
| that this too might happen in a few years. Perhaps browsers
| will gain first class support for it.
| steveklabnik wrote:
| > aren't most languages designed and controlled by some
| relatively centralized organization, whether a company or a
| nonprofit?
|
| This is a relatively recent development in programming
| languages. For example, your next sentence:
|
| > Javascript, on the other hand, is a loose standard that
| different companies kinda sorta adhere to.
|
| This could also describe the history of C. For example,
| let's look at the rationale document for the first
| standardization of C: https://www.open-
| std.org/jtc1/sc22/wg14/www/docs/n802.pdf
|
| I apologize in advance for quoting at length, but I could
| not decide what should be cut.
|
| ---------------------
|
| The X3J11 Committee represents a cross-section of the C
| community: it consists of about fifty active members
| representing hardware manufacturers, vendors of compilers
| and other software development 10 tools, software
| designers, consultants, academics, authors, applications
| programmers, and others.
|
| <snip>
|
| The Committee's overall goal was to develop a clear,
| consistent, and unambiguous Standard for the C programming
| language which codifies the common, existing definition of
| C and which promotes the portability of user programs
| across C language environments.
|
| The X3J11 charter clearly mandates the Committee to codify
| common existing practice. The Committee has held fast to
| precedent wherever this was clear and unambiguous. The vast
| majority of the language defined by the Standard is
| precisely the same as is defined in Appendix A of The C
| Programming Language by Brian Kernighan and Dennis Ritchie,
| and as is implemented in almost all C translators. (This
| document is hereinafter referred to as K&R.)
|
| K&R is not the only source of "existing practice." Much
| work has been done over the years to improve the C language
| by addressing its weaknesses. The Committee has formalized
| enhancements of proven value which have become part of the
| various dialects of C. Existing practice, however, has not
| always been consistent. Various dialects of C have
| approached problems in different and sometimes
| diametrically opposed ways. This divergence has happened
| for several reasons. First, K&R, which has served as the
| language specification for almost all C translators, is
| imprecise in some areas (thereby allowing divergent
| interpretations), and it does not address some issues (such
| as a complete specification of a library) important for
| code portability. Second, as the language has matured over
| the years, various extensions have been added in different
| dialects to address limitations and weaknesses of the
| language; these extensions have not been consistent across
| dialects.
|
| One of the Committee's goals was to consider such areas of
| divergence and to establish a set of clear, unambiguous
| rules consistent with the rest of the language. This effort
| included the consideration of extensions made in various C
| dialects, the specification of a complete set of required
| library functions, and the development of a complete,
| correct syntax for C.
|
| The work of the Committee was in large part a balancing
| act. The Committee has tried to improve portability while
| retaining the definition of certain features of C as
| machine-dependent. It attempted to incorporate valuable new
| ideas without disrupting the basic structure and fabric of
| the language. It tried to develop a clear and consistent
| language without invalidating existing programs. All of the
| goals were important and each decision was weighed in the
| light of sometimes contradictory requirements in an attempt
| to reach a workable compromise.
|
| ---------------------
|
| In general, standards that follow this path, codifying
| existing practice, that serve to coordinate interest
| between various actors, tend to work better than
| specifications that are written up-front and then followed
| by implementation. You can see this operating in a smaller
| way within current standards bodies and organizations, as
| you yourself alluded to with "relatively centralized."
|
| > Javascript became the lowest common denominator, winning
| out not because it was better than say Java or ActiveX or
| Flash or whatever. It was just commonly available.
|
| This statement is shockingly similar to what people say
| about C, as opposed to various other languages that were in
| the same space around the same time.
| jampekka wrote:
| ECMA standardized ECMAScript in 1997, only two years after
| Netscape Navigator first shipped Javascript. ECMAScript and
| Javascript are the same thing. I've never encountered a
| language level incompability in the different ECMAScript
| implementations. The same can't be said e.g. about the
| extremely commitee driven C++.
|
| The browser APIs are specced by W3C and WHATWG. For newer
| APIs there are usually differences in browser
| implementations, but these tend to get ironed out quite
| fast.
| moralestapia wrote:
| Huh? What?
|
| Nothing's more standard than Javascript these days. Not
| even close. It runs the same way on _billions_ of devices
| across virtually all existing architectures.
| rdtsc wrote:
| > As I understand it, it's not even really possible today to
| make WebAssembly do anything meaningful in the browser without
| trampolining back out to JavaScript anyway, which seems like a
| remarkable missed opportunity.
|
| That's the underlying messy API it's built on. There are specs
| to make the API more standardized like
| https://github.com/WebAssembly/WASI
|
| But overall, yeah, it feels like a shiny new toy everyone is
| excited about and wants to use. Some toys can be fun to play
| with, but it doesn't mean we have to rewrite production systems
| in it. Sometimes, or most of the time, toys don't become useful
| tools.
| dylan604 wrote:
| Isn't that specifically why they are called toys and not
| tools?
| rdtsc wrote:
| That's the idea! If we can just convince people who make
| product and technology decisions to see that and not push
| the next shiny toy as the new tool or library everyone has
| to use, we'd all be in good shape :-)
| aseipp wrote:
| > As I understand it, it's not even really possible today to
| make WebAssembly do anything meaningful in the browser without
| trampolining back out to JavaScript anyway, which seems like a
| remarkable missed opportunity.
|
| It was always the goal for WebAssembly code living in the
| browser to have _some_ form of object model /DOM integration,
| and interaction with JavaScript objects. What form it would
| take exactly wasn't clear. But that was _never_ a goal for the
| original 1.0 specification (MVP), and not even in spec for the
| current 2.0 draft -- which mostly add a bunch more useful
| instructions and features, but nothing earth shattering.
|
| The reality is that whatever solution gets accepted has to be
| supported and continue working for what is effectively
| ~infinite time, in multiple major browser engines. For custom
| runtimes it's sort of "whatever", but webpages can live forever
| so it's taking a lot of time to get right. But there was
| clearly a lot of value to be had without that, hence 1.0 was
| the "MVP."
| zengid wrote:
| I think once WasmGC is finished up, that will make shipping a
| VM inside a VM more viable. Opening up direct access to the DOM
| would be cool, but if it were up to me, I'd just skip it and
| render everything inside a <canvas/> and avoid all of the
| "build an application on top of a document format" crap that
| makes web apps so weird to make.
| noman-land wrote:
| Not a very accessible solution.
| zengid wrote:
| It can be! I think that's the number 1 response when anyone
| wants to actually make a better platform. Projects like
| AccessKit are a really great step in the right direction
| https://github.com/AccessKit/accesskit
| munificent wrote:
| _> if it were up to me, I 'd just skip it and render
| everything inside a <canvas/> _
|
| That's very tempting, but you lose a lot if you do that,
| especially around text:
|
| * Accessibility for screen readers, etc.
|
| * The easy ability to select text, copy/paste between other
| apps, etc.
|
| * Line splitting
|
| * Support for multiple languages, RTL, and all their other
| rendering quirks.
|
| Canvas has some text APIs, but they are fairly rudimentary.
| It's a hard problem.
| moralestapia wrote:
| >unshackle the web from the mess that is JavaScript
|
| well_thats_your_opinion.jpeg
|
| Javascript is great and the web became what it is today because
| of it, not in spite of it.
| MichaelMug wrote:
| Where can I find more information about managed data types in
| WebAssembly?
| davexunit wrote:
| GC managed types?
|
| Wasm GC spec: https://webassembly.github.io/gc/core/index.html
|
| Heap types in particular:
| https://webassembly.github.io/gc/core/syntax/types.html#heap...
|
| V8 blog post about GC: https://v8.dev/blog/wasm-gc-porting
| singularity2001 wrote:
| now that it will be cheaper and more natural to pass data
| back and forth with JavaScript, are we likely to see Wasm/GC
| progressively occupying more space in web applications?
|
| is there any tracking issue to see when JavaScript will
| finally be able to read and write Wasm/GC objects? The last
| time I checked any such attempt would result in an error
| davexunit wrote:
| Part of Wasm's capability security model is that JS objects
| are opaque to Wasm and Wasm objects are opaque to JS. This
| is a good thing and it doesn't prevent interop.
|
| Everyone asks about DOM nodes, so let's use that as an
| example. In Wasm, you could import a function known locally
| as $documentGetElementById. The host (JS) could then
| instantiate the module and provide
| Document.prototype.getElementById.bind(document) as the
| implementation of that import. $documentGetElementById's
| return type would be (ref extern), an opaque reference to a
| heap object from the host that can now be freely passed
| around the Wasm module or back to the host. You could then
| import any other DOM functions that you need to
| inspect/manipulate these objects.
|
| On the flip side, if you have a Wasm object reference in
| JS, you need to call some exported Wasm function(s) to
| inspect/manipulate it.
| phendrenad2 wrote:
| Wrong. WASM _is_ just a bytecode format. There 's nothing new
| here compared to JVM, Parrot, CLR, whatever other VM bytecode
| formats have been dreamed up. A lot of people have imagined that
| WASM (or eBPF, but that's another can of worms) somehow has some
| magic sauce that enables it to guarantee correctness or process
| isolation. The truth is your sandbox is only as good as the
| weakest link in (1) Your sandbox runtime (2) Your RPC/API call
| protocol that you're using to control the outside world from
| within your sandbox, which everyone has to build from scratch.
| rdtsc wrote:
| Sure it is bytecode but runs in the browser. That's the magic
| bit. Clients don't have to install .net, java, etc. And because
| it can be a target for some compiled languages, we can play
| cool games built in C and such in the browser.
|
| It also has this property that it makes for very cool demos. It
| may be useful or not in larger production environments, but
| it's hard to deny that it looks cool when being showed off. The
| danger is when someone in charge becomes enamored by it and now
| the whole 20 person team is spending the next two years
| rewriting a production system in it.
| phendrenad2 wrote:
| Most of the exuberance over WASM (including in this article)
| is over the potential for running it _outside_ of the
| browser, such as (apparently) in IoT devices (this article)
| or as a Docker replacement[1].
|
| For the record, I think WASM is a good idea in the browser
| (but is still of limited usability until they add direct DOM
| manipulation, and I feel like someone is intentionally
| blocking that)
|
| [1] - https://news.ycombinator.com/item?id=34078737
| gwervc wrote:
| > Sure it is bytecode but runs in the browser.
|
| About half if not more posts are about WASI (WebAssembly
| outside the browser). There really isn't anything new to
| justifying the level of hype; bytecode or code running in the
| browser already have been done and eventually removed decades
| ago (respectively Java applets and ActiveX).
| joquarky wrote:
| Also, Java applets and ActiveX objects were notoriously
| lacking in accessibility.
|
| I see the same happening with WASM-based web apps if they
| don't find an elegant way to directly utilize the DOM.
| Joker_vD wrote:
| > There's nothing new here compared to ... whatever other VM
| bytecode formats have been dreamed up
|
| Well, there is: it was designed to be easy for already mature
| V8's codebase to adopt as a low-level IR, with minimal changes
| (e.g. V8 keeps the JS AST more or less intact during the
| codegen, it doesn't lower it into 3-address code or anything
| like that, so WASM too has structured loops and blocks but no
| general "goto"). Other VMs, I believe, were developed _after_
| the bytecode design for them was done.
| pjmlp wrote:
| Kind of ironic given PNaCL was equally designed for V8.
| titzer wrote:
| I worked a lot with the PNaCL team and they never told us
| that. Unless you have a reference I am aware of in a design
| doc. PNaCL was LLVM bitcode.
| pjmlp wrote:
| Yeah, this kind of posts selling Webassembly as if it wasn't
| been done before, multiple times since the 1960's is getting
| tiring.
| zozbot234 wrote:
| > There's nothing new here compared to JVM, Parrot, CLR,
| whatever other VM bytecode formats have been dreamed up.
|
| WASM is far more low-level than those. It does not depend on
| the semantics of any existing programming language, and while
| it does sandbox the code it does not focus on providing
| mechanisms for establishing memory safety other than at the
| module level. The focus is almost solely on minimizing overhead
| compared to native code, even the GC implementation is kept as
| simple and efficient as possible.
| munificent wrote:
| Not all bytecode formats are the same.
|
| Steel-reinforced concrete is "just" another building material,
| but what you can do with it in practice is very different from
| wattle and daub.
| scotty79 wrote:
| WebAssembly is bringing the opacity of the apps to the web. Too
| many people learned how the sausage is made by clicking "View
| Source". Of course the ship has mostly sailed already with all
| the layers of abstraction but WebAssembly will be a nice funeral
| wreath.
| zilti wrote:
| I still hope for WASM to get its own rendering facility, and to
| ultimately enable what JavaFX almost did: make true desktop
| applications run in the browser, enabling users to drag them out
| of the browser to have them as actual, integrated desktop
| programs.
| titzer wrote:
| Andy is spot-on, as usual.
|
| Wasm is a software-defined abstraction boundary, possibly the
| most bullet-proof software-defined abstraction boundary yet to
| date, given the formal specification and machine-checked proofs
| of correctness. It has memory sandboxing properties that are
| easily and efficiently implementable on hardware, and it is low-
| level enough to run low-level languages at speeds very close to
| native compilation.
|
| Others in the thread make analogies to things like the JVM, CLR,
| Parrot, Ocaml bytecode, and other things. None of those things
| have the rigor that Wasm has or are low-level enough to be an
| abstraction over hardware. And all of those come with ambient
| capabilities or language concepts that implicitly couple
| applications with the runtime system and/or other applications.
| Wasm by its API-less core spec does not. This was 100%
| intentional.
|
| Andy mentioned WALI briefly in the article. We designed WALI to
| be a similar kind of "just one step up from the bottom"
| abstraction; if you're running on Linux, then the Wasm engine
| exposes a memory-sandboxed Linux syscall set with the exact same
| semantics (effectively pass-through), that allows building
| abstractions and security one layer up (outside of the engine).
| thot_experiment wrote:
| I agree with this, but even if you internalize this it's still
| very easy to miss the point of web assembly. People often talk
| about web assembly with hope that it will "free them from
| javascript". This is missing the point, the beauty of web
| assembly is that you can keep your scaffolding in javascript,
| something it's extremely good at, and have your performance too
| by calling into "native code" as a sort of half-ffi. In short I
| think compiling whole ass programs into wasm is trash, but when
| you compile little libraries, or even individual functions and
| then call them transparently from JS, that's when it really
| shines.
|
| Being able to "natively" perform computations on data, and then
| spit the results back into a terse, expressive language like
| javascript in such a tightly integrated way is heterogeneous
| programming at it's best.
___________________________________________________________________
(page generated 2024-01-09 23:01 UTC)