Le package npm electron inclut désormais un fichier de définition TypeScript qui fournit des annotations détaillées de l’ensemble de l’API Electron. Ces annotations peuvent faciliter vos développements avec Electron même si vous écrivez du JavaScript de base. Il vous suffit d'effectuer la commande npm install electron pour obtenir les types d'Electron à jour dans votre projet.
TypeScript est un langage de programmation open-source créé par Microsoft. C'est un sur-ensemble de JavaScript étendant le langage en ajoutant la prise en charge des types statiques. La communauté TypeScript s'est développée rapidement ces dernières années, et TypeScript s'est classé parmi les langages de programmation les plus appréciés dans une enquête récente de Stack Overflow sur les développeurs . TypeScript est décrit comme un « JavaScript qui évolue », et les équipes de GitHub, Slack, et Microsoft l’utilisent toutes pour écrire des applications Electron évolutives qui sont utilisées par des millions de personnes.
TypeScript prend en charge de nombreuses fonctionnalités parmi les plus récentes de JavaScript, telles que les classes, la déstructuration d’objets et l’async/await, mais sa véritable fonctionnalité de différenciation est les annotations des type. La déclaration des types de données d’entrée et de sortie attendus par votre programme peut réduire les bogues en vous aidant à trouver des erreurs au moment de la compilation, et les annotations peuvent également servir de déclaration formelle de fonctionnement de votre programme.
Lorsque les bibliothèques sont écrites en Javascript de base, les types sont souvent vaguement définis après coup lors de la rédaction de la documentation. Les fonctions peuvent souvent accepter plus de types que ce qui a été documenté ou une avoir des contraintes invisibles qui ne sont pas documentées et ceci peut entraîner des erreurs à l’exécution.
TypeScript résout ce problème avec les fichiers de définition. Un fichier de définition TypeScript décrit toutes les fonctions d'une bibliothèque et ses types d'entrée et de sortie attendus. Lorsque les auteurs de bibliothèque regroupent un fichier de définition typeScript avec leur bibliothèque publiée, les utilisateurs de cette bibliothèque peuvent explorer son API directement dans leur éditeur et commencer à l’utiliser immédiatement, souvent sans avoir besoin de consulter sa documentation.
De nombreux projets populaires comme Angular, Vue.js, node-github (et maintenant Electron!) compilent leur propre fichier de définition et le regroupent avec leur package publié sur npm. Pour les projets ne regroupant pas leur propre fichier de définition, il existe DefinitelyTyped, un écosystème tiers de fichiers de définition gérés par la communauté.
À partir de la version 1.6.10, chaque version d’Electron inclut son propre fichier de définition TypeScript. Lorsque vous installez le package electron à partir de npm, le fichier electron.d.ts est automatiquement fourni avec le package installé.
Le moyen le le plus sûr d’installer Electron est d’utiliser un numéro de version exact :
Si vous utilisiez déjà des définitions tierces telles que @types/electron et @types/node, vous devez les supprimer de votre projet Electron pour éviter toutes collisions.
Le fichier de définition est dérivé de notre documentation API structurée, et sera donc toujours cohérent avec la documentation API de Electron. Installez simplement electron et vous obtiendrez toujours les définitions TypeScript à jour avec la version d'Electron que vous utilisez.
Pour un résumé de l’installation et de l’utilisation des nouvelles annotations TypeScript d’Electron veuillez regarder cette courte démonstration vidéo:
Si vous utilisez Visual Studio Code, vous disposez de la prise en charge de TypeScript intégrée. Il existe également des plugins maintenus par la communauté pour Atom, Sublime, vim, et d’autres éditeurs.
Une fois que votre éditeur est configuré pour TypeScript, vous verrez plus d'indications contextuelles comme des suggestions de saisie semi-automatique, la référence de méthode en ligne, la vérification des des arguments, etc.
Si vous débuter avec TypeScript et que vous souhaitez en savoir plus, cette vidéo d’introduction de Microsoft fournit un bon aperçu des raisons pour lesquelles le langage a été créé, son fonctionnement, son utilisation et sa destinée.
Étant donné que TypeScript est un sur-ensemble de JavaScript, votre code JavaScript existant est déjà du Typescript valide. Cela signifie que vous pouvez progressivement transférer un projet JavaScript existant vers TypeScript, en le parsemant selon les besoins de nouvelles fonctionnalités du langage.
Ce projet n’aurait pas été possible sans l’aide de la communauté des mainteneurs open source d’Electron. Merci à Samuel Attard, Felix Rieseberg, Birunthan Mohanathas, Milan Burda, Brendan Forster, et beaucoup d'autres pour leurs corrections de bogues, améliorations de documentation, et conseils techniques.
Si vous rencontrez des problèmes en utilisant les nouveaux fichiers de définition TypeScript d'Electron, veuillez déclarer un problème sur le dépôt electron-typescript-definitions.
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.
La version bêta d'Electron 1.6.3 contient la prise en charge initiale de la Touch Bar de macOS.
La nouvelle API Touch Bar vous permet d'ajouter des boutons, des étiquettes, des popovers, des sélecteurs de couleurs, des curseurs et des espaceurs. Ces éléments peuvent être mis à jour dynamiquement et émettent également des événements lorsqu'ils interagissent avec eux.
Il s'agit de la première version de cette API, elle évoluera donc au cours de la prochaine quelques rejets d'électrons. Veuillez consulter les notes de version pour d'autres mises à jour et ouvrez issues pour tout problème ou fonctionnalité manquante.
Vous pouvez installer cette version via npm install electron@beta et apprendre plus d'informations à ce sujet dans la TouchBar et BrowserWindow Documents électroniques.
Un grand merci à @MarshallOfSound pour sa contribution à Electron. 🎉
Voici un exemple de création d'un jeu de machine à sous simple dans la Touch Bar. Il montre comment créer une barre tactile, styliser les éléments, l'associer à un fenêtre, gérer les événements de clic de bouton et mettre à jour les étiquettes de manière dynamique.
const{ app,BrowserWindow,TouchBar}=require('electron'); const{TouchBarButton,TouchBarLabel,TouchBarSpacer}=TouchBar; let spinning =false; // Reel labels const reel1 =newTouchBarLabel(); const reel2 =newTouchBarLabel(); const reel3 =newTouchBarLabel(); // Spin result label const result =newTouchBarLabel(); // Spin button const spin =newTouchBarButton({ label:'🎰 Spin', backgroundColor:'#7851A9', click:()=>{ // Ignore clicks if already spinning if(spinning){ return; } spinning =true; result.label=''; let timeout =10; const spinLength =4*1000;// 4 seconds const startTime =Date.now(); constspinReels=()=>{ updateReels(); if(Date.now()- startTime >= spinLength){ finishSpin(); }else{ // Slow down a bit on each spin timeout *=1.1; setTimeout(spinReels, timeout); } }; spinReels(); }, }); constgetRandomValue=()=>{ const values =['🍒','💎','7️⃣','🍊','🔔','⭐','🍇','🍀']; return values[Math.floor(Math.random()* values.length)]; }; constupdateReels=()=>{ reel1.label=getRandomValue(); reel2.label=getRandomValue(); reel3.label=getRandomValue(); }; constfinishSpin=()=>{ const uniqueValues =newSet([reel1.label, reel2.label, reel3.label]).size; if(uniqueValues ===1){ // All 3 values are the same result.label='💰 Jackpot!'; result.textColor='#FDFF00'; }elseif(uniqueValues ===2){ // 2 values are the same result.label='😍 Winner!'; result.textColor='#FDFF00'; }else{ // No values are the same result.label='🙁 Spin Again'; result.textColor=null; } spinning =false; }; const touchBar =newTouchBar([ spin, newTouchBarSpacer({size:'large'}), reel1, newTouchBarSpacer({size:'small'}), reel2, newTouchBarSpacer({size:'small'}), reel3, newTouchBarSpacer({size:'large'}), result, ]); letwindow; app.once('ready',()=>{ window=newBrowserWindow({ frame:false, titleBarStyle:'hidden-inset', width:200, height:200, backgroundColor:'#000', }); window.loadURL('about:blank'); window.setTouchBar(touchBar); });
Voltra est un lecteur de musique destiné aux personnes qui veulent posséder leur musique. C’est aussi un magasin où vous pouvez découvrir et acheter de nouvelles musiques en fonction de ce que vous possédez déjà. Voltra est sans publicité, multi-plateformes pour bureau et mobile. De plus, il ne vous espionne pas.
La radio a toujours eu une grande part d'auditeurs. Elle quitte les ondes pour l'Internet. Maintenant vous pouvez louer de la musique à la demande — c'est le renouveau de la radio ! De nombreux nouveaux produits et services ont vu le jour grâce à cela, mais la radio en streaming laisse encore quelqu'un d'autre au contrôle de votre musique et la façon dont vous la vivez.
Nous voulions un produit entièrement axé sur la musique que vous possédez. Quelque chose qui permette de découvrir et d'acheter facilement de la nouvelle musique directement auprès des artistes ou des labels.
Puisque l'application est gratuite, nous pourrions en ouvrir les sources plus tard. Pour le moment, nous n'avons pas la bande passante pour gérer cela. Nous avons également des idées très précises concernant les fonctionnalités et la direction que nous voulons donner aux choses. Nous avons une communauté bêta active et nous prenons les commentaires à cœur.
Notre archive audio Voltra est un service de sauvegarde cloud conçu spécifiquement pour la musique. Nous ne compressons ni ne partageons les blocs de données. Votre collection musicale est sauvegardée physiquement pour vous.
Pour les artistes et labels, notre adhésion pro offre des outils qui les aident à atteindre des publics plus pertinents, tels que des analytiques et des pages web professionnelles pour les artistes.
Le design et la facilité d'utilisation sont extrêmement importants pour nous. Nous voulons offrir aux auditeurs une expérience d'écoute sans distraction ! Il existe des lecteurs de musique et des magasins intéressants. Mais beaucoup d'entre eux sont plus avancés et plus difficiles à utiliser que leurs créateurs ne le pensent. Nous voulons rendre Voltra accessible au plus grand nombre de personnes possible.
Nous ne prenons pas non plus de commission sur l'artiste ou le label. C'est un différenciateur clé pour nous. C'est vraiment important car cela abaisse la barrière pour les artistes qui souhaitent commercialiser leur musique.
Quels sont les aspects de design & décisions techniques que vous avez prises?
En concevant Voltra, nous avons envisagé des conventions de l'interface utilisateur à partir d'applications natives et du web, nous avons également beaucoup réfléchi à ce que nous pouvions supprimer. Nous avons un groupe bêta privé actif qui nous a donné des commentaires critiques au cours de ces derniers mois.
Nous avons découvert que les pochettes d'album et la photographie sont vraiment importantes pour les gens. De nombreux lecteurs ne sont que des listes de fichiers. L'une des choses intéressantes de la possession d'albums physiques est la pochette de l'album, et nous avons voulu mettre l'accent sur cet aspect dans l'application de bureau Voltra.
Nous nous sommes également assurés de ne pas toucher aux fichiers des gens. Nous utilisons la surveillance de fichiers pour que vous puissiez placer vos fichiers où vous voulez, nous ne les renommons pas et ne les déplaçons pas pour vous. Nous disposons d'une base de données intégrée pour suivre l'état des répertoires surveillés afin de pouvoir suivre ce qui est nouveau, même lorsque le processus n'est pas en cours d'exécution.
Quels sont les défis que vous avez rencontrés lors de la création de Voltra ?
Nous passons beaucoup de temps à nous concentrer sur les performances. Nous avons commencé avec des frameworks, mais nous sommes passés à du Javascript classique. D'après notre expérience, les abstractions généralisées qu'ils fournissent l'emportent sur les pénalités de performance et le cérémonial qu'ils introduisent.
Nous gérons assez bien les très grandes collections à ce stade. De grandes collections signifient potentiellement des dizaines de milliers d'images ! Le fait d'avoir le module de système de fichiers de Node.js directement accessible depuis le processus de rendu a permis de facilement charger et de décharger paresseusement de nombreuses images très rapidement en fonction des événements DOM.
En général setImmediate et requestIdleCallback ont été des outils super importants pour effectuer beaucoup de traitement tout en maintenant l'interface utilisateur réactive. Plus précisément, la répartition des tâches liées au processeur dans des processus distincts aide beaucoup à garder l'interface utilisateur réactive. Par exemple, nous avons déplacé le contexte audio dans un processus distinct, communiquant avec l'interface par IPC pour éviter les interruptions potentielles d'une interface utilisateur occupée.
Pourquoi avez-vous choisi de construire Voltra avec Electron?
Le bac à sable du navigateur est trop restreint pour notre application. Mais nous développons également un lecteur web. Le fait que nous puissions partager presque 100 % du code entre les deux implémentations est donc une grande victoire.
Nous avons en fait commencé par construire une application native avec Swift. Le principal problème que nous avons rencontr é était que nous devions réinventer beaucoup de choses. Le web possède le plus grand écosystème open source au monde. Nous sommes donc assez rapidement passés à Electron.
De plus, et c'est le plus important, avec Electron, vous développez une fois et cela devrait Juste Fonctionner™ sur toutes les principales plateformes. Ce n'est pas garanti, mais le coût du codage natif pour chaque plateforme dépasse nettement sur les autres coûts qu'Electron introduit.
Quelles sont vos choses préférées à propos d'Electron?
GTD!: Having Node.js’ networking stack and Chromium’s presentation layer packaged together is a recipe for getting things done.
Compétence : C'est juste la couche web, donc littéralement toute notre équipe est impliquée dans la construction du produit.
Communauté : Il existe une communauté très organisée qui sait très bien communiquer ! Nous sommes très heureux de pouvoir nous développer avec un tel soutien.
Dans quels domaines Electron pourrait-il être amélioré ?
Nous aimerions voir Electron approuver un seul empaqueteur. L'empaqueteur est aussi important pour Electron que le gestionnaire de paquets est à Node. Il y a plusieurs empaqueteurs dans la zone utilisateur, chacun avec des fonctionnalités intéressantes, mais chacun avec des bogues. Un consensus de la communauté permettrait de diriger l'énergie dépensée par les contributeurs.
Nous développons actuellement une application mobile et travaillons avec des artistes et des labels pour ajouter leur musique à la boutique Voltra. Hé ! Si vous êtes un artiste ou un label, inscrivez-vous maintenant ! Nous prévoyons d'ouvrir la boutique lorsque nous aurons atteint notre objectif de 10 millions de titres.
Electron is based on Google's open-source Chromium, a project that is not necessarily designed to be used by other projects. This post introduces how Chromium is built as a library for Electron's use, and how the build system has evolved over the years.
The Chromium Embedded Framework (CEF) is a project that turns Chromium into a library, and provides stable APIs based on Chromium's codebase. Very early versions of Atom editor and NW.js used CEF.
To maintain a stable API, CEF hides all the details of Chromium and wraps Chromium's APIs with its own interface. So when we needed to access underlying Chromium APIs, like integrating Node.js into web pages, the advantages of CEF became blockers.
So in the end both Electron and NW.js switched to using Chromium's APIs directly.
Even though Chromium does not officially support outside projects, the codebase is modular and it is easy to build a minimal browser based on Chromium. The core module providing the browser interface is called Content Module.
To develop a project with Content Module, the easiest way is to build the project as part of Chromium. This can be done by first checking out Chromium's source code, and then adding the project to Chromium's DEPS file.
NW.js et les toutes premières versions d'Electron utilisent cette méthode pour la construction.
The downside is, Chromium is a very large codebase and requires very powerful machines to build. For normal laptops, that can take more than 5 hours. So this greatly impacts the number of developers that can contribute to the project, and it also makes development slower.
As a user of Content Module, Electron does not need to modify Chromium's code under most cases, so an obvious way to improve the building of Electron is to build Chromium as a shared library, and then link with it in Electron. In this way developers no longer need to build all off Chromium when contributing to Electron.
Le projet libchromiumcontent a été créé par @aroben à cet effet. It builds the Content Module of Chromium as a shared library, and then provides Chromium's headers and prebuilt binaries for download. Le code de la version initiale de libchromiumcontent peut être trouvé dans ce lien.
Le projet brillant est également né dans le cadre de libchromiumcontent, qui fournit une fine couche autour du module de contenu.
By using libchromiumcontent and brightray together, developers can quickly build a browser without getting into the details of building Chromium. And it removes the requirement of a fast network and powerful machine for building the project.
En dehors d'Electron, il y a eu aussi d'autres projets basés sur Chromium construits de cette manière , comme le navigateur Breach.
On Windows there is a limitation of how many symbols one shared library can export. As the codebase of Chromium grew, the number of symbols exported in libchromiumcontent soon exceeded the limitation.
By taking this approach, though Chromium kept adding new exported symbols, libchromiumcontent could still generate shared library files by stripping more symbols.
Before talking about the next steps taken in libchromiumcontent, it is important to introduce the concept of component build in Chromium first.
As a huge project, the linking step takes very long in Chromium when building. Normally when a developer makes a small change, it can take 10 minutes to see the final output. To solve this, Chromium introduced component build, which builds each module in Chromium as separated shared libraries, so the time spent in the final linking step becomes unnoticeable.
With Chromium continuing to grow, there were so many exported symbols in Chromium that even the symbols of Content Module and Webkit were more than the limitation. It was impossible to generate a usable shared library by simply stripping symbols.
As introduced earlier there are two build modes in Chromium. As a result of shipping raw binaries, we have to ship two different distributions of binaries in libchromiumcontent. One is called static_library build, which includes all static libraries of each module generated by the normal build of Chromium. The other is shared_library, which includes all shared libraries of each module generated by the component build.
In Electron, the Debug version is linked with the shared_library version of libchromiumcontent, because it is small to download and takes little time when linking the final executable. And the Release version of Electron is linked with the static_library version of libchromiumcontent, so the compiler can generate full symbols which are important for debugging, and the linker can do much better optimization since it knows which object files are needed and which are not.
So for normal development, developers only need to build the Debug version, which does not require a good network or powerful machine. Though the Release version then requires much better hardware to build, it can generate better optimized binaries.
Being one of the largest projects in the world, most normal systems are not suitable for building Chromium, and the Chromium team develops their own build tools.
Earlier versions of Chromium were using gyp as a build system, but it suffers from being slow, and its configuration file becomes hard to understand for complex projects. After years of development, Chromium switched to gn as a build system, which is much faster and has a clear architecture.
One of the improvements of gn is to introduce source_set, which represents a group of object files. In gyp, each module was represented by either static_library or shared_library, and for the normal build of Chromium, each module generated a static library and they were linked together in the final executable. By using gn, each module now only generates a bunch of object files, and the final executable just links all the object files together, so the intermediate static library files are no longer generated.
This improvement however made great trouble to libchromiumcontent, because the intermediate static library files were actually needed by libchromiumcontent.
La seconde tentative a été faite par @alespergl pour produire des bibliothèques statiques personnalisées à partir de la liste des fichiers d'objet. It used a trick to first run a dummy build to collect a list of generated object files, and then actually build the static libraries by feeding gn with the list. It only made minimal changes to Chromium's source code, and kept Electron's building architecture still.
As you can see, compared to building Electron as part of Chromium, building Chromium as a library takes greater efforts and requires continuous maintenance. However the latter removes the requirement of powerful hardware to build Electron, thus enabling a much larger range of developers to build and contribute to Electron. Les efforts en valent la peine.
Cette semaine, nous avons rattrapé les gens à Automattic pour parler de WordPress Desktop, un client de bureau open-source pour la gestion du contenu WordPress.
Tout le monde connais WordPress, mais qu’est-ce que WordPress Desktop?
L'application de bureau WordPress.com offre une expérience multiplateforme transparente qui vous permet de vous concentrer sur votre contenu et votre conception sans que des onglets de navigateur ne viennent vous distraire - ou de garder vos sites à l'écart mais accessibles. En combinaison avec le support de notre navigateur et de notre application mobile, vous pouvez construire votre site n'importe où, de quelque manière que ce soit pour vous aider à faire votre travail.
Pourquoi construire une application de bureau pour gérer les sites WordPress ? Ne pourrait-il pas tous être basé sur le web?
Il utilise en fait exactement la même technologie que vous obtenez en visitant WordPress.com dans votre navigateur. Cependant, tout est hébergé localement, donc il a des temps de chargement minimes. Avec le bénéfice de fonctionnalités natives comme être dans votre doc, les notifications, etc., vous pouvez vraiment vous concentrer sur vos sites WordPress et blogging.
Pourquoi avez-vous choisi de construire WordPress Desktop sur Electron?
À la fin de 2015, nous avons reconstruit une grande partie de WordPress.com sous la forme de Calypso, une application JavaScript moderne open-source utilisant React. Nous avons commencé à regarder Electron et avec quelques modifications à Calypso ont été en mesure de le faire fonctionner localement. C'était une expérience convaincante et nous pensions qu'il y avait beaucoup de valeur à la développer.
Nous avons eu plusieurs équipes travaillant sur Calypso. Créer un client graphique multi-plateforme qui corresponde à cela en utilisant les technologies de bureau traditionnelles aurait pris plus de travail. En utilisant Electron, une petite équipe de 2-4 d'entre nous ont pu tirer parti des efforts de l'autre équipe et construire l'application de bureau dans quelques mois.
Quels sont les défis que vous avez rencontrés lors de la construction de WordPress Desktop ?
Nous avons réussi à faire fonctionner une première version de l'application très rapidement, mais la mettre au point pour qu'elle se comporte de manière optimale comme une application de bureau a pris beaucoup plus de temps. L'un des grands défis de l'application est que vous exécutez en réalité une copie de Calypso sur votre propre machine - c'est purement une interface utilisateur pilotée par API. Il y a eu beaucoup de travail de transition dans ce domaine, et les changements ont été répercutés sur Calypso elle-même.
En outre, beaucoup d'efforts ont été déployés pour adapter l'application à différentes plateformes - nous proposons des versions Windows, macOS et Linux - et les différences sont suffisantes pour rendre la tâche délicate.
À l'époque, Electron était relativement nouveau et nous rencontrions régulièrement des problèmes qui étaient rapidement résolus (parfois le jour même !)
Electron fournit déjà la plupart de ce dont nous avons besoin pour l'application Desktop, et il progresse rapidement depuis que nous avons commencé à l'utiliser. Cela dit, il y a certains domaines qui sont considérés comme acquis dans une application de bureau, comme la vérification orthographique et la trouver/remplacement, qui sont plus difficiles à reproduire avec Electron tel quel.
Nous aimerions aussi voir certaines des nouvelles technologies Chrome filtrer dans Electron également. Nous sommes particulièrement désireux d’expérimenter avec WebVR.
Quelles sont vos choses préférées à propos d'Electron?
La raison principale pour laquelle nous avons choisi Electron, et c'est la plus grande force, est la communauté très active et ouverte. Automattic a toujours cru en l'open source. C'est l'un de nos principes de base, le projet et la communauté d'Electron suivent beaucoup des convictions fondamentales d'être très ouvert et positif.
L'avantage de notre modèle est que l'application de bureau bénéficie de toutes les nouvelles fonctionnalités de Calypso - il y a des améliorations constantes. Nous espérons que nous pourrons ajouter des fonctionnalités supplémentaires à l'application, telles que le support hors ligne, qui transmettrait réellement l'application dans le territoire natif, et de meilleures notifications systèmes.
Y a-t-il des équipes dans Automattic travaillant sur d'autres applications Electron ?
Oui, après nos efforts sur l'application Desktop, l'équipe Simplenote a décidé d'utiliser Electron pour construire des applications de bureau pour Windows et Linux (un client Mac natif existe déjà). L'application Simplenote Electron est également open source et disponible sur Github.
Nous avons également une prochaine intégration Raspberry Pi qui utilise Electron.
Si l'un de ces éléments semble intéressant, alors nous aimerions avoir de vos nouvelles!
Des conseils d'Electron qui pourraient être utiles aux autres développeurs ?
Le processus d'expédition de logiciels de bureau signés est relativement récent pour nous, en particulier pour Windows. nous avons écrit un article pour Code Signing a Windows App qui inclut le processus et quelques-uns des obstacles que nous avons rencontrés pour le faire correctement.
Le projet vedette de cette semaine est Dat, un projet financé par des subventions, open source et décentralisé pour la distribution d’ensembles de données. Dat est produit et maintenu par une équipe géodistribuée, dont beaucoup de membre ont aidé pour écrire cet article.
Nous voulions apporter le meilleur des systèmes distribués "peer to peer" au partage de données. Nous avons commencé avec le partage de données scientifiques puis nous nous sommes tourné vers des institutions de recherche, le gouvernement, la fonction publique et les équipes open source.
Une autre façon d’y penser est une application de synchronisation et de téléchargement comme Dropbox ou BitTorrent Sync, sauf que Dat est open source . Notre objectif est de produire un logiciel de partage de données puissant, open source et à but non lucratif pour les données de toute sorte et de toute taille.
Pour utiliser l’outil CLI dat , il vous suffit de taper :
dat share path/to/my/folder
Et dat va créer un lien que vous pouvez utiliser pour envoyer ce dossier à quelqu'un d'autre -- aucun serveur central ou tiers n'ayant accès à vos données. Contrairement à BitTorrent, il est également impossible d'aller "fouiner" afin de voir qui partage quoi (voir le brouillon de Dat Paper pour plus de détails).
Maintenant que nous savons ce qu’est Dat. Comment Dat Desktop s’intègre-t-il ?
Dat Desktop est un moyen de rendre Dat accessible aux personnes ne pouvant pas ou ne voulant pas utiliser la ligne de commande. Vous pouvez héberger plusieurs fichiers Dat sur votre machine et diffuser les données sur votre réseau.
Nous travaillons sur un projet nommé Projet Svalbard qui est lié à DataRefuge, un groupe de travail pour soutenir les données gouvernementales sur le climat susceptibles de disparaître. Svalbard a été nommé ainsi en référence au Svalbard Global Seed Vault dans l'Arctique qui possède une grande bibliothèque souterraine d'ADN végétal. Notre version est une grande collection de données scientifiques publiques avec gestion des versions. Une fois que nous avons connaissance aux métadonnées et que nous pouvons leu faire confiance, nous pouvons construire d'autres projets géniaux comme un qui est un réseau bénévole de stockage de données distribué.
CACivicDataest une archive open-source diffusant quotidiennement à partir de la base de données californienne de suivi de l'argent en politique CAL-ACCESS. Des mises à jour quotidiennes sont effectuées, ce qui oblige à héberger beaucoup de données en double dans leurs fichiers zip. Nous travaillons sur l'hébergement de leurs données en tant que repository Dat qui réduira la quantité de tracas et de bande passante nécessaire pour se référer à une version spécifique ou mettre à jour vers une version plus récente.
Celui-ci n'est pas encore concret, mais nous pensons qu'un cas d'utilisation amusante serait de mettre une application Electron compilée dans un dépôt Dat, puis en utilisant un client Dat dans Electron pour tirer les derniers deltas du binaire de l'application construite, pour économiser sur le temps de téléchargement, mais aussi pour réduire les coûts de bande passante pour le serveur.
Toute personne souhaitant partager et mettre à jour des données sur un réseau p2p. Data scientists, hackers de données libres, chercheurs, développeurs. Nous sommes très ouverts aux commentaires à propos de cas d’utilisation sympa auquel nous n’avons pas encore pensé. Vous pouvez passer par notre Gitter Chat et nous demander n’importe quoi!
Quelle est la prochaine étape dans Dat et Dat Desktop ?
Comptes d’utilisateurs et publication de métadonnées. We are working on a Dat registry web app to be deployed at datproject.org which will basically be an 'NPM for datasets', except the caveat being we are just going to be a metadata directory and the data can live anywhere online (as opposed to NPM or GitHub where all the data is centrally hosted, because source code is small enough you can fit it all in one system). Comme beaucoup de jeux de données sont énormes, nous avons besoin d'un registre fédéré (similaire à la façon dont fonctionnent les trackers BitTorrent). Nous voulons faciliter la recherche ou la publication de jeux de données dans le registre de Dat Desktop, pour rendre le partage des données sans friction.
Une autre fonctionnalité est les dossiers multi-auteurs/collaboratifs. Nous avons de gros projets pour faire des flux de travail collaboratifs, peut-être avec des branches, similaires à git, sauf conçu autour de la collaboration de jeux de données. Mais nous travaillons toujours, en ce moment à la stabilité générale et à la standardisation de nos protocoles !
Pourquoi avez-vous choisi de créer Dat Desktop avec Electron?
Dat étant sur Node.js, c'était naturel de l'intégrer ainsi. Au-delà de cela, nos utilisateurs utilisent une variété de machines depuis des scientifiques, les chercheurs et les responsables gouvernementaux peuvent être contraints d'utiliser certaines configurations pour leurs institutions -- cela signifie que nous devons être en mesure de cibler Windows et Linux ainsi que Mac. Dat Desktop nous le donne très facilement.
Quels sont les défis que vous avez rencontrés lors de la construction de Dat et Dat Desktop ?
Trouver ce que les gens veulent. Nous avons commencé avec des jeux de données tabulaires, mais nous avons réalisé que c'était un peu compliqué à résoudre et que la plupart des gens n'utilisent pas de bases de données. Donc, à mi-parcours du projet, nous avons redessiné tout depuis zéro pour utiliser un système de fichiers et nous n'avons pas regardé en arrière.
Nous avons également rencontré des problèmes généraux d'infrastructure d'Electron, notamment :
Télémétrie - comment capturer des statistiques d'utilisation anonymes
Mises à jour - C'est une sorte de piqué et de magie de mettre en place des mises à jour automatiques
Versions - Signature XCode, construction de versions sur Travis, en faisant des versions bêta, tous étaient des défis.
Nous utilisons également Browserify et quelques transformations de Browserify sur le code 'front-end' dans Dat Desktop (ce qui est un peu bizarre parce que nous avons encore des paquets même si nous avons natif require -- mais c'est parce que nous voulons les transformations). Pour mieux aider à gérer notre CSS nous sommes passés de Sass à l'utilisation de sheetify. Il nous a grandement aidés à modulariser notre CSS et à faciliter le déplacement de notre interface utilisateur vers une architecture orientée vers des composants avec des dépendances partagées. Par exemple dat-colors contient toutes nos couleurs et est partagé entre tous nos projets.
Nous avons toujours été un grand fan de standards et d'abstractions minimes. Toute notre interface est construite à l'aide de nœuds DOM réguliers avec seulement quelques bibliothèques nous aidant. Nous avons commencé à déplacer certains de ces composants dans les éléments de base, une bibliothèque de composants réutilisables de bas niveau. Comme avec la plupart de notre technologie, nous continuons à itérer dessus jusqu'à ce que nous y arrivions correctement, mais en tant qu'équipe, nous avons le sentiment que nous allons dans la bonne direction ici.
Nous pensons que le plus grand point de douleur est les modules natifs. Reconstruire vos modules pour Electron avec npm ajoute de la complexité au workflow. Notre équipe a développé un module appelé prebuild qui gère les binaires précompilés, qui a bien fonctionné pour Node, mais les workflows d'Electron nécessitaient toujours une étape personnalisée après l'installation, généralement npm run rebuild. Cela a été ennuyeux. Pour résoudre ce problème, nous sommes récemment passés à une stratégie où nous regroupons toutes les versions binaires compilées de toutes les plates-formes à l'intérieur de l'archive tar npm. Cela signifie que les archives deviennent plus grandes (bien que cela puisse être optimisé avec les fichiers .so - bibliothèques partagées), cette approche évite d'avoir à exécuter des scripts de post-installation et évite également complètement le modèle npm run rebuild. Cela signifie que npm install fait la bonne chose pour Electron la première fois.
Quelles sont vos choses préférées à propos d'Electron?
Les API semblent assez bien pensées, elles sont relativement stables et ça fait un bon travail pour se tenir à jour avec les versions amont de Node, pas grand chose que nous pouvons demander !
Des conseils d'Electron qui pourraient être utiles aux autres développeurs ?
Si vous utilisez des modules natifs, essayez prebuild !
Quelle est la meilleure façon de suivre les développements de Dat ?
This week we chatted with Felix Rieseberg, desktop engineer at Slack and maintainer of Ghost Desktop, an Electron client for the Ghost publishing platform.
Ghost is a fully open source, hackable platform for building and running a modern online publication. We power blogs, magazines and journalists from Zappos to Sky News.
What makes it different from other publishing platforms?
Ghost was founded in April 2013, after a very successful Kickstarter campaign to create a new platform focused solely on professional publishing. Our mission is to create the best open source tools for independent journalists and writers across the world, and have a real impact on the future of online media. It offers a simpler, more focussed experience: Our editor is designed solely around providing the best possible writing experience.
Compared to the all-time classic WordPress, it offers a simpler, more streamlined experience - it is easier to setup and maintain, comes with all important features out-of-the-box, and is dramatically faster. Compared to other online platforms, Ghost gives writers full ownership and control over their content, allows full customization, and enables authors to build a business around their publication.
This one is important to us: Ghost is an independent non-profit organisation. We build publishing tools for modern journalism & blogging because we believe freedom of speech is important. Our software is released under a free open source license, our business model is completely transparent, and our legal structure means that 100% of the money we make is reinvested into making Ghost better.
Ghost Desktop allows writers to manage multiple blogs at once - and to focus on their writing. Des choses simples comme des raccourcis d'écriture courants ne peuvent pas être réalisées dans un navigateur, mais sont disponibles dans notre application de bureau. Il permet à d'autres applications de communiquer directement avec le blog via deeplinks.
This year we're very excited to be dedicating our entire 10 person full-time Ghost team to helping grow three independent publications, along with $45,000 in resources toward their efforts. We're calling it Ghost for Journalism.
We've been building Ghost as the web's next great platform for independent publishers for about three and half years now, and we've now reached a really interesting inflection point. We started this journey to create a simple, well designed blogging platform which could be used by just about anyone. That was always going to be step one.
Long term, we want Ghost to be an incredible platform for the world's best journalism, and that means we need to build features to attract exactly those people. This year we're making a very conscious decision to focus on just that.
Why did you choose to build Ghost Desktop on Electron?
Ghost uses JavaScript and Node.js on both the backend and frontend, so being able to utilize the same technology and skillset enables our team to move faster, build more, and ultimately deliver a better experience. In addition, being able to share more than 95% of code between the macOS, Windows, and Linux version of the app allows us to focus on building a great core user experience, without having to maintain one code base for each platform.
What are some challenges you've faced while building Ghost Desktop?
Spellchecking is likely still one of the most difficult services offered - we could easily utilize one of the many online services, but correctly spellchecking text in multiple languages while guarding the privacy and autonomy of our users is not an easy task.
We would love to see Electron bring the operating system's native spellchecking capabilities to their apps. We're dreaming about a world in which an <input> field receives the same services as a NSTextView, but we are also intimately aware how difficult that is.
Quelles sont vos choses préférées à propos d'Electron?
JavaScript is famous for being a vast ecosystem, involving countless tools and frameworks - but the convenience it affords us is hard to overstate. Building an app with Electron is only slightly harder than building a web app, which is an amazing feat.
Ghost Desktop is also an ongoing project - we're pretty far from being done. We have been talking for a while about bringing a full offline mode to our users, and we're getting fairly close. Other notable work areas are the extension and integration with other text editing apps (like Word or Atom), ultimately allowing people to write posts using their favorite tools. In general, once we've shipped the offline mode feature, we're looking for deeper integration with the operating system. If that sounds interesting to you, join us!
This week we caught up with Paul Frazee, creator of Beaker Browser. Beaker is an experimental peer-to-peer web browser that uses the Dat protocol to host sites from users’ devices.
Beaker is a participatory browser. It's a browser for indie hackers.
The Web is closed source. If you want to influence how social media works, you have to work at Facebook or Twitter. For search, Google. Control is in the hands of companies, rather than the users themselves.
With Beaker, we have a new Web protocol: the Decentralized Archive Transport. "Dat". Il crée des sites à la demande, gratuitement, et ensuite les partage à partir de l'appareil. No servers required. That's our innovation.
When you visit a Dat site in Beaker, you download the files. The site is yours, forever. You can save it, fork it, modify it, and share your new version for free. It's all open-source.
So that's what it's about: We're making a browser for open-source Websites. We want it to be a toolkit for social hacking.
$ 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
Those sites then get hosted out of your browser. It's a little like BitTorrent; you share the sites in a P2P mesh.
If you want a GUI, we have some basic tools built into the browser, but we're pushing those tools into userland. It's all going to be moddable user apps.
It was obvious for this project. If I forked Chrome myself, I'd be writing C++ right now! Nobody wants to do that. I know the Web stack, and I can work quickly with it. It's a no-brainer.
The truth is, I'm not sure I could do any of this without Electron. It's a great piece of software.
What are some challenges you've faced while building Beaker?
Half of it is poking at the tools and figuring out how much I can get away with.
Making the browser itself was pretty easy. Electron is practically a toolkit for making browsers. ...Except for the browser tabs; that took me forever to get right. I finally broke down and learned how to do SVGs. It's much better looking, but it took 3 or 4 iterations before I got that right.
Secure DNS names for Dat sites. A socially configurable URL scheme, called the "app scheme." More Dat APIs.
For folks who may be interested in contributing to the project, in what areas does Beaker need help?
We have lots of open issues. Don't be afraid to ping me. #beakerbrowser on freenode. We keep a page for contributors and we'll add you to it. And if you visit Austin, I'll buy you a beer.
Des conseils d'Electron qui pourraient être utiles aux autres développeurs ?
Use the build tooling that's out there. You don't want to wrestle with your own solutions, trust me. Use electron-builder. Use a boilerplate repo.
If you need to open an issue in the Electron repo, go the extra mile to make it easy to reproduce. You'll get a response much more quickly, and the team will appreciate it. Even better, try fixing it yourself. It's actually pretty interesting to see the innards.
Read through all the guides and advanced docs at least once.
