Sep 21, 2017 In this lesson, you will learn how to build native desktop apps with Angular and Electron.You might be surprised how easy it is to start building high-quality desktop apps for any platform, or even port your existing Angular app to native desktop platforms.
![](/uploads/1/2/6/5/126591632/223795459.jpg)
This list of features on the Electron webpage is setting high expectationsI’m a big fan of Electron and thought the following list could be very helpful for people who are new to the topic. But project managers who are evaluating different stacks and want to avoid “surprises” should benefit as well. The list presents things that are not completely clear in the beginning. Things where it’s worth to spend some extra time on evaluation before a decision and long term commitment is made.
InstallersOnce the coding is over and the release planning starts, the first tough decision is waiting. One can either use the installer and update mechanism as described in the Electron documentation or use the installer and update mechanism that one of the best builder tools (electron-builder) recommends. The suggests the Squirrel (Windows and Mac) installer and the built-in autoUpdater. An open source is available which handles the server side management of updates and releases.The other option is “electron-updater”. It is based on the established NSIS installer (Windows) and plain old mac packages. Electron-builder uses this approach as the default setting for all generated installers.The Electron and electron-builder project do very much disagree on which solution is better. This leads to a tricky situation where devs have to decide between one official solution (which many consider to be complicated and not flexible enough) and a simple and powerful one that has built-in tool support.
![Mac Ui For Electron App -photon Mac Ui For Electron App -photon](https://1175654.v1.pressablecdn.com/wp-content/uploads/2016/09/terminal-icon-300x300.png)
Personally, I think electron-builder is a blessing if you actually plan to provide installations of your software to millions of people around the world and you don’t know where to start. This can be quite confusing and shocking, but cheap and easy multi platform builds are a myth. It is almost ironical how often one will find “cross platform” Electron applications that are “only for Mac” or “only for Windows”. The reason is not that it’s complicated to write code for multiple platforms (Electron handles it amazingly well and the documentation is clear). The reason is simply that many developers do not have the big budget or access to other hardware to test and build on. Even worse: if you plan to be a “legitimate developer” your app needs to be signed and it might have one or more native dependencies.The recommended solution in these cases is to get accounts for different CI providers: one for Mac (and Linux) and one for Windows.
Because Apple officially prohibits the use of their operating systems. in Virtual Machines on Non-OS X systems. on non-Apple HardwareThe result is that if your app is closed source it will cost twice as much to build for two OS.
And if money and a complex build system is not and issue, you still have the issue that the app will only be tested and built on multiple systems. At this point it cannot be shipped yet. Signing your app remotely with an Extended Validation (EV) code signing certificate for example is pretty much impossible with all existing CI tools available since your certificate is bound to a physical hardware token which cannot / should not be transferred. SizeThe fact that each application comes with its own version of Chromium (the 20 million LOC, 30MB packaged Web runtime) is one of the most criticised aspects. Fun fact: if you would decide today to build your own simplified competitor version from scratch it would probably take you.
Some have tried to and critics say it creates the feeling of installing a full operating system on top of an operating system. Not an issueWhile many people would expect Chromium to drastically slow down the performance or “consume precious RAM” I haven’t experienced any of this in practice and haven’t heard bad feedback from thousands of test users. I guess it isn’t such a big issue if you are used to have the Chrome browser running in background anyways. But here is the thing:Not just installations bundle Chromium. Every update also comes with Chromium, Node and all the other Electron components unless the update is designed as delta or differential update.
Delta UpdatesEveryone who’s experienced a Windows update knows that updates suck! But they don’t have to. Updates can introduce cool new stuff, don’t have to interrupt the workflow and they can happen in the background instead of blocking your machine for one hour — I’m looking at you Microsoft. The ? is “delta updates”.
Instead of uninstalling and re-installing everything, only the relevant parts should be updated incrementally. The challenge: how to switch versions without the user noticing it (inspired by )Imagine the example: A class of students is trying out a software and the update is 70MB big.
30 people start their computers and get presented with an update. They download the update simultanously resulting in 2.1GB. Now, compare this to a delta update, handled in background, which is only 100KB in size and brings down the initial 2.1GB to 3MB total. It will shorten the time each student is waiting for the update to write itself to disk, to register with the system after the download; and it takes load from servers, saves bandwith, saves $$$, creates happy students and teachers.Squirrel, in theory, supports delta updates. As of last week, However, I wouldn’ call either one of them to be available out of the box.One of the applications I’m working on — — uses its own “delta” update mechanism which updates the whole app. The twist: the whole application without external modules and libraries is only 750KB(!) in size.
Whenever I mention this, the reactions are priceless. Most people cannot believe the small size considering the feature richness and complexity of the application. A whole desktop application that has the size of a single image is how I would describe a new generation of (Electron) desktop apps. And the way we’ve implemented updates in Autobeat is straighforward and no rocket science.Everything that can be remotely considered static is not part of the application image: jQuery, Font Awesome, Bootstrap, or all the other frontend libraries and any of the node modules are not part of the app itself.If one strips everything that is not frequently changing such as these libraries and only updates the app logic part — the things you’re actually working on — a 99.9% size decrease is absolutely possible.
However, it requires custom update logic. There is no standard solution available. The benefit: in Autobeat’s case we can update the app as a whole as long as external dependencies are not changing which rarely happens. Updates take between 1–2 seconds and go often unnoticed.
It is like updating a website — after a refresh it looks different. No need to worry that the deltas are miscalculated or parts are not working together as expected. Once in a while we add more dependencies and have to do a ”full” 31MB update. But we’re making a long term bet here, assuming that these intervals get longer and longer while our regular release cycles can be as short as a couple of hours. And everyday we are learning more about how to leverage things that work for the Web and how to bring them to desktop to release more efficiently. SecurityThe separation between app logic and libraries as described above unlocks another very powerful feature: it potentially allows to release a second app, which shares the same, existing core libraries and does not require the installation of another Chromium bundled package or the need to signand distribute a new installer. It creates an environment like a super-powered browser that supports jQuery, Vue, Font Awesome, Polymer and every other framework as well as all relevant node modules out of the box and minimizes the app’s size.
Think about it for a second.In recent tests, our team has successfully launched other “instant apps” (. “every time you download express, you favorite this exact tweet from Hot Pockets” —Recently, I was attending a talk from a well-funded startup that scans and analyzes npm modules for vulnerabilities to warn developers before they integrate them. When I asked if they would also consider npm module security in a desktop context the answer was that they haven’t looked into it and that it has no priority. But every module that we reference and install on a user’s machine comes with its own dependencies and we end up sharing the user’s trust and permissions with modules we lose track of and often don’t even know. In a time where a single cyber attack such as the recent WannaCry ransomware can have a financial impact, we are facing complete new challenges. Code ProtectionIn the same way we want to protect users we might also want to protect our own and our company’s work. Electron apps are usually distributed in asar container files.
To retrieve the plain source code from an installation and its contained asar file is as simple as:asar extract app.asar secretsourcecodeFiles don’t get obfuscated, encrypted or protected by default which means someone who wants to temper with an app can pretty much receive the working copy of the repository. This makes Electron a very poor fit for commercial solutions.
![](/uploads/1/2/6/5/126591632/223795459.jpg)