Cette semaine, nous avons rencontré Paul Frazee, créateur de Beaker Browser. Beaker est un navigateur web expérimental peer-to-peer qui utilise le protocole Dat pour héberger des sites à partir des appareils des utilisateurs.

Qu'est-ce que Beaker et pourquoi l'avez-vous créé ?​

Beaker est un navigateur participatif. C'est un navigateur pour les hackers indépendants.

Le Web est une source fermée. Si vous voulez influencer le fonctionnement des réseaux sociaux, vous devez travailler chez Facebook ou Twitter. Pour la recherche, Google. Le contrôle est entre les mains des entreprises plutôt que des utilisateurs eux-mêmes.

Avec Beaker, nous disposons d'un nouveau protocole Web : le Decentralized Archive Transport. "Dat". Il crée des sites à la demande, gratuitement, et ensuite les partage à partir de l'appareil. Aucun serveur requis. C'est notre innovation.

Lorsque vous visitez un site Dat dans Beaker, vous téléchargez les fichiers. Le site vous appartient, pour toujours. Vous pouvez l'enregistrer, le dupliquer, le modifier et partager gratuitement votre nouvelle version. Tout est open source.

Voilà donc de quoi il s'agit : nous développons un navigateur pour les sites Web open source. Nous voulons que ce soit une boîte à outils pour le piratage social.

Qui devrait utiliser Beaker ?​

Hackers Moddeurs Les créatifs. Les personnes qui aiment bricoler.

Comment créer un nouveau projet qui utilise Dat ?​

Nous avons un outil en ligne de commande appelé bkr qui ressemble un peu à git + npm. Voici comment créer un site :

$ cd ~/mon-site
$ bkr init
$ echo "Bonjour, monde!" > index.html
$ bkr publish

Et voici comment créer une duplication d'un site :

$ bkr fork dat://0ff7d4c7644d0aa19914247dc5dbf502d6a02ea89a5145e7b178d57db00504cd/ ~/my-fork
$ cd ~/my-fork
$ echo "Mon fork n'a aucune considération pour l'index précédent. > index.html
$ bkr publish

Ces sites sont alors hébergés en dehors de votre navigateur. C'est un peu comme BitTorrent : vous partagez les sites dans un réseau P2P.

Si vous souhaitez une interface graphique, nous avons intégré quelques outils de base au navigateur, mais nous les transférons vers l'espace utilisateur. Tout cela sera modifiable par les applications utilisateur.

Pourquoi avez-vous choisi de développer Beaker sur Electron ?​

C'était évident pour ce projet. Si je créais moi-même une duplication de Chrome, je serais en train d'écrire du code C++ en ce moment même ! Personne ne veut faire ça. Je connais bien la pile Web et je peux travailler rapidement avec. C'est une évidence.

À vrai dire, je ne suis pas sûr de pouvoir faire tout cela sans Electron. C'est un excellent logiciel.

Quels sont les défis auxquels vous avez été confrontés lors de la création de Beaker ?​

La moitié consiste à tester les outils et à déterminer jusqu'où je peux aller.

La création du navigateur en lui-même a été assez facile. Electron est pratiquement une boîte à outils pour créer des navigateurs. ... À l'exception des onglets du navigateur ; cela m'a pris une éternité pour y arriver. J'ai finalement craqué et appris à utiliser les SVG. C'est beaucoup plus esthétique, mais il m'a fallu trois ou quatre essais avant d'y arriver.

Dans quels domaines faut-il améliorer Electron ?​

Ce serait vraiment génial si je pouvais ancrer les outils de développement dans une vue Web.

Quelles sont les prochaines nouveautés dans Beaker ?​

Noms DNS sécurisés pour les sites Dat. Un schéma d'URL socialement configurable, appelé « schéma d'application ». Plus d'API Dat.

Pour ceux qui seraient intéressés à contribuer au projet, dans quels domaines Beaker a-t-il besoin d'aide ?​

Nous avons beaucoup de problèmes en cours. N'hésitez pas à me contacter. #beakerbrowser sur freenode. Nous tenons à jour une page dédiée aux contributeurs et nous vous y ajouterons. Et si vous venez à Austin, je vous offrirai une bière.

Des conseils d'Electron qui pourraient être utiles aux autres développeurs ?​

1. Utilisez les outils de construction disponibles. Vous ne voulez pas vous débattre avec vos propres solutions, croyez-moi. Utilisez electron-builder. Utilise un dépôt modèle.
2. Si vous devez ouvrir un ticket dans le dépôt Electron, faites un effort supplémentaire pour faciliter sa reproduction. Vous obtiendrez une réponse beaucoup plus rapidement, et l'équipe vous en sera reconnaissante. Mieux encore, essayez de le réparer vous-même. C'est en fait assez intéressant de voir l'intérieur.
3. Lisez au moins une fois tous les guides et documents avancés.
4. Ne créez pas de navigateur, c'est un marché saturé.

The Electron community is growing quickly, and people are creating powerful new apps and tools at an astounding rate. To celebrate this creative momentum and keep the community informed of some of these new projects, we've decided to start a weekly blog series featuring noteworthy Electron-related projects.

This post is the first in the series, and features Kap, an open-source screen recording app built by Wulkano, a geodistributed team of freelance designers and developers.

What is Kap?​

Kap is an open-source screen recorder built primarily for designers and developers to easily capture their work. People use it to share animated prototypes, document bugs, create silly GIFs and everything in-between.

Nous avons vu des gens de tous âges et de tous horizons l'utiliser dans des environnements éducatifs, screencasts, tutoriels... la liste continue. Even to create production assets! We're completely blown away by how well received our little side project has been.

Why did you build it?​

That's a very good question, it's not like there's a lack of screen recorders out there! We felt the alternatives were either too complex, too expensive or too limited. Nothing felt just right for our everyday needs. We also think it's great when the tools we use to do our work are open-source, that way everyone can help shape them. Building Kap ended up being just as much about what we didn't do. It's all in the details, an accumulation of small improvements that became the outline of a tool we wanted to use.

However, and maybe most importantly, Kap has become a place for us to leave our worries at the door and just have fun building something for ourselves and people like us. It's so important to create an environment where you get to just vent, try new thins and enjoy your craft. No requirements, no pressure, no expectations. Should designers and developers side project? Why, yes. Yes, they should.

Why did you choose to build Kap on Electron?​

There were a number of reasons:

• Web tech
• Most of the team are web developers
• We're invested in JavaScript
• It opens the door for more people to contribute
• Electron itself is open-source
• The power and easily maintainable modularity of node_modules
• Cross-platform possibilities

We think the future of apps are in the browser, but we're not quite there yet. Electron is an important step in the journey towards that future. It not only makes the apps themselves more accessible, but also the code they're built with. An interesting thought is imagining a future where the OS is a browser, and the tabs are essentially Electron apps.

Additionally, being primarily web developers, we're big fans of the isomorphic nature of JavaScript, in that you can run JS on the client, server, and now the desktop. With web tech (HTML, CSS and JS), many things are much simpler than native: Faster prototyping, less code, flexbox > auto-layout (macOS/iOS).

What are some challenges you've faced while building Kap?​

Using the resources Electron has available to record the screen was the biggest challenge. They simply weren't performant enough to meet our requirements and would render the project a failure in our eyes. Though at no fault of Electron itself, there's still a gap between native development and building desktop apps with web tech.

We spent a lot of time trying to work around the poor performance of the getUserMedia API, an issue originating in Chromium. One of our main goals when we set out to make Kap was to build the entire app with web tech. After trying everything we could to get it working (the minimum requirement being 30 FPS on a Retina screen), we eventually had to find another solution.

I see some Swift code in the repo. What's that about?​

Being forced to look for alternatives to getUserMedia, we started experimenting with ffmpeg. Besides being one of the best tools for audio and video conversion it has the functionality of recording the screen in almost any OS, and we were able to record crispy video meeting our minimum requirement of 30 FPS on a Retina screen. Problem? The performance was "😩", the CPU usage was going haywire. So we went back to the drawing board, discussed our options and realised that we had to make a compromise. That resulted in Aperture, our own screen recording library for macOS written in Swift.

Dans quels domaines faut-il améliorer Electron ?​

We all know that Electron apps can have a thing for using RAM, but again, that's really a Chromium thing. It's part of how it works and it really depends on what you're running, for example Kap and Hyper typically use less than 100MB of memory.

One of the biggest areas of improvement that we see is payload, particularly how Electron distributes Chromium. One idea would be to have a shared Electron core and make app installers check if it's already present on the system.

Creating cross-platform Electron apps could be a better experience. Right now there are too many inconsistencies, platform-specific APIs, and missing features between platforms, making your codebase littered with if-else statements. For example, vibrancy is only supported on macOS, the auto-updater works differently on macOS and Windows, and is not even supported on Linux. Transparency is a hit or miss on Linux, usually miss.

It should also be easier to call native system APIs. Electron comes with a very good set of APIs, but sometimes you need functionality it doesn't provide. Creating a native Node.js addon is an option, but it's painful to work with. Ideally Electron would ship with a good FFI API, like fastcall. This would have enabled us to write the Swift part in JavaScript instead.

Quelles sont vos choses préférées à propos d'Electron?​

Our favorite thing is easily the fact that anyone with knowledge of creating for the web can build and contribute to multi-platform native experiences. Not to mention the ease and joy of developing on it, the excellent documentation and the thriving ecosystem.

From a front-end perspective, building Kap felt no different than building a simple website using browser APIs. Electron does a really great job of making app development similar (basically identical) to web development. So simple in fact that there was no need for frameworks or similar to help us, just clean and modular JS and CSS.

We are also huge fans of the team building it, their dedication and support, and the active and friendly community they maintain. Hugs to all of you!

What's coming next in Kap?​

The next step for us is to review the app in preparation for our 2.0.0 milestone, which includes a React re-write in addition to support for plugins, allowing developers to extend the functionality of Kap! We invite everyone to follow to project and contribute on our GitHub repository. We're listening and want to hear from as many of you as possible, let us know how we can make Kap the best possible tool it can be for you!

What is Wulkano?​

Wulkano is a design studio and digital collective, a team of remote technologists who love working together on both client gigs and our own projects. We're a distributed but tight knit group of people from different places and backgrounds, sharing knowledge, ideas, experiences, but most importantly silly GIFs and memes, in our virtual office (which happens to be the Electron based Slack!).

Des conseils d'Electron qui pourraient être utiles aux autres développeurs ?​

Take advantage of and get involved in the fantastic community, check out Awesome Electron, look at examples and make use of the great docs!

Nous avons récemment organisé un hackathon Electron au siège de GitHub pour les membres de la Hackbright Academy, une école de codage pour femmes fondée à San Francisco. Pour aider les participants à prendre un bon départ dans leurs projets, notre propre Kevin Sawicki a créé quelques exemples d'applications Electron.

Si vous êtes nouveau dans le développement avec Electron ou si vous ne l'avez pas encore essayé, ces exemples d'applications sont un bon point de départ. Ils sont petits, faciles à lire et le code est fortement commenté pour expliquer comment tout fonctionne.

Pour commencer, clonez ce dépôt :

git clone https://github.com/electron/simple-samples

Pour exécuter l'une des applications ci-dessous, allez dans le répertoire de l'application, installez les dépendances, puis démarrez :

cd activity-monitor
npm install
npm start

Moniteur d'activité​

Affiche un diagramme en beignet du temps d'activité du CPU, de l'utilisateur et d'inactivité.

Hachage​

Affiche les valeurs de hachage du texte saisi en utilisant différents algorithmes.

Miroir​

Lit une vidéo de la caméra de l'ordinateur à une taille maximale, comme si vous regardiez dans un miroir. Inclut un effet de filtre arc-en-ciel optionnel qui utilise des animations CSS.

Prix​

Affiche le prix actuel du pétrole, de l'or et de l'argent à l'aide de l'API Yahoo Finance.

URL​

Charge une URL passée à la ligne de commande dans une fenêtre.

Autres ressources​

Nous espérons que ces applications vous aideront à démarrer avec Electron. Nous vous proposons également ces quelques autres ressources pour en apprendre plus :

• electron-quick-start : Un modèle minimal d'application Electron.
• Electron API Demos : Une application interactive qui présente les principales fonctionnalités de l'API Electron.
• electronjs.org/docs/all : Toute la documentation d'Electron réunie et consultable sur une seule page.
• hokein/electron-sample-apps : Autre collection d'exemples d'applications pour Electron, compilé par le mainteneur d'Electron Haojian Wu.
• awesome-electron - Un dépôt GitHub rassemblant les tutoriels, livres, vidéos, etc. les plus interessants et recents liés à Electron.

Nous avons ajouté une nouvelle section userland au site Web d'Electron pour aider les utilisateurs à découvrir les gens, les packages et les applications qui composent notre écosystème open-source florissant.

Origines du Userland​

Userland est l'endroit où les gens dans les communautés de logiciels se réunissent pour partager des outils et des idées. Le terme est originaire de la communauté Unix, où il fait référence à tout programme qui s'est exécuté en dehors du noyau, mais aujourd'hui, cela signifie quelque chose de plus. Lorsque les membres de la communauté Javascript d’aujourd’hui se réfèrent à userland, ils parlent généralement du registre des paquets npm. C'est là que la majorité des expériences et l'innovation se produisent, alors que Node et le langage JavaScript (comme le noyau Unix) conservent un ensemble relativement petit et stable de fonctionnalités de base.

Node et Electron​

Comme Node, Electron a un petit ensemble d’API de base. Celui ci fournit les fonctionnalités de base nécessaires au développement d'applications de bureau multi-plates-formes. Cette philosophie de conception permet à Electron de rester un outil flexible sans être trop normatif sur la manière dont il devrait être utilisé.

Userland est le pendant du « core », permettant aux utilisateurs de créer et de partager des outils qui étendent les fonctionnalités d’Electron.

Collecte des données d’utilisation​

Pour mieux comprendre les tendances de notre écosystème, nous avons analysé les métadonnées de 15 000 dépôts GitHub publics qui dépendent de electron ou electron-prebuilt

Nous avons utilisé les bibliothèques GitHub API, libraries.io API, et le registre npm pour récupérer des informations sur les dépendances, dépendances de développement, dépendants, auteurs de package, contributeurs de dépôts, compteurs de téléchargement, compteurs de fork, compteurs de stargazer etc.

Nous avons ensuite utilisé ces données pour générer les rapports suivants :

• Dépendances de développement d'applications: Paquets les plus souvent listés comme devDependencies dans les applications Electron.
• Contributeurs GitHub: utilisateurs de GitHub ayant contribué à de nombreux dépôts GitHub liés à Electron.
• Package Dependencies: Packages npm liés à l’électron fréquemment dépendants d’autres package npm.
• Applications favorites: les applications Electron (qui ne sont pas des package npm) avec de nombreux stargazers.
• Packages les plus téléchargés: packages npm liés à Electron téléchargés de nombreuses fois.
• Dépendances des applications: Packages les plus souvent listés comme dependencies dans les applications Electron.
• Package Authors: Les auteurs les plus prolifiques de packages npm liés à Electron.

Filtrage des résultats​

Des rapports tels que les dépendances d’applications et les applications étoilées qui répertorient les packages, les applications et les repos ont une entrée de texte qui peut être utilisée pour filtrer les résultats.

Lorsque vous tapez dans cette entrée, l'URL de la page est mise à jour dynamiquement. Ceci permet de copier une URL représentant une tranche particulière de données de l'espace utilisateur, puis de la partager avec d'autres.

Plus d'infos à venir​

Ce premier ensemble de rapports n'est que le début. Nous continuerons à collecter des données sur la façon dont la communauté construit Electron, et nous ajouterons de nouveaux rapports au site web.

Tous les outils utilisés pour collecter et afficher ces données sont open-source:

• electron/electronjs.org: Le site Electron.
• rapports electron/electron-userland-reports: Tranches de données sur les packages, dépôts et utilisateurs dans Electron userland.
• electron/repos-using-electron : Tous les dépôts publics sur GitHub qui dépendent de electron ou electron-prebuilt
• electron/electron-npm-packages: Tous les packages de npm mentionnant electron dans leur fichier package.json.

Si vous avez des idées sur la façon d'améliorer ces rapports, veuillez nous faire savoir en déclarant un problème sur le dépôt du site web ou l'un des dépôts susmentionnés.

Merci à vous, la communauté Electron, d’avoir fait de userland ce qu’il est aujourd’hui !

Electron 1.4. 2 contient une mise à jour importante qui corrige un problème de Chrome amont où certains Symantec, GeoTrust, et les certificats Thawte SSL/TLS sont incorrectement rejetés 10 semaines à partir de la date de construction de libchromiumcontent, la bibliothèque Chrome sous-jacente d'Electron. There are no issues with the certificates used on the affected sites and replacing these certificates will not help.

In Electron 1.4.0 — 1.4.11 HTTPS requests to sites using these affected certificates will fail with network errors after a certain date. This affects HTTPS requests made using Chrome's underlying networking APIs such as window.fetch, Ajax requests, Electron's net API, BrowserWindow.loadURL, webContents.loadURL, the src attribute on a <webview> tag, and others.

Upgrading your applications to 1.4.12 will prevent these request failures from occurring.

Note: This issue was introduced in Chrome 53 so Electron versions earlier than 1.4.0 are not affected.

Impact Dates​

Below is a table of each Electron 1.4 version and the date when requests to sites using these affected certificates will start to fail.

You can verify your app's impact date by setting your computer's clock ahead and then check to see if https://symbeta.symantec.com/welcome/ successfully loads from it.

More Information​

You can read more about this topic, the original issue, and the fix at the following places:

• What is Certificate Transparency?
• Symtantec knowledge base article
• Chrome issue 664177
• Chrome fix for issue 664177
• libchromiumcontent patch for issue 664177

Voici les nouvelles applications et conférences d'Electron qui ont été ajoutées au site en septembre.

This site is updated with new apps and meetups through pull requests from the community. Vous pouvez surveiller le dépôt pour être informé des nouveaux ajouts ou, si vous n'êtes pas intéressé par toutes les modifications du site, vous pouvez vous abonner au fil RSS du blog.

Si vous avez créé une application Electron ou si vous organisez une réunion, faites une requête pour l'ajouter au site et elle fera partie du prochain regroupement.

Nouvelles discussions​

En septembre, GitHub a tenu sa conférence GitHub Universe présentée comme l'événement pour les personnes qui construisent l'avenir des logiciels. Il y a eu quelques présentations intéressantes d'Electron lors de l'événement.

• Rendre le développement d'Electron plus simple, plus agréable, et plus productif par Machisté Quintana, un ingénieur logiciel chez Slack.
• Electron: Desktop Apps with Web Languages by Zeke Sikelianos, an Electron Developer at GitHub.

Also, if you happen to be in Paris on December 5, Zeke will be giving an Electron talk at dotJS 2016.

Nouvelles applications​

	Pexels	Search for completely free photos and copy them into your clipboard
	Timestamp	A better macOS menu bar clock with a customizable date/time display and a calendar
	Harmony	Music player compatible with Spotify, Soundcloud, Play Music and your local files
	uPhone	WebRTC Desktop Phone
	SealTalk	Instant-messaging App powered by RongCloud IM Cloud Service and IM SDK
	Infinity	An easy way to make presentation
	Cycligent Git Tool	Straightforward, graphic GUI for your Git projects
	Foco	Stay focused and boost productivity with Foco
	Strawberry	Win Diners for Life Know and serve them better with the all-in-one restaurant software suite.
	Mixmax	See every action on your emails in real-time Compose anywhere.
	Firebase Admin	A Firebase data management tool
	ANote	A Simple Friendly Markdown Note
	Temps	A simple but smart menubar weather app
	Amium	A work collaboration product that brings conversation to your files
	Soube	Simple music player
	(Un)colored	Next generation desktop rich content editor that saves documents with themes HTML & Markdown compatible. For Windows, OS X & Linux.
	quickcalc	Menubar Calculator
	Forestpin Analytics	Financial data analytics tool for businesses
	Ling	REST Client
	Shortexts	Shortcuts for texts you copy frequently, folders and emojis
	Front-End Box	Set of front-end-code generators

Nous annonçons aujourd’hui, quelques améliorations de la documentation d’Electron. Chaque nouvelle version inclut désormais un fichier JSON décrivant en détail toutes les API publiques d’Electron. Nous avons créé ce fichier pour permettre aux développeurs d’utiliser la documentation de l’API d’Electron de manière plus intéressante.

Aperçu du schéma​

Chaque API est un objet avec des propriétés telles que nom, description, type, etc. Les classes telles que BrowserWindow et Menu ont des propriétés supplémentaires décrivant leurs méthodes d’instance, propriétés d’instance, événements d’instance, etc.

Voici un extrait du schéma décrivant la classe BrowserWindow:

{
  nom: 'BrowserWindow', description
  : 'Créer et contrôler les fenêtres du navigateur.', processus
  : {
    main: true,
    renderer: false
  }, type
  : 'Class',
  instanceName: 'win',
  slug: 'browser-window',
  websiteUrl: 'https://electronjs.org/docs/api/browser-window',
  repoUrl: 'https://github.com/electron/electron/blob/v1.4.0/docs/api/browser-window.md',
  staticMethods: [...],
  instanceMethods: [...],
  instanceProperties: [...],
  instanceEvents: [...]
}

Et cet autre exemple exemple de description dune méthode, ici, la méthode d'instance apis.BrowserWindow.instanceMethods.setMaximumSize:

{
  name: 'setMaximumSize',
  signature: '(width, height)',
  description: 'Sets the maximum size of window to width and height.',
  parameters: [{
    name: 'width',
    type: 'Integer'
  }, {
    name: 'height',
    type: 'Integer'
  }]
}

Utilisation de ces nouvelles données​

Pour faciliter l'utilisation de ces données structurées dans leurs projets par les développeurs, nous avons créé electron-docs-api, un petit package npm publié automatiquement chaque fois qu'il y a une nouvelle version d'Electron .

npm install electron-api-docs --save

Pour une appréciation rapide, essayez le module dans votre REPL Node.js :

npm i -g trymodule && trymodule electron-api-docs=apis

Comment les données sont collectées​

La documentation API d'Electron adhère à Electron Coding Style et au Electron Styleguide et donc son contenu peut être analysé par programme.

Le electron-docs-linter est une nouvelle dépendance de développement du dépôt electron/electron. C'est un outil en ligne de commande qui effectue un lint de tous les fichiers markdown et applique les règles du styleguide. Si des erreurs sont trouvées, elles sont listées et le processus de publication est interrompu. Si les docs de l'API sont valides, le fichier electron-json.api est créé et téléchargé sur GitHub pour être inclus dans la version d'Electron.

Javascript standard et Markdown standard​

Plus tôt dans l'année, la base de code d'Electron a été mise à jour pour utiliser le linter standard pour tout JavaScript. Le README de Standard résume le raisonnement derrière ce choix :

L'adoption d'un style standard donne plus dl'importance à la clarté du code et des conventions communautaires que le style personnel. Cela n'est peut être pas judicieux pour 100 % des projets et des cultures de développement, toutefois l'open source peut être un environnement hostile pour les débutants. La mise en place d’attentes claires et automatisées des contributeurs rend un projet plus sain.

Nous avons également récemment créé markdown-standard pour vérifier que tous les snippets de code JavaScript de notre documentation sont valides et cohérents avec le style de la base de code elle-même.

Ensemble, ces outils nous aident à utiliser l'intégration continue (CI) pour trouver automatiquement des erreurs dans les pull requests. Cela réduit le fardeau imposé aux humains qui effectuent la revue du code et nous donne plus de confiance quant à l’exactitude de notre documentation.

Un effort de la communauté​

La documentation d’Electron s’améliore constamment, et nous devons remercier notre formidable communauté open-source pour cela. Au moment d’écrire ces lignes, près de 300 personnes ont contribué aux documents.

Nous sommes heureux de voir ce que les gens font avec ces nouvelles données structurées. Utilisations possibles:

• Améliorations de https://electronjs.org/docs/
• Un fichier de définition de TypeScript pour un développement Electron plus simplifié dans les projets utilisant TypeScript.
• Documentation interrogeable hors ligne pour des outils tels que Dash.app et devdocs.io

As a language with garbage collection, JavaScript frees users from managing resources manually. But because Electron hosts this environment, it has to be very careful avoiding both memory and resources leaks.

This post introduces the concept of weak references and how they are used to manage resources in Electron.

Weak references​

In JavaScript, whenever you assign an object to a variable, you are adding a reference to the object. As long as there is a reference to the object, it will always be kept in memory. Once all references to the object are gone, i.e. there are no longer variables storing the object, the JavaScript engine will recoup the memory on next garbage collection.

A weak reference is a reference to an object that allows you to get the object without effecting whether it will be garbage collected or not. You will also get notified when the object is garbage collected. It then becomes possible to manage resources with JavaScript.

Using the NativeImage class in Electron as an example, every time you call the nativeImage.create() API, a NativeImage instance is returned and it is storing the image data in C++. Once you are done with the instance and the JavaScript engine (V8) has garbage collected the object, code in C++ will be called to free the image data in memory, so there is no need for users manage this manually.

Un autre exemple est le problème de disparition de fenêtre, qui montre visuellement comment la fenêtre est des ordures collectées quand toutes les références à lui sont terminées.

Testing weak references in Electron​

There is no way to directly test weak references in raw JavaScript since the language doesn't have a way to assign weak references. The only API in JavaScript related to weak references is WeakMap, but since it only creates weak-reference keys, it is impossible to know when an object has been garbage collected.

In versions of Electron prior to v0.37.8, you can use the internal v8Util.setDestructor API to test weak references, which adds a weak reference to the passed object and calls the callback when the object is garbage collected:

// Le code ci-dessous ne peut s'exécuter que sur Electron < v0.37.8.
var v8Util = process.atomBinding('v8_util');

var object = {};
v8Util.setDestructor(object, function () {
  console.log('The object is garbage collected');
});

// Remove all references to the object.
object = undefined;
// Manually starts a GC.
gc();
// Console prints "The object is garbage collected".

Note that you have to start Electron with the --js-flags="--expose_gc" command switch to expose the internal gc function.

The API was removed in later versions because V8 actually does not allow running JavaScript code in the destructor and in later versions doing so would cause random crashes.

Weak references in the remote module​

Apart from managing native resources with C++, Electron also needs weak references to manage JavaScript resources. Un exemple est le module distantd'Electron, , qui est un module d'appel à distance (RPC) qui permet d'utiliser des objets dans le processus principal à partir des processus de rendu.

One key challenge with the remote module is to avoid memory leaks. When users acquire a remote object in the renderer process, the remote module must guarantee the object continues to live in the main process until the references in the renderer process are gone. Additionally, it also has to make sure the object can be garbage collected when there are no longer any reference to it in renderer processes.

For example, without proper implementation, following code would cause memory leaks quickly:

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
  remote.nativeImage.createEmpty();
}

The resource management in the remote module is simple. Whenever an object is requested, a message is sent to the main process and Electron will store the object in a map and assign an ID for it, then send the ID back to the renderer process. In the renderer process, the remote module will receive the ID and wrap it with a proxy object and when the proxy object is garbage collected, a message will be sent to the main process to free the object.

Using remote.require API as an example, a simplified implementation looks like this:

remote.require = function (name) {
  // Tell the main process to return the metadata of the module.
  const meta = ipcRenderer.sendSync('REQUIRE', name);
  // Create a proxy object.
  const object = metaToValue(meta);
  // Tell the main process to free the object when the proxy object is garbage
  // collected.
  v8Util.setDestructor(object, function () {
    ipcRenderer.send('FREE', meta.id);
  });
  return object;
};

Dans le processus principal :

const map = {};
const id = 0;

ipcMain.on('REQUIRE', function (event, name) {
  const object = require(name);
  // Add a reference to the object.
  map[++id] = object;
  // Convert the object to metadata.
  event.returnValue = valueToMeta(id, object);
});

ipcMain.on('FREE', function (event, id) {
  delete map[id];
});

Maps with weak values​

With the previous simple implementation, every call in the remote module will return a new remote object from the main process, and each remote object represents a reference to the object in the main process.

The design itself is fine, but the problem is when there are multiple calls to receive the same object, multiple proxy objects will be created and for complicated objects this can add huge pressure on memory usage and garbage collection.

For example, the following code:

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
  remote.getCurrentWindow();
}

It first uses a lot of memory creating proxy objects and then occupies the CPU (Central Processing Unit) for garbage collecting them and sending IPC messages.

An obvious optimization is to cache the remote objects: when there is already a remote object with the same ID, the previous remote object will be returned instead of creating a new one.

This is not possible with the API in JavaScript core. Using the normal map to cache objects will prevent V8 from garbage collecting the objects, while the WeakMap class can only use objects as weak keys.

To solve this, a map type with values as weak references is added, which is perfect for caching objects with IDs. Now the remote.require looks like this:

const remoteObjectCache = v8Util.createIDWeakMap()

remote.require = function (name) {
  // Tell the main process to return the meta data of the module.
  ...
  if (remoteObjectCache.has(meta.id))
    return remoteObjectCache.get(meta.id)
  // Create a proxy object.
  ...
  remoteObjectCache.set(meta.id, object)
  return object
}

Notez que le remoteObjectCache conserve des objets comme des références faibles, il n’est donc pas nécessaire de supprimer la clé lorsque l’objet est collecté par le garbage collector.

Native code​

For people interested in the C++ code of weak references in Electron, it can be found in following files:

The setDestructor API:

• object_life_monitor.cc
• object_life_monitor.h

The createIDWeakMap API:

• key_weak_map.h
• atom_api_key_weak_map.h

Voici les nouvelles applications Electron qui ont été ajoutées sur le site en août.

Le site est mis à jour avec de nouvelles applications et rencontres grâce aux demandes d'extraction de la communauté. Vous pouvez surveiller le dépôt pour être informé des nouveaux ajouts ou, si vous n'êtes pas intéressé par toutes les modifications du site, vous pouvez vous abonner au fil RSS du blog.

Si vous avez créé une application Electron ou si vous organisez une réunion, faites une requête pour l'ajouter au site et elle fera partie du prochain regroupement.

Nouvelles applications​

	Code RPGify	Application de codage de type RPG
	PamFax	Une application multiplateforme pour envoyer et recevoir des fax
	BlankUp	Éditeur Markdown avec clarté +1
	Ramblox	Application de messagerie et d'e-mail gratuite et open source qui regroupe les applications web courantes en une seule
	Gordie	La meilleure application pour vos collections de cartes
	Ionic Creator	Créez des applications mobiles exceptionnelles, plus rapidement
	TwitchAlerts	Faites plaisir à vos spectateurs avec de superbes alertes et notifications
	Museeks	Un lecteur de musique simple, épuré et multiplateforme
	Seapig	Un convertisseur de Markdown vers HTML
	GroupMe	Application GroupMe non officielle
	Moeditor	Votre éditeur Markdown polyvalent
	Soundnode	L'application Soundnode est le Soundcloud pour ordinateur.
	QMUI Web	QMUI Web Desktop est une application permettant de gérer des projets basés sur le framework web QMUI.
	Svgsus	Organisez, nettoyez et transformez vos fichiers SVG
	Ramme	Application Instagram non officielle pour ordinateur
	Insomnia	Client API Repos
	Correo	Une application Gmail sous forme de barre de menus/barre des tâches pour Windows, macOS et Linux
	Kongdash	Client d'ordinateur pour l'API Kong Admin
	Translation Editor	Éditeur de fichiers de traduction pour les messages INTL ICU (voir formatjsio)
	5EClient	Client 5EPlay CSGO
	Theme Juice	Le développement WordPress local simplifié

La réalisation d'applications accessibles est importante et nous sommes heureux d'introduire de nouvelles fonctionnalités pour Devtron et Spectron qui donnent aux développeurs la possibilité de rendre leurs applications meilleures pour tous.

Les problèmes d’accessibilité dans les app Electron sont similaires à ceux des sites Web parce qu’ils sont tous deux en HTML. Avec les app Electron, toutefois, vous ne pouvez pas utilisez les ressources en ligne pour les vérifications de l'accessibilité parce que votre application n'est pas une URL.

Ces nouvelles fonctionnalités apportent ces outils d'audit à votre application Electron. Vous pouvez choisir d'ajouter des audits à vos tests avec Spectron ou les utiliser dans DevTools avec Devtron. Lire la suite pour un résumé des outils ou regardez notre documentation sur l'accessibilité pour plus d’informations.

Spectron​

Dans l’infrastructure de test Spectron, vous pouvez maintenant auditer chaque fenêtre et balise <webview> de votre application. Par exemple :

app.client.auditAccessibility().then(function (audit) {
  if (audit.failed) {
    console.error(audit.message);
  }
});

Vous pouvez en savoir plus sur cette fonctionnalité dans la documentation de Spectron.

Devtron​

Dans Devtron il y a un nouvel onglet accessibilité qui vous de vérifier une page dans votre application puis de trier et de filtrer les résultats.

Ces deux outils utilisent la bibliothèque Outils d'accessibilité pour les développeurs faite par Google pour Chrome. Vous pouvez en apprendre davantage sur les règles d’audit accessibilité que cette bibliothèque utilise sur ce wiki du référentiel.

Si vous connaissez d’autres bons outils d'accessibilité pour Electrons, ajoutez-les à la documentation de l’accessibilité avec une pull request.