Integration with Tauri is exciting. To me it makes most sense for a near future of a rendering engine. Desktop apps are controlled environments, without horrors of web bug-compatibility or Google shafting unsupported user agents.
HTML/CSS is a really nice environment for making sophisticated UIs. It would be awesome if Servo could pull off having DOM and CSS without JavaScript, making it a “native” UI for Rust applications.
As I understand it, the cost of FFI calls from JavaScript to the DOM (and the fact that it’s an optimisation boundary) is one of the biggest limiting factors in web app performance, so having the DOM exposed directly to Rust code would be very nice indeed and permit a lot of inlining of fast paths.
Yes, this is why I’ve said in the past that it would make a lot more sense for the browser to be written in javascript (or in a language which can share a runtime and object representation with js). (Also, you know, memory safety. From what I understand, many webkit vulnerabilities resulted from straightline code which mishandled js objects, violating gc invariants or whatever.)
Having everything in JS is one way of avoiding the native<>JS communication cost, but I’ve had in mind complete removal of JS instead.
Rust rendering engine is going to have a native Rust representation of DOM and CSS anyway, and that could be exposed directly using a native Rust API to the Rust application. This could even avoid having any garbage collector, apart from refcounting.
Integration with Tauri is exciting. To me it makes most sense for a near future of a rendering engine. Desktop apps are controlled environments, without horrors of web bug-compatibility or Google shafting unsupported user agents.
HTML/CSS is a really nice environment for making sophisticated UIs. It would be awesome if Servo could pull off having DOM and CSS without JavaScript, making it a “native” UI for Rust applications.
As I understand it, the cost of FFI calls from JavaScript to the DOM (and the fact that it’s an optimisation boundary) is one of the biggest limiting factors in web app performance, so having the DOM exposed directly to Rust code would be very nice indeed and permit a lot of inlining of fast paths.
Yes, this is why I’ve said in the past that it would make a lot more sense for the browser to be written in javascript (or in a language which can share a runtime and object representation with js). (Also, you know, memory safety. From what I understand, many webkit vulnerabilities resulted from straightline code which mishandled js objects, violating gc invariants or whatever.)
Having everything in JS is one way of avoiding the native<>JS communication cost, but I’ve had in mind complete removal of JS instead.
Rust rendering engine is going to have a native Rust representation of DOM and CSS anyway, and that could be exposed directly using a native Rust API to the Rust application. This could even avoid having any garbage collector, apart from refcounting.