7 ms·
When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely h
by cedws 1y ago
When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?
- ygouzerh 1y agoFrom what I understand, WASM is purely functional, to perform side effects, you will need a runtime like WASI to implement it
- DarkNova6 1y agoI am watching patiently from a distance to my hands on a well-designed frontend language but can't help to wonder... is it really _that_ inefficient to call a JS wrapper to touch the DOM? Most code already is so horribly inefficient that I can't imagine this making a noticeable difference in most scenarios.
- thrance 1y agoNo, it's not that bad honestly. But it's not more efficient than JS either, and all this ugly glue code hurts my sensibility.
- DarkNova6 1y agoSounds like something that could be trivially turned into a library, no?
- thrance 1y agoThere are some already (https://docs.rs/web-sys/latest/web_sys https://docs.rs/web-sys/latest/web_sys, for example), and I made mine too as an exercise. But it's still ugly, unecessary, verbose and inefficient code.
- icar 1y agoI would bet on browsers being able to consume Typescript before WASM exposing any DOM API. That'd improve the Javascript situation a bit, at least.
- jesse__ 1y agoPretty sure this is here, my dude.
- matt_kantor 1y agoWhat are you referring to?
- jesse__ 1y agoMy bad, didn't fact check myself before I made an annoying quip. For some reason I thought browsers and started to roll out out native support for TS.
- TheBicPen 1y agoIt's been stuck at stage 1 since early 2022 unfortunately. https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- norman784 1y agoMaybe you got confused, because NodeJS is now able to strip annotations (it does not transform enums, etc) to let you run Typescript files directly.
- jesse__ 1y agoAhhhh, that was it. Thank you
- notnullorvoid 1y agoNot TS, but there are plans to allow something similar with special type annotation syntax. The runtimes still won't do anything with that extra info though, it'll get stripped just like comments. https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- vinkelhake 1y agoYou can write a WASM program today that touches the DOM, it just needs to go through the regular JS APIs. While there were some discussions early on about making custom APIs for WASM to access, that has long since been dropped - there are just too many downsides.
- cedws 1y agoBut then you need two things instead of one. It should be made possible to build WASM-only SPAs. The north star of browser developers should be to deprecate JS runtimes the same way they did Flash.
- bonestamp2 1y agoI agree with the first part, but getting rid of JS entirely means that if you want to augment some HTML with one line of javascript you have to build a WASM binary to do it? I see good use cases for building entirely in html/JS and also building entirely in WASM.
- em-bee 1y agogetting rid of javascript entirely means to be able to manipulate the DOM without writing any javascript code. not to remove javascript from the browser. javascript will still be there if you want to use it.
- catlifeonmars 1y agoMost of the time your toolchain provides a shim so you don’t need to write JS anyway. What’s the difference?
- em-bee 1y agoright, that's exactly the point. those that have a shim already successfully got rid of javascript, and that's enough.
- 1y ago
- pverheggen 1y agoProbably never. There's a pretty good recent thread on this topic: https://news.ycombinator.com/item?id=44775801 https://news.ycombinator.com/item?id=44775801
- apatheticonion 1y agoAgreed. This and (sane) access to multi-threading. I want to be able to write a Rust application, compile to wasm and load it with <html> <body> <div id="root"></div> <script type="application/wasm" src="./main.wasm"></script> </body> </html> Would be great for high performance web applications and for contexts like browser extensions where the memory usage and performance drain is real when multiplied over n open tabs. I'm not sure how code splitting would work in the wasm world, however. v8 could be optimized to reduce its memory footprint if it detects that no JavaScript is running - or wasm-only applications could use an engine like wasmer and bypass v8 entirely. Another factor is that web technologies are used to write desktop applications via Electron/similar. This is probably because desktop APIs are terrible and not portable. First class wasm support in the web would translate to more efficient desktop applications (Slack, VSCode, Discord, etc) and perhaps less hate towards memory heavy electron applications.
- namuol 1y ago> When can we finally kill JavaScript? If you think JavaScript has problems I have bad news about the DOM…
- Tade0 1y agoWanted to say the same thing. People often conflate JS with the DOM API, but that couldn't be further from the case. You can get rid of JS, but that won't help much because it's just a small language interfacing with a huge, old, backwards compatible to 20+ years ago system that is the DOM.
- fullstackchris 1y agoyep, ive still never understood the fetish of HN folks wanting to eliminate JS completely. you tell them to use TS, they say its overcomplicated... i've never heard a definitive or decent answer to "ok what language WOULD you use for manipulating the DOM?" its infuriating, though i suppose those complaining have probably built like one website once. yes, JS is not your strongly typed Rust / Go / .NET, get over it - go learn TypeScript and be happy
- rtpg 1y agoOne of the things that I think make this tricky is that if you have any DOM references you now have visibility into a GCable object. Part of the web Javascript security model is that you cannot see into garbage collection. So if you have some WASM-y pointer to a DOM element, how do you handle that? I think with GC in properly people might come at this problem again, but pre-GC WASM this sounds pretty intractable
- 0x457 1y agoProbably only after Components and WIT are stabilized. No point of making it wihtout it IMO.
- jesse__ 1y agoHot take alert > When is WASM finally going to be able to touch the DOM? Coming from a web background, and having transitioned to games / realtime 3D applications... Fuck the DOM dude. The idea that programming your UI via not one but TWO DSLs, and a scripting language, is utter madness. In principal, it might sound good (something something separation of concerns, or whatever-the-fuck), but in reality you always end up with this tightly coupled garbage fire split across a pile of different files and languages. This is not the way. We need to build better native UI libraries that just open up a WebGL context and draw shit to that. DearIMGUI can probably already do like 85% of what modern webapps do. Anyways .. /rant
- tormeh 1y agoPreach. HTML and CSS are markup languages for creating documents. Using them for GUI applications is wild and obviously a bad idea.
- silon42 1y agoHTML is pretty bad (XUL was better), but (subset) of CSS is probably OK.
- chrismorgan 1y agoMost major GUI frameworks operate on something very similar to HTML + CSS.
- notnullorvoid 1y ago
- dfabulich 1y agoBasically never, because it would require re-standardizing the DOM with a lower-level API. That would take years, and no major browser implementor is interested in starting down that road. https://danfabulich.medium.com/webassembly-wont-get-direct-dom-support-any-time-soon-a3e0ea04c688 https://danfabulich.medium.com/webassembly-wont-get-direct-d... Killing JavaScript was never the point of WASM. WASM is for CPU-intensive pure functions, like video decoding. Some people wrongly thought that WASM was trying to kill JS, but nobody working on standardizing WASM in browsers believed in that goal.
- pjmlp 1y agoPeople have to look at it, from the same point of view Google sees the NDK on Android. "However, the NDK can be useful for cases in which you need to do one or more of the following: - Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations. - Reuse your own or other developers' C or C++ libraries." And I would argue WebGL/WebGPU are preferably better suited, given how clunky WebAssembly tooling still is for most languages.
- mallets 1y agoA bit unrelated, but are there any recent benchmarks comparing it with native perf? Hard to believe it can compete with V8 JIT anytime soon. Might be easier to integrate fast vector libraries within javascript engines.
- yoden 1y agoThat's the issue with WASM. Very, very few people want a limited VM that's only good for CPU-intensive pure functions. The WASM group has redirected a huge amount of resources to create something almost nobody wants.
- apatheticonion 1y agoIt's really not that hard. Node.js has a very mature C FFI for interacting with JavaScript. Just agree on some basic bindings wasb_create_u32(env: *const env, value: u32, result *mut value) -> status wasb_create_string_utf8(env: *const env, str: *const c_char, length: i32, result: *mut value) -> status There is even a shim that ports the Node.js C FFI to wasm: https://github.com/devongovett/napi-wasm/blob/main/index.mjs#L400 https://github.com/devongovett/napi-wasm/blob/main/index.mjs... Heck, just include that in the browser so it doesn't need to be loaded at runtime Stack that with support in the browser for wasi and you have everything you need to work with the DOM from wasm as well as things like threading
- p_l 1y agoGC was required part, because it was needed to allow interaction between DOM-side lifetimes and WASM-side lifetimes. You might still need a puny shim to essentially "declare" whatever form you want the DOM API to look like on WASM side (probably utilizing components and WIT in the future) but that shim won't have to do anything other than register the APIs because WASM will be able to take a reference to DOM object and vice versa instead of throwing a copy of data over the wall as it is now.
- deleted 1y ago[deleted]
- torginus 1y agoContrary to naysayers, I'm pretty sure this is very doable. Most browser JS objects map 1-1 to C++ native objects implemeneted in the browser. As others have pointed out, the Js compoment interface is define in a language called WebIDL: https://firefox-source-docs.mozilla.org/dom/webIdlBindings/index.html https://firefox-source-docs.mozilla.org/dom/webIdlBindings/i... How it works in Chrome(Blink) is that a compiler generates a wrapper between V8, which is a V8 object that holds onto the native object reference using this IDL. Once V8 cleans up the Js object, the native code, holding a weak reference to the native objects, detects that it has become unreachable and cleans that up. In any ways, the object lifetime is encapsulated by the v8 Isolate (which is depending on how you look at it, the lifetime of the HTML document or the heap), so it'd be perfectly fine to expose native references as they'd be cleaned up when you navigate away/close the page. Once you support all the relevant types, define a calling convention, and add an appropriate verifier to Wasm, it'd be possible to expose all native objects to Wasm, probably by generating a different (and lighter weight) glue to the native classes, or delegating this task to the Wasm compiler. Of course, if you wanted to have both JS and Wasm to be able to access the same object, you'd have to do some sort of shared ownership, which'd be quite a bit more complicated. So I'd argue it'd make sense to allow objects that are wholly-owned by the Wasm side or the JS side, which still makes a ton of sense for stuff like WebGL, as you could basically do rendering without calling into JS. I'm going out on a limb here, but I'd guess since this multi-memory support has landed, that means a single webassembly instance can map multiple SABs, so it might be the beginnings of that.
- DanielHB 1y agoI don't think WASM by itself will finally kill Javascript, other languages and their tooling are not well equipped to create DOM-based applications with the constraints expected for the web (fast loading times, lazy-loading, asset bundling, etc). I don't think most languages it is even feasible to compile to wasm in a way that doesn't include a splashscreen for any non-trivial application. Which is simply unacceptable for most web content. And that is even before all the work required in user-land to support browser primitives (like URL routing, asset loading, DOM integration, etc). So I can foresee this unlocking "heavy duty productivity apps" to run in the browser things like video editors or photoshop using web-first GUI (meaning DOM elements) without significant amounts of JS. But for general web content consumed by the masses I find it unlikely. I expect the real "javascript death" will mean a completely new language designed from the ground-up to compile to WASM and work with browser APIs.
- jason-johnson 1y agoMaybe some day, maybe never. A different, perhaps more important question is, does it matter? https://youtu.be/4KtotxNAwME?si=Egu05co4q7-RsanU https://youtu.be/4KtotxNAwME?si=Egu05co4q7-RsanU
- marcelr 1y agothis is a really bad and out of touch take
- hajile 1y agoEven if you had that environment today, how would you replace the function of JS? Web development moves faster than any software in history. A lot of this is on the back of JS being ergonomic/fast to code and having very good performance and a lot of what makes it good at this is also what coders familiar with other languages dislike. What other language has that right combination of really fast development and good performance? You would probably have to go outside the mainstream to something like Scheme or StandardML to get the ergonomics and performance, but that would upset a whole other group of people. After that is an even bigger problem. If everyone adopts different languages, different frameworks for those languages, and different user-facing APIs for the WASM APIs, then finding devs for your frontend team who can be productive quickly suddenly becomes impossibly hard.