The chromium embedded framework is used more and more not only for rendering websites but also for rendering the whole gui. For example Visual Studio Code and Atom are build with CEF. I think that with the ability to read and write JavaScript from Rust we had a good starting point for building graphical interfaces.

I personally wouldn’t use that as my experience of both of these chromium-based text editors is that their interface is much more laggy than what I would expect from a desktop app. On my computers, at least.

But that is a personal feeling, and many other people seem to be happy with them. And we have much more front-end web devs out there than people experienced with Gtk. So it sounds like a very good idea to have that in the Rust ecosystem as well

Nice idea,maybe? see my thoughts in this other thread. Current state of GUI development in Rust? The only hazard being “perhaps a web-browser engine is over-complex for simple gui cases”, but you could argue, ‘this is for writing 21st century software and people come with expectations forged by using web based tools’.

Basically I think Rust suffers a little at the point where one is told "use x bindings to library y written in language z’ … the reason for C++'s persistence is the lack of friction in the case where you’re dealing with C++ libraries… (chicken/egg).

So anything ‘written in rust, for rust…’ should push the language along?

Well, most Mozilla applications are currently (at least partially) written in XUL and use XulRunner, a Gecko-based GUI toolkit. I can’t see Servo replacing Gecko without being able to run XUL too, so I suppose that’s already the plan.

Additionally, it would be nice to have Servo plugin for Cordova and Servo branch of NW.js and/or Electron, if it brings noticeable performance benefits as it promises. However, keep in mind that applications are written in these toolkits to be portable, so don’t expect anybody to actually rely on that renderer—just use it to improve performance.

AFAIK Mozilla is right now in long-term process of removing XUL from Gecko. XUL extensions to Firefox will not be supported by the end of this year. There is experimental project browser.html that builds browser chrome (the gui part) in HTML and CSS.

The idea in theory is good. I’m actually building a browser for that purpose (in Rust). The difference is I will be using a simplified/purified set of XML/CSS standards (that actually work.) And it will serve as a shared library so it is meant to be used as a GUI toolkit. Servo is intended to be a real web browser, though, which means it adheres to web standards. If you didn’t know, web standards are not really standards at all, so developing with them is not inherently efficient or intuitive. Of course there are dozens of libraries meant to smooth that over, like React, jQuery, Angular, Ember, etc, etc. I even wrote one myself called “on.js”

There are Linux distros that implement JS in the Desktop Environment, like Linux Mint’s Cinnamon DE.

Firefox OS was a really cool thing that was probably the closest we’ve seen to that. It implemented full HTML5 web technology in the DE, but I think it got discontinued. A lot of DEs use XML too, including Android, so it’s a popular idea. As far as something for Windows/Linux/Mac, electron and others based on Nodejs and Chromium are fascinating, but you have to think long-term with platforms, such a GUI toolkit.

Think about this. Nodejs is also a huge mess. (lackluster event system and chaotic ecosystem.) That is all because, in my belief, it was hyped to boot and pushed out the door too quickly, and once a platform is established, developers have to live with the ecosystem and build off of it, which perpetuates the chaos. Similar situation with the browser, which is due to mainly vendor compatibility, legacy codebase, and unexpected rapidly growing specifications outside of the original platform model. Now you combine those two, and yes, it’s revolutionary the power you can get out of it if you’re careful enough to wade through all that. You can create some awesome apps and get them out the door too.

All that being said, it’s not going to be nearly the power and stability you can get out of a platform that’s designed specifically to handle the paradigm, ecosystem, and scale. Rust in fact holds to that discipline, integrating the paradigm completely first as a foundation, which is why entire kernels and OS and even GUI have been built from scratch with it! That’s the power no other modern language is achieving!

Servo is a much needed initiative to modernize web technology, and break free of the legacy code that’s holding it back. In order to do that, they needed a whole new language! So we have Rust. I’m sure we could hook up Servo to Nodejs, but that may take a step backwards, and we may find ourselves where we were before. Of course experimentation is fun and valuable too.

Platforms like GUI toolkits should ultimately empower the developer, not the application. Food for thought.

I made an incomplete map of a Fullstack Environment with a little view into a possible future. From Frontend to Backend, over Databases and Embedded-systems. With a focus on the reach of JavaScript and where Rust/Servo could be used alternatively or to improve the Stack.

"The next generation, ABI-stable Node.js API for native modules or N-API aims to solve this problem, by providing an ABI-stable abstraction layer for native APIs in JavaScript VMs. This will allow native module authors to compile their module once per platform and architecture and make it available for any version of Node.js that implements N-API. This holds true even for versions of Node.js that are built with a different VM e.g. Node-ChakraCore."https://nodejs.org/api/n-api.html
or
a safe Rust abstraction layer for native Node.js modules. https://www.neon-bindings.com/