Over the course of the GSoC program, I implemented an API history feature for the
Electron documentation and its functions, classes, etc. in a similar fashion to the
Node.js documentation: by allowing the
use of a simple but powerful YAML schema in the API documentation Markdown files
and displaying it nicely on the Electron documentation website.
We are excited to announce that Electron has been accepted as a mentoring organization for
the 20th edition of Google Summer of Code (GSoC) 2024! Google Summer of Code is a global
program focused on bringing new contributors into open source software development.
Electron is a JavaScript framework for building cross-platform desktop applications using
web technologies. The core Electron framework is a compiled binary executable built with
Chromium and Node.js, and is mostly written in C++.
Outside of Electron core, we also work on a variety of projects to help sustain the
Electron organization, such as:
As a Summer of Code contributor, you would be collaborating with some of Electron’s core contributors
on one of many projects under the github.com/electron umbrella.
If you aren’t very familiar with Electron, we would recommend you start by reading the
documentation and trying out examples in Electron Fiddle.
To learn more about Electron app distribution, you can also play around with
Electron Forge by creating a sample application:
npm init electron-app@latest my-app
After familiarizing yourself with the code a bit, come join the conversation on the
Electron Discord server.
info
If this is your first time participating in Google Summer of Code or if you’re new to open source in general,
we recommend reading Google’s Contributor Guide as a first step
before engaging with the community.
Interested in collaborating with Electron? First, check out the seven project idea drafts
that we have prepared. All of the listed ideas are currently open for proposals.
Have a different idea you’d like us to consider? We’re also open to accepting new ideas that
are not on the proposed project list, but make sure your approach is thoroughly outlined and detailed.
When in doubt, we recommend sticking with our listed ideas.
Your application should include:
Your proposal: a written document that describes in detail what you plan to achieve over
the course of the summer.
Your background as a developer. If you have a resume, please include a copy. Otherwise,
tell us about your past technical experience.
Lack of experience in certain areas won’t disqualify you, but it will help our mentors
work out a plan to best support you and make sure your summer project is successful.
Applications open on March 18th, 2024 and close on April 2nd, 2024.
info
Our 2022 Google Summer of Code intern, @aryanshridhar,
did an amazing job! If you want to see what Aryan worked on during his summer with Electron,
you can read his report in the 2022 GSoC program archives.
If you have questions we didn’t address in the blog post or inquiries for your proposal draft,
please send us an email at summer-of-code@electronjs.org or check GSoC FAQ!
In short, we want to smooth out the process of landing significant changes to Electron core.
Currently, new code changes are mostly discussed through issues and pull requests on GitHub.
For most changes to Electron, this is a good system. Many bug fixes, documentation changes,
and even new features are straightforward enough to review and merge asynchronously through
standard GitHub flows.
For changes that are more significant—for instance, large API surfaces or breaking changes
that would affect the majority of Electron apps—it makes sense for review to happen at the
ideation stage before most of the code is written.
This process is designed to be open to the public, which will also make it easier for the
open source community at large to give feedback on potential changes before they land in
Electron.
The entire RFC process lives in the electron/rfcs repository
on GitHub. The steps are described in detail in the repository
README.
In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository.
A Proposed RFC becomes:
Active when the PR is merged into the main branch of the repository, which means that Electron
maintainers are amenable to an implementation in electron/electron, or
Declined if the PR is ultimately rejected.
info
For the RFC to become Active, the PR must be approved by at least 2 API Working Group members.
Before merging, the RFC should be presented synchronously and accepted unanimously by a quorum of at
least two-thirds of the WG members. If consensus is reached, a one-month final comment period will
be triggered, after which the PR will be merged.
An Active RFC is Completed if the implementation has been merged into electron/electron.
We wanted to make this process a two-way dialogue and encourage community participation to get a
diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re
interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created
a few:
The first commit to the electron/electron repository was on March 13, 20131.
10 years and 27,147 more commits from 1192 unique contributors later, Electron has become one of the
most popular frameworks for building desktop applications today. This milestone is the perfect
opportunity to celebrate and reflect on our journey so far, and to share what we’ve learned along
the way.
We would not be here today without everyone who has dedicated their time and effort to contribute to
the project. Although source code commits are always the most visible contributions, we also have to
acknowledge the effort of folks who report bugs, maintain userland modules, provide documentation
and translations, and participate in the Electron community across cyberspace.
Every contribution is invaluable to us as maintainers.
Before we continue with the rest of the blog post: thank you. ❤️
Atom Shell was built as the backbone for GitHub’s Atom editor, which launched in
public beta in April 2014. It was built from the ground up as an alternative to the web-based
desktop frameworks available at the time (node-webkit and Chromium Embedded Framework). It had a
killer feature: embedding Node.js and Chromium to provide a powerful desktop runtime for web
technologies.
Within a year, Atom Shell began seeing immense growth in capabilities and popularity.
Large companies, startups, and individual developers alike had started building apps with it
(some early adopters include Slack, GitKraken, and
WebTorrent), and the project was aptly renamed to Electron.
From then on, Electron hit the ground running and never stopped. Here’s a look at our weekly
download count over time, courtesy of npmtrends.com:
Electron v1 was released in 2016, promising increased API stability and better docs and tooling.
Electron v2 was released in 2018 and introduced semantic versioning, making it easier for Electron
developers to keep track of the release cycle.
By Electron v6, we shifted to a regular 12-week major release cadence to match Chromium ’s. This
decision was a change in mentality for the project, bringing “having the most up-to-date Chromium
version” from a nice-to-have to a priority. This has reduced the amount of tech debt between
upgrades, making it easier for us to keep Electron updated and secure.
Since then, we’ve been a well-oiled machine, releasing a new Electron version on the same day as
every Chromium stable. By the time Chromium sped up their release schedule to 4 weeks in 2021,
we were able to shrug our shoulders and increase our release cadence to 8 weeks accordingly.
We’re now on Electron v23 (and counting), and are still dedicated to building the best runtime for
building cross-platform desktop applications. Even with the boom in JavaScript developer tools in
recent years, Electron has remained a stable, battle-tested stalwart of the desktop app framework
landscape. Electron apps are ubiquitous nowadays: you can program with Visual Studio Code, design
with Figma, communicate with Slack, and take notes with Notion (amongst many other use cases).
We’re incredibly proud of this achievement and grateful to everyone who has made it possible.
The road to the decade mark has been long and winding. Here are some key things that have
helped us run a sustainable large open source project.
Scaling distributed decision-making with a governance model
One challenge we had to overcome was handling the long-term direction of the project once Electron
first exploded in popularity. How do we handle being a team of a couple dozen engineers distributed
across companies, countries, and time zones?
In the early days, Electron’s maintainer group relied on informal coordination, which is fast and
lightweight for smaller projects, but doesn’t scale to wider collaboration. In 2019, we shifted to
a governance model where different working groups have formal areas of responsibility. This has been
instrumental in streamlining processes and assigning portions of project ownership to specific
maintainers. What is each Working Group (WG) responsible for nowadays?
Getting Electron releases out the door (Releases WG)
Upgrading Chromium and Node.js (Upgrades WG)
Overseeing public API design (API WG)
Keeping Electron secure (Security WG)
Running the website, documentation, and tooling (Ecosystem WG)
Around the same time we shifted to the governance model, we also moved Electron's ownership from
GitHub to the OpenJS Foundation.
Although the original core team still works at Microsoft today, they are only a part of a larger
group of collaborators that form Electron governance.2
While this model isn’t perfect, it has suited us well through a global pandemic and ongoing
macroeconomic headwinds. Going forward, we plan on revamping the governance charter to
guide us through the second decade of Electron.
The community part of open source is hard, especially when your Outreach team is a dozen engineers
in a trench coat that says “community manager”. That said, being a large open source project means
that we have a lot of users, and harnessing their energy for Electron to build a userland ecosystem
is a crucial part of sustaining project health.
What have we been doing to develop our community presence?
In 2020, we launched our community Discord server. We previously had a section in Atom’s forum,
but decided to have a more informal messaging platform to have a space for discussions between
maintainers and Electron developers and for general debugging help.
In 2021, we established the Electron China user group with the help of
@BlackHole1. This group has been instrumental in Electron growth
in users from China’s booming tech scene, providing a space for them to collaborate on ideas and
discuss Electron outside of our English-language spaces. We’d also like to thank
cnpm for their work in supporting Electron’s nightly releases in their
Chinese mirror for npm.
Participating in high-visibility open source programs
We have been celebrating Hacktoberfest every year since 2019.
Hacktoberfest is yearly celebration of open source organized by DigitalOcean, and we get dozens of
enthusiastic contributors every year looking to make their mark on open source software.
In 2020, we participated in the initial iteration of Google Season of Docs, where we worked with
@bandantonio to rework Electron’s new user tutorial flow.
In 2022, we mentored a Google Summer of Code student for the first time.
@aryanshridhar did some awesome work to refactor
Electron Fiddle's core version loading logic and migrate its bundler
to webpack.
Today, Electron governance has about 30 active maintainers. Less than half of us are full-time
contributors, which means that there’s a lot of work to go around. What’s our trick to keeping
everything running smoothly? Our motto is that computers are cheap, and human time is expensive.
In typical engineer fashion, we’ve developed a suite of automated support tooling to make our lives
easier.
The core Electron codebase is a behemoth of C++ code, and build times have always been a limiting
factor in how fast we can ship bug fixes and new features. In 2020, we deployed
Not Goma, a custom
Electron-specific backend for Google’s Goma
distributed compiler service.
Not Goma processes compilation requests from authorized user’s machines and distributes the process
across hundreds of cores in the backend. It also caches the compilation result so that someone else
compiling the same files will only need to download the pre-compiled result.
Since launching Not Goma, compilation times for maintainers have decreased from the scale of hours
to minutes. A stable internet connection became the minimum requirement for contributors to compile
Electron!
info
If you’re an open source contributor, you can also try Not Goma’s read-only cache, which is
available by default with Electron Build Tools.
Continuous Factor Authentication (CFA) is a layer of automation
around npm’s two-factor authentication (2FA) system that we combine with
semantic-release to manage
secure and automated releases of our various @electron/ npm packages.
While semantic-release already automates the npm package publishing process, it requires turning off
two-factor authentication or passing in a secret token that bypasses this restriction.
We built CFA to deliver a time-based one-time password (TOTP) for npm 2FA to arbitrary CI jobs,
allowing us to harness the automation of semantic-release while keeping the additional security of
two-factor authentication.
We use CFA with a Slack integration front-end, allowing maintainers to validate package publishing
from any device they have Slack on, as long as they have their TOTP generator handy.
info
If you want to try CFA out in your own projects, check out
the GitHub repository or
the docs!
If you use CircleCI as your CI provider, we also have
a handy orb to quickly scaffold a project with CFA.
Sheriff is an open source tool we wrote to automate the
management of permissions across GitHub, Slack, and Google Workspace.
Sheriff’s key value proposition is that permission management should be a transparent process.
It uses a single YAML config file that designates permissions across all the above listed services.
With Sheriff, getting collaborator status on a repo or creating a new mailing list is as easy as
getting a PR approved and merged.
Sheriff also has an audit log that posts to Slack, warning admins when suspicious activity occurs
anywhere in the Electron organization.
GitHub is a platform with rich API extensibility and a first-party bot application framework called
Probot. To help us focus on the more creative parts of our job,
we built out a suite of smaller bots that help do the dirty work for us. Here are a
few examples:
Sudowoodo automates the Electron release process
from start to finish, from kicking off builds to uploading the release assets to GitHub and npm.
Trop automates the backporting process for Electron by
attempting to cherry-pick patches to previous release branches based on GitHub PR labels.
Roller automates rolling upgrades of Electron’s Chromium
and Node.js dependencies.
Cation is our status check bot for electron/electron PRs.
Altogether, our little family of bots has given us a huge boost in developer productivity!
As we enter our second decade as a project, you might be asking: what’s next for Electron?
We’re going to stay in sync with Chromium's release cadence, releasing new major versions of
Electron every 8 weeks, keeping the framework updated with the latest and greatest from the web
platform and Node.js while maintaining stability and security for enterprise-grade applications.
We generally announce news on upcoming initiatives when they become concrete. If you want to
keep up with future releases, features, and general project updates, you can read
our blog and follow our social media profiles
(Twitter and Mastodon)!
This is actually the first commit from the
electron-archive/brightray project, which got
absorbed into Electron in 2017 and had its git history merged. But who’s counting?
It’s our birthday, so we get to make the rules! ↩
Contrary to popular belief, Electron is no longer owned by GitHub or Microsoft, and is part of
the OpenJS Foundation nowadays. ↩
Google Summer of Code (GSoC) is a yearly mentoring program connecting open source software projects with potential contributors. Previously open only to students, anyone ages 18 and up can now register for GSoC.
Want to apply? First, check out the five project idea drafts that we have prepared. All of the listed ideas are currently open for proposals. We are also open to accepting new ideas that are not on the proposed project list.
Your application should include:
Your proposal, which is a written document that describes in detail what you plan to achieve over the course of the summer.
Your background as a developer. If you have a resume, please include a copy, otherwise tell us about your past experience with an emphasis on relevant technical experience.
In its early days as the backbone of the Atom text editor, community discussion on the Electron
framework occurred in a single channel in Atom’s Slack workspace. As time passed and the two projects were increasingly
decoupled, the relevance of the Atom workspace to the Electron project decreased, and maintainer participation in the
Slack channel declined in the same manner.
Up until now, we had still been redirecting our broader community to the Atom Slack workspace, even though we’ve
had many reports from folks who have had trouble receiving invitations, and few of our core maintainers were
frequenting the channel.
We’re setting up this shiny new server to be a central discussion hub for the community where you can get the latest
news on all things Electron.
So far, the server’s membership consists of a few maintainers who have been working together to set it up, but we’re
so excited to chat with you all! Come ask for help, keep up to date with Electron releases, or just hang out with other
developers. We’ve got a handy invite for you that’ll give you access to the server!
Hacktoberfest 2020
As a large and long-running open-source project, Electron wouldn’t have been nearly as successful without all the
contributions from its community, from code submissions to bug reports to documentation changes, and much more.
That’s why we believe in the importance of participating in Hacktoberfest to usher in a wider community of developers
of all skill levels into the project.
This year, we don’t have a wider project to give you all to work on, but we’d like to focus on opportunities to contribute
across the Electron JavaScript ecosystem.
P.S. If you're feeling particularly adventurous, we also have a backlog of issues marked with
help wanted
tags if you're looking for more of a challenge.
Moreover, it’s also no coincidence that the grand opening of our Discord server coincides with the largest celebration of
open-source software of the year. Check out the #hacktoberfest channel to ask for help on your Hacktoberfest PR. In case
you missed it, here's the invite link again!
Electron is proud to be participating in the second edition of Google's Season of Docs initiative, which pairs mentors from open source organizations with technical writers to improve project documentation.
What is Season of Docs?
Season of Docs is a program that fosters collaboration between technical writers and open source communities to the benefit of both parties. Open source maintainers utilize the writer's technical writing expertise to improve the structure and content of their documentation, while the technical writer is introduced to an open-source community under the guidance of its mentors. Learn more about it on the Google's Season of Docs website.
For our first time participating in the program, we'll be mentoring a single technical writer who will be working alongside Electron's Ecosystem Working Group to reshape large parts of our documentation. You can learn more about the timeline of the whole project here.
How do I sign up?
Are you interested in collaborating with us as a technical writer? First, get familiar with Google's tech writer guide for this year's program, and check out the two project idea drafts that we have prepared.
In order to be selected as Electron's technical writer for Season of Docs, candidates will need to apply on the Google Season of Docs website during the Technical Writer Application phase that is running from June 8 to July 9..
Your application should include a proposal, which is a written document that describes in detail what you plan to achieve on the Electron docs over the course of 3 months. This proposal can either develop on one of the starting points mentioned in our Project Idea doc, or can be something entirely new. Don't know where to start? You can check out last year's list of accepted proposals for inspiration.
Aside from the proposal, we'll also be looking at your background as a technical writer. Please include a copy of your resume with an emphasis on relevant writing experience, as well as technical writing samples (these samples could be existing documentation, tutorial, blog posts, etc.)
If you want to discuss project proposals, shoot us an email at season-of-docs@electronjs.org and we can chat from there!
Electron is working on making its release cycles faster and more stable. To make that possible, we've started the App Feedback Program for large-scale Electron apps to test our beta releases and report app-specific issues to us. This helps us to prioritize work that will get applications upgraded to our next stable release sooner.
We understand not everyone can share exact user numbers, however better data helps us decide how stable a particular release is. We ask that apps commit to testing a minimum number of user-hours, currently 10,000 across the beta cycle.
10 user-hours could be 10 people testing for one hour, or one person testing for 10 hours
You can split the testing between beta releases, for example test for 5,000 user-hours on 3.0.0-beta.2 and then test for 5,000 user-hours on 3.0.0-beta.5. More is better, but we understand that some applications cannot test every beta release
CI or QA hours do not count towards the total; however, internal releases do count
Your app's bugs will be tracked and be on the core Electron team's radar. Your feedback helps the Electron team to see how the new betas are doing and what work needs to be done.
Will my application's info be shared publicly? Who gets to see this info?
No, your application's information will not be shared with the general public. Information is kept in a private GitHub repo that is only viewable to members of the App Feedback Program and Electron Governance. All members have agreed to follow Electron's Code of Conduct.
We are currently accepting a limited number of signups. If you are interested and are able to fulfill the above requirements, please fill out this form.
When people use GitHub in their job or OSS activities, they tend to receive many notifications on a daily basis. As a way to subscribe to the notifications, GitHub provides email and web notifications. I used these for a couple of years, but I faced the following problems:
It's easy to overlook issues where I was mentioned, I commented, or I am watching.
I put some issues in a corner of my head to check later, but I sometimes forget about them.
To not forget issues, I keep many tabs open in my browser.
It's hard to check all issues that are related to me.
It's hard to grasp all of my team's activity.
I was spending a lot of time and energy trying to prevent those problems, so I decided to make an issue reader for GitHub to solve these problems efficiently, and started developing Jasper.
Jasper is used by developers, designers, and managers in several companies that are using GitHub.
Of course, some OSS developers also are using it.
And it is also used by some people at GitHub!
Once Jasper is configured, the following screen appears. From left to right, you can see "streams list", "issues list" and "issue body".
This "stream" is the core feature of Jasper. For example, if you want to see "issues that are assigned to @zeke in the electron/electron repository", you create the following stream:
repo:electron/electron assignee:zeke is:issue
After creating the stream and waiting for a few seconds, you can see the issues that meet the conditions.
Issues that are requested review by cat. But these are not reviewed yet.
is:pr reviewed-by:cat
Issues that are reviewed by cat
As you may have noticed by looking at these, streams can use GitHub's search queries.
For details on how to use streams and search queries, see the following URLs.
Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.
Apps can be built for Windows, Mac, and Linux platforms.
Electron is actively developed and has a large community.
These features enable rapid and simple desktop application development. It is awesome! If you have any product idea, you should consider using Electron by all means.
What are some challenges you've faced while developing Jasper?
I had a hard time figuring out the "stream" concept. At first I considered using GitHub's Notifications API. However I noticed that it does not support certain use cases. After that I considered using the Issues API and Pull Requests API, in addition to the Notification API. But it never became what I wanted. Then while thinking about various methods, I realized that polling GitHub's Search API would offer the most flexibility. It took about a month of experimentation to get to this point, then I implemented a prototype of Jasper with the stream concept in two days.
Note: The polling is limited to once every 10 seconds at most. This is acceptable enough for the restriction of GitHub API.
This week we caught up with @feross and @dcposch to talk about WebTorrent, the web-powered torrent client that connects users together to form a distributed, decentralized browser-to-browser network.
WebTorrent is the first torrent client that works in the browser. It's written completely in JavaScript and it can use WebRTC for peer-to-peer transport. No browser plugin, extension, or installation is required.
Using open web standards, WebTorrent connects website users together to form a distributed, decentralized browser-to-browser network for efficient file transfer.
You can see a demo of WebTorrent in action here: webtorrent.io.
Imagine a video site like YouTube, but where visitors help to host the site's content. The more people that use a WebTorrent-powered website, the faster and more resilient it becomes.
Browser-to-browser communication cuts out the middle-man and lets people communicate on their own terms. No more client/server – just a network of peers, all equal. WebTorrent is the first step in the journey to re-decentralize the Web.
About one year ago, we decided to build WebTorrent Desktop, a version of WebTorrent that runs as a desktop app.
We created WebTorrent Desktop for three reasons:
We wanted a clean, lightweight, ad-free, open source torrent app
We wanted a torrent app with good streaming support
We need a "hybrid client" that connects the BitTorrent and WebTorrent networks
If we can already download torrents in my web browser, why a desktop app?
First, a bit of background on the design of WebTorrent.
In the early days, BitTorrent used TCP as its transport protocol. Later, uTP came along promising better performance and additional advantages over TCP. Every mainstream torrent client eventually adopted uTP, and today you can use BitTorrent over either protocol. The WebRTC protocol is the next logical step. It brings the promise of interoperability with web browsers – one giant P2P network made up of all desktop BitTorrent clients and millions of web browsers.
“Web peers” (torrent peers that run in a web browser) make the BitTorrent network stronger by adding millions of new peers, and spreading BitTorrent to dozens of new use cases. WebTorrent follows the BitTorrent spec as closely as possible, to make it easy for existing BitTorrent clients to add support for WebTorrent.
Some torrent apps like Vuze already support web peers, but we didn't want to wait around for the rest to add support. So basically, WebTorrent Desktop was our way to speed up the adoption of the WebTorrent protocol. By making an awesome torrent app that people really want to use, we increase the number of peers in the network that can share torrents with web peers (i.e. users on websites).
What are some interesting use cases for torrents beyond what people already know they can do?
One of the most exciting uses for WebTorrent is peer-assisted delivery. Non-profit projects like Wikipedia and the Internet Archive could reduce bandwidth and hosting costs by letting visitors chip in. Popular content can be served browser-to-browser, quickly and cheaply. Rarely-accessed content can be served reliably over HTTP from the origin server.
The Internet Archive actually already updated their torrent files so they work great with WebTorrent. So if you want to embed Internet Archive content on your site, you can do it in a way that reduces hosting costs for the Archive, allowing them to devote more money to actually archiving the web!
There are also exciting business use cases, from CDNs to app delivery over P2P.
What are some of your favorite projects that use WebTorrent?
The coolest thing built with WebTorrent, hands down, is probably Gaia 3D Star Map. It's a slick 3D interactive simulation of the Milky Way. The data loads from a torrent, right in your browser. It's awe-inspiring to fly through our star system and realize just how little we humans are compared to the vastness of our universe.
You can read about how this was made in Torrenting The Galaxy, a blog post where the author, Charlie Hoey, explains how he built the star map with WebGL and WebTorrent.
We're also huge fans of Brave. Brave is a browser that automatically blocks ads and trackers to make the web faster and safer. Brave recently added torrent support, so you can view traditional torrents without using a separate app. That feature is powered by WebTorrent.
So, just like how most browsers can render PDF files, Brave can render magnet links and torrent files. They're just another type of content that the browser natively supports.
One of the co-founders of Brave is actually Brendan Eich, the creator of JavaScript, the language we wrote WebTorrent in, so we think it's pretty cool that Brave chose to integrate WebTorrent.
Why did you choose to build WebTorrent Desktop on Electron?
There is a meme that Electron apps are "bloated" because they include the entire Chrome content module in every app. In some cases, this is partially true (an Electron app installer is usually ~40MB, where an OS-specific app installer is usually ~20MB).
However, in the case of WebTorrent Desktop, we use nearly every Electron feature, and many dozens of Chrome features in the course of normal operation. If we wanted to implement these features from scratch for each platform, it would have taken months or years longer to build our app, or we would have only been able to release for a single platform.
Just to get an idea, we use Electron's dock integration (to show download progress), menu bar integration (to run in the background), protocol handler registration (to open magnet links), power save blocker (to prevent sleep during video playback), and automatic updater. As for Chrome features, we use plenty: the <video> tag (to play many different video formats), the <track> tag (for closed captions support), drag-and-drop support, and WebRTC (which is non-trivial to use in a native app).
Not to mention: our torrent engine is written in JavaScript and assumes the existence of lots of Node APIs, but especially require('net') and require('dgram') for TCP and UDP socket support.
Basically, Electron is just what we needed and had the exact set of features we needed to ship a solid, polished app in record time.
The WebTorrent library has been in development as an open source side project for two years. We made WebTorrent Desktop in four weeks. Electron is the primary reason that we were able to build and ship our app so quickly.
Just as Node.js made server programming accessible to a generation of jQuery-using front-end programmers, Electron makes native app development accessible to anyone familiar with Web or Node.js development. Electron is extremely empowering.
Do the website and the Desktop client share code?
Yes, the webtorrent npm package works in Node.js, in the browser, and in Electron. The exact same code can run in all environments – this is the beauty of JavaScript. It's today's universal runtime. Java Applets promised "Write Once, Run Anywhere" apps, but that vision never really materialized for a number of reasons. Electron, more than any other platform, actually gets pretty darn close to that ideal.
What are some challenges you've faced while building WebTorrent?
In early versions of the app, we struggled to make the UI performant. We put the torrent engine in the same renderer process that draws the main app window which, predictably, led to slowness anytime there was intense CPU activity from the torrent engine (like verifying the torrent pieces received from peers).
We fixed this by moving the torrent engine to a second, invisible renderer process that we communicate with over IPC. This way, if that process briefly uses a lot of CPU, the UI thread will be unaffected. Buttery-smooth scrolling and animations are so satisfying.
Note: we had to put the torrent engine in a renderer process, instead of a "main" process, because we need access to WebRTC (which is only available in the renderer.)
One thing we'd love to see is better documentation about how to build and ship production-ready apps, especially around tricky subjects like code signing and auto-updating. We had to learn about best practices by digging into source code and asking around on Twitter!
Is WebTorrent Desktop done? If not, what's coming next?
We think the current version of WebTorrent Desktop is excellent, but there's always room for improvement. We're currently working on improving polish, performance, subtitle support, and video codec support.
If you're interested in getting involved in the project, check out our GitHub page!
Any Electron development tips that might be useful to other developers?
Feross, one of the WebTorrent Desktop contributors, recently gave a talk "Real world Electron: Building Cross-platform desktop apps with JavaScript" at NodeConf Argentina that contains useful tips for releasing a polished Electron app. The talk is especially useful if you're at the stage where you have a basic working app and you're trying to take it to the next level of polish and professionalism.
DC, another WebTorrent contributor, wrote a checklist of things you can do to make your app feel polished and native. It comes with code examples and covers things like macOS dock integration, drag-and-drop, desktop notifications, and making sure your app loads quickly.
