Table of contents
- What is Electron?
- Stakeholder Analysis
1. What is Electron?
The applications built from Electron consist of two types of processes: the main process and multiple renderer processes which follow a master-slave pattern. The main process of the application is the master and the multiple renderer processes are the slaves which communicate using Inter-Process Communication (IPC). Fig. 1 shows that this is analogous to a Chromium browser where there is one main window and multiple tabs (renderer processes).
Figure 1: One Main process with Multiple renderer processes. This is analogous to a window of Chromium browser with multiple tabs
Specifically, Electron looks into the start entry in the
package.json manifest included in the project to determine the entry point of the application, which runs as the main process.
Main process: The main process is responsible for responding to application lifecycle events such as starting up, quitting, preparing to quit, going to the background, coming to the foreground, and more. The main process is also responsible for communicating to native operating system APIs. For example, to display a dialog to open or save a file.  The main process can also create and destroy renderer processes using Electron’s
Renderer processes: Renderer processes can load web pages to display a GUI. Each process takes advantage of Chromium’s multi-process architecture and runs on its own thread. Unlike normal web pages, there is access to all the Node APIs in the renderer processes, allowing developers to leverage native modules and lower-level system interactions. 
At the time of writing, the stable version of Electron is 1.8.4 and all our analysis are mainly focused on the
master branch of core Electron's repository. Before doing in-depth architectural analysis let's look at the people and organizations involved in Electron's development.
2. Stakeholder Analysis
Stakeholder Analysis describes the people involved in Electron and their roles. We have categorized them according to the eleven types proposed by Rozanski and Woods.
|Developers||Core developers, Committer team and contributors||Core developers like @zcbenz, @zeke and others set policies and are the general managers. Most of the core developers work at Github (which sponsors Electron). Committers like @deepak1556 and open-source active developers like Alexey Kuzmin from Microsoft, Felix Rieseberg from Slack help the core developers with pull requests.|
|Acquirers||Core Developers at Github||The core developers and (some) senior contributors from prominent users (Alexey Kuzmin from Microsoft and Felix Rieseberg from Slack) decide the future roadmap for Electron.|
|Assessors||Developers||Developers of Electron as well as from the user organizations using Electron assess the conformance to standards and legal regulations themselves.|
|Communicators||Teachers||Electron is taught by teachers in online environments such as YouTube Videos, Tutorials and Blogs on the web.|
|Maintainers||Core developers, Contributors||The overall evolution is maintained by the core developers, and maintenance tasks by both core developers and contributors.|
|Production Engineers||John Kleinschmidt and team||Manages the production releases and runs tests on new builds. He also manages the code for Circle-CI integration tests.|
|Suppliers||Github||Github sponsors Electron and is a supplier for Electron as it provides software and infrastructure for Electron to run.|
|Support Staff||Developers, Teachers||Support for development and contributions for Electron is done through mailing lists, Slack, Discuss Forums and platforms such as StackOverflow.|
|System Administrators||John Kleinschmidt and Core developers||They control the evolution and development of the project. They also manages the code for integration tests through Circle-CI, Travis-CI, AppVeyor etc.|
|Testers||Developers, Committer team||They are responsible for the testing of new commits and builds through explicit unit and application tests.|
|Users||Developers and organisations using Electron||Electron is used in Skype, Slack, WhatsApp, Atom close to 7400 independent developer forks.|
Going beyond Rozanski and Woods classification:
The following stakeholders identified are additional stakeholders who do not match the groups in Rozanski and Woods.
Other repositories and products in Electron Umbrella project like Spectron the testing framework, i18n the home for documentation and its translations, electronjs.org the website, libchromiumcontent the content-rendering library of Chromium, node the backend component, devtron the chrome development tools and around 40 other repositories complete Electron as a framework.
End-Users are normal users who experience a native desktop app built on Electron and it indirectly influences Electron's development.
Bloggers are unambiguous and reliable sources of information who use and help new developers to use Electron.
Translators contribute to translations for Electron's documentation to different languages for its website and there are close to 300 translators (including us) who have contributed for this purpose till date.
Quantifying the stakeholder's involvement: Power vs Interest Grid
Mendelow's power/interest grid is used to classify the groups of stakeholders necessary to be managed closely. Figure 2 shows that the core developers, committer team, active contributors from prominent products like Skype, Slack, etc. using Electron are stakeholders who have both high interest and power. These are the people that actively contribute to and maintain the project and need to be managed closely. Teachers and projects that use Electron without active contributions show high interest but have low power and must be informed well. Electron’s dependencies have low interest and low power. The power of Chromium is slightly higher because it influences Electron's future developement as explained in the development viewpoint.
Figure 2: Power Interest Grid of Electron where the interest of the stakeholder is shown on the horizontal axis and the power of the stakeholder is shown on the vertical axis.
In this section, we describe the architecture of Electron based upon various (1) views and (2) perspectives. According to Rozanski and Woods , a view is a representation of one or more structural aspects of an architecture that illustrates how the architecture addresses one or more concerns held by some stakeholder and an architectural perspective is a collection of activities, tactics, and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’s architectural views.
In this section, we describe the context, development and deployment viewpoints of Electron.
3.1.1 Context Viewpoint
Figure 3: Context View of Electron showcasing relationships with its environment
Some prominent findings from the context view diagram are:
Integrators are the active core developers from Github. The are the architects of the Electron and their merging their challenges and merging strategies are explained in the Evolution Perspective
Users are organizations and developers of cross-platform desktop applications using Electron. The communicators are the link between users and Electron's developer community.
Testing Frameworks and Continuous Integration: Spectron is the testing framework for Electron apps. Travis and Jenkins are the CI systems for testing new application build using the virtual display driver for Chromium.
GitHub sponsors the entire project and provides infrastructure for version control using git and issue tracking with Github issue tracker.
Target Platforms: The Electron apps are built on/for MacOS, Windows and Linux platforms. The Packaging tools allow for automatic packaging of Electron apps for these platforms.
Add-ons like Native Node modules, Pepper Flash plugin etc. are supported by Electron and enhance the features of developed applications.
3.1.2 Development Viewpoint
Electron combines Chromium's single thread multi-process model and Node's single thread event-loop model into single runtime. As a consequence, Electron design patterns resembles its two primary dependencies namely Node.js and Chromium Webkit. Electron includes customized forked embeddings of Chromium and Node modules to keep its size small. Electron application's design pattern is similar to the master-slave pattern as discussed in section 1.
The layered architecture shown in Figure 4 gives a very high-level overview of Electron and applications built using Electron. In this section, the development view of Electron's core is summarized using module organization and dependencies, common design models and codeline models
Apart from reducing size, the customized forked embeddings of Chromium and Node removes the need for external interfacing dependencies, and improves speed and performance through preconfiguration of dependencies. The module organization in Figure 5 demonstrates high cohesion through Electron Core block and low coupling as demonstrated through custom embeddings of the dependencies in Electron extensions, which is an example of good software design.
electron/electronrepository and the other 45 repositories where the links to external dependencies are shown in color blue whereas internal dependencies in Electron's core are shown in green.
Now we explain the 3 blocks in the diagram:
Electron embeds different Chromium modules like
libchromiumcontent, the content-rendering module. Other examples are
native-matewhich makes writing JS bindings easy, and automatically converts V8 types to C++ types, and
pdf-vieweris a fork of Chrome's pdf extension to work as
The custom embedding of Node runtime environment handles the interactions between with the native OS and various add-on node packages. Electron also uses some node packages for internal use like
node-minidumpis used to process minidump files, and the full list can be seen in .
All of the Electron's documentation and translations are collected in i18n repository as a large JSON object in every language. The JSON object from i18n repository is used as content in the electronjs.org website.
Native OS installers are modules developed for different native operating systems on which Electron can be installed like
windows-installerfor the Windows operating system. Electron apps can be packaged to
Asarformat which is a tar like archiving format providing advantages of mitigating issues like long file names in Windows, speeding up
requireand concealing source code from cursory inspection.. Electron supports native Node.js module injection using
electron-rebuildwhich rebuilds native them against the currently installed Electron's version.
Framework Modules and APIs for applications: In applications, Electron APIs can be used for both the main process and renderer process. Node APIs are available globally, while only DOM/Browser APIs are available in a renderer. Based on Figure 6 and the API documentation , the following is an overview of some common APIs used:
- Main process:
- Renderer process
- Common APIs
- Script,spec and tools modules:
scriptcontains scripts used for development purposes like building, packaging and testing.
speccontains automatic tests for the framework APIs (main, renderer and common), packaging formats (asar), version checks etc.
toolscontains non user centric helper functions. The framework (API) modules use
toolsas helper functions and
specfor creating automatic tests.
Common Design Models
Commonality across the different versions of Electron is done by defining a set of strict design constraints that are followed in Electron's development.
Termination and restart of operation on the framework during application development is with the
main process. For applications, the app API that controls the application's event lifecycle is responsible for the termination and restart operations.
Message Logging -
crashpadis a Chromium project used for capturing, storing and transmitting postmortem crash reports from a client to an upstream collection server for diagnostic purposes[14, 15]. For applications, communication between the main and renderer processes are done as IPC messages using the
Internationalization - Electron's developer community is worldwide and thus Electron's documentation is translated into different languages under the Electron-i18n project. Moreover, to facilitate better contribution and maintain a supportive, active community the conduct of conduct states,
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
Internal and external interfacing in Electron is applicable to both the framework and application APIs. In the framework, the different code modules and method invocations between the framework are internal interfacings whereas the Node and Chromium modules used the account as external interfacing. In applications, the API bindings between the main process and renderer processes are internal whereas additional Node packages that are used on applications as add-ons are the external interfacing.
Standardization of Design: Electron's development guide documents the steps for issue creation, contributing to issues, making pull requests in accordance to the conduct of conduct which is adhered by every developer and contributor. This section briefly summarizes the design standards laid out for Electron.
Issues is the first stop for either a developer, contributor or a user to get technical assistance with build-specific issues like compilation errors, display errors, system crashes, etc. The issues found on the repository of Electron, are generally resolved within 3-7 days .
Pull Requests facilitate the contribution to addition of new features, modification of existing features or bug fixes for a particular feature of Electron. There is an official documentation for pull requests which standardizes the steps to be followed for submitting a new pull request to Electron. Every pull request is subjected to a Continuous Integration (CI) check and the merge pattern involves thorough code review and discussion with contributors.
Coding Styles standardizes formatting the source code making it easy to read and understand by the contributor community.
- Electron is mostly written in C++ with some flavours of Objective-C codes which is styled based on Chromium's C++ Style Guide. Electron uses the
clang-formatfor formatting C++ source code.
- Electron uses Python version 2.7 as per the documentation for generating projects, follows the Chromium Coding Style and uses
script/cpplint.pyscript to check code formatting to conformance.
- Electron is well documented and is written entirely on Markdown with the Github style. A node package called
electron-docs-linterdeveloped to ensure that documentation changes are formatted correctly and can be used as
npm run lint-docs
- Naming Conventions for files and variables in the source code is a good design practice which makes the code base consistent and stable for continuous development. In Electron, file names should be concatenated with
_and naming variables in code is similar to Node.js as Electron APIs uses the same capitalization scheme.
- Electron is mostly written in C++ with some flavours of Objective-C codes which is styled based on Chromium's C++ Style Guide. Electron uses the
Standardization of Testing: Testing in Electron can be done in the framework and application levels. In this section, the tools used in Electron for testing is discussed,
Framework Testing in Electron is a continuous testing framework to maintain stable builds. Electron uses Jenkins for continuous integration tests on builds in Mac and Linux, AppVeyor for Windows, and Circle CI for pull requests.
Application Testing - Spectron is a testing framework built upon WebdriverIO with helpers to access Electron APIs in tests and bundles ChromeDriver. WebDriverJs and WebdriverIO provide Node packages for testing with web driver. Devtron, is a Electron Dev Tool developed on the Chrome Developer Tools for developers to inspect, monitor, and debug their Electron apps . Devtron can be used to visualize dependency graphs, inspect the events and event listeners registered on the Electron app, monitor the IPC messages between the main process and renderer process and check the application for consistent code styles or linting.
According to Rozanski and Woods, the codeline models describe the source code structure, release process, configuration management, build and testing approaches.
Source Code Structure: The source code organization structure of Electron is compliant with Chromium's Multi-Process model . For example,
atom/(C++ source code) and
common/which contain submodules for main process, renderer process and main and renderers (both) respectively. All the scripts are maintained
scriptfolder. These are examples of classic Chromium style coding. The
third_partydependencies of Electron such as Node and Chromium's
libchromiumcontentare found under the
/vendorsub-directory to prevent a naming conflict with Chromium's Source Tree . The complete directory organization of Electron based on the docs  with some additions to match the current repository is made below:
Build Approach: Electron uses gyp for project generation which is built using ninja-build. The binaries of third-party frameworks that are used in Electron but are not supported in
gypbuild are found in the
Release Process: The release process begins with the selection of the Release Candidate (RC) branch. In the RC branch the
prepare-releasescript is run to perform checks, update version number and auto-generate draft release notes. After the
prepare-releasescript execution is done, the release notes are compiled with major and minor changes done on the code base. The release takes place after the completion of the release draft and the release branch is pushed/ published.
Configuration Management: Electron is managed on Github and new versions of Electron are released through Github releases. Github provides a powerful version control system to maintain the source code which supports repeatability via branches and commits. The technical integrity of the main code is preserved as the master branch is always version-less. The configuration structures used are repositories, branches, labels, tags, milestones, issue trackers and pull requests.
3.1.3 Deployment View
In the previous sections, a view of the dependencies which make Electron work is described. This section summarizes the system requirements and additional frameworks to successfully run Electron. We now explain the Figure deployment view of Electron as illustrated in figure 7.
Third-party software requirements: Electron uses different Chromium modules and Node packages, like
libchromiumcontentfor content rendering,
node-minidumpfor processing minidump files, and other packages like
Chromium's Crashpadfor message logging. There is also a collection of binary frameworks that are bundled by Electron for making it truly cross-platform. These assets are downloaded as part of Electron's bootstrapping process and form the third-party system requirements for running Electron apps.
Operating Systems: Electron is built on Node and Chromium which are cross-platform which makes Electron and applications built-on it cross-platform. Thus, Electron is supported on Windows (both
64 bitversions from Windows 7 and above), macOS(
64 bitof macOS 10.9) and Linux (
64 bitversions of Ubuntu 12.04 and later, also works on Fedora 21 and Debian 8)
3.2 Architectural Perspectives
We give an overview of evolution perspective of Electron and also depict some interesting facts about the analyzed technical debt related to it. We then describe the security perspective of the Electron.
3.2.1 The Evolution Perspective and the related Technical Debt
Electron started as a fork of NW.js for building GitHub's Atom editor and was called Atom-Shell in 2013. The project was developed a Cheng Zhao, an intern at GitHub. By spring 2014, Atom and Atom-Shell branched out into two separate projects. Atom-Shell was renamed as Electron in 2015 and in 2016 Electron reached version 1.0 with the support to publish apps to Mac and Windows App Store. In the perspecitve of technical debt(TD), this is an indication of single-point of failure in terms of only one contributor Cheng Zhao, which can be inferred from the code additions to the project in Figure 8.
After 2015, around the time when Electron branched out from Atom more core developers like @zeke joined and the single-point of failure TD started to reduce gradually as seen in Figure 9. To minimize TD in the code level the core developers standardized writing and testing contributions to ensure stable builds which has helped Electron develop at a rapid pace attracting many new contributors to the project.
Figure 9: Electron's development timeline
From Rozanski and Woods 3, the evolution perspective is defined by:
Magnitude and Speed of Change: At the time of testing, the stable version was
1.8.4. Given the speed of evolution for Electron and still staying at the major version
1.x.xfrom 2016 till Spring 2018 indicates stability of the platform. This indicates that the magnitude of major change in Electron is long-term and minor releases are short-term in nature.
Product Management/ Integrators are the architects of the Electron. The core developers at Github like @zcbenz,@zeke and @ckerr are the integrators. Their challenge is to keep Electron releases stable as only pull requests (PR) that pass all the continuous integration checks and review requirements are merged. The code reviews are done by the integrators and there is a thorough discussion on the proposed change to make sure that the integrator and the contributor are on the same page, and this results in maintaining quality across contributions. PRs are subject to CI checks on CircleCI, Appveyor, Travis and Jenkins for different OS so that the changes are non-breaking, forward and backward compatible across all Electron versions and satisfy the contributing guidelines like linting of code, etc.
Dimension of Change: Platform evolution are the major version updates like
v2.0.0in which even the versioning strategy has changed to
semver. This requires Electron to change for every major update of its dependencies (Node and Chromium). The functional evolution is periodic through patch and minor version increments.
Changes driven by External Factors: Electron evolves with the version of Chromium which is used for rendering the GUI components. Since, Electron uses custom embeddings of its dependencies the Chromium update could be done at a later time and need not be an immediate one. But when the Electron 2.0 arrives, Electron will conform to
semverwhich requires Electron to change for every major update of Node and Chromium.
At the time of writing this chapter the major update version 2.0.0 is in the final stages of development and we analyzed the technical debt on the versionless
master during an impending new version release. The tools used were:
|Name of Tool||Purpose|
|SonarQube||Code smells, code duplicates, finding bugs and security vulnerability|
|Github Insights||to find indicators of technical debt from contributions and contributors|
Results from SonarQube
Following are the results we got from using SonarQube to assess the code quality of core electron repository:
Afor all files except one testing file. Hence, we can say current version of
masterof electron is maintained pretty well.
- Duplicates: There are only 4% duplications found which again comes from testing code. Our analysis states that these duplicates cannot be avoided due to the nature of
describe-itstatements in Mocha and Chai testing frameworks.
Still, one can say that testing methods have a little bit of technical debt in terms of code smells and duplicates but electron developers do discuss about these through TODOs and FIXMEs as explained in point 4 below.
- Bugs and Vulnerabilities: SonarQube detected 15 bugs and 3 security vulnerabilities. The bugs were related to coding style such as defining functions outside loop and argument mismatch. Only one of them was critical in nature and was related to how
evalfunction was used at runtime to call an object's property. The solution is to call the object's property at compile time. It also estimates security remediation would take only about an hour to fix all three of them. Again, this is extremely low number of bugs and security warnings compares to the size of electron.
Results from github-grep for TODOs and FIXMEs
The developers of Electron do discuss about the technical debt there is and they communicate through code as well as github issue tracking by mentioning TODOs and FIXMEs. We used
github -grep to find TODOs and FIXMEs in the code. In total there were 79 TODOs and 46 FIXMEs found. Each of them decribed who wrote it and/or who will fix it. Examples are shown below:
atom/browser/api/atom_api_app.cc: // TODO(juturu): Remove in 2.0, deprecate before release
chromium_src/chrome/browser/process_singleton.h: // TODO(brettw): Make the implementation of this method non-platform-specific
spec/api-crash-reporter-spec.js: // TODO(alexeykuzmin): Skip the test instead of marking it as passed.
spec/webview-spec.js: // FIXME(alexeykuzmin): Skip the test.
atom/browser/web_contents_preferences.h: // FIXME(zcbenz): This method does not belong here.
Majority of them were about skipping tests instead of marking them passed in the version 2.0. However, by doing this we got to know the technical debt (still relatively very small compared to repo's size) not found by automatic finders like SonarQube and can only be found through developer insights and project's long term plans. The TODOs in core Electron's code represent deprecations to be done in release 2.0 of the release. Our solution to this is that these 2.0 TODOs should not be in the versionless master branch but 1.8.4 (current production version's) branch.
There is also discussion about these on github issue tracking. The TODOs and FIXMEs there are on much higher abstraction level as described in this recent example on:
- https://github.com/electron/electron/issues/10836: List of hacks and workarounds made during the upgrade to Chromium 61. They are to be fixed before Chromium 61 is merged or right after. Most of the issues are fixed already. This reinforces that Electron's developers are very active and keep it's technical debt low.
- https://github.com/electron/electron/issues/11242: This described the debt in terms of updating documentation (Remove async menu from the docs) that came with upgrades in Chromium 61.
We can infer from this activity that Electron developer's community is well aware of the technical debt that is arising from the new incoming version 2.0 and is actively working towards reducing the same. This makes evolution of Electron future-proof and their steps towards
semver, where they will update Electron with every major update of its dependencies reinforces this fact.
3.2.2 Security Perspective
It is important to distinguish that Electron is not a web-browser and the applications are built using Chromium as a renderer and Node to make remote calls to sources on the web. The security of applications built on Electron depends on the current, latest version of Chromium. Chromium has an off-the-shelf sandbox to run processes which can freely use CPU and memory. However, being a restrictive environment, there are well-defined policies for processes which prevents bugs and attacks during IO operations.
To provide applications with desktop functionality, the Electron team modified Chromium to introduce a runtime to access native APIs as well as Node.js’s built in and third-party modules. To do this the Chromium sandbox protection was disabled, meaning any application running inside Electron is given unfiltered access to the operating system.
Figure 15: Electron's architecture combined with disabled Chromium sandboxes 
This is not a concern for a lot of Electron applications, especially those that don’t pull in remote data and need extensive operating system privileges anyway (such as an IDE). However, this is a (potentially) serious and unnecessary security risk for applications that do pull in remote data, any successful XSS attack would give the attacker full control over the victim’s machine! It’s worth stressing that a successful XSS attack within a sandboxed application is still a catastrophic event that can do untold damage. Even restricted to the sandbox, an attack can execute scripts to hijack user sessions, deface web sites, insert hostile content, redirect users and install malware. Nonetheless, unless they escape the sandbox the potential for damage stops at the browser level with the operating system left unharmed and only data explicitly shared with the browser at risk.
A cross-site-scripting (XSS) attack is more dangerous if an attacker can jump out of the renderer process and execute code on the user's computer. Cross-site-scripting attacks are fairly common - and while an issue, their power is usually limited to messing with the website that they are executed on. Disabling Node.js integration helps prevent an XSS from being escalated into a so-called "Remote Code Execution" (RCE) attack.
It’s worth pointing out that there’s an open discussion around Electron’s security model on GitHub, so further changes and improvements are likely to be made once this discussion is finalised.
To summarise, Electron currently has its fair share of security issues that complicate the process of building secure applications. Various workarounds also exist that circumvent turning node integration off in the event of an XSS attack. One major goal should be a more secure way for applications that do need some node and desktop integration to interact with the operating system. Fortunately, due to the framework’s popularity and active community the Electron team are already making good progress to resolving these issues.
We can summarize our detailed analysis through the following points:
- Electron makes thing easy by providing a framework for developing cross-platform desktop apps through web technologies.
- Electron has a large and friendly community, who is always eager to welcome new contributors. The experience is based on our own contributions. One of the core developers @Zeke even did a video call to help us with coding issues for the contribution.
- Lots of applications are dependent on Electron and hence, extra focus is given on Electron's stability at any given point of time.
- Electron is backed up by Github and other large communities. The developers of Electron are well-aware of the technical debt that comes with evolving and actively discuss and contribute towards keeping it low.
- Electron is gaining a lot of attention and the contributor community is large, skilled and fast growing, and so when you might be reading this chapter, a new version 2.x.x must be available.
- In 2.x.x, Electron has promised to update according to every major update to its depedencies making it more secure and robust.
Do you want to contribute to Electron as well? Take a look at Electron and the contributing guidelines for the Electron project. It's our guarantee that you will be welcomed with open arms by team Electron and will provide help and feedback by all means possible for your contributions.
1. Electron (software framework)(2018). [online] Available at: https://en.wikipedia.org/wiki/Electron_(software_framework) [Accessed 23 Feb. 2018].
4. Electron: Tutorial (2018). [online] Available at: https://electronjs.org/docs/tutorial/ [Accessed 23 Feb. 2018].
6. Lynch, A. (2017). Beyond The Browser: From Web Apps To Desktop Apps. [online] Available at: https://www.smashingmagazine.com/2017/03/beyond-browser-web-desktop-apps/ [Accessed at 4 March, 2018]
7. Electron: Source code structure(2018). [online] Available at: https://github.com/electron/electron/edit/master/docs/development/source-code-directory-structure.md [Accessed 4 March, 2018]
8. Betts, P. (2016). Building Hybrid Applications with Electron. [online] Available at: https://slack.engineering/building-hybrid-applications-with-electron-dc67686de5fb [Accessed at 4 March, 2018]
9. Betts, P. (2016). Using ES2015 with Electron — introducing electron-compile. [online] Available at: https://slack.engineering/using-es2015-with-electron-introducing-electron-compile-2a0e5ccbadb6 [Accessed at 4 March, 2018]
10. Electron's dependecies (2018), [online] Available at: https://david-dm.org/electron/electron?type=dev [Accessed at 4 March, 2018]
11. Elctron API documentation, [online] Available at: from https://electronjs.org/docs/api [Accessed at 4 March, 2018]
12. Nokes, C. (2016). Deep dive into Electron’s main and renderer processes.[online] Available at: https://codeburst.io/deep-dive-into-electrons-main-and-renderer-processes-7a9599d5c9e2 [Accessed at 5 March, 2018]
13. Norris, T. (2015). Understanding the Nodejs Event Loop. [online] Available at: http://nodesource.com/blog/understanding-the-nodejs-event-loop/ [Accessed at 5 March, 2018]
14. Crashpad README(2018). [online] Available at: https://github.com/electron/crashpad/blob/master/doc/overview_design.md [Accessed at 5 March, 2018]
15. Crashpad- Development Notes (2018 ). [online] Available at: https://github.com/electron/crashpad/blob/master/doc/developing.md [Accessed at 5 March, 2018]
16. Electronjs.org Testing on Headless CI (2018). [online] Available at: https://electronjs.org/docs/tutorial/testing-on-headless-ci [Accessed at 5 March, 2018]
17. Electronjs.org Testing (2018). [online] Available at: https://electronjs.org/docs/development/testing [Accessed at 5 March, 2018]
18. Spectron. (2018). [online] Available at: https://github.com/electron/spectron [Accessed at 5 March, 2018]
19. Devtron. (2018). [online] Available at: https://github.com/electron/devtron [Accessed at 5 March, 2018]
20. Electronjs.org source code strucutre. (2018). Source Code Directory Structure. [online] Available at: https://electronjs.org/docs/development/source-code-directory-structure [Accessed at 6 March, 2018]
21. Electronjs.org/ build overview. (2018). Build System Overview. [online] Available at: https://electronjs.org/docs/development/build-system-overview [Accessed at 6 March, 2018]
22. Chromium.org/ multi-process architecture. (2018). Multi-Process Architecture. [online] Available at: https://www.chromium.org/developers/design-documents/multi-process-architecture [Accessed at 6 March, 2018]
23. Lord, J. (2018). Jlordus. [online] Available at: http://jlord.us/essential-electron/ [Accessed at 6 March, 2018]
24. Electronjs.org Releasing (2018). [online] Available at: https://electronjs.org/docs/development/releasing [Accessed at 6 March, 2018]
25. Electronjs.org. (2018). Releasing. [online] Available at: https://electronjs.org/docs/tutorial/application-packaging [Accessed at 6 March, 2018]
26. Cunningham, W. (2011). Ward Explains Debt Metaphor. [online] Available at: http://c2.com/cgi/wiki?WardExplainsDebtMetaphor [Accessed at 15 March, 2018]
27. Electron's Versioning Documents. [online] Available at: https://github.com/electron/electron/blob/master/docs/tutorial/electron-versioning.md [Accessed at 15 March, 2018]
28. Kerr, D. (2018). As It Stands - Electron Security. [online] Available at: http://blog.scottlogic.com/2016/03/09/As-It-Stands-Electron-Security.html [Accessed 1 Apr. 2018].
29. Electronjs.org. (2018). Security. [online] Available at: https://electronjs.org/docs/tutorial/security [Accessed 1 Apr. 2018].