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. Alle aufgeführten Ideen sind derzeit offen für Vorschläge.
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.
Ihre Bewerbung sollte beinhalten:
Your proposal: a written document that describes in detail what you plan to achieve over
the course of the summer.
Dein Hintergrund als Entwickler. 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:
Der erste Commit in das electron/electron Repository war am 13. März 20131.
10 Jahre und 27.147 weitere Commits von 1192 individuellen Mitwirkenden später, Electron ist heute zu einem der beliebtesten Frameworks für das Erstellen von Desktop-Anwendungen geworden. Dieser Meilenstein ist die perfekte Gelegenheit, um unsere bisherige Reise zu feiern und zu reflektieren, und mitzuteilen, was wir auf dem Weg gelernt haben.
Wir wären heute nicht hier ohne alle, die ihre Zeit und Mühe geopfert haben, um das Projekt zu unterstützen. Obwohl Quellcode-Commits immer die sichtbarsten Beiträge sind, müssen wir auch die Anstrengungen der Leute anerkennen, die Fehler melden, userland-Module warten, Dokumentation und Übersetzungen bereitstellen und an der Electron Community im gesamten Cyberspace teilnehmen. Jeder Beitrag ist für uns als Betreiber von unschätzbarem Wert.
Bevor wir mit dem Rest des Blog-Beitrags fortfahren: Vielen Dank. ❤️
Atom Shell wurde als Gerüst für GitHubs Atom-Editorgebaut, der im April 2014 in die öffentliche Beta startete. Es wurde von Grund auf als Alternative zu den webbasierten Desktop-Frameworks gebaut, die zu dieser Zeit verfügbar waren (node-webkit und Chromium Embedded Framework). Es hatte eine Killer-Funktion: Einbetten von Node.js und Chromium, um eine leistungsfähige Desktop-Laufzeit für Web- Technologien zu bieten.
Innerhalb eines Jahres begann Atom Shell ein immenses Wachstum der Fähigkeiten und Popularität zu sehen. Große Firmen, Startups und einzelne Entwickler hatten gleichermaßen damit begonnen, Apps damit zu bauen (einige frühe Anwender waren Slack, GitKraken, und WebTorrent), und das Projekt wurde treffend in Electron umbenannt.
Von da an startete Electron voll durch und hielt nie auf. Hier ist ein Blick auf unsere wöchentliche Download-Anzahl über die Zeit, dank npmtrends.com:
Electron v1 wurde 2016 veröffentlicht und versprach eine höhere API-Stabilität und bessere Dokumentation und Werkzeuge. Electron v2 wurde 2018 veröffentlicht und führte semantische Versionierung ein, was es den Entwicklern von Electron einfacher macht, den Release-Zyklus zu verfolgen.
Mit Electron v6 haben wir auf eine reguläre 12-wöchige große Release-Kadenz umgeschaltet, um der Chromium-Kadenz zu folgen. Diese Entscheidung war ein Mentalitätswandel für das Projekt und hat "die aktuellste Chromium-Version zu haben" von einem Nice-to-have zu einer Priorität gemacht. Dies hat die Menge an technischer Schulden zwischen den Upgrades reduziert und macht es uns einfacher, Electron aktualisiert und sicher zu halten.
Seitdem sind wir eine gut geölte Maschine und veröffentlichen eine neue Elektro-Version am selben Tag wie jede stabile Version von Chromium. Als Chromium 2021 seinen Veröffentlichungszyklus auf 4 Wochen beschleunigte, konnten wir entspannt darauf reagieren und unseren Veröffentlichungsrhythmus entsprechend auf 8 Wochen erhöhen.
Wir sind nun bei Electron v23 (und es geht weiter) und sind weiterhin bestrebt, die beste Laufzeitumgebung für die Erstellung plattformübergreifender Desktop-Anwendungen zu entwickeln. Trotz des Booms von JavaScript-Entwicklerwerkzeugen in den letzten Jahren ist Electron ein stabiler und erprobter Eckpfeiler im Bereich der Desktop-Anwendungs-Frameworks geblieben. Heutzutage sind Electron-Apps allgegenwärtig: Du kannst mit Visual Studio Code programmieren, mit Figma designen, mit Slack kommunizieren und mit Notion Notizen machen (unter vielen anderen Anwendungsfällen). Wir sind unglaublich stolz auf diese Leistung und dankbar für alle, die dies möglich gemacht haben.
Der Weg zur Dekaden-Marke war lang und gewunden. Hier sind ein Paar der Kernelemente, die uns geholfen haben, ein solch großes Open-Source Projekt am Leben zu erhalten.
Skalierung verteilter Entscheidungsfindung mit einem Governance-Modell
Eine Herausforderung, die wir bewältigen mussten, war, die langfristige Richtung des Projekts zu bewältigen, nachdem Electron zum ersten Mal in der Popularität explodierte. Wie gehen wir damit um, ein Team von ein paar Dutzend Ingenieuren zu sein, die über Firmen, Länder und Zeitzonen verteilt arbeiten?
In den Anfangstagen verließ sich die Gruppe der Electron-Maintainer auf informelle Koordination, die für kleinere Projekte schnell und unkompliziert ist, aber nicht auf breitere Zusammenarbeit skaliert. 2019 wechselten wir zu einem Governance-Modell, bei dem verschiedene Arbeitsgruppen formelle Verantwortungsbereiche haben. Dies war entscheidend, um Prozesse zu optimieren und Projektanteile spezifischen Maintainers zuzuweisen. Wofür ist jede Arbeitsgruppe (WG) heutzutage verantwortlich?
Electron-Versionen herausbringen (Releases WG)
Upgrade von Chromium und Node.js (Upgrades WG)
Überwachung des öffentlichen API-Designs (API WG)
Electron sicher halten (Sicherheit WG)
Die Webseite am Laufen halten, Dokumentation und Bereitstellung von Werkzeugen (Ecosystem WG)
Community und Firmenreichweite (Outreach WG)
Community-Moderation (Community & Safety WG)
Wartung unserer Build-Infrastruktur, Maintainer-Tools und Cloud-Services (Infrastructure WG)
Etwa zur gleichen Zeit, als wir zum Governance-Modell wechselten, übertrugen wir auch das Eigentum von Electron von GitHub zur OpenJS Foundation. Obwohl das ursprüngliche Kernteam heute noch bei Microsoft arbeitet, sind sie nur ein Teil einer größeren Gruppe von Mitwirkenden, die die Electron-Governance bilden.2
Obwohl dieses Modell nicht perfekt ist, hat es uns gut durch eine globale Pandemie und anhaltende makroökonomische Gegenwinde gebracht. Für die Zukunft planen wir, die Governance-Charta zu überarbeiten, um uns durch das zweite Jahrzehnt von Electron zu führen.
info
Wenn du mehr erfahren möchtest, schau dir das electron/governance Repository an!
Der Community-Teil von Open Source ist schwierig, besonders wenn dein Outreach-Team aus einem Dutzend Ingenieuren in einem Trenchcoat besteht, auf dem "Community Manager" steht. Das bedeutet jedoch, dass wir als großes Open-Source-Projekt viele Nutzer haben, und ihre Energie für Electron zu nutzen, um ein Userland-Ökosystem aufzubauen, ist ein entscheidender Teil, um die Gesundheit des Projekts zu erhalten.
Was haben wir unternommen, um unsere Präsenz in der Community zu entwickeln?
Im Jahr 2020 starteten wir unseren Community-Discord-Server. Zuvor hatten wir einen Bereich im Forum von Atom, aber wir entschieden uns für eine informellere Messaging-Plattform, um einen Raum für Diskussionen zwischen Maintainern und Electron-Entwicklern sowie für allgemeine Debugging-Hilfe zu schaffen.
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 ist ein Open-Source-Werkzeug, das wir geschrieben haben, um die Verwaltung von Berechtigungen in GitHub, Slack und Google Workspace zu automatisieren.
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 ist unser Statusprüfbot für electron/electron PRs.
Insgesamt hat uns unsere kleine Bot-Familie einen enormen Schub in der Entwicklungsproduktivität gebracht!
Wenn wir in unser zweites Jahrzehnt als ein Projekt kommen, könnten Sie fragen: Was ist das nächste für 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) ist ein jährliches Mentoring-Programm, das Open-Source-Software-Projekte mit potenziellen Mitwirkenden verbindet. Früher nur für Studierende geöffnet, können sich jetzt alle ab 18 Jahren bei GSoC registrieren.
Sind Sie an einer Zusammenarbeit mit Electronic interessiert? Wenn Sie ein neuer oder Anfänger von Open-Source-Mitwirkender sind, freuen wir uns über Ihre Bewerbung!
Möchtest du dich bewerben? Schauen Sie sich zuerst die fünf Projektideen an, die wir vorbereitet haben. Alle aufgeführten Ideen sind derzeit offen für Vorschläge. Wir sind auch bereit, neue Ideen zu akzeptieren, die nicht auf der vorgeschlagenen Projektliste stehen.
Ihre Bewerbung sollte beinhalten:
Ihr Vorschlag, das ist ein schriftliches Dokument, das genau beschreibt, was Sie im Laufe des Sommers zu erreichen gedenken.
Dein Hintergrund als Entwickler. Wenn Sie einen Lebenslauf haben, geben Sie bitte ein Exemplar an, sonst teilen Sie uns Ihre Erfahrungen mit einem Schwerpunkt auf relevante technische Erfahrung mit.
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 ist stolz darauf, an der zweiten Auflage der Initiative "Season of Docs" von Google teilzunehmen die Mentoren von Open-Source-Organisationen mit technischen Autoren kombiniert, um die Projektdokumentation zu verbessern.
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
Sie können das Testen auf Beta-Versionen aufteilen, zum Beispiel auf 3.0.0-Beta für 5.000 User-Stunden. und dann 5.000 Userstunden auf 3.0.0-beta.5 testen. Mehr ist besser, aber wir verstehen, dass einige Anwendungen nicht jede Beta-Version testen können
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.
Wenn Menschen GitHub in ihren Job- oder OSS-Aktivitäten verwenden, neigen sie dazu, täglich viele Benachrichtigungen zu erhalten. Um die Benachrichtigungen zu abonnieren, bietet GitHub E-Mail und Web-Benachrichtigungen. Ich habe diese für ein paar Jahre verwendet, aber ich bin auf folgende Probleme gestoßen:
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!
Sobald Jasper konfiguriert ist, erscheint der folgende Bildschirm. Von links nach rechts können Sie "Streams List", "Issue List" und "Issue Body" sehen.
Dieser "Stream" ist die Kernfunktion von Jasper. Wenn Sie zum Beispiel "Issues, die @zeke im electron/electron Repository zugewiesen sind" sehen wollen, erstellen Sie den folgenden 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, die von cat reviewed werden
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.
Ist Jasper ein bezahltes Produkt? Wie viel kostet es?
Jasper kostet $12. However you can use the free trial edition for 30 days.
Apps können mit JavaScript/CSS/HTML entwickelt werden.
Apps können für Windows, Mac und Linux-Plattformen gebaut werden.
Electron wird aktiv entwickelt und hat eine große 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.
Was sind einige Herausforderungen, denen Sie bei der Entwicklung von Jasper gegenüberstanden?
I had a hard time figuring out the "stream" concept. Zuerst habe ich über die Verwendung von GitHubs Benachrichtigungs-API nachgedacht. Ich habe jedoch festgestellt, dass sie bestimmte Anwendungsfälle nicht unterstützt. Danach habe ich die Issues API und Pull-Requests APIzusätzlich zur Benachrichtigungs-API in Erwägung gezogen. Aber es wurde nie das, was ich wollte. Während ich über verschiedene Methoden nachdachte, erkannte ich, dass das Umfragen von GitHubs Such-API die größte Flexibilität bieten würde. 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?
Es gibt eine Meme, die Electron-Apps "geblockt" werden, da sie das gesamte Chrome-Inhaltsmodul in jeder App enthalten. In einigen Fällen ist dies teilweise der Fall (ein Electron-App-Installer ist normalerweise ~40MB, wobei ein OS-spezifischer App-Installer normalerweise ~20MB beträgt).
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. Der Vortrag ist besonders nützlich, wenn Sie sich in der Phase befinden, in der Sie eine grundlegende Arbeits-App haben und Sie versuchen, sie auf die nächste Stufe von Polnisch und Professionalität zu bringen.
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.
