Why did we choose Electron

    Prehistory


    We are a small team of developers, we are creating a new tool for working with API Testmace . In fact, this is an advanced rest client with the ability to create automated API tests using a graphical interface, equipped with such nice things as an advanced variable mechanism, autocompiles in all input fields and total syntax highlighting.

    I want to tell you about how we came to Electron as a technology for writing our application.

    Why desktop


    In the past 10-15 years, the web has experienced explosive growth and continues to grow rapidly. Constantly there are more and more new tools for creating more and more functional and complex web applications. Even whole programming languages ​​are created, sharpened for writing web applications and practically having no ready-made solutions outside this area. Yes, and in our daily life, we have partially replaced the microsoft office and thunderbird with google docs and gmail interface.

    However, the web can not yet completely replace desktop applications, and for some reason:

    • Insufficient responsiveness of web applications. There is client-server synchronization and slow Internet somewhere to blame, somewhere the single-stream nature of javascript, and somewhere just the gluttony of the browser on your not very powerful machine. It is worth noting that the solution of the above problems is only a matter of time. In particular, web workers are already supported by all modern browsers, which partially solves the problem of lack of multithreading, and features like SharedArrayBuffer reduce the overhead of copying memory between the main stream and workers.
    • Access to local system resources. There are whole classes of applications (file managers, tweakers, daemons and services) that cannot be implemented as web applications (at least at this stage of development).
    • The limitations of the browser itself. For example, network interaction is limited only by sending an http request and connection via web-sockets. More low-level things (tcp, upd sockets), alas, are not available.
    • Artificial restrictions of browsers for security purposes. CORS, work with cookies, restrictions on sending headers.
    • A limited set of languages ​​and approaches. Unlike web applications, where javascript remains the only language for writing applications, desktop applications allow you to use any programming language up to assemblers, use system resources efficiently, using multi-threaded programming and low-level instructions. It should be noted that the situation is improving on this issue - transpilers from some languages ​​appear in javascript. Moreover, compiling into a webassembly allows you to transfer developments from other languages ​​(C ++, C #, rust, etc.), often getting a good performance boost.

    Considering the reasons listed above, we can conclude that TestMace should be a typical desktop application:

    • We need access to the file system to work with the project.
    • The fetch constraints do not allow for full control over the configuration and execution of the query.
    • In the future, we may need low-level optimizations to improve application performance.

    Technology selection


    We decided that our application will be desktop, however, have not yet decided on the language and technology on which we will implement it. As for programming languages, we have the following requirements for them:

    1. This should be a language with static typing.
    2. The language should have a large and mature infrastructure - there should be both proven libraries and support from the IDE and other tools.
    3. Language should be familiar to most team members.

    The last point is also important. We, as a startup, are interested in the quickest (within six months) launch of a product to the market, making maximum use of the team’s internal resources. Learning a new language and infrastructure reduces the predictability of planning and is fraught with mistakes in making certain decisions.

    Anyway, the list of requirements does not seem too rigid, and such languages ​​as C #, TypeScript, Go satisfy it. Further selection of technologies will be carried out taking into account the availability of implementations of the necessary components for these languages.

    Much more interesting is the situation with the choice of solutions for the development of the user interface. The requirements for them are as follows:

    1. Cross-platform (Windows, Linux, MacOS)
    2. Rich set of both built-in and third-party components
    3. Component customization
    4. The presence of a markup language to describe the interface
    5. Good support

    Consider which solutions are suitable for these requirements.

    Qt (Qml)


    Qt is a powerful toolkit for writing cross-platform applications. In the latest versions of this framework, the Qt Quick component has appeared for writing applications using the declarative markup language QML. Qt in general and QML in particular are proven solutions in battles that have found their application in almost all areas - from embedded to software shells of operating systems.

    The main programming language in Qt is C ++ (javascript can be used in QML). However, for Qt and QML there are binders for other programming languages ​​(for example, for C # ). However officiallyonly integration with python is supported. All the rest are third-party implementations. Agree, I would not want to trust the most basic part of the application library, which is developed as a hobby by a small group of enthusiasts.

    There is also a Brig project . This is NodeJS binding for QML. A distinctive feature of this project is an impressive demo . However, as it often happens in open source projects, the authors do not pay enough attention to the project and therefore it also leaves the race.

    GTK


    The library for building the user interface, which began as part of the GIMP project and was subsequently allocated as a separate project. There is a tool Glade for rapid development of the user interface. The main language for developing GTK is C, however there are binders for many popular programming languages . Moreover, using C # bindings , MonoDevelop was created - one of the most powerful IDE for C # development. However, after a closer look, we understand that the GTK # project is in a semi-abandoned state - the last commit was in February 2018, the next in January 2017 and then in 2016. By commit per year. Sparsely, given that the main gtk repositoryactively developing. And happiness was so close ...

    Electron


    Recently, a lot of noise associated with this framework. Someone praises him for the opportunity to transfer the experience of web applications to the desktop, someone hates for excessive gluttony. And those and others can be understood. Electron under the hood uses the node.js and rendering library from Chromium. In essence, a normal web application is created and wrapped in an executable file. And each application comes with its own version of Node.js and Chrome.

    In fact, there is only one minus, but rather serious - this is a large (compared to other technologies) memory consumption: an empty project takes 100-200 megabytes in memory. For some, this is the reason to stop using such applications (hello, Skype). However, let's analyze the market situation. At the moment, manypopular applications are written in Electron (Slack, Skype, Discord, VSCode, Atom, Postman, Insomnia, etc.). Many of them are standards in their field or are rapidly gaining the hearts of users (such as, for example, the same VSCode and Insomnia). People simply use tools that solve their daily tasks well, despite some side effects. On the other hand, computers are becoming more and more powerful (at a minimum, the growth of RAM has not stopped ), and fewer and fewer hear testimonials from disgruntled customers that “your chrome ate all my memory. In summary, we believe that the increased consumption of RAM will not play a big role if the product is really good in its field.

    The advantages of this technology are obvious:

    1. The ability to use developments from the web.
    2. Easier to find experts in this field.
    3. Spent vorkflow "designer" - "layout designer" - "programmer", replete with handy tools at each stage.

    We also attribute to the advantage the fact that the team has extensive experience in creating front-end applications.

    As a result, we settled on Electron as the main tool for developing our project. Automatically, we chose TypeScript as the language for developing the application.

    Conclusion


    One of the main tasks of a startup is to bring the product to the market as soon as possible. Cool, if you can do it with minimal cost. The purpose of this analysis was to find a tool that would allow us to solve these problems. In our opinion, Electron is perfect for us. Three months after the start of development, it is still out of competition, and it looks like we are all serious.
    Tags:

    Also popular now: