Why use DOM manipulation when you can use WebGL? (half-joking, it’s what Qt does)
On a serious note, there are rust frameworks (Yew and Leptos for example) that generate all the DOM manipulation stuff for you. No need to touch JS or the DOM in JS.
I imagine part of the challenge going forward would be the hordes of programmers brought up on designing UIs using a DOM, and all the associated tooling.
My prediction is the situation could be similar to how today many text-only programs assumes a terminal-like device. Terminals have been obsolete for years but I personally feel it’s a ball-and-chain on text UI development. The web document model could persist long after web browsers are a kind of “terminal” to load and render web documents.
Got it, but if you expect people to switch from JS to Rust , you’re going to be disappointed. That’s like asking people who just got their driving license to hop into a fighter jet just because it’s faster. JS is a simple language. Its widespread adoption is not due only to it being ubiquitous, but also because it’s pretty easy to learn. Rust, on the contrary, not so much.
Honestly I’m better off this way, personally. At least javascript is text, and very often readable after pretty printing and debuggabke as a user, I’m not comfortable with loading basically opaque binaries for websites.
Isn’t production JavaScript usually minified/obfuscated to make it hard to read?
Also wasm is actually bytecode, which I believe has a 1:1 conversion into a text-based format called wat.
I agree with your main point though, it’s kinda creepy when you realise just how much we are expected to allow other people’s code to run on our machines.
I still have no idea what WASM really is. I’ve tried looking at articles but it still confuses me. I know how to use HTML, CSS, JS, and actual ARM assembly language at a basic level, but I don’t see how any of this could be used with WASM.
WASM is just like assembly. It has instructions similar to MOV, JMP, STA, etc. It can be distributed as the textual instructions or as the compiled binary format.
When it started it was interpreted by JS or could be compiled to JS directly. It proved to be faster than hand-written JS. However, it still had to go through a JS interpreter. Now, there’s a WASM interpreter / virtual machine built into browsers. It’s very much the new java bytecode but without running an unsandboxed, external (outside of the browser) java virtual machine.
Given it’s an intepreter / virtual machine, it of course has limited APIs in the browser. For a while, it was not possible to access the DOM from WASM, so JS would do the DOM stuff and WASM was called (just like calling an external function in a lib in C/C++/Rust/…) upon to do computationally complex stuff since it was faster than running it in JS through the JS interpreter. IINM, WASM now does have access to the DOM.
Of course there are WASM interpreters outside of browsers that can be included as libraries in other languages. Rust devs are using it for example for plugin systems in their software.
WASM still hasn’t convinced enough people to drop JS and write their website in something other than JS/TS. Maybe someday…
CC BY-NC-SA 4.0
Isn’t DOM manipulation notoriously tedious with WASM? That seems quite a showstopper for most client-side js I’d say.
Why use DOM manipulation when you can use WebGL? (half-joking, it’s what Qt does)
On a serious note, there are rust frameworks (Yew and Leptos for example) that generate all the DOM manipulation stuff for you. No need to touch JS or the DOM in JS.
CC BY-NC-SA 4.0
I imagine part of the challenge going forward would be the hordes of programmers brought up on designing UIs using a DOM, and all the associated tooling.
My prediction is the situation could be similar to how today many text-only programs assumes a terminal-like device. Terminals have been obsolete for years but I personally feel it’s a ball-and-chain on text UI development. The web document model could persist long after web browsers are a kind of “terminal” to load and render web documents.
Got it, but if you expect people to switch from JS to Rust , you’re going to be disappointed. That’s like asking people who just got their driving license to hop into a fighter jet just because it’s faster. JS is a simple language. Its widespread adoption is not due only to it being ubiquitous, but also because it’s pretty easy to learn. Rust, on the contrary, not so much.
Rust is only one of the languages. There are other languages which compile to WASM: Kotlin, Swift, Zig, Go, C#, and more.
CC BY-NC-SA 4.0
Honestly I’m better off this way, personally. At least javascript is text, and very often readable after pretty printing and debuggabke as a user, I’m not comfortable with loading basically opaque binaries for websites.
Isn’t production JavaScript usually minified/obfuscated to make it hard to read?
Also wasm is actually bytecode, which I believe has a 1:1 conversion into a text-based format called wat.
I agree with your main point though, it’s kinda creepy when you realise just how much we are expected to allow other people’s code to run on our machines.
Somewhat, but often it’s still readable. Or maybe I just don’t look at it often enough to notice the worse cases…
That’s good to be aware of, thanks!
I still have no idea what WASM really is. I’ve tried looking at articles but it still confuses me. I know how to use HTML, CSS, JS, and actual ARM assembly language at a basic level, but I don’t see how any of this could be used with WASM.
WASM is just like assembly. It has instructions similar to
MOV,JMP,STA, etc. It can be distributed as the textual instructions or as the compiled binary format.When it started it was interpreted by JS or could be compiled to JS directly. It proved to be faster than hand-written JS. However, it still had to go through a JS interpreter. Now, there’s a WASM interpreter / virtual machine built into browsers. It’s very much the new java bytecode but without running an unsandboxed, external (outside of the browser) java virtual machine.
Given it’s an intepreter / virtual machine, it of course has limited APIs in the browser. For a while, it was not possible to access the DOM from WASM, so JS would do the DOM stuff and WASM was called (just like calling an external function in a lib in C/C++/Rust/…) upon to do computationally complex stuff since it was faster than running it in JS through the JS interpreter. IINM, WASM now does have access to the DOM.
Of course there are WASM interpreters outside of browsers that can be included as libraries in other languages. Rust devs are using it for example for plugin systems in their software.
CC BY-NC-SA 4.0
Removed by mod
Thanks
I thought it was pretty common 🤔 Like LGTM (looks good to me) and IIRC (if I recall correctly).
CC BY-NC-SA 4.0
Removed by mod