3 ms·
Very true. The current frontend frameworks that exist are very immature and I wouldn't use them for anything other than small personal projects right now. The
by the_duke 7y ago
Very true.
The current frontend frameworks that exist are very immature and I wouldn't use them for anything other than small personal projects right now.
The current translation layer (going through JS to access the DOM) has an overhead, but is surprisingly small. There are no frameworks yet that really take advantage of this, though.
Things will become really interesting once wasm code can access the DOM directly without going through JS. (See the "Interface Types" wasm proposal)
But then again, the value of writing a frontend in Rust with it's verbosity and strict type system is very questionable when we have Typescript and the incredibly fast JS engines.
It could be valuable for large, long running apps. But those are commercial projects, which won't go for Rust (language complexity, lack of developers, productivity, ...)
- MaulingMonkey 7y agoI agree with most of your points, but will note a couple of things: 1) Tools like wasm-pack already generate typescript definitions for your WASM targeting Rust code - it seems like it shouldn't be too painful to write just a couple of particularly hot loops in Rust even if the bulk of your web app is in Typescript. 2) Multi-threaded JS is a non-starter, but we're already seeing experimental support for multi-threaded WASM. Admittedly, web workers let you write something similar to multi-process JS... 3) Less GC pressure, since WASM memory isn't garbage collected. While the scale of things you'd put in a website or typical web app really don't care about this, GC pauses in the single digits of milliseconds can start causing problems for games and other framerate sensitive applications if they cause vsync to be regularly missed. 4) Sharing code between a web demo and a "proper desktop app" via WASM targeting languages like Rust imposes a lot less constraints than a JS targeting language like Typescript (where you now need a full blown JS engine, if not a full blown browser engine ala electron, for the desktop version) I wouldn't suprise me if WASM never gains widespread adoption for frontend development. But it also wouldn't suprise me if it gets used by a node module or two that eventually get popular, in an attempt to shave off a couple milliseconds, with end users being none the wiser.
- hackcasual 7y agoThat and you need to allow unsafe scripts in your CSP to support WASM in Chrome, so it's a bit of a killer for anything that takes security seriously.
- simcop2387 7y agoGood chance that'll start to change as WASM gets more fleshed out and more commonly used, but that is a barrier to it's adoption at the moment.
- dmix 7y agoWhat's stopping it exactly?
- dmix 7y agoNevermind found time to research it myself, this was a good overview https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md https://github.com/WebAssembly/content-security-policy/blob/...
- namibj 7y agoChrome restricts it to unsafe-eval CSP. The main risk described seems to be escaping to the global object. Can't we use the power of a tracing GC to determine whether the global object is reachable from the import object, and put _that_ under unsafe-eval? Or add descriptions/tags that need to explicitly allow dangerous APIs to be reachable by the import object, and refuse if any undeclared dangerous APIs are reachable with a CSP not containing unsafe-eval? I see both sides, but full unsafe-eval is too much of a wrecking ball when a warded lock[0] on this proverbial door to the WASM kingdom would be sufficient. [0]: https://en.wikipedia.org/wiki/Warded_lock https://en.wikipedia.org/wiki/Warded_lock
- hackcasual 7y agoBoth FireFox and Safari support same origin CSP on instantiateStreaming sources though, which doesn't work on Chrome.