10 ms·
Lots of possible answers here but I’ll go with DOM bindings
by alehlopeh 1y ago
Lots of possible answers here but I’ll go with DOM bindings
- yakshaving_jgt 1y agoThat's not part of the language.
- bottd 1y agoIf you wanna access DOM you can't avoid JavaScript
- yakshaving_jgt 1y agoThat's not quite true. There are a number of languages which compile to JavaScript, e.g., Elm, and provide an API for interacting with the DOM, as well as some kind of FFI.
- Wowfunhappy 1y agoCouldn’t you use WebAssembly? I think (?) GP’s point is that it would make more sense to use a different language that compiles to WebAssembly. (Or transpile to Javascript I guess, but I don’t know why you’d do that.)
- saulpw 1y agoWith WASM, you still have to have a JS layer that interacts with the DOM. WASM can't touch the DOM by itself, it can only communicate with JS.
- WorldMaker 1y agoWebAssembly still doesn't have direct DOM bindings. That's at least two levels deeper and several more standards to go after the very basic Wasm GC that was only just recently standardized. For the moment you basically have an FFI/IPC bridge that you can send TypedArray buffers and attempt to UTF-8 decode them and then JSON.parse that on the JS side. (We don't even have strings agreed upon yet, mostly just arrays of bytes. Wasm Strings is a possible standard still in the process.) Anyone doing serious HTML rendering with WebAssembly today A) has a build step, B) still has a bunch of JS to do memory buffer FFI/IPC and decoding/encoding, C) is usually using some form of Virtual DOM in the Wasm side and the JS side is some version of JSON-driven React/Preact-Lite. It is not today more efficient than React's build process nor React's runtime experience.