In the last article we made a short introduction of our product. Today I’d like to tell you why we chose Electron for building our application.

Why Desktop

The web has been growing rapidly for the past 10-15 years. We stumble upon new tools for creating more functional and complex web applications every now and then. There even exist specific programming languages for web development that virtually have no ready solutions for other fields. In our everyday life we have already partially replaced Microsoft Office and Thunderbird with Google Docs and Gmail interface.

However the web can’t yet completely drive desktop out for a number of reasons:

• Low web applications responsiveness. It may be caused by either client-server synchronization or poor Internet connection or single-threaded JavaScript or simply your resource hungry browser if your machine is not powerful enough. It should be noted that the problems mentioned above are to be solved, it’s just a matter of time. Web workers, in particular, are already supported by all modern browsers that partially deal with the multithreading problem, and features like SharedArrayBuffer allow to reduce memory copy overhead between the main thread and workers.
• Accessing local system resources. There are certain application classes (file managers, tweakers, daemons, and services) that can’t be implemented as web-applications (at least at the current state of their development).
• Restricted browser features. For instance, networking is restricted to sending http-request and web-sockets connection only. Lower-level things like tcp, upd-requests are unavailable.
• Intentional browser restrictions in terms of security. CORS, working with cookies, headers restrictions.
• Limited set of languages and approaches. Unlike web-applications, which are only written in Javascript, for desktop applications it is allowed to use any language up to assembler to achieve efficient use of system resources with the help of multithreading and low-level instructions. One should note that the situation is being improved – say hello to transpilers from some languages to JavaScript. Moreover, compilation to WebAssembly allows to transfer your code from other languages (C++, C#, Rust, etc.) and often to enjoy significant performance improvement.

So, we can conclude that due to the above mentioned reasons TestMace should be a typical desktop application:

• We need to get access to the file system to work with projects.
• Fetch restrictions do not allow us to get full control over configuring and sending requests.
• We might need low-level optimizations to improve performance in the future.

Choosing a Tech Stack

As we decided that our application should be a desktop one, we still need to choose the language and technologies we are going to use to implement it. As for the programming language, requirements are the following:

1. It should be statically typed.
2. It should have huge and mature ecosystem: there should be both tried and tested libraries and IDE and other tools’ support.
3. The majority of the team members must be familiar with the language.

This is quite important. As a startup, we are interested in a fast product launch (in half a year), taking full advantage of internal team resources. Learning a new language and its ecosystem makes planning less predictable and may lead to certain mistakes in decision-making.

Nevertheless, the requirements don’t seem so strict, and some languages as C#, TypeScript, Go meet them. We’ll be choosing technologies taking into account if there are implementations in these languages.

It is way more exciting to choose software for user interface design. Requirements are the following:

1. It should be multiplatform (Windows, Linux, MacOS)
2. A full set of build-in and external components
3. Customizable components
4. Markdown for interface description
5. Good support

Now let’s look at some solutions that meet the requirements.

Qt (QML)

Qt is a powerful toolkit for creating multiplatform applications. The latest versions of this framework contain Qt Quick component for writing apps using the declarative markup language QML. QT in general and QML in particular – are battle-tested solutions, that are used in almost all software development fields – from embedded systems to operating system shells.

The main programming language of Qt is C++ (JavaScript can be used in QML). But still there are bindings to Qt and QML for other languages (here is for C#). However, only integration with python is officially supported. Everything else is just a third party’s implementation. And surely you won’t base your application on the library, that was developed by a small team of enthusiasts in their spare time.

There also is Brig – NodeJS bindings for QML. What is so special about the project is its impressive demo. Yet, as it often happens with open source projects, developers do not pay due attention to their product, so it is also out of the game.

GTK

This is a user interface design library, that initially was a part of the GIMP project and then became a separate project. There is the Glade instrument for nice and easy UI development. The main language for GTK development is C, there are bindings for all popular languages though. Besides, MonoDevelop – one of the most powerful IDE for C# development – was created with the help of C# bindings. Unfortunately, going deeper we see that the GTK# project got dusty – the last commit was in February, 2018, then – January, 2017 and 2016. One commit a year. It’s nothing, given the main GTK repository is being actively developed. So close…

Electron

There has been so much fuss about this framework. Some like it for opportunity to transfer parts of their web-applications to desktop, others – hate it for being so resource hungry. Both sides make sense. Electron uses Node.js and Chromium’s rendering library under the hood. Basically, you create a typical web-application and wrap it into an executable file, and every application comes with its own version of Node.js and Chrome.

There is only one major disadvantage – high (compared to other technologies) memory usage: a blank project takes 100-200 MB. Some would consider that to be a reason against the apps like that (hello, Skype). But let’s analyze the market. A lot of popular applications are built using Electron (Slack, Skype, Discord, VSCode, Atom, Postman, Insomnia, etc.). Many of them are standards in their fields or are conquering users’ hearts (VSCode and Insomnia, for instance). People just use the tools that are good at solving their everyday tasks and ignore some side effects. On the other side, machines are getting more and more powerful (at least, RAM continues to climb), and less clients complain that “Chrome eats all RAM.” In summary, we reckon high memory usage will be quite irrelevant if the product can do the job well enough.

The advantages of Electron are quite obvious:

1. Some things from the web-application can be reused.
2. It is easier to find professionals in this sphere.
3. A proven workflow ‘designer – layout designer – developer’ with plenty of useful tools for every stage.

Another benefit of ours is that the team has substantial experience in front-end development.

We eventually decided to go for Electron as the main tool to develop our project. That also means we had to choose the TypeScript language for our application.

Conclusion

One of the main goals of the startup is the fast product launch, and, of course, we’d like to minimize the costs. This review was aimed at finding the tool that would help us in that. We believe, Electron is the best choice here. It’s been 1 year since we’ve started working on the project, and Electron still has no rivals. It seems we’re getting serious here 🙂

💥 Bonus 💥

Also we’re glad to give you 👉 special 50% exclusive offer 👈 for TestMace professional version which includes a built in cloud synchronization for you team! The promo code is: ELECTRON_BETTER. Promo code is valid for only two days! Have time to try the full power of professional tool for working with API! 💪