9 ms·

I still entirely don't understand the point of web assembly - at best isn't it a pretend emulation layer? You have to have some sort translation layer/virtual

• azangru 3y ago
  - Adobe has a C-based codebase of Photoshop developed over decades for the desktop app - Adobe wants to bring Photoshop to the web for easier distribution and tighter control - Adobe engineers compile the existing C-based codebase to webassembly instead of rewriting it from scratch in javascript - Photoshop for the Web is born - ... - Profit?
  • pxmpxm 3y ago
    That's great for the actual meat and potatoes, but like half of the codebase will be tied to whatever UX libraries (MFC on windows / Cocoa in osx) that won't port over. So you will be rewriting most of it in java script anyway? That argument feels a bit academic.
    • whizzter 3y ago
      Partially, much of what makes Photoshop photoshop that clones can't replicate is the actual image manipulations,layer adjustments,etc that needs to be carrier over 1:1 or people will just be annoyed that it's not exactly right. Also Asm.JS (Wasm's predecessor) was born to port GAMES, games often have their own GL,etc UI's that they render themselves and then tons upon tons of gameplay logic code that runs in C/C++ (or whatever scripting language the engine supports like C#). That was the most important part initially, even if people on the outside are starting to benefit like the Figma folks that uses Wasm, kinda like GPU's were for gaming and now power a ton of modern UI and AI workloads.
    • macNchz 3y ago
      Applications like Photoshop typically have fully custom UI frameworks that are not tightly tied to the OS, so porting to run in a browser is less about rewriting the entire UI to work with html elements, and more about writing a renderer for the UI kit that can draw it to a canvas. If you’re not writing a fully custom UI, you might choose something like Qt, which has wasm built in: https://www.qt.io/web-assembly-example-slate?hsCtaTracking=3bba596e-b49d-42b2-8846-5afc7f2d8da8%7C3dc35563-7a40-4061-b98b-b66f42959c8d https://www.qt.io/web-assembly-example-slate?hsCtaTracking=3...
      • spankalee 3y ago
        Photoshop for the Web's UI is built with Lit.
      • malkia 3y ago
        Try loading a big image, then flood fill it :) - My browser crashed - or rather - went into deep sleep!
    • flohofwoe 3y ago
      Here are a couple of real-world examples, these are all written in C and some C++ and run across Linux, macOS, Windows, iOS, Android and in browsers from the same code, the web is basically "just another target platform": Home computer emulators: https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/ CPU simulators for Z80 and 6502 (based on the netlists from visual6502.org): https://floooh.github.io/visualz80remix/ https://floooh.github.io/visualz80remix/ https://floooh.github.io/visual6502remix/ https://floooh.github.io/visual6502remix/ The shareware version of Doom: https://floooh.github.io/doom-sokol/ https://floooh.github.io/doom-sokol/ A Pacman clone in C: https://floooh.github.io/pacman.c/pacman.html https://floooh.github.io/pacman.c/pacman.html ...and the same in Zig: https://floooh.github.io/pacman.zig/pacman.html https://floooh.github.io/pacman.zig/pacman.html This is all relatively small hobby stuff written just by me, but there's nothing that would prevent scaling to bigger projects. Finally here are the examples for the cross-platform libraries this stuff is built on top: https://floooh.github.io/sokol-html5/ https://floooh.github.io/sokol-html5/ Also specifically about Photoshop: since PS is already a cross-platform application I would expect that they abstracted their UI layer enough to be portable to other UI frameworks without too much hassle. Hybrid WASM/JS applications are in fact a pretty good idea for some use cases (e.g. compile the core logic written in C/C++/Rust/Zig... to WASM, but implement the UI layer via HTML+CSS).
      • DonHopkins 3y ago
        Here's something I'm working on right this moment, using ChatGPT to help generate emscripten embind wrappers for the MicropolisCore MicropolisEngine (based on the original SimCity game). The idea is to be able to make plugin zones and robots (like the monster or tornado or train) by subclassing with JavaScript! https://github.com/SimHacker/MicropolisCore/blob/main/src/MicropolisEngine/src/emscripten.cpp https://github.com/SimHacker/MicropolisCore/blob/main/src/Mi... //////////////////////////////////////////////////////////////////////// // This file uses emscripten's embind to bind C++ classes, // C structures, functions, enums, and contents into JavaScript, // so you can even subclass C++ classes in JavaScript, // for implementing plugins and user interfaces. // // Wrapping the entire Micropolis class from the Micropolis (open-source // version of SimCity) code into Emscripten for JavaScript access is a // large and complex task, mainly due to the size and complexity of the // class. The class encompasses almost every aspect of the simulation, // including map generation, simulation logic, user interface // interactions, and more. // // Strategy for Wrapping // // 1. Core Simulation Logic: Focus on the core simulation aspects, such // as the methods to run the simulation, update game states, and handle // user inputs (like building tools and disaster simulations). This is // crucial for any gameplay functionality. // // 2. Memory and Performance Considerations: JavaScript and WebAssembly // run in a browser context, which can have memory limitations and // performance constraints. Carefully manage memory allocation, // especially when dealing with the game's map and various buffers. // // 3. Direct Memory Access: Provide JavaScript access to critical game // data structures like the map buffer for efficient reading and // writing. This can be done using Emscripten's heap access functions // (HEAP8, HEAP16, HEAP32, etc.). // // 4. User Interface and Rendering: This part might not be necessary to // wrap, as modern web technologies (HTML, CSS, WebGL) can be used for // UI. However, providing some hooks for game state (like score, budget, // etc.) to JavaScript might be helpful. // // 5. Callbacks and Interactivity: Ensure that key game events and // callbacks are exposed to JavaScript, allowing for interactive and // responsive gameplay. // // 6. Optimizations: Where possible, optimize C++ code for WebAssembly, // focusing on critical paths in the simulation loop. // // Decisions and Explanations // // - Excluded Elements: // // - Low-level rendering or platform-specific code, as this can be // handled more efficiently with web technologies. // // - Parts of the code that handle file I/O directly, as file access // in a web context is typically handled differently (e.g., using // browser APIs or server-side support). // // - Any networking or multiplayer code, as web-based // implementations would differ significantly from desktop-based // network code. // // - Included Elements: // // - Core game mechanics, such as map generation, zone simulation // (residential, commercial, industrial), disaster simulation, and // basic utilities. // // - Game state management, including budgeting, scoring, and city // evaluation. // // - Direct memory access to critical structures like the map // buffer, allowing efficient manipulation from JavaScript. // // - Essential callbacks and event handling mechanisms to ensure // interactivity. // // Conclusion // // Given the complexity and size of the Micropolis class, wrapping the // entire class directly is impractical. However, focusing on key areas // essential for gameplay and providing efficient interfaces for // critical data structures can create a functional and interactive city // simulation in a web context. Further optimizations and adjustments // would likely be needed based on testing and specific requirements of // the web implementation.
    • krona 3y ago
      Dunno, seems to have worked well for Figma.
  • mr_toad 3y ago
    it will crash as soon as it tries to make a system call.
• grishka 3y ago
  It's a replacement for Flash's bytecode VM. Supposedly.
• pdpi 3y ago
  It's significantly faster than JS, but still has a solid security model that makes it appropriate for contexts where you're running untrusted code. More or less like a lower-level JVM.
  • password54321 3y ago
    >It's significantly faster than JS There doesn't appear to be much evidence to support this claim. In fact, there are benchmarks where Javascript outperforms Wasm.
    • kevingadd 3y ago
      If you're solving the category of problems WASM is aimed at, it is almost always faster. If JS is faster it's probably because you're using it to do something that WASM wasn't designed for, i.e. DOM manipulation.
      • password54321 3y ago
        https://programming-language-benchmarks.vercel.app/javascript-vs-wasm https://programming-language-benchmarks.vercel.app/javascrip...
        • kevingadd 3y ago
          These aren't like-for-like comparisons, as demonstrated by how there are multiple implementations of each 'benchmark'. Picking the fastest JS and non-JS binary trees there, for example, the JS one relies on the garbage collector, which means that in practice it can bump allocate all of its temporary objects, and the GC will never run, so they will never be freed. The Rust one in comparison is allocating a bunch of ref-counted handles. It is automatically going to lose. EDIT: I dug around that site more and if you pull up 'JavaScript vs Rust' for the same benchmark, JS is still faster. So I don't understand why you're even using this for a 'JS is faster than WASM' argument if it appears to be saying that JS is also faster than Rust.
• cornstalks 3y ago
  Outside of the web, Wasm is useful anywhere that you might use a scripting language embedded in a program. For example, Lua with game engines. You could replace the scripting layer (e.g., Lua) with Wasm. Some might see this as pointless, but others, like myself, see this as an opportunity to do some cool things. Some things I'm excited for are (1) wasm-c-api, which creates a VM-agnostic API so I can swap out VM implementations without recoding my app; (2) great performance, since there are many Wasm VMs that are heavily optimized for both quick startup and maximum speed; (3) the ability to use many languages, which means I can use a consistent language for the main game and the scripting files.
  • rockwotj 3y ago
    I think the wasm C API is not going to live up to the promise. To actually use high performance features you need many additions to that API that most implementations provide, thus making it less portable. Source: I contribute a lot to wasmtime’s C API and build Redpanda’s Wasm Data Transforms using it
    • cornstalks 3y ago
      Yeah and wasm-c-api has stalled (they still don’t support v128, for example). I’m currently exploring starting an unsanctioned v2 wasm-c-api that aims to be feature complete and hopefully more performance focused.
      • rockwotj 3y ago
        Would be super interested in this if you explore this more! Feel free to reach out (contact info linked from my bio) if you’re interested in collaborating.
    • kelp 3y ago
      I'd been hoping projects like wasmtime could end up looking like a Docker alternative for server side things. Do you think that's unlikely to pan out without a lot more work that doesn't seem to be happening?
• apignotti 3y ago
  The point is to have a more efficient solution to deploy large scale Web applications. Efficiency here is measured in comparison to JavaScript, and it's based on 3 main points 1. More compact representation due to binary encoding compared to text 2. Improved compilation times, since WebAssembly is "lower-level" compared to JS and the engines can assume code has been already optimized and can skip a good chunk of the normal JIT optimization pipeline. 3. Improved runtime performance due to strict typing. No type-checks, no bailouts, etc These come with their set of drawbacks, the main one being that WebAssembly cannot _really_ use the DOM or interact with JavaScript directly and is effectively just a computational engine. Any interaction with the outside word is abstracted to "imports": calls with arbitrary semantics come from outside of WebAssembly. At some point WebAssembly also had the advantage of predictable performance, with the idea being that code would be compiled once-and-for-all during module loading. This promise was, as far as I understand, effectively abandoned first by the introduction of "Baseline" compilers (Liftoff, in V8 terminology) and in more recent times by the requirement of WasmGC, which (I think) has reintroduced the need for bailouts and dynamic recompilation.
  • azakai 3y ago
    I wouldn't say that predictable performance was abandoned, but you are right that it is less of a strict guarantee these days: 1. Baseline compilers are generally 2x slower than optimizing ones. That's noticeable, but it is still a far smaller difference than JS has between its tiers. 2. Even WasmGC doesn't require bailouts - in fact no VM implements them for Wasm AFAIK. However WasmGC is often compiled by languages that do benefit significantly from dynamic inlining, which adds unpredictability, but again the effect (30% [0]) is far smaller than typical differences in JS. [0] https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting
  • UncleEntity 3y ago
    > This promise was, as far as I understand, effectively abandoned first by the introduction of "Baseline" compilers (Liftoff, in V8 terminology)... This, I don't understand... AFAICT the "baseline" compiler's entire job is to get pixels on the screen as fast as possible and then they use optimization strategies to recompile code sections or functions or whatever to speed it up based on $reasons.
• deleted 3y ago
  [deleted]
• jedisct1 3y ago
  Among other things, WebAssembly is very useful for decentralized apps. Check out zkWASM and CosmWasm.
• flohofwoe 3y ago
  It's just the name that's confusing. It has nothing to do with assembly code, and it doesn't require the web. It's just another instruction set for a virtual machine which can be distributed in a CPU-agnostic format and compiled to native CPU instructions on the user's machine (much like JVM, .NET or Flash).
• xipix 3y ago
  Quite simply: it lets you build portable apps with near-native performance. Same source for both your desktop browser and your phone. I really love using it to make audio apps like this one: https://bungee.parabolaresearch.com/bungee-web-demo https://bungee.parabolaresearch.com/bungee-web-demo, also it's great for other real time rendering / visualisation in the browser.
• paulddraper 3y ago
  > emulation layer Absolutely. E.g. JVM byte code > why is that better Portability and sandboxing
• baudaux 3y ago
  WebAssembly allows other kinds of web applications. "Classical" C/C++ apps can run in a browser and can be easily shared. For these purposes, I am creating https://exaequOS.com https://exaequOS.com, a Unix-like OS fully running in a web browser.
• RiverCrochet 3y ago
  > I still entirely don't understand the point of web assembly - at best isn't it a pretend emulation layer? No ... it's a "bytecode." A runtime for an interpreted languages like Javascript can operate directly on the code text and execute the source code. The runtime has to parse, lex, and interpret the code text into things that represent what the code should do - in realtime. "Bytecode" is basically that parse/lex/interpretation step already done. The runtime that interprets bytecode (often called a JIT or jitter) is drastically simpler since it only has to know how to do the relatively simple bytecode operations, instead of complex high-level things like Javascript syntax and object moderling. Benefits: - multiple languages can be targeted to that bytecode (Microsoft does this with it's CIL/.NET) - porting the JIT to different platforms is potentially easier and less error/security-issue prone than the runtime for a high-level langauge - bytecode is easier to examine for security issues than high-level languages - if you want sandboxed code - a whole lot easier to do in a JIT than a full interpreter. - if you design your bytecode right, the JIT could basically translate it to actual CPU assembly language fairly easily.