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.
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:
- 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.
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:
- It should be statically typed.
- It should have huge and mature ecosystem: there should be both tried and tested libraries and IDE and other tools’ support.
- 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:
- It should be multiplatform (Windows, Linux, MacOS)
- A full set of build-in and external components
- Customizable components
- Markdown for interface description
- Good support
Now let’s look at some solutions that meet the requirements.
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.
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.
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…
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:
- Some things from the web-application can be reused.
- It is easier to find professionals in this sphere.
- 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.
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 3 months since we’ve started working on the project, and Electron still has no rivals. It seems we’re getting serious here 🙂