Gone are the days where Javascript is locked behind the shackles of a browser. Electron, or Electron.js, is a framework maintained by the OpenJS foundation to build native desktop applications using web technologies like JavaScript, HTML, and CSS.
More and more native applications, like Spotify, VSCode, and Slack, are all being built using Electron!
This open-source framework uses Chromium and Node.js, and it can be used to create cross-platform applications compatible with Windows, Mac, and Linux. In this article, we’ll build a simple tic-tac-toe game with Electron that can run locally.
Basics of Electron
Electron consists of three primary components:
- Chromium that handles all the web content
- Node.js that handles interaction with the operating system
- Custom APIs for additional functionality and solving common issues when dealing with the OS
All these components work together to facilitate a desktop application.
Additionally, Electron includes two primary processes. The main process handles window management, all OS interactions, and the renderer process is responsible for the web content.
The renderer process cannot directly interact with the OS and only communicates with it through the Main process. Depending on the application, there can be multiple renderer processes for a single main process. However, in most cases, a single main process with a single renderer that’s used to load the web application is used.
With the explanation out of the way, let’s start building.
Setting up Our Project
To use Electron, you will need to have Node.js installed in your environment. We can start by creating our npm project by running
npm init
After setting up our project, we can install Electron with:
npm i -D electron@latest
Creating the Electron Application
For our Electron app, we’re going to use a simple HTML page to facilitate a game of pong. This way, we just need to focus on the Electron aspects of the application and not on the game itself.
A couple of weeks ago we made Pong with just a 100 lines of code, so we’ll use that reuse that project
We will create two files in our project folder. index.js which will act as our main node process, while pong.html, which will act as the renderer process to load the weather data.
The index.js file will facilitate the window creation for the application and load the appropriate renderer process. In this instance, our pong.html file will look like this:
We can now run our application locally with:
electron index.js
And there we have it! Our html file is running natively!
Conclusion
Electron’s increasing popularity makes it a must learn for aspiring developers. Not to mention, if you’re a web developer looking to make a quick native version of your website, Electron is likely the best option.
If you’re building software and looking to eliminate bottlenecks, look no further than Codesphere for you cloud service needs! We’re building Codesphere to be the most intuitive cloud and devops tool on the market!
Happy coding!
Top comments (14)
A far better way to go is a PWA to make a local version of your site.
TBH - the whole idea of Electron is flawed - you are essentially shipping almost an entire web browser with every single app. You end up with a whole bunch of web browsers all running at once, hogging memory and resources. This would be fine if all the apps were sharing an instance of a central webpage renderer - but AFAIK, they aren't.
The overall result is a bunch of massively bloated, resource hungry apps that, in reality could be way, way, way more efficient. Not to mention the fact that they'll all likely be running different versions of the web renderer, with all the associated security and update issues that that brings.
This is quite typical of the way a lot of development is done today - little or no consideration being given to whether or not the tools are appropriate to what is being built (using React for ridiculously simple portfolio sites etc.) - people just want to use whatever they know, or is the current 'cool' thing.
The priority always seems to be making it 'easier' for the developer with no regard to efficiency, resource use etc.
You're neglecting to take into account that a lot of smaller companies simply cannot afford to pay for native developers and separate teams. Javascript, HTML, and CSS are very popular skills sets that are much easier to hire for. You can hire 8 devs, half knowing Swift and the other half knowing C++, or you can hire 4 or less front-end devs to build for both iOS and Windows with Electron.
The memory consumption of Electron is a semi-fair complaint because most of the time, it seems to boil down to how efficient the devs are and how aware they are of memory usage in Javascript. VSCode is built with Electron and it's been a dream come true for web development. Hell, they even have it working directly in the browser on Github (press the period key while in one of your repos). VSCode has a reasonable footprint for being a full on IDE with an integrated terminal and the ability to load extensions, among a multitude of other features. I have never once had to worry about my memory usage while running VSCode and a handful of other Electron apps and a browser at the same time, and my laptop is like 5 years old. When the average user has a RAM memory pool of upwards of 50GBs, a single Electron app using 1GB isn't going to cause memory concerns for the average user, even if you had 8 of them open at the same time.
So healthy skepticism in all things. Electron does come with some extra overhead by nature of being a browser, but for people with limited capital, it's a solid option to get your MVP off the ground and considering doing native later on once the app has hit critical mass. For many small companies, it's really their only option. Don't neglect the business side of things. Lots of developers tend to do that and it's rather disingenuous, imo. Not all companies have bottomless pockets.
I often have fights at work about poor decisions being made due to 'business' considerations - $$$ decisions very often suck 🙂
I mean, at the end of the day, these people are paying your salary and giving you a means of living to buy all of the nice things you own. A lot of devs seem to want to have their cake and eat it too when they should just be happy they have the cake to begin with. I personally am not a fan of the one-sided developer takes that seem to always default to "business bad". It shows a lack of understanding of the business side (which most devs have never been a part of or understand on more than a surface level) and comes off as economically naive.
What’s the old adage? When all you have is a hammer, everything looks like a nail… I get it. I’m a web dev too. I don’t know the popular mobile or desktop languages, as well as I know Javascript. But, I’ve also run into issues where the Electron based apps are so memory hungry, it bottlenecks the whole system. There’s always a better tool for the job, and as much as it pains me to say it… Javascript just wasn’t made to run native mobile or desktop apps.
For example provided in the article a PWA would definitely be much better option. But bigger apps wouldn't be able to merely as a PWA since the main thread of Electron app provides so much more options. Another huge benefit of Electron is that with single codebase you can have both the web app and desktop app. Your point about Electron apps not being as efficient as true native apps could be is valid but apparently all those corporations using it don't feel like it's that big of a downside compared to what they are saving on maintaining multiple standalone apps for all the platforms and devices.
Write worse performing software, better hardware is needed; better hardware comes along, software efficiency gets worse... ad infinitum.
Vicious cycle driven by $$$
As computer hardware gets closer to it's limits in terms of efficiency, more and more emphasis will be put into software efficiency, perhaps "green" in software development will become a thing.
By the time that happens, the knowledge required to make efficient software/code will have to be excavated by archaeologists - as sadly it has been being forgotten/discarded/ignored at a frightening rate for many, many years
I already used electronJs on production, it's very useful! What impressed me the most, its the auto update system (autoupdater)!
Instead of shipping an entire web browser in an app 🙉, try using wails.app
I’ll have to check this out.
Not using localstorage is a big drawback to me.
Just make a call to the Golang part and use gorm or bbolt