3 ms·
I wonder how this approach will combine/contrast with compiling rust to wasm directly -- I'm under the impression that the benefits would be similar. I absolut
by hardwaresofton 9y ago
I wonder how this approach will combine/contrast with compiling rust to wasm directly -- I'm under the impression that the benefits would be similar.
I absolutely believe building electron apps is the future -- why would you struggle with the M*N effort of building different UIs when you can get comfortable with a paradigm that you already know that works relatively predictably across OSes and is constantly being improved (HTML+CSS).
Unfortunately, one of the big problems left to get tackled (I think?) is the lack of native system accessiblity features that are more advanced than what the web can/does offer.
So excited to see this idea getting attention -- I really want to work on a cross-platform app with neon + rust in the future, and see if we can finally get past the gripe of memory usage for electron apps so that people can stop bashing them.
- lynaghk 9y agoAuthor here. I'm compiling Rust to WASM on another project, so I can address this question. I haven't studied relative perf, so can't make any claims there. But for this application your guess is correct: It's iterop. It's easier to go with Rust via Neon rather than WASM because Finda needs to: + Walk the filesystem for file results + Call OS X CoreGraphics APIs to list windows + Run a websocket server to collect results from browsers and VSCode All of this requires leaving the browser sandbox, and so can't be done in WASM.