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. Toutes les idées listées sont actuellement ouvertes aux propositions.
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.
Votre candidature devra inclure :
Your proposal: a written document that describes in detail what you plan to achieve over
the course of the summer.
Votre expérience en tant que d éveloppeur. 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:
Le premier commit dans le dépôt electron/electron date du 13 mars 20131.
10 ans et 27 147 commits supplémentaires de 1192 contributeurs uniques plus tard, Electron est devenu l'un des frameworks les plus populaires pour la construction d'applications de bureau aujourd'hui. Ce étape importante est l'occasion parfaite de célébrer et de réfléchir au parcours effectué jusqu’à maintenant, et de partager ce que nous avons appris au fil du temps.
Nous ne serions pas ici aujourd’hui sans tous ceux qui ont consacré leur temps et leurs efforts à ce projet. Bien que les commits de code source soient toujours les contributions les plus visibles, nous devons également saluer les efforts des personnes qui signalent les bogues, tiennent à jour les modules d’utilisateur, fournissent de la documentation et des traductions, et participent à la communauté Electron à travers le cyberespace. Chaque contribution est inestimable pour nous en tant que responsables.
Avant de continuer avec le reste du billet : un grand merci. ❤️
Atom Shell a été construit pour être la colonne vertébrale de l’éditeur Atom de GitHub, présenté au public en version bêta en avril 2014. Construit en partant de zéro comme une alternative aux framework de bureau basé sur le web disponibles à l’époque (node-webkit et Chrome Embedded Framework). Son aspect le plus remarquable etait d' intégrer Node.js et Chromium pour fournir un environnement d’exécution de bureau puissant aux technologies web.
En moins d’un an, Atom Shell a commencé à voir une croissance très importante en terme de capacités et de popularité. Les grandes entreprises, les startups et les développeurs individuels ont commencé à l'utiliser pour construire des applications (parmi les premiers utilisateurs figurent Slack, GitKraken et WebTorrent), et le projet a été renommé judicieusement Electron.
A partir de ce moment, Electron a démarré sur les chapeaux de roue et ne s'est jamais arrêté. Voici un aperçu de notre decompte hebdomadaire de téléchargements au fil du temps, c'est une gracieuseté de npmtrends.com :
Electron v1 a été publié en 2016, promettant une meilleure stabilité de l'API et de meilleurs outils et documentation. Electron v2 a été publié en 2018 et a introduit le versionnage sémantique, ce qui permet aux développeurs d'Electron de garder une trace du cycle de publication.
Avec Electron v6, nous sommes passés à une cadence régulière de 12 semaines pour s'aligner sur celle de Chromium. Cette décision a été un changement de mentalité pour le projet, le fait d'avoir la version Chromium la plus à jour passant d'un souhait à une priorité. Cela a réduit la dette technologique entre les mises à niveau, ce qui nous a permis de garder Electron à jour et sécurisé.
Depuis lors, la machine tourne bien avec une nouvelle version Electron publiée le même jour que Chromium pour chaque version stable. Lorsque Chromium a accéléré sa cadence de libération en passant à 4 semaines en 2021, nous avons modifié sans problème la notre en conséquence.
Nous sommes maintenant à Electron v23 et nous sommes toujours dédiés à construire le meilleur runtime pour créer des applications de bureau multiplateformes. Même avec l'explosion du nombre d'outils de développement JavaScript ces dernières années, Electron est resté un pilier stable et éprouvé de la conception d'application pour bureau. Les applications Electron sont omniprésentes de nos jours : vous pouvez programmer avec Visual Studio Code, concevoir avec Figma, communiquez avec Slack, et prendre des notes avec Notion (entre autres choses). Nous sommes incroyablement fiers de ce résultat et nous sommes reconnaissants envers tous ceux qui ont rendus ce projet possible.
Le chemin pour atteindre cette décennie a été long et sinueux. Voici quelques éléments clés qui nous ont aidés à gérer ce grand projet open source de façon durable.
Redimensionnement de la prise de décision répartie avec un modèle de gouvernance
Un des défis que nous avons dû surmonter était de gérer la direction à long terme du projet lorsque la popularité d'Electron a explosé. Comment gérer le projet avec une équipe de quelques dizaines d’ingénieurs répartis dans différentes entreprises, dans différents pays et sous différents fuseaux horaires?
Dans les premiers temps, le groupe de mainteneurs d’Electron s'est fié à une coordination informelle, qui était rapide et légere pour les petits projets, mais ne pouvait pas s'adapter à une collaboration plus large. En 2019, nous sommes passés à un modèle de gouvernance avec différents groupes de travail ayant des domaines de responsabilité officiels. Cela a été déterminant pour la rationalisation des processus et l’attribution de de certaines parties du projet à des responsables spécifiques. Voici, de nos jours, la répartition des responsabilités des groupes de travail (GT):
Assurer la publication des versions d'Electron (Releases WG)
Mettre à jour Chromium et Node.js (Upgrades WG)
Surveiller la conception de l'API publique (API WG)
Garder Electron sécurisé (Security WG)
Gérer le site Web, la documentation et l'outillage (Ecosystem WG)
Sensibiliser les communautés et les entreprises (Outreach WG)
Effectuer la modération de la communauté (Community & Safety WG)
Maintenir notre infrastructure de compilation, nos outils pour les mainteneurs et nos services de cloud (Infrastructure WG)
À peu près en même temps que nous adoptions le modèle de gouvernance, nous avons également transféré la propriété d’Electron de GitHub à la Fondation OpenJS. Bien que l'équipe de base initiale travaille toujours chez Microsoft aujourd'hui, elle ne représente qu'une partie d'un groupe plus large de collaborateurs qui forment la gouvernance d'Electron.2
Bien que ce modèle ne soit pas parfait, il nous a convenu même pendant la traversée d'une pandémie mondiale et de vents macroéconomiques contraires . Pour le futur, nous prévoyons de réorganiser la charte de gouvernance pour qu'elle nous guide tout au long de la deuxième décennie d'Electron.
La partie communautaire d'un projet open source est un peu compliquée à gérer, surtout lorsque votre équipe de sensibilisation est composée d’une douzaine d’ingénieurs en trench indiquant « community manager ». Cela dit, étant un grand projet open source signifie d'avoir un gran nombre d'utilisateurs, et l'exploitation de leur énergie disponible pour Electron pour construise un écosystème utilisateur est un élément crucial pour le maintien de la santé du projet.
Qu’avons-nous fait pour renforcer notre présence communautaire?
En 2020, nous avons lancé notre serveur communautaire Discord. Nous avions auparavant une section dans le forum d’Atom, mais avons décidé d’avoir une plateforme de messagerie plus informelle pour avoir un espace de discussion entre responsables et développeurs Electron ainsi que pour l’aide générale au débogage.
En 2021, nous avons créé le groupe d'utilisateurs Electron China avec l'aide de @BlackHole1. Ce groupe a contribué à la croissance du nombre d'utilsateurs d’Electron de la scène technologique qui est en plein essor en Chine, leur offrant un espace pour collaborer sur des idées et discuter d’électron en dehors des espaces de langue anglaise. Nous aimerions également remercier cnpm pour leur travail de support des publications nocturnes d'Electron dans leur miroir chinois de npm.
Participation à des programmes open source à haute visibilité
Nous célébrons Hacktoberfest chaque année depuis 2019. Hacktoberfest est une célébration annuelle de l'open source organisée par DigitalOcean, et nous recevons chaque année des dizaines de contributeurs enthousiastes cherchant à se démarquer dans le domaine du logiciel libre.
En 2020, nous avons participé à la première de Google Season of Docs, où nous avons travaillé avec @bandantonio pour retravailler le nouveau flux de tutoriels utilisateur d'Electron.
En 2022, pour la première fois, nous avons encadré un étudiant pour son Google Summer of Code . @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.
Aujourd'hui, la gouvernance d'Electron compte environ 30 responsables actifs. Moins de la moitié d'entre nous sont des contributeurs à temps plein, ce qui implique beaucoup de travail. Quelle est notre astuce pour que tout fonctionne sans heurts ?: Notre devise est que les ordinateurs sont bon marché, et que le temps humain coûte cher. En tant qu’ingénieurs typiques, nous avons développé une suite d’outils de soutien automatisés pour nous rendre la vie plus facile.
Le cœur de la base de code Electron est un mastodonte de code C++, et les temps de compilation ont toujours été un facteur limitant pour la rapidité avec laquelle nous pouvons livrer des corrections de bugs et de nouvelles fonctionnalités. En 2020, nous avons déployé Not Goma, un backend personnalisé spécifique à Electron pour le service de compilation distribué Goma de Google. Ne pas Goma traite les demandes de compilation des machines de l'utilisateur autorisé et distribue le processus sur des centaines de cœurs dans le backend. Il met également en cache le résultat de la compilation de sorte que quelqu'un d'autre compilant les mêmes fichiers n'aura besoin que de télécharger le résultat pré-compilé.
Depuis le lancement de Not Goma, les temps de compilation pour les responsables sont passés de plusieurs heures à quelques minutes. Une connexion internet stable est devenue la condition minimale pour que les contributeurs compilent Electron!
info
Si vous êtes un contributeur open source, vous pouvez également essayer le cache en lecture seule de Not Goma, qui est disponible par défaut avec les Electron Build Tools.
L'authentification continue à plusieurs facteurs(CFA) est une couche d'automatisation autour du système d'authentification à deux facteurs (2FA) de npm que nous avons combinée combinons avec semantic release afin de gérer les publications sécurisées et automatisées de nos différents paquets @electron/ npm.
Alors que le versionnage sémantique automatise déjà le processus de publication des paquets npm, il faut désactiver authentification à deux facteurs ou passage d’un jeton secret qui contourne cette restriction.
Nous avons conçu le CFA pour fournir un mot de passe à usage unique (TOTP) pour les tâches de CI arbitraires, nous permettant ainsi d’exploiter l’automatisation du versionage sémantique tout en conservant la sécurité supplémentaire de l'authentification à deux facteurs.
Nous utilisons CFA avec une intégration frontale Slack, permettant aux responsables de valider la publication des paquets de n’importe quel appareil qu’ils ont Slack, tant qu’ils ont leur générateur TOTP à portée de main.
info
Si vous voulez essayer la FCA dans vos propres projets, consultez le dépôt GitHub ou ces autres documents! Si vous utilisez CircleCI comme fournisseur de CI, nous avons également orb , très paratique, pour mettre rapidement sur pied un projet avec CFA.
Sheriff est un outil open source que nous avons écrit pour automatiser la gestion des permissions à travers GitHub, Slack et Google Workspace.
L'apport de sheriff vient du fait que la gestion des autorisations devrait être un processus transparent. Il utilise un seul fichier de configuration YAML désignant les autorisations pour tous les services énumérés ci-dessus. Avec Sheriff, obtenir le statut de collaborateur sur un dépôt ou créer une nouvelle liste de diffusion est aussi simple que faire approuver et fusionner un Push request.
Sheriff a également un journal d'audit publie vers Slack, avertissant les administrateurs lorsque des activités suspectes se produisent n'importe où dans l'organisation Electron.
GitHub est une plate-forme avec une extensibilité API riche et un robot de framework d'application appelé Probot. Pour nous aider à nous concentrer sur les parties les plus créatives de notre travail, nous avons construit une suite de robots moins conséquents nous aidant à faire le sale boulot pour nous. Voici quelques exemples :
Sudowoodo automatise le processus de publication da A à Z, du lancement des compilations au téléchargement des ressources de publication sur GitHub et npm.
Trop automatise le processus de rétroportage d' Electron en essayantr de choisir des correctifs sur mesure pour les branches de diffusion précédentes en fonction des étiquettes PR de GitHub.
Rouleau automatise les mises à jour en cours des dépendances Chromium et Node.js d'Electron.
Cation est notre robot de vérification de l’état des Pull Request.
Dans l'ensemble, notre petite famille de bots nous a donné un énorme coup de pouce pour améliorer la productivité des développeurs!
Alors que nous entrons dans la deuxième décennie de notre projet, vous vous demanderez peut-être : que va t-il se passer maintenant pour Electron?
Nous allons demeurer en phase avec la cadence de sortie de Chromium, libérant de nouvelles versions majeures d'Electron toutes les 8 semaines en conservant les mises à jour relatives aux nouvautés les plus importants du web et de Node.js tout en maintenant la stabilité et la sécurité pour les applications de niveau entreprise.
Nous présentons généralement les initiatives à venir quand elles deviennent concrètes. Si vous voulez rester au courant des versions, des fonctionnalités et des mises à jour générales du projet, vous pouvez lire notre blog et nous suivre sur les médias sociaux (Twitter et Mastodon ) !
Il s'agit en fait du premier commit du projet electron-archive/brightray, qui a été absorbé par Electron en 2017 et dont l'historique git été fusionné. Mais est ce que cela compte ? C’est notre anniversaire, donc nous devons établir les règles ! ↩
Contrairement à la croyance populaire, Electron n'est plus la propriété de GitHub ou de Microsoft, et fait maintenant partie de la OpenJS Foundation. ↩
Le Google Summer of Code (GSoC) est un programme de mentorat annuel qui rassemble plusieurs projets de logiciel open source avec des contributeurs potentiels. Récemment ouvert seulement pour les étudiants, n'importe qui ayant 18 ans et plus peut désormais s'inscrire pour le GSoC.
Êtes-vous intéressé à collaborer avec Electron? Si vous êtes nouveau ou débutant dans la contribution de l'open source, nous vous invitons à postuler !
Envie de postuler ? Premièrement, regardez les cinq idées brouillons de projets que nous avons préparé. Toutes les idées listées sont actuellement ouvertes aux propositions. Nous acceptons également de nouvelles idées que nous n'avons pas proposées dans la liste des projets.
Votre candidature devra inclure :
Votre proposition, avec un document écrit qui décrit en détail votre plan de ce que vous comptez achever au cours de cet été.
Votre expérience en tant que développeur. Si vous avez un C.V, merci de l'inclure une copie, par ailleurs, parlez-nous de vos expériences passées en mettant l'accent sur vos expériences techniques pertinentes.
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. Si vous vous sentez particulièrement aventureux et à la recherche de défis., nous avons également un arriéré de problèmes marqués par les tags help wanted.
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. Au cas où vous l’auriez manqué, voici le lien d’invitation à nouveau!
Electron est fier de participer à la deuxième édition de l'initiative de Google Season of Docs, qui associe des mentors d'organisations open source avec des rédacteurs techniques pour améliorer la documentation du projet.
Qu'est-ce que Season of Docs ?
Season of Docs est un programme qui favorise la collaboration entre les rédacteurs techniques et les communautés open source au profit des deux parties. Les responsables de l’open source utilisent l’expertise technique de rédaction de l’auteur pour améliorer la structure et le contenu de leur documentation, tandis que le rédacteur technique est présenté à une communauté open source sous la direction de ses mentors. En savoir plus à ce sujet sur le site Web de google Season of Docs.
Pour la première fois que nous participerons au programme, nous encadrerons un seul rédacteur technique qui travaillera aux côtés du groupe de travail sur l’écosystème d’Electron pour remodeler de grandes parties de notre documentation. Vous pouvez en savoir plus sur la chronologie de l’ensemble du projet ici.
Comment s'inscrire ?
Êtes-vous intéressé à collaborer avec nous en tant que rédacteur technique ? Tout d’abord, familiarisez-vous avec le guide du rédacteur technique de Google pour le programme de cette année et consultez les deux ébauches d’idées de projet que nous avons préparées.
Afin d’être sélectionnés en tant que rédacteur technique d’Electron pour Season of Docs, les candidats devront postuler sur le site Web google Season of Docs pendant la phase de candidature rédatcteur technique qui se déroule du 8 juin au 9 juillet..
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 travaille à rendre ses cycles de publication plus rapides et plus stables. Pour rendre cela possible, nous avons lancé le programme de rétroaction pour les applications Electron à grande échelle pour tester nos versions bêta et nous signaler les problèmes spécifiques à l'application. Cela nous aide à prioriser le travail qui fera passer les applications à notre prochaine version stable plus tôt.
Modification (21/05/2020): Ce programme a été retiré.
Nous comprenons que tout le monde ne peut pas partager des nombres d'utilisateurs exacts, mais de meilleures données nous aident à décider de la stabilité d'une version en particulier. Nous demandons que les applications s'engagent à tester un nombre minimum d'heures-utilisateurs, actuellement 10 000 pour tout le cycle bêta.
10 heures-utilisateurs peuvent être de 10 personnes testant pendant une heure ou une personne testant pendant 10 heures
Vous pouvez diviser les tests entre des versions bêta, par exemple ceux pour 5 000 heures d'utilisateurs sur la version 3.0.0-beta et ensuite ceux pour 5 000 heures sur 3.0.0-beta.5. Plus on fait, mieux c'est, mais nous comprenons que certaines applications ne peuvent pas tester chaque version bêta
Les heures d'intégration continue ou d'assurance qualité ne sont pas prises en compte dans le total, cependant, les versions internes comptent
Pourquoi mon application Electron devrait-elle rejoindre ?
Les bogues de votre application seront suivis et seront sur le radar de l'équipe d'Electron. Vos commentaires aident l'équipe d'Electron à voir comment les nouvelles bêta font et ce qui doit être fait.
Les informations de mon application seront-elles partagées publiquement? Qui peut voir cette information?
Non, les renseignements de votre application ne seront pas partagés publiquement. Les informations sont conservées dans un dépôt GitHub privé qui n'est visible que par les membres du programme de rétroaction de l'application et Electron Governance. Tous les membres ont accepté de suivre le Code de conduite d'Electron.
Nous acceptons actuellement un nombre limité d'inscriptions. Si vous êtes intéressé et êtes en mesure de remplir les conditions ci-dessus, veuillez remplir ce formulaire.
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. Au début, j'ai envisagé d'utiliser l'API Notifications de GitHub. However I noticed that it does not support certain use cases. Après cela, j'ai envisagé d'utiliser l'API Issues API et Pull Requests API, en plus de l'API de notification. But it never became what I wanted. Puis en pensant à diverses méthodes, j'ai réalisé que le sondage de l'API de recherche de GitHub offrirait la plus grande flexibilité. 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.
Cette semaine, nous avons organisé une rencontre avec @feross et @dcposch pour parler de WebTorrent, le client torrent basé sur le Web qui connecte les utilisateurs pour former un réseau distribué et décentralisé de navigateur à navigateur.
WebTorrent est le premier client torrent qui fonctionne dans le navigateur. Il est écrit entièrement en JavaScript et il peut utiliser WebRTC pour les transmissions pair-à-pair. Aucun plugin, extension ou installation n'est nécessaire.
En exploitant les standards ouverts, WebTorrent connecte les utilisateurs de sites Web pour former un réseau distribué décentralisé de navigateur à navigateur, pour un transfert efficace de fichiers.
Vous pouvez voir une démonstration de WebTorrent en action ici : webtorrent.io.
Imaginez un site d'hébergement de vidéo comme YouTube, mais où les visiteurs aident à héberger le contenu du site. Plus le nombre d'utilisateurs d'un site Web propulsé par WebTorrent augmente, plus le site devient rapide et résilient.
La communication de navigateur à navigateur retire les intermédiaires et permet aux utilisateurs de communiquer selon leurs propres conditions. Plus de client/serveur – juste un réseau de pairs, tous égaux. WebTorrent est la première étape du voyage vers une nouvelle décentralisation du Web.
Il y a environ un an, nous avons décidé de créer WebTorrent Desktop, une version de WebTorrent qui fonctionne comme une application de bureau.
Nous avons créé WebTorrent Desktop pour trois raisons :
Nous voulions une application torrent propre, légère, sans publicité, open source
Nous voulions une application torrent avec un bon support pour la diffusion en flux
Nous avons besoin d'un "client hybride" qui connecte les réseaux BitTorrent et WebTorrent
Si nous pouvons déjà télécharger des torrents dans mon navigateur web, pourquoi une application de bureau ?
Tout d'abord, un peu de contexte sur la conception de WebTorrent.
Au début, BitTorrent a utilisé TCP comme protocole de transport. Plus tard, uTP est arrivé, promettant de meilleures performances et des avantages supplémentaires par rapport à TCP. Les principaux client pair-à-pair ont finalement adopté uTP, et aujourd'hui vous pouvez utiliser BitTorrent sur les deux protocoles. Le protocole WebRTC est l'étape logique suivante. Il promet l’interopérabilité avec les navigateurs web – un réseau pair-à-pair géant composé de tous les clients de bureau BitTorrent et de millions de navigateurs web.
Les “pairs Web” (pair torrent qui fonctionne dans un navigateur Web) renforcent le réseau BitTorrent en ajoutant des millions de nouveaux pairs, et permettent à BitTorrent de satisfaire des dizaines de nouveaux cas d'utilisation. WebTorrent suit la spécification BitTorrent aussi près que possible pour faciliter la prise en charge des clients BitTorrent existants par WebTorrent.
Certaines applications torrent comme Vuze prennent déjà en charge les pairs web, mais nous ne voulions pas attendre le support de la part des autres clients. Fondamentalement, WebTorrent Desktop a été notre façon d'accélérer l'adoption du protocole WebTorrent. En créant une application torrent géniale que les gens veulent vraiment utiliser, nous augmentons le nombre de pairs dans le réseau qui ont la capacité partager des torrents avec des pairs web (ex : utilisateurs sur les sites Web).
Quels sont des cas d'utilisation intéressants pour les torrents au-delà de ce que les gens conaissent déjà ?
Une des utilisations les plus excitantes pour WebTorrent est la diffusion assistée par pairs. Des projets à but non lucratif comme Wikipedia et l'Internet Archive pourraient réduire la bande passante et les coûts d'hébergement en permettant aux visiteurs de contribuer. Le contenu populaire peut être servi de navigateur à navigateur, rapidement et à moindre coût. Le contenu rarement consulté peut être servi de manière fiable via HTTP à partir du serveur d'origine.
L'Internet Archive a déjà mis à jour leurs fichiers torrent pour qu'ils fonctionnent au mieux avec WebTorrent. Donc, si vous voulez intégrer du contenu de l'Internet Archive à votre site, vous pouvez le faire d'une façon qui réduire les coûts d'hébergement pour l'Archive, leur permettant de consacrer plus de ressources à l'archivage effectif du web !
Il y a aussi de multiples cas d'utilisation métier excitant, des CDN à la livraison d'applications de pair-à-pair.
Quelque projets favoris qui utilisent WebTorrent ?
La chose la plus cool construite avec WebTorrent est, de loin, probablement Gaia 3D Star Map. Il s'agit d'une simulation interactive en 3D de la Voie Lactée. Les données se chargent à partir d'un torrent, directement dans votre navigateur. C'est impressionnant de voler au travers notre système stellaire et de réaliser à quel point nous, les humains, sommes insignifiants comparés à l'immensité de notre univers.
Vous pouvez lire sur la réalisation du projet dans Torrenting The Galaxy (en anglais), un article de blog où l'auteur, Charlie Hoey, explique comment il a construit la carte des étoiles avec WebGL et WebTorrent.
Nous sommes également des admirateurs de Brave. Brave est un navigateur qui bloque automatiquement les publicités et les pisteurs pour rendre le Web plus rapide et plus sûr. Brave à récemment ajouté le support de torrent pour que vous puissiez voir les torrents traditionnels sans utiliser une application séparée (en anglais). Cette fonctionnalité est supportée grâce à WebTorrent.
Ainsi, tout comme la façon dont la plupart des navigateurs peuvent afficher des fichiers PDF, Brave peut afficher les liens magnet et les fichiers torrents. Ce sont juste un autre type de contenu que le navigateur prend en charge nativement.
L'un des cofondateurs de Brave est Brendan Eich, le créateur de JavaScript, le langage dans lequel nous avons écrit WebTorrent, donc nous pensons qu'il est assez cool que Brave ait choisi d'intégrer WebTorrent.
Pourquoi avez-vous choisi de créer WebTorrent Desktop sur Electron?
Il y a un meme que les applications Electron sont « gonflées » parce qu'elles incluent l'intégralité du module de contenu Chrome dans chaque application. Dans certains cas, c'est partiellement vrai (un installateur d'applis Electron est généralement ~40 Mo, où un installateur d'applis spécifique au système d'exploitation est généralement ~20 Mo).
Cependant, dans le cas de WebTorrent Desktop, nous utilisons presque toutes les fonctionnalités d'Electron, et des dizaines de fonctionnalités de Chrome dans le cadre d'un fonctionnement normal. Si nous voulions implémenter ces fonctionnalités de zéro pour chaque plate-forme, il aurait fallu des mois ou des années de plus pour développer notre application, ou nous n'aurions pu être publiés que pour une seule plate-forme.
Juste pour donner une idée, nous utilisons l'intégration du dock d'Electron (pour afficher la progression du téléchargement), l'intégration de la barre de menu (pour l'exécution en arrière-plan), l'enregistrement des protocoles (pour ouvrir des liens magnet), le bloqueur d'économie d'énergie (pour éviter la mise en veille pendant la lecture vidéo) et la mise à jour automatique. En ce qui concerne les fonctionnalités de Chrome, nous utilisons également une grande quantité : la balise <video> (pour lire plusieurs formats vidéo différents), la balise <track> (pour la prise en charge des sous-titres), le support du glisser-déposer et WebRTC (qui n'est pas trivial à utiliser dans une application native).
Sans oublier : notre moteur torrent est écrit en JavaScript et présuppose l'existence de nombreuses API Node, principalement require('net') et require('dgram') pour le support des socket TCP et UDP.
Fondamentalement, Electron est exactement ce dont nous avions besoin et possède exactement le jeu de fonctionnalités dont nous avions besoin pour publier une application solide et soignée en un temps record.
Quelles sont vos choses préférées à propos d'Electron?
La bibliothèque WebTorrent est en développement, en tant que projet open source, depuis deux ans. Nous avons créé WebTorrent Desktop en quatre semaines. Electron est la principale raison pour laquelle nous avons pu développer et publier notre application si rapidement.
Tout comme Node.js a rendu la programmation serveur accessible à une génération de programmeurs front-end habitués à jQuery, Electron rend le développement d'applications natives accessibles à tous ceux qui sont familiers avec Web ou le développement Node.js. Electron est extrêmement puissant.
Le site Web et le client Desktop partagent-ils leur code ?
Oui, le paquet npm webtorrent fonctionne avec Node.js, le navigateur, et dans Electron. Le même code peut s’exécuter dans tous les environnements – c’est la beauté de JavaScript. C'est la plateforme d'exécution universelle d'aujourd'hui. Les applets Java ont promis des applications « Write Once, Run Anywhere » (n.d.l.t. : écrire une seule fois, exécuter partout, ancien slogan de Sun Microsystems), mais cette vision ne s'est jamais matérialisée, pour plusieurs raisons. Electron, plus que toute autre plate-forme, se rapproche réellement de cet idéal.
Quels sont les défis que vous avez rencontrés lors de la création de WebTorrent?
Dans les premières versions de l'application, nous avons rencontré des difficultés à rendre l'interface plus performante. Nous avons mis le moteur torrent dans le processus de rendu qui dessine également la fenêtre principale de l'application, ce qui, de manière prévisible, a mené à des ralentissements à chaque fois qu'il y avait une activité CPU intense provenant du moteur de torrent (comme la vérification des segments de torrent reçus des pairs).
Nous avons corrigé cela en déplaçant le moteur de torrent dans un second processus de rendu, invisible, avec lequel nous communiquons au travers IPC. Ainsi, si ce processus utilise brièvement beaucoup de CPU, le processus responsable de l'interface utilisateur n'est pas affecté. Les animations et défilement délicats sont si satisfaisants.
Note : nous avons dû mettre le moteur torrent dans un processus de rendu au lieu d'un processus "main", parce que nous avons besoin d'accéder à WebRTC (qui n'est disponible que dans le rendu.)
Une chose que nous aimerions voir est une meilleure documentation sur la façon de créer et de déployer des applications adaptées à la production, principalement autour de sujets délicats comme la signature de code et la mise à jour automatique. Nous avons dû apprendre les meilleures pratiques en creusant dans le code source et en demandant sur Twitter !
WebTorrent Desktop est-il terminé ? If not, what's coming next?
Nous pensons que la version actuelle de WebTorrent Desktop est excellente, mais il est toujours possible de l'améliorer. Nous travaillons actuellement au polissage et à l'amélioration des performances, du support des sous-titres et des codecs vidéo.
Si vous souhaitez participer au projet, consultez notre page GitHub!
Quelque conseils de développement pour Electron qui pourraient être utiles à d'autres développeurs ?
Feross, l'un des contributeurs de WebTorrent Desktop a récemment donné une conférence "Real world Electron: Building Cross-platform desktop apps with JavaScript" à la NodeConf Argentina qui contient des conseils utiles pour la publication d'une application Electron soignée. La conférence est particulièrement utile si vous êtes au stade où vous avez une application de travail de base et que vous essayez de la faire passer au niveau suivant du polissage et du professionnalisme.
DC, un autre contributeur WebTorrent, a écrit une liste des choses que vous pouvez faire (en anglais) pour que votre application apparaisse soignée et native. Il est livré avec des exemples de code et couvre des sujets tels que l'intégration du dock macOS, le glisser-déposer, les notifications de bureau et l'assistance pour que votre application se lance rapidement.
