Mist: Any version not requiring node? Maybe Qt?

[Goddard]

Node type: geth/eth
OS: linux/windows/osx
Network type: main/test
Mist version: 0.0.0

Please check the already existing issues, before creating an issue. We would like to keep duplicates at a minumim.
Read the https://github.com/ethereum/wiki/wiki/Mist-Troubleshooting-Guide first, where we summarized a few of the known issues.

Add the following to issue, when possible:

• Screenshots
• Check the console, of Mist (CTRL/CMD + ALT + i) and take a screenshot.
• Log files (as ZIP archive)
• osx: ~/Library/Application Support/Mist/node.log (Open Home folder > Show View Options > Show Library Folder)
• windows: %APPDATA%/Roaming/Mist/node.log
• linux: ~/.config/Mist/node.log

[luclu]

The QT-version of Mist has been dropped in favour of Electron (Chrome, node). The standard-dapp framework was decided to be meteor (node).
Perhaps a plain node with RPC/IPC-interface will suite your needs.

[Goddard]

Did anyone do performance testing? Every time I use an electron/node based application it is riddled with performance issues.. often worse then Java... Not trying to troll. Just curious.

[bas-vk]

Hi @Goddard,

I can elaborate a bit on that. First some explaining why we choose for electron. The first experiment was a QT/go based native version. The QT-bindings had a lot of problems and integrating something that should be trivial such as a webview turned out to be a nightmare, especially on windows. Going further into that direction would lead to a path with a lot of problems.

Back then it wasn't clear if Ethereum would be a success. Almost all of the available resources where aimed to get the mainnet live. The team who would be working on Mist was very small and had a lot of other tasks. The decision to go for electron/node was therefore strongly influenced by the capacity and skills of the team. We know that we would have to make sacrifices if we go with electron. Not just on performance but also on delivering something that is nice to use. But if we want to deliver a wallet/mist that works on all 3 major operating systems and provides a decent user experience this was the best option.

Regarding your point on performance. There are 2 sides to this:

1. the node, synchronizing takes way too long and uses a lot of disk space. In the long term we would have a light client that solves this. In the short therm, geth 1.5 will be about performance improvements and we try to release that within a month (this is not a promise, 1.4 took way to long and we learned from that).
2. electron, most performance problems occur with the dao contract. Mist is aimed to provide a general DApp environment. For 99/100 of the DApp's the performance of electron is more than enough. For those special cases it may fall short. We are working on improvements, @hiddentao is currently working on creating a better node integration which will reduce code complexity and adds better tracing, @alexvandesande has added caching which helps to reduce the number of writes. These things can improve things but I cannot give you any guarantees things like the dao contract will work flawless.

It is actually hard to do performance testing. How would you define and execute a representative performance test?

[alexvandesande]

Great write up Bas

[Goddard]

With a simple application I can understand why you would go with what ever you feel comfortable with, but in my experience all the electron/nodejs apps are so bad and use way more resources then a comparable native application written in c++. Qt provides QML was that not good enough? It supports 3D programming and OpenGL. Qt and Go do not pair well in my experience unless you are creating your own library/bindings which makes me wonder why you wouldn't just use C++ itself for everything.

The Qt library supports synchronous and asynchronous communications QIODevice. Lots of other sub-classes of that as well. If you wanted to create a performance test I am not sure which way you would create a apple to apples comparison other then simply create a client/server example.

Just to list a few, VSCODE, Atom, Popcorn Time, and many of these new applications are easily 3 times as large on disk, use 2 times more ram, and to develop require downloading a huge amount of random unverified code onto your system that could have any number of vulnerabilities in it.

I am not trying to troll you guys, but it just doesn't make sense to me. Thanks for your comments.

[bas-vk]

Most of your comment is about which technology would have been better. And yes, you have a point if you look it at from that point of view. As explained, our decision was heavily influenced by practical stuff such as which skills do we have and how fast can we deliver something that works reasonably good. If the Mist team was big enough we probably have gone with a native application. In fact, we decided that we would do an evaluation later and see if electron is still a good fit.

The Qt library supports synchronous and asynchronous communications QIODevice. Lots of other sub-classes of that as well. If you wanted to create a performance test I am not sure which way you would create a apple to apples comparison other then simply create a client/server example.

Electron should be more than fast enough to handle almost all DApp's just like the chrome browser is able to open several tabs without problems.

Just to list a few, VSCODE, Atom, Popcorn Time, and many of these new applications are easily 3 times as large on disk, use 2 times more ram, and to develop require downloading a huge amount of random unverified code onto your system that could have any number of vulnerabilities in it.

I don't think for a modern desktop application the current size of Mist is really an issue. Most serious vulnerabilities are the one's that are exploitable without the user doing anything special. And I consider developers special. The biggest risk is a DApp that is able to exploit a bug in chromium, break out of the sandbox and steal your keys and passwords. As long as you run untrusted code this will always be an issue, regardless which technology you wrap it in. I believe that chromium has a decent track records if it comes to security (the servo project looks very promising). This problem is similar if you use QtWebEngine.

[alexvandesande]

I've built Mist for a couple of months using Qt. My personal opinion is that Qt is a terrible tool for building interfaces, the markup is nonsensical and the results are atrocious unless you put a lot of work into it.

Sure, performance is degraded by Electron? A bit, but the overall experience is much better. Of course, some people might not care about the UI and think performance is all there is, but I'm not one of these people, and I'm targeting users who will care about it.

[Goddard]

@bas-vk ahh I see. Makes sense. I usually just render native elements and then pull in the data from the ether rather then display a web page.

@alexvandesande I don't think it is nonsensical and atrocious. Qt is one of the best designed C++ library and tool stacks around in my opinion. Qt Creator 4 was just released as well and it just had a UI re-fresh. The stack is so simple it puts things like XCode and VS to shame. It is not web design if that is what you mean. Looking at the interface of the current version I would think it would only take a day or two to mimic completely with either QML, or the more traditional ui elements.

I don't want to put down your choices as I was just curious why people make the choice to use electron.

I've just noticed a lot of these apps being made and all experience with them has been poor. I can understand the desire to use these technologies though. Especially since web designers are so pervasive nowadays and a comparable UI designer is probably harder to find.

I will look into the things you said in regards to Qt and take them back to the community. Again thanks for your comments.

[alexvandesande]

@Goddard of course that has been my experience, and I have a CSS background so maybe some of the things I found weird were simply different opinions. Maybe had we hired a QT specialist or maybe if we all dived deeply into it, we would get a better understanding.

But in the end we have to use our strengths, and Qt wasn't helping us.

[lock[bot]]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.