Indeed. I tried atom and the experience was terrible enough to make me want to have nothing to do with electron or apps built on it, like Slack. An application can't function when its foundation is draining all your system resources.
Hence the rocket approach 
Has anyone tried using Servo as the html5 Rendering engine ? I am thinking of using the HTML Frontend and Rocket Backend. But i am concerned about the Performance AS i have Seen terrible Electron Apps.
To me it doesnt make sense to use Rust for GUI applications. IT is too lowlevel and gets in the way all the time when you Just want to Display a Data Grid and fill it with data. All the mentioned librariries are Not even Close to What you can do with wpf and mvvm and Data binding and all that sexy stuff.
After trying a few toolkits, I've settled for now on the Sciter bindings for Rust. And yeah, being able to delegate the layout logic to HTML and CSS is really, really nice. The documentation is seriously wonk (mostly the official Sciter documentation; the Rust documentation is just sparse), but I've managed to implement everything I need so far.
A similar option using Servo and WebRender to stay pure- or purer-Rust would be perfect!
Performance should be much better in Servo than in Electron, IF you have the proper multicore hardware. For example, Servo should be able to render a single page using multiple cores, aside from tab isolation. There is also a similar feature for CSS IIRC.
Those changes can add up, but how much exactly is still up in the air as Servo isn't exactly done baking yet. Great things take time
I'd just like to mention that a lot of applications are built using Qt (C++) and GTK, and people seem to still be quite productive 
That said, I've spent quite a lot of time on a GUI application we made at work (not in Rust) and the ownership story with GUIs tends to be... complicated. Most people work around it with either reference counting (poor man's GC) or using a garbage collected language (C#, Java, etc), but I feel like we may need to rethink how GUIs are done if we want to use Rust.
I think I have an idea for that, and it's not even mine: dataflow designs.
If you know hoe Vue.JS works (I imagine React works similarly), that's the entire idea, except in Rust. Advantage: if set up properly, it can compile to native and to the web, all without source modifications.
That just leaves the actual rendering part, and that seems to be a solvable problem given that Servo also has an all-Rust HTML rendering engine, not to mention Stylo/Quantum CSS.
well I must disagree. I havent seen a complicated GUI app written with qt or gtk. Take level editors for example. the people who write game engines in c++ wont use qt or gtk but c#. why ?
another example would be JS. JS is a horrendous langugage but people are productive with it (they have to) but it doesnt make a delight to work with it.
Have you ever used WPF or UWP with PRISM ? there is no competitor to it in qt or gtk. heck, they dont even have a proper data binding support.
If talk about 3D, Autodesk Maya is much more complex then level editors, and it is written with Qt. And if we talk about gtk+,
then of course gimp, again I suppose it is much more complex then level editors.
As I know even in small game dev team these are different people,
some persons responsible for "tooling", another for game engine.
If of course game engine is part of development, as I know in most cases rent/buy ready to use game engine is "a way to go".
...and then there are all the C++ applications which use custom GUI toolkits built on top of OpenGL and raw OS APIs. Think Blender, Adobe software, and pretty much every "serious" audio or video editing software around...
The reports of C++'s death in the GUI programming space have been greatly exaggerated.
JavaScript is slow, unsafe (in Rust's sense) and inefficient, contributing to climate change. IMHO everyone should prefer compiled languages.
Javascript is not unsafe in the Rust sense, nor is it particularly slow given a JIT.
You have a point in that there's no possibility of unsafe memory accesses, but it's still really easy to create race conditions or shoot yourself in the foot with shared mutable state.
Most JavaScript codes don't use SharedArrayBuffer. JavaScript without SharedArrayBuffer is safe in the Rust sense.
Type confusion is unsafe in the rust sense and type confusion is an essential part of JavaScript.
I haven't seen any fast JavaScript application so far. Maybe those JITs just exist only in theory. There are plenty of desktop applications out there supporting my argument, e.g. Telegram desktop, Visual Studio Code, GNOME shell, Firefox addons, ….
For example, GNOME Evolution or KDE's KMail.
Telegram Desktop not built using javascript but C++(Qt)
No. unsafe is far more specific than "type confusion"- no amount of "type confusion" in Javascript will ever lead to use-after-free, double free, buffer overrun, null pointer dereference, or anything else that safe Rust protects you from.
The one exception, as @Michael-F-Bryan noted, is data races in SharedArrayBuffer. However, these data races do not actually lead to unsafety as they would in Rust, because any garbage data produced by one will still go through bounds checking or some other filter that maintains safety.
Javascript certainly has TypeErrors that Rust might not, and shared mutation that idiomatic Rust might not (but which Rust can still express). It is certainly less straightforward to get good performance out of Javascript, and it that performance is less predictable. But Javascript is not unsafe in the Rust sense, nor is it "slow" in some platonic, context-free sense, nor is "type confusion" an "essential part."
The discussion went in another direction. The question was: are we gui yet ?
The answer is a firm "no", but the language is extremely well suited for performant desktop applications.
The lack of a GUI working group coordinating effort behind, for instance, limn, seems to belie a lack of interest among the more experienced Rustaceans. Especially when an already-strong area like CLI has a bustling WG.