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 é um framework JavaScript para construção de aplicações desktop multiplataforma, utilizando tecnologias web. 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:
O primeiro commit do repositório electron/electron foi em 13 de março de 20131.
Após 10 anos e 27,147 mais commits de 1192 contribuintes únicos, Electron se tornou uma das estruturas mais populares para construir aplicativos de desktop hoje. Esse marco é a oportunidade perfeita para celebrar e refletir sobre nossa jornada até agora, e para compartilhar o que aprendemos ao longo o caminho.
Nós não estaríamos aqui hoje sem todos que dedicaram seu tempo e seu esforço para contribuir com o projeto. Embora as contribuições de commits de código-fonte sejam sempre as mais visíveis, também devemos reconhecer o esforço das pessoas que relatam bugs, mant êm módulos de usuário, fornecem documentação e traduções, e participam na comunidade Electron em todo o ciberespaço. Todos os contributos são inestimáveis para nós, como mantenedores.
Antes de continuarmos com o resto do post: obrigado. ❤️
Atom Shell foi construído como a espinha dorsal do GitHub Editor Atom, que foi lançado em beta público em Abril de 2014. Foi construído a partir do zero como uma alternativa aos frameworks baseados na web disponíveis no tempo (node-webkit e Chromium Embedded Framework). Ele tinha um recurso matador: incorporando Node.js e Chromium para fornecer um poderoso tempo de execução desktop para tecnologias web.
Dentro de um ano, Atom Shell começou a assistir a um enorme crescimento das capacidades e da popularidade. Grandes empresas, startups e desenvolvedores individuais também começaram a construir aplicativos com ele (alguns early adopters incluem Slack, GitKraken, e WebTorrent), e o projeto foi apropriadamente renomeado para Electron.
A partir daí, o Electron começou com força total e nunca parou. Aqui está uma olhada em nossa contagem semanal de downloads ao longo do tempo, cortesia de npmtrends.com:
Electron v1 foi lançado em 2016, prometendo maior estabilidade da API e melhores documentos e ferramentas. Electron v2 foi lançado em 2018 e introduzido a versão semântica, tornando mais fácil para desenvolvedores Electron manter controle do ciclo de lançamento.
Por Electron v6, mudamos para uma cadência de lançamento maior de 12 semanas para combinar com a do Chromium. Esta decisão foi uma alteração na mentalidade do projeto, trazendo “ter a versão mais atualizada do Chromium ” de um nicho a ter uma prioridade. Isso reduziu a quantidade de dívida em tecnologia entre atualizações, tornando mais fácil para nós manter o Electron atualizado e seguro.
Desde então, temos funcionado como uma máquina bem oleada, lançando uma nova versão do Electron no mesmo dia que cada versão estável do Chromium. Quando o Chromium acelerou seu cronograma de lançamentos para 4 semanas em 2021, conseguimos simplesmente dar de ombros e aumentar nossa cadência de lançamentos para 8 semanas de acordo.
Agora estamos no Electron v23 (e contando), e ainda estamos dedicados a construir o melhor tempo de execução para construir aplicativos desktop multiplataforma. Mesmo com o boom das ferramentas de desenvolvedor de JavaScript em últimos anos, Electron continuou a ser uma paisagem estável e testada por batalhas do framework do aplicativo para desktop. Aplicativos Electron atualmente são onipresentes: você pode programar com o Visual Studio Code, projetar com Figma, se comunicar com o Slack, e fazer notas com Notion (entre muitos outros casos de uso). Estamos incrivelmente orgulhosos desta conquista e gratos a todos que a tornaram possível.
O caminho para o marco da década tem sido longo e ventoso. Aqui estão algumas coisas-chave que nos ajudaram a administrar um projeto de código aberto grande e sustentável.
Dimensionamento da tomada decisória distribuída com um modelo de governança
Um desafio que tivemos que superar foi lidar com a direção de longo prazo do projeto uma vez que o Electron explodiu na popularidade. Como lidamos com ser uma equipe de algumas dezenas de engenheiros distribuídos por empresas, países e fusos horários?
Nos primeiros dias, o grupo de mantenedores do Electron baseou-se em coordenação informal, que é rápido e leve para projetos menores, mas não escala para uma colaboração mais ampla. Em 2019, mudamos para um modelo de governança onde diferentes grupos de trabalho têm áreas formais de responsabilidade. Isto tem sido instrumental na racionalização de processos e atribuição de porções de propriedade do projeto a mantenedores específicos. Qual é a responsabilidade de cada grupo de trabalho (WG) actualmente?
Obter lançamentos do Electron rápido (Releases WG)
Atualizar o Chromium e o Node.js (Atualiza o WG)
Supervisão do design da API pública (Grupo de Trabalho de API)
Manter o Electron seguro (WG de segurança)
Manter o site, a documentação e a ferramenta (Ecosystem WG)
Alcance da Comunidade e corporativa (Outreach WG)
Moderação comunitária (Community & Segurança WG)
Manutenção de nossa infraestrutura construtiva, mantenedores de ferramentas e serviços de nuvem (Infraestrutura de WG)
Por volta do mesmo período em que mudamos para o modelo de governança, transferimos a propriedade do Electron do GitHub para a OpenJS Foundation. Embora a equipe central original ainda trabalhe na Microsoft hoje, eles são apenas uma parte de um grupo maior de colaboradores que compõem a governança do Electron.2
Embora esse modelo não seja perfeito, ele nos serviu bem durante uma pandemia global e desafios econômicos contínuos. Indo em frente, nós planejamos renovar a carta de governança para nos guiar durante a segunda década da Electron.
A parte da comunidade de código aberto é difícil, especialmente quando sua equipe de Outreach é uma dúzia de engenheiros em um casaco de trincheiras que diz "gerente da comunidade". Dito isso, ser um grande projeto de código aberto significa que temos muitos usuários, e utilizar sua energia para o Electron construir um ecossistema da userland é uma parte crucial para sustentar a saúde do projeto.
O que temos estado a fazer para desenvolver a nossa presença na comunidade?
Em 2020, lançamos o servidor da nossa comunidade do Discord. Anteriormente tínhamos uma secção no fórum do Atom, mas decidiu ter uma plataforma de mensagens mais informal para ter um espaço para discussões entre mantenedores e desenvolvedores Electron e para ajuda geral na depuração.
Em 2021, estabelecemos o grupo de usuários Electron China com a ajuda da @BlackHole1. Este grupo tem sido instrumental no crescimento do Electron em usuários da cena tecnológica da China, proporcionando um espaço para eles colaborarem em ideias e discuta o Electron fora de nossos espaços em inglês. Nós também gostaríamos de agradecer à cnpm pelo seu trabalho de apoio aos lançamentos noturnos da Electron, em seu espelho Chinês para o npm.
Participando de programas de alta visibilidade de código aberto
Temos comemorado o Hacktoberfest todos os anos desde 2019. O Hacktoberfest é uma celebração anual de código aberto organizada pela DigitalOcean, e todos os anos recebemos dezenas de colaboradores entusiasmados que buscam deixar sua marca no software de código aberto.
Em 2020, participamos da iteração inicial da Google Season of Docs, onde trabalhamos com @bandantonio para retrabalhar o novo fluxo de tutorial do Electron.
Em 2022, mentorizamos um aluno do Google Summer of Code pela primeira vez. @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.
Hoje, a governaça do Electron conta com cerca de 30 mantenedores ativos. Menos de metade de nós somos colaboradores a tempo integral contribuidores, o que significa que há muito trabalho a fazer. Qual é o nosso truque para manter tudo funcionando sem problemas? O nosso lema é que os computadores são baratos, e o tempo humano é caro. De forma típica de engenheiro, nós desenvolvemos um conjunto de ferramentas automatizadas de suporte para tornar nossas vidas mais fáceis.
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!
À medida que entramos em nossa segunda década como um projeto, você deve estar perguntando: o que vem por aí com o Electron?
Vamos continuar em sincronia com a cadência de lançamentos do Chromium, lançando novas versões principais do Electron a cada 8 semanas, mantendo o framework atualizado com o que há de mais recente na plataforma web e no Node.js, ao mesmo tempo em que mantemos estabilidade e segurança para aplicativos de nível empresarial.
Normalmente anunciamos notícias sobre iniciativas futuras quando elas se tornam concretas. Se você quiser se manter informado sobre as versões futuras, recursos e atualizações gerais do projeto, você pode ler nosso blog e seguir nossos perfis de mídia social (Twitter e Mastodon)!
Esse é realmente o primeiro commit do projeto electron-archive/brightray, que foi absorvido pelo pelo Electron em 2017 e teve sua história git fundida. Mas quem está contando? É nosso aniversário, então vamos fazer as regras! ↩
Ao contrário do que se acredita popularmente, o Electron não é mais de propriedade do GitHub ou da Microsoft e, atualmente, faz parte da OpenJS Foundation. ↩
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!
O Electron tem orgulho de participar da segunda edição da iniciativa Temporada de Docs do Google, que compara mentores de organizações de código aberto com escritores técnicos para melhorar a documentação do projeto.
O que é Temporada de Docs?
A Temporada de Docs é um programa que promove a colaboração entre autores técnicos e comunidades de código aberto em benefício de ambas as partes. Mantenedores de código aberto utilizam os conhecimentos técnicos de escrita do escritor para melhorar a estrutura e o conteúdo de sua documentação, enquanto o escritor técnico é introduzido a uma comunidade de código aberto sob a orientação de seus mentores. 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
Você pode dividir os testes entre versões beta, por exemplo, teste por 5.000 horas de usuário em 3.0.0-beta. e, em seguida, teste por 5.000 horas de usuário na 3.0.0-beta.5. Mais é melhor, mas entendemos que algumas aplicações não podem testar cada lançamento beta
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. No começo eu considerei usar o API de Notificações do GitHub. However I noticed that it does not support certain use cases. Depois disso, considerei o uso da API de problemas e Pull Requests API, além da API de notificação. But it never became what I wanted. Então, enquanto pensando em vários métodos, eu percebi que API de pesquisa do GitHub ofereceria a maior flexibilidade. 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?
Há um meme que os apps do Electron estão "bloate" porque eles incluem todo o módulo de conteúdo do Chrome em cada aplicativo. Em alguns casos, isso é parcialmente verdade (um instalador de aplicativos do Electron normalmente é ~40MB, onde o instalador de aplicativo específico para Sistema Operacional geralmente é ~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. A palestra é especialmente útil se você estiver no estágio onde você tem um aplicativo básico de trabalho e está tentando levá-la para o próximo nível de polimento e profissionalismo.
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.
