19 ms·

Pay attention to WebAssembly

344 points by hsheth2 5y ago

6510 5y ago
I would like to see a time line of technologies making computers considerably slower. > “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript Nice try! That is not how I look at it.
goombacloud 5y ago
You lose the regular Linux process you are used to and the interaction you can have between processes: start new ones to offload a small task, pipe data, trace them with strace or debug them with gdb. I think this convenience also held back people from moving to Unikernels.
- flohofwoe 5y ago
  Security considerations aside, if you control the WASM runtime (for instance if WASM is used for a plugin/extension system) you can expose most of this functionality to the WASM code through your own runtime API.
- pjmlp 5y ago
  Yet they are running containers on a top of type 1 hypervisor that they can only control over Web dashboards and cluster telemetry.
ogazitt 5y ago
The Open Policy Agent has been able to compile Rego policies into executable Wasm modules [0] for a couple of years, with some nice performance benefits [1]. [0] https://www.openpolicyagent.org/docs/latest/wasm/ https://www.openpolicyagent.org/docs/latest/wasm/ [1] https://medium.com/open-policy-agent/opa-v0-15-1-rego-on-webassembly-81c226c51be4 https://medium.com/open-policy-agent/opa-v0-15-1-rego-on-web...
ramesh31 5y ago
WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?
- smitop 5y ago
  > garbage collection The draft WASM garbage collection proposal is partially implemented in Chromium, you can try it by enabling the enable-experimental-webassembly-features feature flag. > DOM access WebAssembly will never have direct access to the DOM, but at least with Rust the wasm-bindgen+web_sys crates make interacting with the DOM as simple as it is from JavaScript.
  - deleted 5y ago
    [deleted]
  - ducharmdev 5y ago
    Assuming the GC proposal eventually reaches general availability, do you think the approach of the wasm-bindgen+web_sys crates you mention could serve as a model for garbage-collected languages wishing to serve as a replacement for JavaScript? I know the original intention of WASM was to peacefully coexist with JavaScript, not replace it, but one can dream.
  - chrismorgan 5y ago
    > WebAssembly will never have direct access to the DOM I haven’t been paying much attention to WASM proposals for the last few years, but I thought that direct DOM access (avoiding JavaScript trampolining) was one of the driving goals of the reference type, interface type and garbage collection proposals. https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16 mentions “call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript”, and WASM’s high level goals document <https://github.com/WebAssembly/design/blob/main/HighLevelGoals.md https://github.com/WebAssembly/design/blob/main/HighLevelGoa...> lists “access browser functionality through the same Web APIs that are accessible to JavaScript” (not “through JavaScript”, but “through the same APIs”). Am I misunderstanding things?
hwers 5y ago
Another random reason webassembly is really cool is that it let's you run ML models way faster after page load than through the GPU (which can take a ton of time to load all the buffers into VRAM).
- the_duke 5y ago
  In contrast, webgpu Webassembly bindings have the potential to enable fast ML code execution everywhere. Both for browser and native use cases.
  - pjmlp 5y ago
    OpenGL ES 3.2 is already capable of that, but politics killed the support for compute shaders in WebGL. Now we have to wait for WebGPU.
fancyfredbot 5y ago
WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?
- thrown_22 5y ago
  It's already in all browsers.
- deleted 5y ago
  [deleted]
- anonporridge 5y ago
  Not owned by shit for brains Oracle.
  - ducharmdev 5y ago
    This is the best response I've seen to this question
    - anonporridge 5y ago
      Fuck Oracle.
  - hankman86 5y ago
    Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssembly. Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was Java code then and is now Rust or C/C++ in case of WebAssembly. It goes without saying that these are very different developer experiences with virtually no overlap in toolchains and programming languages. Oh and of course even WebAssembly suffers from browser fragmentation. Not only will performance be different, depending on whether you run your wasm module in Chrome, Safari or Firefox. These browsers do also not implement the same feature set (atop the basic wasm MVP). Like Safari doesn’t have SIMD. Other important additions (like tail calls, garbage collection and others) are also not yet universally supported. For the sake of WebAssembly I do hope that they’ve learned their lessons from why Java applets (and Silverlight, Flash, PNaCl) all failed.
a1o 5y ago
Emscripten port on Adventure Game Studio was just merged. :)
- brian_herman 5y ago
  Sick! I didn't know emscripten used webassembly I should have guessed by now they would have merged it or something.
MR4D 5y ago
I’m waiting for a Docker container with a WASM runtime. Wait, maybe someone’s already done that… /s PS - actually, originally I was being sarcastic, but there probably are some very good security use cases for it.
- twalla 5y ago
  You joke, but this is a thing: https://krustlet.dev/ https://krustlet.dev/
  - ducharmdev 5y ago
    I took OP's comment to mean having a wasm runtime in a container, not as a container; AFAICT, krustlet seems more like a replacement for Docker containers.
- hectaman 5y ago
  This is Liam, co-founder of wasmCloud, founder of Cosmonic, and co-chair of the CNCF Cloud Native Wasm Day. I don't think this is actually as crazy as it sounds - when we designed the messaging around CNCF, container, and WebAssembly we deliberately went with a better together story. Why? In a large enterprises you have huge systems that each represent a variety of concerns - security, compliance, governance, reputation, etc, etc. These systems show up as stakeholders in software development like gates in CI/CD. Starting with something like wasmCloud inside a container today lets enterprises leverage their existing benefits while still achieving _many_of the benefits of WebAssembly and wasmCloud. wasmCloud publishes docker containers, helm charts, and integrations with service mesh for that reason. Start where your users are today and take them where you want to go.
  - MR4D 5y ago
    Thanks for the comment, Liam. In honesty, I was only thinking about the simple security use cases, but your comment makes it obvious that this will become a huge marketplace very quickly. You are clearly much closer to the puck than I am !
hankman86 5y ago
There are many things to love about WebAssembly, but let’s not forget it’s downsides. Like it’s threading model relies on Web workers and SharedArrayBuffers and is a royal pain in the … to work with. Not to mention that you’ll need to become COOP/COEP compliant to mitigate side-channel attacks. Then there is the plain fact that it requires a compilation step, which is OK for large apps. But it makes me wonder if wasm really is the natural replacement for JavaScript in serverless cloud apps (aka “FaaS”). So yes, WebAssembly has potential and is almost without an alternative for in-browser apps that do some heavy compute. But I am less convinced about server-side. Time and again, we’re told how great portability across architectures supposedly is. And time and again, the only cloud architecture that matters is x86-64. Maybe ARM or even RISC-V in some cases, but let’s not fool ourselves about these niche platforms.
- kccqzy 5y ago
  WebAssembly itself is independent of the web or the browser. Therefore it is impossible for it to depend on Web Workers or SharedArrayBuffers. Rather it is the browser implementation of WASM (the embedder) that uses these technologies you seem to hate. Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answer is obviously no. WASM itself merely provides shared memory and instructions needed in multithreaded environments like i32.atomic.rmw.cmpxchg and i32.atomic.store, but it doesn't stipulate how threads are created. I don't blame you but lots of people confuse WASM itself with the browsers' implementation of WASM (which, among other things, decides which functions are imported into WASM and how they work). But to me, the most exciting future of WASM is outside the browser. So we must clearly delineate features of WASM from the browser-specific bits.
  - pjmlp 5y ago
    Looking at history from polyglot bytecodes in computing since 1960, there is hardly anything exciting about WASM on the server besides business opportunities to jump into WASM gold rush.
  - melony 5y ago
fxtentacle 5y ago
I'm paying attention, but we are still in the hype phase. "near-native performance" yeah a few seconds per hour. With all the jit and garbage collection, it's way too unreliable for anything that needs real-time performance and more than a pittance of CPU power. Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentation while xnnpack easily handles 200fps on CPU only. For everything that can be inefficient, emscripten was already good enough. For stuff that needs efficiency, Wasm is not reliable enough yet.
- cogman10 5y ago
  > With all the jit and garbage collection Web assembly doesn't have a GC. It is currently in the works so WASM can support other languages, such as python, more natively. As for the JIT, WASM in most implementations has only 2 levels of compilation. [1] > Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentation while xnnpack easily handles 200fps on CPU only. Native TesnorFlow has GPU access, WASM does not. You are seeing the difference between all CPU and CPU + GPU. > For everything that can be inefficient, emscripten was already good enough. WASM is the spiritual successor to emscripten's asm.js. In fact, emscripten emits WASM [2]. It's a little strange talking about it as if it were something different. [1] https://v8.dev/docs/wasm-compilation-pipeline https://v8.dev/docs/wasm-compilation-pipeline [2] https://emscripten.org/docs/compiling/WebAssembly.html https://emscripten.org/docs/compiling/WebAssembly.html
  - Jasper_ 5y ago
    I have low faith in the current WebAssembly GC proposal. It's been such a daunting task that they've started talking about "mini-mini MVPs". The GC proposal does not do what most people think it does, the current draft is basically impossible for most languages to target, and even contributors are finding it difficult to reach consensus [0]. It might be a while before it becomes useful. [0] https://github.com/WebAssembly/gc/issues/254 https://github.com/WebAssembly/gc/issues/254
chubot 5y ago
Cross-language interactions suck. We need WebAssembly components and good code generators for a critical mass of languages before people actually start to use Wasm across different languages. Unpopular opinion: Users will eventually realize that the lowest common denominator between languages is ... a BYTE STREAM (e.g. JSON/CSV/HTML), or what I think of as shell / Unix / Web -style composition. IDLs and code generators are useful in many limited domains (e.g. when you control both sides of the wire), but they bake in a lot of assumptions that people don't realize are language-specific. e.g. Protobufs are very good for C++ <-> C++ communication, but Java and Python users seem to dislike them equally, and even Go users do too. COM is probably better than what most people are proposing now -- it recognizes the problem is dynamic, rather than trying to create the leaky abstraction of "fake" static system. It's true that IDL is reinvented every 5 / 10 / 20 years. (Related recent story: https://news.ycombinator.com/item?id=30128048 https://news.ycombinator.com/item?id=30128048) I expect WASM will get some kind of component system (if it doesn't already exist), but many apps will still need to fall back to something more general. ----- I'm writing about byte streams as a narrow waist of interoperability now, and this is the "lead in" review post: http://www.oilshell.org/blog/2021/12/review-arch.html http://www.oilshell.org/blog/2021/12/review-arch.html Even though disparate WebAssembly components can run in the same process (with memory potentially shared by the host), for something as wide as the "Web", the lowest common denominator is still the common text-based interchange formats we already have. Related comment on WebAssembly: https://news.ycombinator.com/item?id=28581634 https://news.ycombinator.com/item?id=28581634 Programmers underestimate the degree to which languages and VMs are coupled i.e. I question whether WebAssembly is truly polyglot, i.e. GC requires a richer type system in the VM, and types create languages that are winners or losers. Losers are the language implementations that experience 2x-10x slowdowns.
- krona 5y ago
  The Interface Types Proposal is Wasm's answer to what you're describing: https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/main/pro...
- deathanatos 5y ago
  > e.g. Protobufs are very good for C++ <-> C++ communication, but Java and Python users seem to dislike them equally, and even Go users do too. Well, hilariously, when I looked at using it on a project, JSON outperformed protobuf in Python. JSON is implemented in C, Protobuf in Python, and the C decoder for a less efficient format won out. (Now, technically, Protobuf has a C implementation, but at the time I was testing, it segfaulted reliably. Which is the problem with C…) I also recall there were some severe problems with protobuf's ability to represent some types, but I don't remember what they are at this point. I thought it was something to do with sum types, but I'm looking at it now and it does have oneof, so IDK.
labrador 5y ago
Why not LLVM intermediate representation (IR)? Why do we need a whole new assembly language?
- tester756 5y ago
  I don't know but you can generate LLVM IR and then use wasm-ld in order to generate WASM :P
  - astrange 5y ago
    LLVM IR is not an executable target, it is a compiler IR. It is not safe, machine-independent, or even specified.
- azakai 5y ago
  See "Why not just use LLVM bitcode as a binary format?" on the Wasm website FAQ: https://webassembly.org/docs/faq/ https://webassembly.org/docs/faq/
  - labrador 5y ago
    Thank you. For a minute there I thought I asked a stupid question, but I should RTFM
syrusakbary 5y ago
Hey, I'm Syrus From Wasmer [1]! I'm really happy to see more people bringing their attention to the Wasm ecosystem. There are tons of opportunities on this space. Regarding WAPM [2] and how its development had become a bit dormant, expect news about it soon. Can't wait to share what we have been working on! [1] https://wasmer.io https://wasmer.io [2] https://wapm.io https://wapm.io
- wiqar 5y ago
  Looking forward to it!
- hsheth2 5y ago
  Hey Syrus, that's great to hear - I'm excited to see what WAPM has in store!
- stevemk14ebr 5y ago
  please consider raising the priority of no_std wasmer support. This is the biggest barrier for seeing wasm in some really cool areas, kernel, embedded, etc
maga 5y ago
> “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime. Yeah, nah: https://github.com/zandaqo/iswasmfast https://github.com/zandaqo/iswasmfast JS is about 10x faster than wasm in simple linear regression, and 30% faster in levenstein distance calculation.
- azakai 5y ago
  At a glance, the bindings for wasm copy the data, https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185c974a47d7dd9e2431ddf9ff/src/wasm.cpp#L12-L30 https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185... If the running code is short enough then that copy might easily make the wasm version much slower. That is indeed a known downside of wasm (calls to JS are somewhat slow, and copying of data even more so - wasm shines when you can avoid those things, which certainly limits where it makes sense!). If it's not that, then a 10x difference suggests you are running into some kind of a VM bug or limitation.
  - maga 5y ago
    Yep, that's it. And the data marshalling overhead is even more pronounced with the native addon example (N-API Addon). But that's the thing, it's not "WASM always faster than JavaScript" as the author presents it. And on top of that, JS engines are no slouches either, you can optimize JS code to be pretty competitive in terms of performance even for computationally heavy tasks. WASM is _predictively_ performant, being less subject to the vicissitudes of JIT, and offers better startup performance, allows for code reusability for existing C++/Rust code, but it's not a cure-all performance solution.
    - peterth3 5y ago
      The author isn’t saying it’s a “cure all performance solution.” The quote you copied uses cautious language like “almost always” and “results do vary.” The author also cites real world apps that have switched to WASM and seen big performance gains (Figma and 1Password), which is much more compelling than the benchmarks you shared.
squidsoup 5y ago
This article mentions inflection points, but doesn’t delve into clientside apps significantly (e.g. SPAs). How far away are we from transitioning from component based JavaScript frameworks like react, to something which compiles to wasm?
- nicoburns 5y ago
  I doubt JavaScript will ever be fully replaced here. JavaScript is a pretty good language for these use cases, and it has a huge ecosystem. But if you want to use a front end framework that compiles to warm then you can do that today. Rust, Go, C# and more all have libraries (only Rust really makes sense though, as the others involve shipping a huge runtime). Just don’t expect it to be any faster than JS.
- hsheth2 5y ago
  Agree with sibling comment - the JS ecosystem has a huge momentum behind it and probably isn't going away anytime soon. On the web, Wasm has currently found the most success with compute-intensive applications, since the JS <-> Wasm bridge is still pretty expensive. There are already some Wasm-based frameworks like https://platform.uno/ https://platform.uno/ that work on the web, but things like React/React-native and Flutter have a huge head start.
  - WA 5y ago
    React is for connecting state to the DOM and managing the redraws. I don’t see how Wasm could ever replace React, if you want to deal with UI. It’s a different thing.
    - hsheth2 5y ago
      If we get to a point where interacting with browser DOM is comparably fast with Wasm, either through JS or with native APIs, then we could see Wasm replace React. That said, you're right that we probably won't see anything of that sort in the short term.
      - 5y ago
darau1 5y ago
I've heard of webassembly replacing containerization before. As an avid abuser of gitlab-runner: does this mean I'll eventually be able to run my pipelines using webassembly instead of docker? What might this look like?
- Arnavion 5y ago
  Your pipeline processes would be compiled to wasm, and any syscalls they make would be serviced by the wasm runtime, which can apply whatever restrictions it wants to to contain what the process can do. If your pipeline processes are not compiled to wasm, they could alternatively be run on an ELF loader + interpreter that is compiled to wasm and functions just like in the previous paragraph. Of course that'd likely be slow, just like running CI for a foreign arch in qemu is slow.
  - darau1 5y ago
    That does sound promising. It makes me wonder why, though? What does WASM do that containers don't? edit: actually no, I answered my own question in my head: I can think of some applications for WASM that docker simply can't handle at the moment. ledger-cli, for one. I've wanted to include that in a flutter application for almost two years now. WASM seems like the perfect candidate to take care of this.
evmar 5y ago
> Figma makes use of a low-level C++ library called Skia for 2D graphics rather than building their own graphics engine This is not quite right. The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library. Source: I work on this code.
- hsheth2 5y ago
  Thanks for the correction - I'll update my post shortly.
  - astlouis44 5y ago
    Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.
    - jackothy 5y ago
      Some advantages that Steam will still have: 1. Steam provides a system for user accounts and profiles 2. Steam handles payment securely for both buyers and sellers 3. Steam handles social networks/friend list/multiplayer 4. Steam allows you to have all your games in one place 5. Steam is a platform for reviews 6. Steam has its own internal economy/marketplace
      - astlouis44 5y ago
        What’s your point? All of that can be done on the web, besides it isn’t really targeting the Steam audience at the end of the day. Think the mobile audience, but on the web. You can do a Sims or PUBG in HTML5 today, and all that’s required is a hyperlink to share it with others. Same strategy that made Wordle go viral and get acquired today for over $1M.
ashvardanian 5y ago
I am surprised there is no isolation schema for binaries. WASM may look lite and fast compared to Docker, but its still painfully slow compared to AVX or Neon enabled assembly. We went from VMs to Containers. From Containers to WASM. Now, I guess, we just need to learn how to properly isolate simple binaries.
- staticassertion 5y ago
  > Now, I guess, we just need to learn how to properly isolate simple binaries. I think unikernels are appealing as a solution. Every program is "the operating system" running in something like Firecracker on a baremetal host.
- Findecanor 5y ago
  There is a fixed-width SIMD extension though. It conforms to a common subset of instructions with similar semantics in SSE/AVX and the Neons.
- duskwuff 5y ago
  > [WASM is] still painfully slow compared to AVX or Neon enabled assembly. There's an open proposal to add SIMD intrinsics to WASM. https://github.com/WebAssembly/proposals/issues/1 https://github.com/WebAssembly/proposals/issues/1
  - charcircuit 5y ago
    That's an issue from 2018 with no replies to it.
    - azakai 5y ago
      For current status ("phase 3" as that link says is maybe not obvious enough), there is a solid spec and multiple implementations, see the "Fixed-width SIMD" line here: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ And here is an overview of this spec: https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md https://github.com/WebAssembly/simd/blob/master/proposals/si...
Ygg2 5y ago
Is escaping WASM container theoretically harder or easier?
SquibblesRedux 5y ago
Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)
- pie_flavor 5y ago
  Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not, under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work with than Flash, it tried to do both and ended up doing neither. So, why should WASM succeed where Java failed? Well, for pretty much every actual reason Java failed. There's really no places to compare them. WASM is implemented in-browser (and the runtime is very small), it's got a ~1.5x slowdown compared to the 2.5x-3x of the big clunkers like Java and C#, and most importantly it knows its place: low level computation. It does not try to do GUI, but leaves that up to the environment; it does not try to do a high level object model, but leaves that up to the language being compiled for it. What reason do you see that Java failed that's also applicable to WASM?
  - charcircuit 5y ago
    >- it was not, under any circumstances, performant It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.
    - kaba0 5y ago
      As mentioned, that happened much later, so it is irrelevant. But for the others, java is insanely fast today, with pretty much the state of the art GC it has. In practice, a really significant chunk of all important server backends run on the JVM.
syrusakbary 5y ago
> Wasm-native orchestrators will eventually build bridges that ease migration from or integration with Docker That's a good point. And it's actually already happening (although not on the shared memory space yet as the post mentions). Youki and curn (OCI/Docker runtimes) have already integrated Wasmer to enable running WebAssembly on their runtime. https://github.com/containers/crun https://github.com/containers/crun https://github.com/containers/youki https://github.com/containers/youki
_8j50 5y ago
This is great, my hope is for wasm packaging and delivery to have more metadata and code signing signature support. I say this because I fear potential security nightmares in the future. Imagine Log4J in wasm except it is also in cars, IoT devices , corporate intranet sites,etc... It's easy to leave that problem to whoever maintains the app but being able to revoke vulnerable or backdoored wasm apps/components will make everyone's lives easier I think
charcircuit 5y ago
>There’s good reason to believe that Wasm represents the future of containerization. Compared to Docker, it has 10-100x faster cold start times, has a smaller footprint, and uses a better-constrained capability-based security model. Making Wasm modules, as opposed to containers, the standard unit of compute and deployment would enable better scalability and security. I don't see how these are "big" wins over containers. The services I run don't have to worry about cold start times. It takes much longer than starting a container for my services to be ready anyways. I also don't see how it has a smaller footprint. The application needs to be stored somewhere. While containers may only have coarse capability based security using namespaces I'm not sure having super fine grained capability based security would make it be worth switching over to wasm.
jfmc 5y ago
Is WASM still 32-bit based? (at least in browsers)
deleted 5y ago
[deleted]
pjmlp 5y ago
20 years ago, > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d...
- skywal_l 5y ago
  I believe .NET was not open initially. Moreover, there are some patents involved I believe. Add to that the general distrust of Micro$oft among the open source community (especially in 2001).
  - pjmlp 5y ago
    Sure, that was just one example, there are plenty of others to reach for since 1960's.
    - skywal_l 5y ago
      Chip8 for example. /s
usrbinbash 5y ago
WebAssembly will not displace Server Side languages. "oh but it compiles once and then runs everywhere!!!!"...ceased to be an argument over 15y ago, when it became clear that the "backend" is synonymous with linux, and almost every machine has the same architecture. Plus, the time required by the compilation step is not prohibitive in a CI/CD pipeline.
- Chris2048 5y ago
  I understand that compilation is not an issue, but WDYM by the other stuff? Even python is a bit of a PITA to package and run where interpreters already exist, not all distros are the same - The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. JS, in virtue of being properly sandboxed, seems to be in a position to prevent coupling outside expected interfaces, and hence reduces the scope for compatibility creep. maybe? ...
  - usrbinbash 5y ago
    > Even python is a bit of a PITA to package and run where interpreters already exist That's mostly a result of everything and everyone having a different opinion where python modules should live in the filesystem, and the default behavior of a lot of package managing software to replace python installations between versions instead of shoving them into different packages and be done with it. > The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. The same advantage exists for compiled languages, provided that dependencies are either staticaly compiled, unambigously listed, or shipped with the software as a package. A similar effect is achieved in Python Projects by virtualenving everything, essentially stuffing all dependencies, including the correct version of the interpreter, in one location as a single package.
    - Chris2048 5y ago
      there are also differences between lib/interpreter versions (str differences, use of Byte arrays) and stuff like Unicode/crypto support, the c-lib used (e.g. musl). The "provided that" is exactly what I'm sceptical of - if the language is general use, not everyone will play ball unless the language/language-derivative is for the explicit purpose of maintaining this compatibility, and this is somewhat enforced. Python packaging would also be great if it shipped with an unambiguous and bulletproof/portable solution, but it didn't, and then the wheel was (partially) reinvented several times. This is before we even consider bad-actors purposefully attacking (python packages are also susceptible to this I believe).
robertlagrant 5y ago
> Just as Docker could not replace virtual machines entirely I keep seeing this. Docker in no way replaces virtual machines. Can someone explain?
- detaro 5y ago
  Previously: "We want to deploy apps as isolated units we can have variable amounts of instances of, so we make VM images and deploy them to AWS/our VMWare cluster/...". Now: "..., so we make Docker containers and deploy them to AWS/our Kubernetes cluster/...". Hence, Docker replaced virtual machines in a way.
  - usrbinbash 5y ago
    It replaced them from something VMs were unsuited for to begin with (running isolated environments which don't need sepearately emulated hardware).
    - detaro 5y ago
      they weren't really "unsuited", just more than necessary. Hence why they replaced them quite thoroughly. (And places like AWS spent effort on making them low-overhead, e.g. the microVMs that run your lambda functions)
  - robertlagrant 5y ago
    Prebaked VMs, sure. That never seemed like something that was used that much to deliver software.
immmmmm 5y ago
just a stupid question: is it / will it be possible to use some language (python for instance) compiled to wasm to replace javascript for webpage scripting. i'm not a full time web developer, but do sometimes some simple web apps with python flask for backend and html js for front end, sometimes w socketio for communication. for my little use case it would be amazing to have the same language on both sides. i'm certainly missing something here, but i guess it's allowed to dream.
- bmn__ 5y ago
  Not a stupid question. This has already been done for numerous languages. Your search terms are "X in the Web browser" and "X compiled to wasm".
apatheticonion 5y ago
5 years ago they told me I could write multi threaded web applications using C, C++ (or Rust). Then they realized that web assembly could solve world peace and got to work on that. Today I am still unable to create a div from a wasm compiled C application. - yes, yes, I know interface types are cool and yes proposals take a while but please, I just want to write better web apps. Given wasm will need to be imported as a script src and have a robust threading model before the dream of web applications competing with native applications for performance, I suspect I won't see it usable in my lifetime
pmlnr 5y ago
I'm afraid WASM is going to break the internet. There will be the real, now fully closed apps (silos, walled gardens, call them whatever you want) and the remnants of what the internet was, written in HTML, an observable, hackable text. In the other hand... Java couldn't pull this off. Flash couldn't pull this off either. So we'll see.
- joquarky 5y ago
  Also, accessibility is going to take quite a hit if developers favor canvas UI libraries over (re)generating DOM elements.
bacan 5y ago
I have it disabled along with WebGL, WebRTC, etc and refuse to use a browser that has WASM.
husamia 5y ago
Maybe with the explosion of IoT we will see it explode.
fbjork 5y ago
Fredrik here, founder of Grafbase. Grafbase is an edge-first data platform for developers. It will allow you to deploy globally fast backends using a Git workflow. We're also betting big on server-side WASM. We're launching the private beta in a few months. Sign up for early access if you're interested in building this with us: https://grafbase.com https://grafbase.com
deleted 5y ago
[deleted]
juntao 5y ago
Great articles! > the unification of Docker and Wasm containers will happen at the orchestration layer. In fact, it happens now. The integration with WasmEdge and K8s toolings has been done. Developers could use crun, CRI-O, containerd, KubeEdge, KIND, OpenYurt and K8s to start, manage, and orchestrate WasmEdge Apps. See more here: https://wasmedge.org/book/en/kubernetes.html https://wasmedge.org/book/en/kubernetes.html WebAssembly will run side by side with Docker using the same orchestration tools.

344 points by hsheth2 5y ago

6510 5y ago

I would like to see a time line of technologies making computers considerably slower. > “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript Nice try! That is not how I look at it.

goombacloud 5y ago

You lose the regular Linux process you are used to and the interaction you can have between processes: start new ones to offload a small task, pipe data, trace them with strace or debug them with gdb. I think this convenience also held back people from moving to Unikernels.

flohofwoe 5y ago
Security considerations aside, if you control the WASM runtime (for instance if WASM is used for a plugin/extension system) you can expose most of this functionality to the WASM code through your own runtime API.
pjmlp 5y ago
Yet they are running containers on a top of type 1 hypervisor that they can only control over Web dashboards and cluster telemetry.

ogazitt 5y ago

The Open Policy Agent has been able to compile Rego policies into executable Wasm modules [0] for a couple of years, with some nice performance benefits [1]. [0] https://www.openpolicyagent.org/docs/latest/wasm/ https://www.openpolicyagent.org/docs/latest/wasm/ [1] https://medium.com/open-policy-agent/opa-v0-15-1-rego-on-webassembly-81c226c51be4 https://medium.com/open-policy-agent/opa-v0-15-1-rego-on-web...

ramesh31 5y ago

WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?

smitop 5y ago
> garbage collection The draft WASM garbage collection proposal is partially implemented in Chromium, you can try it by enabling the enable-experimental-webassembly-features feature flag. > DOM access WebAssembly will never have direct access to the DOM, but at least with Rust the wasm-bindgen+web_sys crates make interacting with the DOM as simple as it is from JavaScript.
- deleted 5y ago
  [deleted]
- ducharmdev 5y ago
  Assuming the GC proposal eventually reaches general availability, do you think the approach of the wasm-bindgen+web_sys crates you mention could serve as a model for garbage-collected languages wishing to serve as a replacement for JavaScript? I know the original intention of WASM was to peacefully coexist with JavaScript, not replace it, but one can dream.
- chrismorgan 5y ago
  > WebAssembly will never have direct access to the DOM I haven’t been paying much attention to WASM proposals for the last few years, but I thought that direct DOM access (avoiding JavaScript trampolining) was one of the driving goals of the reference type, interface type and garbage collection proposals. https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16 mentions “call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript”, and WASM’s high level goals document <https://github.com/WebAssembly/design/blob/main/HighLevelGoals.md https://github.com/WebAssembly/design/blob/main/HighLevelGoa...> lists “access browser functionality through the same Web APIs that are accessible to JavaScript” (not “through JavaScript”, but “through the same APIs”). Am I misunderstanding things?

hwers 5y ago

Another random reason webassembly is really cool is that it let's you run ML models way faster after page load than through the GPU (which can take a ton of time to load all the buffers into VRAM).

the_duke 5y ago
In contrast, webgpu Webassembly bindings have the potential to enable fast ML code execution everywhere. Both for browser and native use cases.
- pjmlp 5y ago
  OpenGL ES 3.2 is already capable of that, but politics killed the support for compute shaders in WebGL. Now we have to wait for WebGPU.

fancyfredbot 5y ago

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

thrown_22 5y ago
It's already in all browsers.
deleted 5y ago
[deleted]
anonporridge 5y ago
Not owned by shit for brains Oracle.
- ducharmdev 5y ago
  This is the best response I've seen to this question
  - anonporridge 5y ago
    Fuck Oracle.
- hankman86 5y ago
  Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssembly. Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was Java code then and is now Rust or C/C++ in case of WebAssembly. It goes without saying that these are very different developer experiences with virtually no overlap in toolchains and programming languages. Oh and of course even WebAssembly suffers from browser fragmentation. Not only will performance be different, depending on whether you run your wasm module in Chrome, Safari or Firefox. These browsers do also not implement the same feature set (atop the basic wasm MVP). Like Safari doesn’t have SIMD. Other important additions (like tail calls, garbage collection and others) are also not yet universally supported. For the sake of WebAssembly I do hope that they’ve learned their lessons from why Java applets (and Silverlight, Flash, PNaCl) all failed.

a1o 5y ago

Emscripten port on Adventure Game Studio was just merged. :)

brian_herman 5y ago
Sick! I didn't know emscripten used webassembly I should have guessed by now they would have merged it or something.

MR4D 5y ago

I’m waiting for a Docker container with a WASM runtime. Wait, maybe someone’s already done that… /s PS - actually, originally I was being sarcastic, but there probably are some very good security use cases for it.

twalla 5y ago
You joke, but this is a thing: https://krustlet.dev/ https://krustlet.dev/
- ducharmdev 5y ago
  I took OP's comment to mean having a wasm runtime in a container, not as a container; AFAICT, krustlet seems more like a replacement for Docker containers.
hectaman 5y ago
This is Liam, co-founder of wasmCloud, founder of Cosmonic, and co-chair of the CNCF Cloud Native Wasm Day. I don't think this is actually as crazy as it sounds - when we designed the messaging around CNCF, container, and WebAssembly we deliberately went with a better together story. Why? In a large enterprises you have huge systems that each represent a variety of concerns - security, compliance, governance, reputation, etc, etc. These systems show up as stakeholders in software development like gates in CI/CD. Starting with something like wasmCloud inside a container today lets enterprises leverage their existing benefits while still achieving _many_of the benefits of WebAssembly and wasmCloud. wasmCloud publishes docker containers, helm charts, and integrations with service mesh for that reason. Start where your users are today and take them where you want to go.
- MR4D 5y ago
  Thanks for the comment, Liam. In honesty, I was only thinking about the simple security use cases, but your comment makes it obvious that this will become a huge marketplace very quickly. You are clearly much closer to the puck than I am !

hankman86 5y ago

There are many things to love about WebAssembly, but let’s not forget it’s downsides. Like it’s threading model relies on Web workers and SharedArrayBuffers and is a royal pain in the … to work with. Not to mention that you’ll need to become COOP/COEP compliant to mitigate side-channel attacks. Then there is the plain fact that it requires a compilation step, which is OK for large apps. But it makes me wonder if wasm really is the natural replacement for JavaScript in serverless cloud apps (aka “FaaS”). So yes, WebAssembly has potential and is almost without an alternative for in-browser apps that do some heavy compute. But I am less convinced about server-side. Time and again, we’re told how great portability across architectures supposedly is. And time and again, the only cloud architecture that matters is x86-64. Maybe ARM or even RISC-V in some cases, but let’s not fool ourselves about these niche platforms.

kccqzy 5y ago
WebAssembly itself is independent of the web or the browser. Therefore it is impossible for it to depend on Web Workers or SharedArrayBuffers. Rather it is the browser implementation of WASM (the embedder) that uses these technologies you seem to hate. Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answer is obviously no. WASM itself merely provides shared memory and instructions needed in multithreaded environments like i32.atomic.rmw.cmpxchg and i32.atomic.store, but it doesn't stipulate how threads are created. I don't blame you but lots of people confuse WASM itself with the browsers' implementation of WASM (which, among other things, decides which functions are imported into WASM and how they work). But to me, the most exciting future of WASM is outside the browser. So we must clearly delineate features of WASM from the browser-specific bits.
- pjmlp 5y ago
  Looking at history from polyglot bytecodes in computing since 1960, there is hardly anything exciting about WASM on the server besides business opportunities to jump into WASM gold rush.
- melony 5y ago

fxtentacle 5y ago

I'm paying attention, but we are still in the hype phase. "near-native performance" yeah a few seconds per hour. With all the jit and garbage collection, it's way too unreliable for anything that needs real-time performance and more than a pittance of CPU power. Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentation while xnnpack easily handles 200fps on CPU only. For everything that can be inefficient, emscripten was already good enough. For stuff that needs efficiency, Wasm is not reliable enough yet.

cogman10 5y ago
> With all the jit and garbage collection Web assembly doesn't have a GC. It is currently in the works so WASM can support other languages, such as python, more natively. As for the JIT, WASM in most implementations has only 2 levels of compilation. [1] > Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentation while xnnpack easily handles 200fps on CPU only. Native TesnorFlow has GPU access, WASM does not. You are seeing the difference between all CPU and CPU + GPU. > For everything that can be inefficient, emscripten was already good enough. WASM is the spiritual successor to emscripten's asm.js. In fact, emscripten emits WASM [2]. It's a little strange talking about it as if it were something different. [1] https://v8.dev/docs/wasm-compilation-pipeline https://v8.dev/docs/wasm-compilation-pipeline [2] https://emscripten.org/docs/compiling/WebAssembly.html https://emscripten.org/docs/compiling/WebAssembly.html
- Jasper_ 5y ago
  I have low faith in the current WebAssembly GC proposal. It's been such a daunting task that they've started talking about "mini-mini MVPs". The GC proposal does not do what most people think it does, the current draft is basically impossible for most languages to target, and even contributors are finding it difficult to reach consensus [0]. It might be a while before it becomes useful. [0] https://github.com/WebAssembly/gc/issues/254 https://github.com/WebAssembly/gc/issues/254

chubot 5y ago

Cross-language interactions suck. We need WebAssembly components and good code generators for a critical mass of languages before people actually start to use Wasm across different languages. Unpopular opinion: Users will eventually realize that the lowest common denominator between languages is ... a BYTE STREAM (e.g. JSON/CSV/HTML), or what I think of as shell / Unix / Web -style composition. IDLs and code generators are useful in many limited domains (e.g. when you control both sides of the wire), but they bake in a lot of assumptions that people don't realize are language-specific. e.g. Protobufs are very good for C++ <-> C++ communication, but Java and Python users seem to dislike them equally, and even Go users do too. COM is probably better than what most people are proposing now -- it recognizes the problem is dynamic, rather than trying to create the leaky abstraction of "fake" static system. It's true that IDL is reinvented every 5 / 10 / 20 years. (Related recent story: https://news.ycombinator.com/item?id=30128048 https://news.ycombinator.com/item?id=30128048) I expect WASM will get some kind of component system (if it doesn't already exist), but many apps will still need to fall back to something more general. ----- I'm writing about byte streams as a narrow waist of interoperability now, and this is the "lead in" review post: http://www.oilshell.org/blog/2021/12/review-arch.html http://www.oilshell.org/blog/2021/12/review-arch.html Even though disparate WebAssembly components can run in the same process (with memory potentially shared by the host), for something as wide as the "Web", the lowest common denominator is still the common text-based interchange formats we already have. Related comment on WebAssembly: https://news.ycombinator.com/item?id=28581634 https://news.ycombinator.com/item?id=28581634 Programmers underestimate the degree to which languages and VMs are coupled i.e. I question whether WebAssembly is truly polyglot, i.e. GC requires a richer type system in the VM, and types create languages that are winners or losers. Losers are the language implementations that experience 2x-10x slowdowns.

krona 5y ago
The Interface Types Proposal is Wasm's answer to what you're describing: https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/main/pro...
deathanatos 5y ago
> e.g. Protobufs are very good for C++ <-> C++ communication, but Java and Python users seem to dislike them equally, and even Go users do too. Well, hilariously, when I looked at using it on a project, JSON outperformed protobuf in Python. JSON is implemented in C, Protobuf in Python, and the C decoder for a less efficient format won out. (Now, technically, Protobuf has a C implementation, but at the time I was testing, it segfaulted reliably. Which is the problem with C…) I also recall there were some severe problems with protobuf's ability to represent some types, but I don't remember what they are at this point. I thought it was something to do with sum types, but I'm looking at it now and it does have oneof, so IDK.

labrador 5y ago

Why not LLVM intermediate representation (IR)? Why do we need a whole new assembly language?

tester756 5y ago
I don't know but you can generate LLVM IR and then use wasm-ld in order to generate WASM :P
- astrange 5y ago
  LLVM IR is not an executable target, it is a compiler IR. It is not safe, machine-independent, or even specified.
azakai 5y ago
See "Why not just use LLVM bitcode as a binary format?" on the Wasm website FAQ: https://webassembly.org/docs/faq/ https://webassembly.org/docs/faq/
- labrador 5y ago
  Thank you. For a minute there I thought I asked a stupid question, but I should RTFM

syrusakbary 5y ago

Hey, I'm Syrus From Wasmer [1]! I'm really happy to see more people bringing their attention to the Wasm ecosystem. There are tons of opportunities on this space. Regarding WAPM [2] and how its development had become a bit dormant, expect news about it soon. Can't wait to share what we have been working on! [1] https://wasmer.io https://wasmer.io [2] https://wapm.io https://wapm.io

wiqar 5y ago
Looking forward to it!
hsheth2 5y ago
Hey Syrus, that's great to hear - I'm excited to see what WAPM has in store!
stevemk14ebr 5y ago
please consider raising the priority of no_std wasmer support. This is the biggest barrier for seeing wasm in some really cool areas, kernel, embedded, etc

maga 5y ago

> “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime. Yeah, nah: https://github.com/zandaqo/iswasmfast https://github.com/zandaqo/iswasmfast JS is about 10x faster than wasm in simple linear regression, and 30% faster in levenstein distance calculation.

azakai 5y ago
At a glance, the bindings for wasm copy the data, https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185c974a47d7dd9e2431ddf9ff/src/wasm.cpp#L12-L30 https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185... If the running code is short enough then that copy might easily make the wasm version much slower. That is indeed a known downside of wasm (calls to JS are somewhat slow, and copying of data even more so - wasm shines when you can avoid those things, which certainly limits where it makes sense!). If it's not that, then a 10x difference suggests you are running into some kind of a VM bug or limitation.
- maga 5y ago
  Yep, that's it. And the data marshalling overhead is even more pronounced with the native addon example (N-API Addon). But that's the thing, it's not "WASM always faster than JavaScript" as the author presents it. And on top of that, JS engines are no slouches either, you can optimize JS code to be pretty competitive in terms of performance even for computationally heavy tasks. WASM is _predictively_ performant, being less subject to the vicissitudes of JIT, and offers better startup performance, allows for code reusability for existing C++/Rust code, but it's not a cure-all performance solution.
  - peterth3 5y ago
    The author isn’t saying it’s a “cure all performance solution.” The quote you copied uses cautious language like “almost always” and “results do vary.” The author also cites real world apps that have switched to WASM and seen big performance gains (Figma and 1Password), which is much more compelling than the benchmarks you shared.

squidsoup 5y ago

This article mentions inflection points, but doesn’t delve into clientside apps significantly (e.g. SPAs). How far away are we from transitioning from component based JavaScript frameworks like react, to something which compiles to wasm?

nicoburns 5y ago
I doubt JavaScript will ever be fully replaced here. JavaScript is a pretty good language for these use cases, and it has a huge ecosystem. But if you want to use a front end framework that compiles to warm then you can do that today. Rust, Go, C# and more all have libraries (only Rust really makes sense though, as the others involve shipping a huge runtime). Just don’t expect it to be any faster than JS.
hsheth2 5y ago
Agree with sibling comment - the JS ecosystem has a huge momentum behind it and probably isn't going away anytime soon. On the web, Wasm has currently found the most success with compute-intensive applications, since the JS <-> Wasm bridge is still pretty expensive. There are already some Wasm-based frameworks like https://platform.uno/ https://platform.uno/ that work on the web, but things like React/React-native and Flutter have a huge head start.
- WA 5y ago
  React is for connecting state to the DOM and managing the redraws. I don’t see how Wasm could ever replace React, if you want to deal with UI. It’s a different thing.
  - hsheth2 5y ago
    If we get to a point where interacting with browser DOM is comparably fast with Wasm, either through JS or with native APIs, then we could see Wasm replace React. That said, you're right that we probably won't see anything of that sort in the short term.
    - 5y ago

darau1 5y ago

I've heard of webassembly replacing containerization before. As an avid abuser of gitlab-runner: does this mean I'll eventually be able to run my pipelines using webassembly instead of docker? What might this look like?

Arnavion 5y ago
Your pipeline processes would be compiled to wasm, and any syscalls they make would be serviced by the wasm runtime, which can apply whatever restrictions it wants to to contain what the process can do. If your pipeline processes are not compiled to wasm, they could alternatively be run on an ELF loader + interpreter that is compiled to wasm and functions just like in the previous paragraph. Of course that'd likely be slow, just like running CI for a foreign arch in qemu is slow.
- darau1 5y ago
  That does sound promising. It makes me wonder why, though? What does WASM do that containers don't? edit: actually no, I answered my own question in my head: I can think of some applications for WASM that docker simply can't handle at the moment. ledger-cli, for one. I've wanted to include that in a flutter application for almost two years now. WASM seems like the perfect candidate to take care of this.

evmar 5y ago

> Figma makes use of a low-level C++ library called Skia for 2D graphics rather than building their own graphics engine This is not quite right. The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library. Source: I work on this code.

hsheth2 5y ago
Thanks for the correction - I'll update my post shortly.
- astlouis44 5y ago
  Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.
  - jackothy 5y ago
    Some advantages that Steam will still have: 1. Steam provides a system for user accounts and profiles 2. Steam handles payment securely for both buyers and sellers 3. Steam handles social networks/friend list/multiplayer 4. Steam allows you to have all your games in one place 5. Steam is a platform for reviews 6. Steam has its own internal economy/marketplace
    - astlouis44 5y ago
      What’s your point? All of that can be done on the web, besides it isn’t really targeting the Steam audience at the end of the day. Think the mobile audience, but on the web. You can do a Sims or PUBG in HTML5 today, and all that’s required is a hyperlink to share it with others. Same strategy that made Wordle go viral and get acquired today for over $1M.

ashvardanian 5y ago

I am surprised there is no isolation schema for binaries. WASM may look lite and fast compared to Docker, but its still painfully slow compared to AVX or Neon enabled assembly. We went from VMs to Containers. From Containers to WASM. Now, I guess, we just need to learn how to properly isolate simple binaries.

staticassertion 5y ago
> Now, I guess, we just need to learn how to properly isolate simple binaries. I think unikernels are appealing as a solution. Every program is "the operating system" running in something like Firecracker on a baremetal host.
Findecanor 5y ago
There is a fixed-width SIMD extension though. It conforms to a common subset of instructions with similar semantics in SSE/AVX and the Neons.
duskwuff 5y ago
> [WASM is] still painfully slow compared to AVX or Neon enabled assembly. There's an open proposal to add SIMD intrinsics to WASM. https://github.com/WebAssembly/proposals/issues/1 https://github.com/WebAssembly/proposals/issues/1
- charcircuit 5y ago
  That's an issue from 2018 with no replies to it.
  - azakai 5y ago
    For current status ("phase 3" as that link says is maybe not obvious enough), there is a solid spec and multiple implementations, see the "Fixed-width SIMD" line here: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ And here is an overview of this spec: https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md https://github.com/WebAssembly/simd/blob/master/proposals/si...

Ygg2 5y ago

Is escaping WASM container theoretically harder or easier?

SquibblesRedux 5y ago

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

pie_flavor 5y ago
Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not, under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work with than Flash, it tried to do both and ended up doing neither. So, why should WASM succeed where Java failed? Well, for pretty much every actual reason Java failed. There's really no places to compare them. WASM is implemented in-browser (and the runtime is very small), it's got a ~1.5x slowdown compared to the 2.5x-3x of the big clunkers like Java and C#, and most importantly it knows its place: low level computation. It does not try to do GUI, but leaves that up to the environment; it does not try to do a high level object model, but leaves that up to the language being compiled for it. What reason do you see that Java failed that's also applicable to WASM?
- charcircuit 5y ago
  >- it was not, under any circumstances, performant It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.
  - kaba0 5y ago
    As mentioned, that happened much later, so it is irrelevant. But for the others, java is insanely fast today, with pretty much the state of the art GC it has. In practice, a really significant chunk of all important server backends run on the JVM.

syrusakbary 5y ago

> Wasm-native orchestrators will eventually build bridges that ease migration from or integration with Docker That's a good point. And it's actually already happening (although not on the shared memory space yet as the post mentions). Youki and curn (OCI/Docker runtimes) have already integrated Wasmer to enable running WebAssembly on their runtime. https://github.com/containers/crun https://github.com/containers/crun https://github.com/containers/youki https://github.com/containers/youki

_8j50 5y ago

This is great, my hope is for wasm packaging and delivery to have more metadata and code signing signature support. I say this because I fear potential security nightmares in the future. Imagine Log4J in wasm except it is also in cars, IoT devices , corporate intranet sites,etc... It's easy to leave that problem to whoever maintains the app but being able to revoke vulnerable or backdoored wasm apps/components will make everyone's lives easier I think

charcircuit 5y ago

>There’s good reason to believe that Wasm represents the future of containerization. Compared to Docker, it has 10-100x faster cold start times, has a smaller footprint, and uses a better-constrained capability-based security model. Making Wasm modules, as opposed to containers, the standard unit of compute and deployment would enable better scalability and security. I don't see how these are "big" wins over containers. The services I run don't have to worry about cold start times. It takes much longer than starting a container for my services to be ready anyways. I also don't see how it has a smaller footprint. The application needs to be stored somewhere. While containers may only have coarse capability based security using namespaces I'm not sure having super fine grained capability based security would make it be worth switching over to wasm.

jfmc 5y ago

Is WASM still 32-bit based? (at least in browsers)

deleted 5y ago

[deleted]

pjmlp 5y ago

20 years ago, > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d...

skywal_l 5y ago
I believe .NET was not open initially. Moreover, there are some patents involved I believe. Add to that the general distrust of Micro$oft among the open source community (especially in 2001).
- pjmlp 5y ago
  Sure, that was just one example, there are plenty of others to reach for since 1960's.
  - skywal_l 5y ago
    Chip8 for example. /s

usrbinbash 5y ago

WebAssembly will not displace Server Side languages. "oh but it compiles once and then runs everywhere!!!!"...ceased to be an argument over 15y ago, when it became clear that the "backend" is synonymous with linux, and almost every machine has the same architecture. Plus, the time required by the compilation step is not prohibitive in a CI/CD pipeline.

Chris2048 5y ago
I understand that compilation is not an issue, but WDYM by the other stuff? Even python is a bit of a PITA to package and run where interpreters already exist, not all distros are the same - The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. JS, in virtue of being properly sandboxed, seems to be in a position to prevent coupling outside expected interfaces, and hence reduces the scope for compatibility creep. maybe? ...
- usrbinbash 5y ago
  > Even python is a bit of a PITA to package and run where interpreters already exist That's mostly a result of everything and everyone having a different opinion where python modules should live in the filesystem, and the default behavior of a lot of package managing software to replace python installations between versions instead of shoving them into different packages and be done with it. > The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. The same advantage exists for compiled languages, provided that dependencies are either staticaly compiled, unambigously listed, or shipped with the software as a package. A similar effect is achieved in Python Projects by virtualenving everything, essentially stuffing all dependencies, including the correct version of the interpreter, in one location as a single package.
  - Chris2048 5y ago
    there are also differences between lib/interpreter versions (str differences, use of Byte arrays) and stuff like Unicode/crypto support, the c-lib used (e.g. musl). The "provided that" is exactly what I'm sceptical of - if the language is general use, not everyone will play ball unless the language/language-derivative is for the explicit purpose of maintaining this compatibility, and this is somewhat enforced. Python packaging would also be great if it shipped with an unambiguous and bulletproof/portable solution, but it didn't, and then the wheel was (partially) reinvented several times. This is before we even consider bad-actors purposefully attacking (python packages are also susceptible to this I believe).

robertlagrant 5y ago

> Just as Docker could not replace virtual machines entirely I keep seeing this. Docker in no way replaces virtual machines. Can someone explain?

detaro 5y ago
Previously: "We want to deploy apps as isolated units we can have variable amounts of instances of, so we make VM images and deploy them to AWS/our VMWare cluster/...". Now: "..., so we make Docker containers and deploy them to AWS/our Kubernetes cluster/...". Hence, Docker replaced virtual machines in a way.
- usrbinbash 5y ago
  It replaced them from something VMs were unsuited for to begin with (running isolated environments which don't need sepearately emulated hardware).
  - detaro 5y ago
    they weren't really "unsuited", just more than necessary. Hence why they replaced them quite thoroughly. (And places like AWS spent effort on making them low-overhead, e.g. the microVMs that run your lambda functions)
- robertlagrant 5y ago
  Prebaked VMs, sure. That never seemed like something that was used that much to deliver software.

immmmmm 5y ago

just a stupid question: is it / will it be possible to use some language (python for instance) compiled to wasm to replace javascript for webpage scripting. i'm not a full time web developer, but do sometimes some simple web apps with python flask for backend and html js for front end, sometimes w socketio for communication. for my little use case it would be amazing to have the same language on both sides. i'm certainly missing something here, but i guess it's allowed to dream.

bmn__ 5y ago
Not a stupid question. This has already been done for numerous languages. Your search terms are "X in the Web browser" and "X compiled to wasm".

apatheticonion 5y ago

5 years ago they told me I could write multi threaded web applications using C, C++ (or Rust). Then they realized that web assembly could solve world peace and got to work on that. Today I am still unable to create a div from a wasm compiled C application. - yes, yes, I know interface types are cool and yes proposals take a while but please, I just want to write better web apps. Given wasm will need to be imported as a script src and have a robust threading model before the dream of web applications competing with native applications for performance, I suspect I won't see it usable in my lifetime

pmlnr 5y ago

I'm afraid WASM is going to break the internet. There will be the real, now fully closed apps (silos, walled gardens, call them whatever you want) and the remnants of what the internet was, written in HTML, an observable, hackable text. In the other hand... Java couldn't pull this off. Flash couldn't pull this off either. So we'll see.

joquarky 5y ago
Also, accessibility is going to take quite a hit if developers favor canvas UI libraries over (re)generating DOM elements.

bacan 5y ago

I have it disabled along with WebGL, WebRTC, etc and refuse to use a browser that has WASM.

husamia 5y ago

Maybe with the explosion of IoT we will see it explode.

fbjork 5y ago

Fredrik here, founder of Grafbase. Grafbase is an edge-first data platform for developers. It will allow you to deploy globally fast backends using a Git workflow. We're also betting big on server-side WASM. We're launching the private beta in a few months. Sign up for early access if you're interested in building this with us: https://grafbase.com https://grafbase.com

deleted 5y ago

[deleted]

juntao 5y ago

Great articles! > the unification of Docker and Wasm containers will happen at the orchestration layer. In fact, it happens now. The integration with WasmEdge and K8s toolings has been done. Developers could use crun, CRI-O, containerd, KubeEdge, KIND, OpenYurt and K8s to start, manage, and orchestrate WasmEdge Apps. See more here: https://wasmedge.org/book/en/kubernetes.html https://wasmedge.org/book/en/kubernetes.html WebAssembly will run side by side with Docker using the same orchestration tools.