13 ms·

WASM being the “new k8s” is only one small fragment of where it is going to go. I think there is a good chance it’s going to become the defacto deployment targe

WASM being the “new k8s” is only one small fragment of where it is going to go. I think there is a good chance it’s going to become the defacto deployment target for a lot of software, so in addition to browser and server: - Plugins for desktop/mobile apps, wasm provides a nicely sandboxed environment for them. - Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime. - Embedded electronics, simplifying the development and deployment of IoT devices. When it comes to wasm on the server, it’s often talked about as targeting the “edge”. I believe this the next area of massive growth, however the part that I don’t think is fully solved yet is on the database side. If your server app is making multiple database calls from the edge to a central db there is a good chance that it will slower than a traditional (single location) deployment. What’s needed is a edge first database, we need at least read replicas to be at the edge with your app. Fly.io have something like this with their Postgres’s product. The alternative is to use an eventually consistent db such as CouchBD, but that causes other problems. I’m interested to see if CloudFlare do anything in this area as it’s the part of their stack that’s missing.

kaba0 5y ago
Do we have a bright lookout at WebGPU? Based on historic trends, similar projects seldom come to fruition, and not even cross-platform graphics frameworks managed to stick (vulkan, metal, directx, opengl, basically none of them run on all 3 major platforms, let alone if we add mobile platforms as well to the list)
- bobthebuilders 5y ago
  As much as I hate it, I think economics will make WebGPU a thing the same way it did electron.
- codeflo 5y ago
  I don’t think it’s a matter of trends, we have to look at the particulars of each API. OpenGL/WebGL aren’t well enough aligned with modern hardware to serve as a cross-platform graphics layer. That’s where the newer APIs come in. Vulkan, Metal and DirectX 12 all follow similar principles that would work from a technical standpoint, but we live in an age where platform vendors would rather cripple their platform than make it easy to port software. Apple is the worst offender here, because while Microsoft isn’t happy about it and disables it in “metro” apps, at least they don’t prevent GPU vendors from shipping Vulkan support for normal “desktop” apps. But I’m optimistic about WebGPU: It’s designed to be efficiently implemented on top of the vendor APIs, so platform vendors can’t block it. And it’s low-level enough that it should allow implementing modern games on top of it. (To clarify: I’m optimistic about WebGPU as an API for desktop applications. For browser apps, it seems like all vendors are on board already.)
  - j-pb 5y ago
    > It’s designed to be efficiently implemented on top of the vendor APIs, so platform vendors can’t block it. Their choice of inventing their own shading language instead of using the ONE standard that the industry finally could agree on (SPIRV) makes me very pessimistic. Apple is purposefully crippling stuff to retain their App dominance yes, but Apple IS a major part of WebGPU. So it never had a chance and was doomed to fail from the very begining. Google even had a presentation titled "regaining developer trust" on this topic, but WebGPU continued to push WGSL nevertheless.
    - krona 5y ago
      SPIR-V is an intermediate representation and WSGL compiles to it. WSGL is (or will eventually be) a w3c specification. I fail to see where your point about trust fits in to that.
      - j-pb 5y ago
        Apple + Mozilla did a bait and switch on developers in a textbook case of: Embrace, Extend, Extinguish The original google proposal was to simply use SPIRV. A compromise was then settled for the intermediary language to be isomorphic to SPIRV, removing some of the warts and edges of it and make verification easier. However, Apple with the help of the Mozilla folk successfully managed to twist the semantics into something that is no longer easy to translate from and to. Game developers don't want to work with WSGL, the whole point of the new WASM and WASI ecosystem is to allow devs to bring their own tools. This is especially bad for something like a shader language, where you want to squeeze every bit of performance out of the hardware, often with hand rolled instructions. Having the browser run a mangled version of the SPIRV that you or your toolchain/engine e.t.c. produced is simply not acceptable.
    - the_duke 5y ago
      As the draft says [1]: > Trivially convertable to SPIR-V > Constructs are defined as normative references to their [SPIR-V] counterparts > All features in WGSL are directly translatable to [SPIR-V] > Features and semantics are exactly the ones of [SPIR-V] > Each item in this spec must provide the mapping to [SPIR-V] for the construct So WGSL is essentially just an alternative representation for SPIR-V. But I don't see how this compromises the viability of webgpu. [1] https://www.w3.org/TR/WGSL https://www.w3.org/TR/WGSL
- yolo69420 5y ago
  vulkan runs everywhere except on apple shit, and that is on nobody but apple. they are actively working against open standards. the world is better off if you ignore them and their users.
  - kaba0 5y ago
    That’s not true: https://news.ycombinator.com/item?id=30021878 https://news.ycombinator.com/item?id=30021878
  - pjmlp 5y ago
    No Vulkan for you on Playstation, XBox.
- nicoburns 5y ago
  WebGPU is to WebGL as Vulkan, Metal, DX12 are to OpenGL, DX11 and below. In that context I would expect WebGPU to be just as successful as WebGL has been.
  - pjmlp 5y ago
    Basically mostly 3D renderings for online shops, while most indie devs rather focused on mordern hardware on mobile platforms. Ah, and Google Maps.
- torginus 5y ago
  I hope so. And for that matter, I hope that WebGPU makes it out of the browser as well. It's a modern API, based upon Metal, that has an execution model much closer to actual GPUs, much like Vulkan/DX12, while still handling some of the hairy scheduling/dependency issues for you, as well as lacking the incredible verbosity of the modern APIs.
- tracker1 5y ago
  It could happen... I still remember how exciting VRML was in the 90's. Of course, I still have more of a wait and see approach to anything actually working out.
tester34 5y ago
Is WASM going to replace: Lua, JS and LLV IRM?
- BlueTemplar 5y ago
  Isn't it an intermediating language ? Why would it replace them, it's not like a lot of people directly code in assembly when C is available...
  - cpuguy83 5y ago
    Instead of, as an example, coding a plugin in lua, you code it in whatever you want and compile to wasm (that supports wasm as a compile target). In that sense it would be replacing lua.
    - BlueTemplar 5y ago
      But lua is typically used as an easy scripting language for non-programmers...
- _nalply 5y ago
  No. I am not a clairvoyante but I think there will be possibilitites to compile to WASM. LLV IRM is a special case but transcompiling is not unimaginable.
- kortex 5y ago
  No, no, and no. The only one remotely close in scope is LLVM-IR, and even then scope is pretty significantly different. LLVM-IR is a general purpose IR for native compilation. Wasm is deliberately small in scope and designed for sandboxing. Lua and JS are not even binary languages.
  - hajile 5y ago
    There is a proposal from Mozilla/Facebook for a binary JS format. https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast
tlarkworthy 5y ago
I hope to create a wire compatible Firebase Realtime server for edge use https://observablehq.com/@tomlarkworthy/rtdb-protocol https://observablehq.com/@tomlarkworthy/rtdb-protocol
astlouis44 5y ago
Agree 100% on gaming, which is why my team and I at Wonder Interactive are creating a suite of optimization tools and a hosting platform for Unreal Engine developers to to target the browser using WebAssembly, with WebGPU and WebXR support on the way for UE4 and UE5. We’ve already got some demos online that are really impressive despite only being WebGL 2 (OpenGL ES 3.0) for the time being. With WebGPU, it’ll enable desktop quality on par with what you’d except from Vulkan, Metal, or Direct 3D 12, except in Chrome, Safari, Edge, and Firefox. The future of gaming and the metaverse is cross-platform and free of walled gardens, with developers empowered to distribute directly to their end users online without a middleman required. The reinvention and subsequent golden age of high fidelity 3D browser games will be upon us sooner than most realize. Links for anyone interested: https://www.theimmersiveweb.com/ https://www.theimmersiveweb.com/ Our Discord: https://discord.gg/zUSZ3T8 https://discord.gg/zUSZ3T8
- manuelabeledo 5y ago
  > The future of gaming and the metaverse is cross-platform and free of walled gardens Given that you mentioned Unreal Engine, why the web and not native? I mean, this sounds like an awful lot of work to port something to the web, when it already runs in every platform.
  - Guidii 5y ago
    Perhaps because of the web's deployment model? Quickly getting from "interested in" to "running the game" might be a game-changer. (apologies for the unintentional pun)
- winter_squirrel 5y ago
- have_faith 5y ago
  > free of walled gardens How will it reduce walled gardens?
- BlueTemplar 5y ago
  Well, the hardest in cross-platform has always been designing for different input / output devices (which usually fails, better stick to a single platform and do it well). Another question : how, as a player, do you run a game like this offline, or run multiplayer when the game company servers have shut down ?
singularity2001 5y ago
> edge first database Sqlite was successfully ported to wasm, maybe something can grow out of that?
- samwillis 5y ago
  We are singing from the same song sheet. SQLite in the browser and at the edge is going to explode in popularity. A slightly unknown feature of SQLite is “sessions” which would allow you to build an eventually consistent system on top of SQLite. https://www.sqlite.org/sessionintro.html https://www.sqlite.org/sessionintro.html I can very much see SAAS type apps wheee each costumer/workplace has a SQLite db effectively deployed to the edge.
- infogulch 5y ago
  This is the biggest question actually. Something like cockroachdb's serverless might fit too: https://www.cockroachlabs.com/blog/how-we-built-cockroachdb-serverless/ https://www.cockroachlabs.com/blog/how-we-built-cockroachdb-...
kllrnohj 5y ago
> Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. That storm already happened. It was called Unity. And since then others have joined, like Unreal. WASM + WebGPU doesn't bring anything to the table here other than being a decade late, slower, and with fewer features. Why would anything outside of a web app touch any of it? Why would steam bother? You still have to build so, so much platform-specific stuff to make it work (input, audio, windowing, etc...), why would you do all that and then just pay a massive performance overhead to avoid compiling a whopping ~5 times? WebGPU could potentially see a use as a middleware for things that want to use the GPU but aren't concerned all that much about performance or overhead, things like image filter effects. But there's also no shortage of existing solutions for them, either, like bgfx (as well as domain-specific offerings like halide of course)
- deleted 5y ago
  [deleted]
- y4mi 5y ago
  To my knowledge (correct me if I'm wrong please), the performance issues from WASM only exist in the context of moving things back into the DOM. I was always of the understanding that WASM itself is super performant and if it's possible to run a WASM application without going through the DOM you'd get native performance, making it a valid choice for things like gaming. Most devs would obviously still use unreal engine etc, but these engines will be able to give you improved performance of your games by utilizing WASM
  - kllrnohj 5y ago
    WASM gets you faster performance than JavaScript, sure, but it's not native, either. Sandboxing & byte code aren't free to have. See the extremely long history of existing byte code VMs here - WASM isn't really doing anything new.
    - manmal 5y ago
      Modern hypervisors have astonishing performance, and I don’t see why Chrome and Safari wouldn’t manage to eventually provide a similarly efficient implementation.
jmrm 5y ago
The only part here that I'm a bit sceptic are the embedded electronic. Maybe I'm too into bare metal and RTOS instead of Yocto or other Linux-based development, but I don't see the advantages of using WASM here. By the other hand, I agree completely with the rest of the other deployment targets.
- tracker1 5y ago
  I wouldn't mind better isolation interfaces between my entertainment system and my engine performance options. Of course, this doesn't require WASM... also, the hardware horsepower (so to speak) for the computers you interact with are anemic to begin with, let alone the 2-5x impact of WASM on top of it.
delarq 5y ago
> - Plugins for desktop/mobile apps, wasm provides a nicely sandboxed environment for them. > - Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime. > - Embedded electronics, simplifying the development and deployment of IoT devices. We will finally be able to write code once and run it everywhere! I bet at least 3 billion devices will run WASM. It's a breakthrough, how come nobody came up with such great idea yet?
- csmpltn 5y ago
  > "how come nobody came up with such great idea yet?" Cross-platform Virtual Machines have been around for a very long time, enabling exactly the kind of thing you're talking about. So in-fact, lots of people thought about this, and built various versions of this. The browser doesn't bring anything new to the table here: it's yet another high-level abstraction layer which inevitably will incur performance penalties in a setting where performance means everything. People want to play complex, immersive games at 60 FPS with amazing graphics and textures, sounds, single/multiplayer settings, and more. The browser was never built for modern triple-A gaming in mind, which means the APIs available for game creators will inevitably be less flexible and lag behind the more platform-native APIs we've had for 30+ years. This isn't a precedent by the way: recently developed APIs such as WebAudio & WebWorkers are just awful and don't come anywhere close to what a desktop application can do on a modern OS, and those are often considered "cutting edge". Synchronization APIs and locking primitives are only now being introduced to browsers - https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A... - something games could easily make use of outside of the browser for the past 40+ years. Lightweight gaming can easily take place within the browser, and perhaps this new technology can make that easier to build and use. But to build a proper heavy-weight game - you'll need much more than a browser can offer.
  - samwillis 5y ago
    I think unfortunately the post you are replying to was another sarcastic joke about the JVM and probably didn't deserve your thoughtful reply. Completely agree that web despite being perfect for light weight and casual gaming, is not (yet) the platform for AAA games.
throwaway81523 5y ago
Write once run anywhere sounds like Java of the 1990s ;).
- dragonwriter 5y ago
  Sure, its the JVM, but open from the start, native in major browsers, and at a time when a popular choice for desktop development is “wrap a browser in a layer providing access to OS services”.
  - pjmlp 5y ago
    With the caveat that Electron is basically Windows 98 Active Desktop, and if we forget about Mozilla boycotts against CodeAlchemy and PNaCL. Ironically, those boycotts are now meaningless given Chrome market share, including Electron.
- brabel 5y ago
  It's very similar. If Java had had a good sandbox model and not shipped with a large runtime available to all applications, from the beginning, there would be no reason for WASM to exist. WASM is like Java bytecode without access to the Java standard library (like, no `java.lang.String` or even `java.lang.Object`... just the primitives). But it has a mechanism to call "host" or "imported" functions and to use linear memory (an array of bytes which can be shared with other modules and the host), which is how it actually does anything useful. I can imagine a version of Java that works like this as well, actually, I wonder if there's ever been anything like that?
  - ptx 5y ago
    Once the GC proposal lands, letting the host and application interact through object graphs, won't that bring back most of the same perennial security problems that Java suffered from?
    - monocasa 5y ago
      Java's perennial security issues was that the sandboxing mechanism was implemented in Java in the same VM as it was trying to sandbox... then they added reflection. They couldn't plug all of the holes that could let you get a reference to the security management objects and go to town on them with reflection.
ignoramous 5y ago
> What’s needed is a edge first database, we need at least read replicas to be at the edge with your app... I'm interested to see if CloudFlare do anything in this area as it’s the part of their stack that’s missing. Cloudflare already has a free caching layer, a freemium eventually-consistent KV store that optimises for frequently-read items, and a strongly-consistent datastore. Besides, they partner with other database vendors too: https://blog.cloudflare.com/partnership-announcement-db/ https://blog.cloudflare.com/partnership-announcement-db/
- samwillis 5y ago
  > strongly-consistent datastore I think you are referring to the upcoming R2 object store? I’m not aware of what I would think of as a “strongly-consistent datastore” which would be closer to a traditional database with querying. It’s that that I think is missing. Quite right they have partnered with other db providers, however I think there is a need for something native to their platform that ensures good proximity to Workers to ensure low latency.
  - mwarkentin 5y ago
    I think they’re referring to Cloudflare Durablr Objects: https://developers.cloudflare.com/workers/learning/using-durable-objects https://developers.cloudflare.com/workers/learning/using-dur...
api 5y ago
There are a lot of security reasons to get away from compiled native code as well as convenience reasons. Something like Spectre/Meltdown could have been mitigated completely with a JIT upgrade. Then there's the huge advantage of encouraging more competition in the CPU market. Something like RISC-V would have a much better chance if you didn't have to recompile everything for it. I'm surprised native binary is still the standard. Back in the 1990s when I saw Java and then .NET I thought it would be dead by now outside of specialized high performance libraries for things like codecs and cryptography.
torginus 5y ago
Isn't multithreading support, which is kinda essential for high-performance applications, spotty under WASM? I've read that threads in WASM are hack built-on top of Web Workers + SharedArrayBuffer, which is kinda dodgy at best, and most importantly, not even supported under Safari.
- azakai 5y ago
  Safari does support wasm threads now! It's pretty recent: https://twitter.com/RReverser/status/1471623675623481356 https://twitter.com/RReverser/status/1471623675623481356 Yes, wasm threading support on the web uses workers + SAB. There are some limitations (the usual issues with blocking on the main thread on the web), but it works well in production for many things.
justshowpost 5y ago
> What’s needed is a edge first database, we need at least read replicas to be at the edge with your app. Cloudflare Durable Objects is exactly this.
birdyrooster 5y ago
The future in the datacenter is unikernel virtual machines scheduled by kubernetes.

kaba0 5y ago

Do we have a bright lookout at WebGPU? Based on historic trends, similar projects seldom come to fruition, and not even cross-platform graphics frameworks managed to stick (vulkan, metal, directx, opengl, basically none of them run on all 3 major platforms, let alone if we add mobile platforms as well to the list)

bobthebuilders 5y ago
As much as I hate it, I think economics will make WebGPU a thing the same way it did electron.
codeflo 5y ago
I don’t think it’s a matter of trends, we have to look at the particulars of each API. OpenGL/WebGL aren’t well enough aligned with modern hardware to serve as a cross-platform graphics layer. That’s where the newer APIs come in. Vulkan, Metal and DirectX 12 all follow similar principles that would work from a technical standpoint, but we live in an age where platform vendors would rather cripple their platform than make it easy to port software. Apple is the worst offender here, because while Microsoft isn’t happy about it and disables it in “metro” apps, at least they don’t prevent GPU vendors from shipping Vulkan support for normal “desktop” apps. But I’m optimistic about WebGPU: It’s designed to be efficiently implemented on top of the vendor APIs, so platform vendors can’t block it. And it’s low-level enough that it should allow implementing modern games on top of it. (To clarify: I’m optimistic about WebGPU as an API for desktop applications. For browser apps, it seems like all vendors are on board already.)
- j-pb 5y ago
  > It’s designed to be efficiently implemented on top of the vendor APIs, so platform vendors can’t block it. Their choice of inventing their own shading language instead of using the ONE standard that the industry finally could agree on (SPIRV) makes me very pessimistic. Apple is purposefully crippling stuff to retain their App dominance yes, but Apple IS a major part of WebGPU. So it never had a chance and was doomed to fail from the very begining. Google even had a presentation titled "regaining developer trust" on this topic, but WebGPU continued to push WGSL nevertheless.
  - krona 5y ago
    SPIR-V is an intermediate representation and WSGL compiles to it. WSGL is (or will eventually be) a w3c specification. I fail to see where your point about trust fits in to that.
    - j-pb 5y ago
      Apple + Mozilla did a bait and switch on developers in a textbook case of: Embrace, Extend, Extinguish The original google proposal was to simply use SPIRV. A compromise was then settled for the intermediary language to be isomorphic to SPIRV, removing some of the warts and edges of it and make verification easier. However, Apple with the help of the Mozilla folk successfully managed to twist the semantics into something that is no longer easy to translate from and to. Game developers don't want to work with WSGL, the whole point of the new WASM and WASI ecosystem is to allow devs to bring their own tools. This is especially bad for something like a shader language, where you want to squeeze every bit of performance out of the hardware, often with hand rolled instructions. Having the browser run a mangled version of the SPIRV that you or your toolchain/engine e.t.c. produced is simply not acceptable.
  - the_duke 5y ago
    As the draft says [1]: > Trivially convertable to SPIR-V > Constructs are defined as normative references to their [SPIR-V] counterparts > All features in WGSL are directly translatable to [SPIR-V] > Features and semantics are exactly the ones of [SPIR-V] > Each item in this spec must provide the mapping to [SPIR-V] for the construct So WGSL is essentially just an alternative representation for SPIR-V. But I don't see how this compromises the viability of webgpu. [1] https://www.w3.org/TR/WGSL https://www.w3.org/TR/WGSL
yolo69420 5y ago
vulkan runs everywhere except on apple shit, and that is on nobody but apple. they are actively working against open standards. the world is better off if you ignore them and their users.
- kaba0 5y ago
  That’s not true: https://news.ycombinator.com/item?id=30021878 https://news.ycombinator.com/item?id=30021878
- pjmlp 5y ago
  No Vulkan for you on Playstation, XBox.
nicoburns 5y ago
WebGPU is to WebGL as Vulkan, Metal, DX12 are to OpenGL, DX11 and below. In that context I would expect WebGPU to be just as successful as WebGL has been.
- pjmlp 5y ago
  Basically mostly 3D renderings for online shops, while most indie devs rather focused on mordern hardware on mobile platforms. Ah, and Google Maps.
torginus 5y ago
I hope so. And for that matter, I hope that WebGPU makes it out of the browser as well. It's a modern API, based upon Metal, that has an execution model much closer to actual GPUs, much like Vulkan/DX12, while still handling some of the hairy scheduling/dependency issues for you, as well as lacking the incredible verbosity of the modern APIs.
tracker1 5y ago
It could happen... I still remember how exciting VRML was in the 90's. Of course, I still have more of a wait and see approach to anything actually working out.

tester34 5y ago

Is WASM going to replace: Lua, JS and LLV IRM?

BlueTemplar 5y ago
Isn't it an intermediating language ? Why would it replace them, it's not like a lot of people directly code in assembly when C is available...
- cpuguy83 5y ago
  Instead of, as an example, coding a plugin in lua, you code it in whatever you want and compile to wasm (that supports wasm as a compile target). In that sense it would be replacing lua.
  - BlueTemplar 5y ago
    But lua is typically used as an easy scripting language for non-programmers...
_nalply 5y ago
No. I am not a clairvoyante but I think there will be possibilitites to compile to WASM. LLV IRM is a special case but transcompiling is not unimaginable.
kortex 5y ago
No, no, and no. The only one remotely close in scope is LLVM-IR, and even then scope is pretty significantly different. LLVM-IR is a general purpose IR for native compilation. Wasm is deliberately small in scope and designed for sandboxing. Lua and JS are not even binary languages.
- hajile 5y ago
  There is a proposal from Mozilla/Facebook for a binary JS format. https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast

tlarkworthy 5y ago

I hope to create a wire compatible Firebase Realtime server for edge use https://observablehq.com/@tomlarkworthy/rtdb-protocol https://observablehq.com/@tomlarkworthy/rtdb-protocol

astlouis44 5y ago

Agree 100% on gaming, which is why my team and I at Wonder Interactive are creating a suite of optimization tools and a hosting platform for Unreal Engine developers to to target the browser using WebAssembly, with WebGPU and WebXR support on the way for UE4 and UE5. We’ve already got some demos online that are really impressive despite only being WebGL 2 (OpenGL ES 3.0) for the time being. With WebGPU, it’ll enable desktop quality on par with what you’d except from Vulkan, Metal, or Direct 3D 12, except in Chrome, Safari, Edge, and Firefox. The future of gaming and the metaverse is cross-platform and free of walled gardens, with developers empowered to distribute directly to their end users online without a middleman required. The reinvention and subsequent golden age of high fidelity 3D browser games will be upon us sooner than most realize. Links for anyone interested: https://www.theimmersiveweb.com/ https://www.theimmersiveweb.com/ Our Discord: https://discord.gg/zUSZ3T8 https://discord.gg/zUSZ3T8

manuelabeledo 5y ago
> The future of gaming and the metaverse is cross-platform and free of walled gardens Given that you mentioned Unreal Engine, why the web and not native? I mean, this sounds like an awful lot of work to port something to the web, when it already runs in every platform.
- Guidii 5y ago
  Perhaps because of the web's deployment model? Quickly getting from "interested in" to "running the game" might be a game-changer. (apologies for the unintentional pun)
winter_squirrel 5y ago
have_faith 5y ago
> free of walled gardens How will it reduce walled gardens?
BlueTemplar 5y ago
Well, the hardest in cross-platform has always been designing for different input / output devices (which usually fails, better stick to a single platform and do it well). Another question : how, as a player, do you run a game like this offline, or run multiplayer when the game company servers have shut down ?

singularity2001 5y ago

> edge first database Sqlite was successfully ported to wasm, maybe something can grow out of that?

samwillis 5y ago
We are singing from the same song sheet. SQLite in the browser and at the edge is going to explode in popularity. A slightly unknown feature of SQLite is “sessions” which would allow you to build an eventually consistent system on top of SQLite. https://www.sqlite.org/sessionintro.html https://www.sqlite.org/sessionintro.html I can very much see SAAS type apps wheee each costumer/workplace has a SQLite db effectively deployed to the edge.
infogulch 5y ago
This is the biggest question actually. Something like cockroachdb's serverless might fit too: https://www.cockroachlabs.com/blog/how-we-built-cockroachdb-serverless/ https://www.cockroachlabs.com/blog/how-we-built-cockroachdb-...

kllrnohj 5y ago

> Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. That storm already happened. It was called Unity. And since then others have joined, like Unreal. WASM + WebGPU doesn't bring anything to the table here other than being a decade late, slower, and with fewer features. Why would anything outside of a web app touch any of it? Why would steam bother? You still have to build so, so much platform-specific stuff to make it work (input, audio, windowing, etc...), why would you do all that and then just pay a massive performance overhead to avoid compiling a whopping ~5 times? WebGPU could potentially see a use as a middleware for things that want to use the GPU but aren't concerned all that much about performance or overhead, things like image filter effects. But there's also no shortage of existing solutions for them, either, like bgfx (as well as domain-specific offerings like halide of course)

deleted 5y ago
[deleted]
y4mi 5y ago
To my knowledge (correct me if I'm wrong please), the performance issues from WASM only exist in the context of moving things back into the DOM. I was always of the understanding that WASM itself is super performant and if it's possible to run a WASM application without going through the DOM you'd get native performance, making it a valid choice for things like gaming. Most devs would obviously still use unreal engine etc, but these engines will be able to give you improved performance of your games by utilizing WASM
- kllrnohj 5y ago
  WASM gets you faster performance than JavaScript, sure, but it's not native, either. Sandboxing & byte code aren't free to have. See the extremely long history of existing byte code VMs here - WASM isn't really doing anything new.
  - manmal 5y ago
    Modern hypervisors have astonishing performance, and I don’t see why Chrome and Safari wouldn’t manage to eventually provide a similarly efficient implementation.

jmrm 5y ago

The only part here that I'm a bit sceptic are the embedded electronic. Maybe I'm too into bare metal and RTOS instead of Yocto or other Linux-based development, but I don't see the advantages of using WASM here. By the other hand, I agree completely with the rest of the other deployment targets.

tracker1 5y ago
I wouldn't mind better isolation interfaces between my entertainment system and my engine performance options. Of course, this doesn't require WASM... also, the hardware horsepower (so to speak) for the computers you interact with are anemic to begin with, let alone the 2-5x impact of WASM on top of it.

delarq 5y ago

> - Plugins for desktop/mobile apps, wasm provides a nicely sandboxed environment for them. > - Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime. > - Embedded electronics, simplifying the development and deployment of IoT devices. We will finally be able to write code once and run it everywhere! I bet at least 3 billion devices will run WASM. It's a breakthrough, how come nobody came up with such great idea yet?

csmpltn 5y ago
> "how come nobody came up with such great idea yet?" Cross-platform Virtual Machines have been around for a very long time, enabling exactly the kind of thing you're talking about. So in-fact, lots of people thought about this, and built various versions of this. The browser doesn't bring anything new to the table here: it's yet another high-level abstraction layer which inevitably will incur performance penalties in a setting where performance means everything. People want to play complex, immersive games at 60 FPS with amazing graphics and textures, sounds, single/multiplayer settings, and more. The browser was never built for modern triple-A gaming in mind, which means the APIs available for game creators will inevitably be less flexible and lag behind the more platform-native APIs we've had for 30+ years. This isn't a precedent by the way: recently developed APIs such as WebAudio & WebWorkers are just awful and don't come anywhere close to what a desktop application can do on a modern OS, and those are often considered "cutting edge". Synchronization APIs and locking primitives are only now being introduced to browsers - https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A... - something games could easily make use of outside of the browser for the past 40+ years. Lightweight gaming can easily take place within the browser, and perhaps this new technology can make that easier to build and use. But to build a proper heavy-weight game - you'll need much more than a browser can offer.
- samwillis 5y ago
  I think unfortunately the post you are replying to was another sarcastic joke about the JVM and probably didn't deserve your thoughtful reply. Completely agree that web despite being perfect for light weight and casual gaming, is not (yet) the platform for AAA games.

throwaway81523 5y ago

Write once run anywhere sounds like Java of the 1990s ;).

dragonwriter 5y ago
Sure, its the JVM, but open from the start, native in major browsers, and at a time when a popular choice for desktop development is “wrap a browser in a layer providing access to OS services”.
- pjmlp 5y ago
  With the caveat that Electron is basically Windows 98 Active Desktop, and if we forget about Mozilla boycotts against CodeAlchemy and PNaCL. Ironically, those boycotts are now meaningless given Chrome market share, including Electron.
brabel 5y ago
It's very similar. If Java had had a good sandbox model and not shipped with a large runtime available to all applications, from the beginning, there would be no reason for WASM to exist. WASM is like Java bytecode without access to the Java standard library (like, no `java.lang.String` or even `java.lang.Object`... just the primitives). But it has a mechanism to call "host" or "imported" functions and to use linear memory (an array of bytes which can be shared with other modules and the host), which is how it actually does anything useful. I can imagine a version of Java that works like this as well, actually, I wonder if there's ever been anything like that?
- ptx 5y ago
  Once the GC proposal lands, letting the host and application interact through object graphs, won't that bring back most of the same perennial security problems that Java suffered from?
  - monocasa 5y ago
    Java's perennial security issues was that the sandboxing mechanism was implemented in Java in the same VM as it was trying to sandbox... then they added reflection. They couldn't plug all of the holes that could let you get a reference to the security management objects and go to town on them with reflection.

ignoramous 5y ago

> What’s needed is a edge first database, we need at least read replicas to be at the edge with your app... I'm interested to see if CloudFlare do anything in this area as it’s the part of their stack that’s missing. Cloudflare already has a free caching layer, a freemium eventually-consistent KV store that optimises for frequently-read items, and a strongly-consistent datastore. Besides, they partner with other database vendors too: https://blog.cloudflare.com/partnership-announcement-db/ https://blog.cloudflare.com/partnership-announcement-db/

samwillis 5y ago
> strongly-consistent datastore I think you are referring to the upcoming R2 object store? I’m not aware of what I would think of as a “strongly-consistent datastore” which would be closer to a traditional database with querying. It’s that that I think is missing. Quite right they have partnered with other db providers, however I think there is a need for something native to their platform that ensures good proximity to Workers to ensure low latency.
- mwarkentin 5y ago
  I think they’re referring to Cloudflare Durablr Objects: https://developers.cloudflare.com/workers/learning/using-durable-objects https://developers.cloudflare.com/workers/learning/using-dur...

api 5y ago

There are a lot of security reasons to get away from compiled native code as well as convenience reasons. Something like Spectre/Meltdown could have been mitigated completely with a JIT upgrade. Then there's the huge advantage of encouraging more competition in the CPU market. Something like RISC-V would have a much better chance if you didn't have to recompile everything for it. I'm surprised native binary is still the standard. Back in the 1990s when I saw Java and then .NET I thought it would be dead by now outside of specialized high performance libraries for things like codecs and cryptography.

torginus 5y ago

Isn't multithreading support, which is kinda essential for high-performance applications, spotty under WASM? I've read that threads in WASM are hack built-on top of Web Workers + SharedArrayBuffer, which is kinda dodgy at best, and most importantly, not even supported under Safari.

azakai 5y ago
Safari does support wasm threads now! It's pretty recent: https://twitter.com/RReverser/status/1471623675623481356 https://twitter.com/RReverser/status/1471623675623481356 Yes, wasm threading support on the web uses workers + SAB. There are some limitations (the usual issues with blocking on the main thread on the web), but it works well in production for many things.

justshowpost 5y ago

> What’s needed is a edge first database, we need at least read replicas to be at the edge with your app. Cloudflare Durable Objects is exactly this.

birdyrooster 5y ago

The future in the datacenter is unikernel virtual machines scheduled by kubernetes.