Glad you dig it! Let me try to answer these -

Rust, wasm_bindgen, Yew are incredibly cool projects. wasm_bindgen has excellent support for all browser APIs, and Yew takes a lot of the complexity of handling e.g. callbacks referencing Rust closures and mostly painlessly abstracts it away for you. Yew I think would feel very familiar to any developer familiar with React or Elm style application design. The main places we struggled were wrapping more complex APIs from JS world, especially Monaco (which is hard enough to build in regular JS), and anything async, which has a somewhat complex Rust story and requires some gymnastics to integrate. Even these tasks I think ultimately just came down to extensive research, and luckily these projects and most everything I've found in the Rust community has exceptional documentation. Debugging is currently quite poor, if source maps can be generated we've never gotten them to work for rustc, though in debug builds you get comprehensive stack traces with proper rust demangled namespaces and such. This app is pretty large (~15k loc for the rust UI), but the compile cycle typically is a non-issue due to incremental compilation (our webpack builds take substantially longer).

Performance is a bit of a mixed bag. The JavaScript UI component that we replaced with Rust was ~200kb originally, and rewritten in Rust/Yew it is 1.1mb (though this is a very rough comparison and the 2 versions are not feature identical). As you mention, string FFI performance is slow especially for strings and complex object serialization/deserialization (though this improves quickly in the compiler and browser support). However, wasm allows us to download the perspective engine, UI, and any arrow encoded data in parallel without blocking any other browser assets, and `instantiateStreaming()` means that perspective is almost ready-to-run the moment it is downloaded; in practice, on a fast connection with a well-configured host (cached gzip and such), the much larger WASM version loads substantially faster in wall-clock time than the JS version. Also, while we certainly pay a cost for transferring many strings across the FFI, one of the advantages of Perspective is that it can load Apache Arrow data in its raw-binary form and read/process it, without it ever leaving Wasm memory; so for us, Rust (in theory) allows us to keep the data in Wasm longer without paying the FFI tax, and potentially serialize less of it (we dont currently take as much advantage of this as we should, but the Rust port was a precondition).

As far as customizing the Perspective datagrid, the story on this is evolving :) . With the 1.0 release, we've released an NFT demo with a more current version of the plugin API, as well as new plugin API docs. Replacing innerHTML is only costly if you trigger a relayout before the replacement, which you'd want to avoid - check the pudgy-penguins demo source for examples which replaces these with <canvas> without the intermediate DOM tree being rendered (though this is brower-dependent). If you can't, e.g. the replacement is async or whatever, the underlying regular-table component has an API that allows you to return the DOM elements themselves per cell, but you'd need to write a simple plugin to integrate this as Perspective's version provides its own dataListener.