We are excited to announce that Electron has been accepted as a mentoring organization for the 20th edition of Google Summer of Code (GSoC) 2024! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

For more program details, check out Google’s Summer of Code homepage.

About us​

Electron is a JavaScript framework for building cross-platform desktop applications using web technologies. The core Electron framework is a compiled binary executable built with Chromium and Node.js, and is mostly written in C++.

Outside of Electron core, we also work on a variety of projects to help sustain the Electron organization, such as:

• End-user distribution tooling (e.g. Electron Forge and update.electronjs.org).
• Learning materials for Electron developers (e.g. electronjs.org and Electron Fiddle).
• Internal tools to streamline developer productivity (e.g. Electron Build Tools and Sheriff).

As a Summer of Code contributor, you would be collaborating with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

Before applying​

If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out examples in Electron Fiddle.

To learn more about Electron app distribution, you can also play around with Electron Forge by creating a sample application:

npm init electron-app@latest my-app

After familiarizing yourself with the code a bit, come join the conversation on the Electron Discord server.

Drafting your proposal​

Interested in collaborating with Electron? First, check out the seven project idea drafts that we have prepared. All of the listed ideas are currently open for proposals.

Have a different idea you’d like us to consider? We’re also open to accepting new ideas that are not on the proposed project list, but make sure your approach is thoroughly outlined and detailed. When in doubt, we recommend sticking with our listed ideas.

Your application should include:

• Your proposal: a written document that describes in detail what you plan to achieve over the course of the summer.
• Your background as a developer. If you have a resume, please include a copy. Otherwise, tell us about your past technical experience.
  • Lack of experience in certain areas won’t disqualify you, but it will help our mentors work out a plan to best support you and make sure your summer project is successful.

A detailed guide of what to submit as part of your Electron application is here. Submit proposals directly to the Google Summer of Code portal. Note that proposals emailed to the Electron team rather than submitted through the application portal will not be considered as a final submission.

If you want more guidance on your proposal or are unsure of what to include, we also recommend that you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 18th, 2024 and close on April 2nd, 2024.

Questions?​

If you have questions we didn’t address in the blog post or inquiries for your proposal draft, please send us an email at summer-of-code@electronjs.org or check GSoC FAQ!

Ресурсы​

• Electron Google Summer of Code 2024 Ideas List
• Electron Google Summer of Code 2024 Contributor Guidance
• Google Summer of Code Student/Contributor Guide

Electron’s API Working Group is adopting an open Requests for Comments (RFC) process to help shepherd larger changes to Electron core.

Why RFCs?​

In short, we want to smooth out the process of landing significant changes to Electron core.

Currently, new code changes are mostly discussed through issues and pull requests on GitHub. For most changes to Electron, this is a good system. Many bug fixes, documentation changes, and even new features are straightforward enough to review and merge asynchronously through standard GitHub flows.

For changes that are more significant—for instance, large API surfaces or breaking changes that would affect the majority of Electron apps—it makes sense for review to happen at the ideation stage before most of the code is written.

This process is designed to be open to the public, which will also make it easier for the open source community at large to give feedback on potential changes before they land in Electron.

Как это работает?​

The entire RFC process lives in the electron/rfcs repository on GitHub. The steps are described in detail in the repository README.

In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository. A Proposed RFC becomes:

• Active when the PR is merged into the main branch of the repository, which means that Electron maintainers are amenable to an implementation in electron/electron, or
• Declined if the PR is ultimately rejected.

An Active RFC is Completed if the implementation has been merged into electron/electron.

Who can participate?​

Anyone in the Electron community can submit RFCs or leave feedback on the electron/rfcs repository!

• To see the list of active RFCs, refer to the text folder in the repository.
• To leave feedback on proposed RFCs, check out the list of open PRs.
• To submit a new RFC, check out the repo’s README and the RFC template.

We wanted to make this process a two-way dialogue and encourage community participation to get a diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created a few:

• Electron C APIs
• Preload Realm for Service Workers

Credits​

Electron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas and major portions of copywriting go to:

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

Первый коммит в репозитории electron/electron был совершен 13 марта 2013 года¹.

После 10 лет и 27,147 коммитов от 1,192 различных участников, на сегодняшний день Electron стал одним из самых популярных фреймворков для создания настольных приложений. Этот этап - идеальная возможность отметить, посмотреть на наше приключение и поделиться тем, что мы выучили на этом пути.

Мы бы не были тут сегодня без всех тех, кто посвятил свои время и усилия, чтобы внести свой вклад в проект. Хотя коммиты исходного кода всегда являются самой видимой частью, мы также должны быть признательны усилиям тех людей, что сообщают об ошибках, поддерживают пользовательские модули, предоставляют документацию и переводы, а также участвуют в сообществе Electron в киберпространстве. Каждый вклад неоценим для нас, разработчиков.

Перед тем, как мы продолжим, хотим сказать: спасибо. ❤️

Как мы сюда попали?​

Atom Shell был разработан как основа Atom editor для GitHub'а, который вступил в открытую бету в апреле 2014 года. Он был разработан с нуля в качестве альтернативы веб-платформам, доступным в то время (node-webkit и Chromium Embedded Framework). У него была главная черта: встроенный Node.js и Chromium для обеспечения высокой производительности веб-технологий.

В течение года Atom Shell начал приобретать огромный рост как в возможностях, так и в популярности. Большие компании, стартапы и отдельные разработчики начали создавать приложения с этой технологией (некоторые ранние версии, включая Slack, GitKraken и WebTorrent) и проект был вскоре переименован в Electron.

С тех пор и появился Electron, и никогда не останавливался. Вот, к примеру, наш недельный счетчик количества загрузок, любезно представленная npmtrends.com:

Первая версия Electron была выпущена в 2016 году и обещала увеличение стабильности API, улучшенные документацию и инструменты. Вторая версия Electron была выпущена в 2018 году и предоставляла семантический учет версий, делая учет циклов выпуска версий Electron для разработчиков легче.

К шестой версии Electron, мы перешли к 12-ти недельному циклу выпуска больших обновлений, чтобы синхронизироваться с Chromium. Это решение поменяло и отношение к проекту, возводя "наличие последней версии Chromium" вместо "лучше бы был" в приоритет. Это уменьшило количество технологических задержек между обновлениями, облегчая для нас хранение Electron обновленным и безопасным.

С тех времен, мы были трудоголиками, выпуская новую версию Electron в тот же день, как и Chromium. К моменту, когда Chromium уменьшил время между выпусками до 4 недель в 2021, мы лишь пожали плечами и увеличили наш цикл обновлений до 8 недель соответственно.

Теперь мы на Electron v23 (счет продолжается) и до сих пор преданны созданию лучшей среды создания настольных предложений для различных платформ. Даже учитывая бум создания JavaScript инструментов для разработчиков в последние годы, Electron остался стабильным, протестированным в боях украшением структуры для настольных приложений. Приложения Electron на сегодняшний день являются повсеместными: вы можете программировать с помощью Visual Studio Code, проектировать дизайн с Figma, общаться со Slack и делать заметки с Notion (среди многих других вариантов). Мы невероятно гордимся этим достижением и благодарны каждому, кто сделал это возможным.

Чему мы научились на этом пути?​

Путь к отметке десяти лет был долгий и извилистый. Вот несколько ключевых вещей, которые помогли нам поддерживать стабильность огромного проекта с открытым исходным кодом.

Масштабирование распределенных решений с помощью модели управления​

Одной из сложных задач, которую нам пришлось преодолеть, стала разработка направления проекта, как только Electron впервые получил огромную популярность. Как мы справляемся с организацией команды, составляющей несколько десятков инженеров, распределенных между компаниями, странами и временными зонами?

В первые дни, группа, поддерживающая Electron, опиралась на неформальную координацию, что было быстро и легко для небольших проектов, но не могло расширять сотрудничество. В 2019 году, мы перешли на модель управления, в котором различные рабочие группы имели формальные сферы ответственности. Это было полезно в упрощении процессов и присвоении частей работы к определенным людям, поддерживающим проект. За что отвечают Working Group (WG) на сегодняшний день?

• Выпуском версий Electron (Releases WG)
• Обновлением Chromium и Node.js (Upgrades WG)
• Управлением публичным дизайном API (API WG)
• Поддержка защиты Electron (Security WG)
• Поддержка вебсайта, документации и инструментария (Ecosystem WG)
• Общественная и корпоративная связь (Outreach WG)
• Модерация сообщества (Community & Safety WG)
• Поддержка нашей инфраструктуры, инструментов поддержки и облачных сервисов (Infrastructure WG)

Примерно в то же время, как мы сменили модель управления, мы также поменяли владельца с GitHub'а на OpenJS Foundation. Хоть и первоначальная основная команда по-прежнему работает в Microsoft сегодня, они являются лишь частью более крупной группы сотрудников, которые формируют управление Electron. ²

Хотя эта модель и не является идеальной, она хорошо поработала во время глобальной пандемии и текущих макроэкономических потрясений. Заходя наперед, мы планируем пересмотреть управленческий устав, чтобы он повел нас вперед ко второму десятилетию Electron.

Сообщество​

Вклад сообщества в открытый исходный код огромно, особенно когда наша команда по связи с сообществом составляет десятки инженеров с припиской "менеджер сообщества". Тем не менее, быть огромным проектом с открытым исходным кодом означает наличие огромного числа пользователей, и использование их энергии построения пользовательской экосистемы Electron является важнейшей составляющей поддержки здоровья проекта.

Что мы делаем для развития поддержки связи с сообществом?

Создание виртуальных сообществ​

• В 2020 году мы запустили наш Discord сервер. Ранее у нас был раздел на форуме Atom, однако мы решили использовать более неформальную платформу для ведения дискуссий между людьми, поддерживающими проект и разработчиками Electron, а также для общей информационной помощи в исправлении ошибок.
• В 2021 году мы создали пользовательскую группу Electron China с помощью @BlackHole1. Эта группа играла важную роль в развитии Electron для пользователей из китайской быстрорастущей технологической сцены, предоставляя им место для обмена идеями и обсуждения Electron за пределами англоговорящего сообщества. Мы также хотели бы поблагодарить cnpm за работу и поддержку ночных обновлений Electron в китайском зеркале для npm.

Участие в известных и открытых мероприятиях​

• Мы празд��уем Hacktoberfest каждый год, начиная с 2019. Hacktoberfest это ежегодное мероприятие, посвященное проектам с открытым исходным кодом, организованное DigitalOcean, и мы получаем десятки энтузиастов каждый год, жаждущих оставить свой след на ПО с открытым исходным кодом.
• В 2020 году мы участвовали в первой части Google Season of Docs, где мы работали вместе с @bandantonio, чтобы переработать учебный процесс Electron для новых пользователей.
• В 2022 году мы начали обучать студентов Google Summer of Code в первый раз. @aryanshridhar провела невероятную работу, чтобы переработать основную версию Electron Fiddle, а именно: переработать загрузочную логику и перенести ее сборщик на webpack.

Автоматизация производства!​

Сегодня, команда управления Electron составляет около 30 активных разработчиков. Меньше чем половина из нас работают над проектом полный рабочий день, а это значит, что у нас впереди еще много работы. Что мы делаем для поддержки быстрой работоспособности? Наш девиз заключается в том, что компьютеры - вещь дешевая, а человеческое время - вещь дорогая. Ну как типичные инженеры, мы разработали автоматический инструментарий поддержки для облегчения нашей жизни.

Not Goma​

Ядро кода Electron - это код на C++, от чего время сборки всегда играл ограничивающий фактор в том, насколько быстро мы могли исправлять ошибки и добавлять новые возможности. В 2020 году мы запустили Not Goma, особый, направленный на язык Electron, бэкенд для распределенного компилятора Goma от Google. Not Goma обрабатывает заявки от авторизированных пользовательских машин, и распределяет процесс между сотнями ядер в бэкенде. Она также сохраняет результат компиляции для того, чтобы другому человеку, который компилирует те же файлы, надо было только загрузить предварительно скомпилированный результат.

С момента запуска Not Goma, время компиляции для поддержки сократилась с масштаба часов до масштабов минут. Стабильное интернет-соединение стало минимальным требованием для разработчиков, чтобы компилировать Electron!

Фактор Непрерывной Аутентификации​

Continuous Factor Authentication (CFA) является автоматизированным слоем вокруг Двухфакторной Аутентификационной (2FA) системы npm, которую мы комбинируем с семантическим обновлением для управления безопасностью и автоматическим выпуском обновлений различных пакетов npm для @electron/.

Хоть семантический выпуск версий уже автоматизирует процесс публикации npm пакетов, он требует выключения двухфакторной аутентификации или секретный токен, который обходит это ограничение.

Мы создали CFA для предоставления одноразового пароля на основе времени (TOTP) для npm 2FA с целью произвольной работы Cl, что позволяет нам использовать автоматический семантический выпуск, сохраняя при этом дополнительный слой безопасности в виде двухфакторной аутентификации.

Мы используем CFA в интеграции с фронтендом Slack, что позволяет разработчикам проверять публикацию пакетов с любого устройства, в котором есть Slack до тех пор, пока у них есть свой генератор TOTP.

Sheriff​

Sheriff это инструмент с открытым исходным кодом, который мы написали для автоматизации управления правами доступа в GitHub, Slack и Google Workspace.

Ключевая особенность Sheriff - управление правами доступа является прозрачным процессом. Он использует один конфигурационный файл YAML, который определяет права на все платформы, перечисленные выше. С Sheriff, получение статуса соавтора в репозитории или создание нового списка рассылок становится таким же легким, как и получение одобрения и слияния PR.

У Sheriff также есть журнал аудита, который отправляет сообщение в Slack, предупреждая администраторов о подозрительной активности внутри организации Electron.

...и всех наших ботов на GitHub​

GitHub это платформа с богатым количеством расширений API и их собственной автоматической структурой для создания приложений под названием Probot. Чтобы помочь нам сфокусироваться на более творческих частях нашей работы, мы создали набор маленьких ботов, которые выполняют за нас нашу грязную работу. Вот несколько примеров:

• Sudowoodo автоматизирует процесс выпуска Electron с начала и до конца, от отказа от определенных сборок и до загрузки финальных ресурсов в GitHub и npm.
• Trop автоматизирует бэкпортинг Electron, пытаясь выбрать только лучшие изменения веток предыдущих обновлений, основанные на метках GitHub PR.
• Roller автоматизирует ротационные обновления дополнений для Chromium и Node.js, которые требуются в Electron.
• Cation это бот для проверки статуса electron/electron PR.

В целом, наша маленькая семейка ботов дала нам огромное ускорение производительности разработчиков!

What’s next?​

Вступая в наше второе десятилетие, вы можете спросить: "А что дальше будет с Electron?"

Мы будем синхронизироваться с выпуском изменений Chromium, выпуская большие обновления для Electron каждые 8 недель, держа его обновленной и выбирая только лучшее из веб-платформ и Node.js, пока поддерживаем стабильность и безопасность приложений для предприятий.

Мы сообщаем о предстоящих инициативах, как только они обретут конкретные очертания. Если вы хотите быть в курсе будущих обновлений и общих обновлений проекта, вы можете читать нас в нашем блоке, а также подписаться на нас в социальных сетях (Twitter и Mastodon)!

Команда Electron рада сообщить, что в этом году мы впервые примем участие в Google Summer of Code!

Что такое Google Summer of Code?​

Google Summer of Code (GSoC) - это ежегодная программа наставничества, объединяющая проекты программного обеспечения с открытым исходным кодом с потенциальными участниками. Раньше это было только для студентов, но теперь зарегистрироваться в GSoC может любой желающий в возрасте от 18 лет и старше.

Для получения подробной информации, ознакомьтесь с сайтом GSoC.

How do I sign up?​

Вы заинтересованы в сотрудничестве с Electron? If you are a new or beginner open source contributor, we welcome you to apply!

In order to be selected as an Electron contributor for Google Summer of Code, you will need to submit an application. Applications will open on April 4th, 2022 and close on April 19th, 2022. You can follow updates for Google: Summer of Code application guidelines here.

Want to apply? First, check out the five project idea drafts that we have prepared. All of the listed ideas are currently open for proposals. We are also open to accepting new ideas that are not on the proposed project list.

Your application should include:

• Your proposal, which is a written document that describes in detail what you plan to achieve over the course of the summer.
• Your background as a developer. If you have a resume, please include a copy, otherwise tell us about your past experience with an emphasis on relevant technical experience.

A detailed guide of what to submit as part of your Electron application is here.

You can also read through the official GSoC student/contributor guide for important tips on preparing your proposal.

If you want to discuss project proposals or have questions, come hang out in our #gsoc-general Discord channel!

References​

• Electron Proposal Guide
• Electron GitHub
• Project Ideas Document
• Google Summer of Code Student/Contributor Guide

Join us for community bonding and a month-long celebration of open-source.

Electron Community Discord Launch

Electron’s Outreach Working Group is excited to announce the launch of our official community Discord server!

Why a new Discord server?​

In its early days as the backbone of the Atom text editor, community discussion on the Electron framework occurred in a single channel in Atom’s Slack workspace. As time passed and the two projects were increasingly decoupled, the relevance of the Atom workspace to the Electron project decreased, and maintainer participation in the Slack channel declined in the same manner.

Up until now, we had still been redirecting our broader community to the Atom Slack workspace, even though we’ve had many reports from folks who have had trouble receiving invitations, and few of our core maintainers were frequenting the channel.

We’re setting up this shiny new server to be a central discussion hub for the community where you can get the latest news on all things Electron.

Get in here!​

So far, the server’s membership consists of a few maintainers who have been working together to set it up, but we’re so excited to chat with you all! Come ask for help, keep up to date with Electron releases, or just hang out with other developers. We’ve got a handy invite for you that’ll give you access to the server!

Hacktoberfest 2020

As a large and long-running open-source project, Electron wouldn’t have been nearly as successful without all the contributions from its community, from code submissions to bug reports to documentation changes, and much more. That’s why we believe in the importance of participating in Hacktoberfest to usher in a wider community of developers of all skill levels into the project.

Odds and ends​

This year, we don’t have a wider project to give you all to work on, but we’d like to focus on opportunities to contribute across the Electron JavaScript ecosystem.

Look out for issues tagged hacktoberfest across our various repositories, including the main electron/electron repository, the electron/electronjs.org website, electron/fiddle, and electron-userland/electron-forge!

P.S. If you're feeling particularly adventurous, we also have a backlog of issues marked with help wanted tags if you're looking for more of a challenge.

Stuck? Come chat with us!​

Moreover, it’s also no coincidence that the grand opening of our Discord server coincides with the largest celebration of open-source software of the year. Check out the #hacktoberfest channel to ask for help on your Hacktoberfest PR. In case you missed it, here's the invite link again!

Electron имеет честь участвовать во второй версии инициативы "Google's Season of Docs", которая соединяет менторов из open source организаций с техническими писателями для улучшения документации проектов.

Что такое "Season of Docs"?

"Season of Docs" это программа, которая способствует сотрудничеству между техническими писателями и сообществами с открытым исходным кодом в интересах обеих сторон. Open source maintainers utilize the writer's technical writing expertise to improve the structure and content of their documentation, while the technical writer is introduced to an open-source community under the guidance of its mentors. Learn more about it on the Google's Season of Docs website.

For our first time participating in the program, we'll be mentoring a single technical writer who will be working alongside Electron's Ecosystem Working Group to reshape large parts of our documentation. You can learn more about the timeline of the whole project here.

How do I sign up?

Are you interested in collaborating with us as a technical writer? First, get familiar with Google's tech writer guide for this year's program, and check out the two project idea drafts that we have prepared.

In order to be selected as Electron's technical writer for Season of Docs, candidates will need to apply on the Google Season of Docs website during the Technical Writer Application phase that is running from June 8 to July 9..

Your application should include a proposal, which is a written document that describes in detail what you plan to achieve on the Electron docs over the course of 3 months. This proposal can either develop on one of the starting points mentioned in our Project Idea doc, or can be something entirely new. Don't know where to start? You can check out last year's list of accepted proposals for inspiration.

Aside from the proposal, we'll also be looking at your background as a technical writer. Please include a copy of your resume with an emphasis on relevant writing experience, as well as technical writing samples (these samples could be existing documentation, tutorial, blog posts, etc.)

If you want to discuss project proposals, shoot us an email at season-of-docs@electronjs.org and we can chat from there!

References

• Electron documentation
• Project ideas document
• Season of Docs tech writer guide

Electron is working on making its release cycles faster and more stable. To make that possible, we've started the App Feedback Program for large-scale Electron apps to test our beta releases and report app-specific issues to us. This helps us to prioritize work that will get applications upgraded to our next stable release sooner.

Edit (2020-05-21): This program has been retired.

Who can join?​

Our criteria and expectations for apps joining this program include the following items:

• Test your app during the beta period for 10,000+ user-hours
• Have a single point-person who will check in weekly to discuss your app's Electron bugs and app blockers
• You agree to abide by Electron's Code of Conduct
• You are willing to share the following information listed in the next question

What info does my Electron app have to share?​

• Total user-hours your app has been running with any beta release
• Version of Electron that your app is testing with (e.g., 4.0.0-beta.3)
• Any bugs preventing your application from upgrading to the release line being beta tested

User-hours​

We understand not everyone can share exact user numbers, however better data helps us decide how stable a particular release is. We ask that apps commit to testing a minimum number of user-hours, currently 10,000 across the beta cycle.

• 10 user-hours could be 10 people testing for one hour, or one person testing for 10 hours
• Тестирование можно разделить на бета-релизы, например, тест на 5,000 пользовательских часов на 3.0.0-бету. Протестируйте 5,000 пользовательских часов 3.0.0-beta.5. Больше лучшего, но мы понимаем, что некоторые приложения не могут протестировать каждый бета-релиз
• CI or QA hours do not count towards the total; however, internal releases do count

Why should my Electron app join?​

Your app's bugs will be tracked and be on the core Electron team's radar. Your feedback helps the Electron team to see how the new betas are doing and what work needs to be done.

Will my application's info be shared publicly? Who gets to see this info?​

No, your application's information will not be shared with the general public. Information is kept in a private GitHub repo that is only viewable to members of the App Feedback Program and Electron Governance. All members have agreed to follow Electron's Code of Conduct.

Зарегистрироваться​

We are currently accepting a limited number of signups. If you are interested and are able to fulfill the above requirements, please fill out this form.

На этой неделе мы опросили создателя Jasper, инструмента на основе Electron для управления уведомлениями GitHub.

Hello! Who are you?​

I'm Ryo Maruyama, a software developer in Japan. I am developing Jasper and ESDoc.

What is Jasper?​

Jasper является гибким и мощным читателем задач для GitHub. It supports issues and pull requests on github.com and GitHub Enterprise.

Why did you make it?​

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.

Who's using 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!

How does Jasper work?​

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.

What can we do with streams?​

I will introduce what kind of conditions can be used for stream.

Users and Teams​

involves means mention, author, assignee or commenter

Repositories and Organizations​

org is same as user

Attributes​

Review Status​

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.

• jasperapp.io/doc.html#stream
• help.github.com/articles/searching-issues
• help.github.com/articles/search-syntax

Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.

Is Jasper a paid product? How much does it cost?​

Jasper is $12. However you can use the free trial edition for 30 days.

Why did you choose to build Jasper on Electron?​

I like the following aspects of Electron:

• Apps can be developed with JavaScript/CSS/HTML.
• 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. Сначала я подумал использовать Notifications API. However I noticed that it does not support certain use cases. После этого я считал использование Issues API и Pull requests API, в дополнение к API уведомлений. But it never became what I wanted. Затем, думая о различных методах, я понял, что опрос поискового API GitHub's предоставит самую гибкую возможность. 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.

What's coming next?​

I have a plan to develop the following features:

• A filtered stream: A stream has some filtered stream that filter issues in the stream. It is like as view of SQL.
• Multiple accounts: you will be able to use both github.com and GHE
• Improve performance: For now the loading a issue in WebView is low speed than normal browser.

Follow @jasperappio on Twitter for updates.

This week we caught up with @feross and @dcposch to talk about WebTorrent, the web-powered torrent client that connects users together to form a distributed, decentralized browser-to-browser network.

What is WebTorrent?​

WebTorrent is the first torrent client that works in the browser. It's written completely in JavaScript and it can use WebRTC for peer-to-peer transport. No browser plugin, extension, or installation is required.

Using open web standards, WebTorrent connects website users together to form a distributed, decentralized browser-to-browser network for efficient file transfer.

You can see a demo of WebTorrent in action here: webtorrent.io.

Why is this cool?​

Imagine a video site like YouTube, but where visitors help to host the site's content. The more people that use a WebTorrent-powered website, the faster and more resilient it becomes.

Browser-to-browser communication cuts out the middle-man and lets people communicate on their own terms. No more client/server – just a network of peers, all equal. WebTorrent is the first step in the journey to re-decentralize the Web.

Where does Electron come into the picture?​

About one year ago, we decided to build WebTorrent Desktop, a version of WebTorrent that runs as a desktop app.

We created WebTorrent Desktop for three reasons:

1. We wanted a clean, lightweight, ad-free, open source torrent app
2. We wanted a torrent app with good streaming support
3. We need a "hybrid client" that connects the BitTorrent and WebTorrent networks

If we can already download torrents in my web browser, why a desktop app?​

First, a bit of background on the design of WebTorrent.

In the early days, BitTorrent used TCP as its transport protocol. Later, uTP came along promising better performance and additional advantages over TCP. Every mainstream torrent client eventually adopted uTP, and today you can use BitTorrent over either protocol. The WebRTC protocol is the next logical step. It brings the promise of interoperability with web browsers – one giant P2P network made up of all desktop BitTorrent clients and millions of web browsers.

“Web peers” (torrent peers that run in a web browser) make the BitTorrent network stronger by adding millions of new peers, and spreading BitTorrent to dozens of new use cases. WebTorrent follows the BitTorrent spec as closely as possible, to make it easy for existing BitTorrent clients to add support for WebTorrent.

Some torrent apps like Vuze already support web peers, but we didn't want to wait around for the rest to add support. So basically, WebTorrent Desktop was our way to speed up the adoption of the WebTorrent protocol. By making an awesome torrent app that people really want to use, we increase the number of peers in the network that can share torrents with web peers (i.e. users on websites).

What are some interesting use cases for torrents beyond what people already know they can do?​

One of the most exciting uses for WebTorrent is peer-assisted delivery. Non-profit projects like Wikipedia and the Internet Archive could reduce bandwidth and hosting costs by letting visitors chip in. Popular content can be served browser-to-browser, quickly and cheaply. Rarely-accessed content can be served reliably over HTTP from the origin server.

The Internet Archive actually already updated their torrent files so they work great with WebTorrent. So if you want to embed Internet Archive content on your site, you can do it in a way that reduces hosting costs for the Archive, allowing them to devote more money to actually archiving the web!

There are also exciting business use cases, from CDNs to app delivery over P2P.

What are some of your favorite projects that use WebTorrent?​

The coolest thing built with WebTorrent, hands down, is probably Gaia 3D Star Map. It's a slick 3D interactive simulation of the Milky Way. The data loads from a torrent, right in your browser. It's awe-inspiring to fly through our star system and realize just how little we humans are compared to the vastness of our universe.

You can read about how this was made in Torrenting The Galaxy, a blog post where the author, Charlie Hoey, explains how he built the star map with WebGL and WebTorrent.

We're also huge fans of Brave. Brave is a browser that automatically blocks ads and trackers to make the web faster and safer. Brave recently added torrent support, so you can view traditional torrents without using a separate app. That feature is powered by WebTorrent.

So, just like how most browsers can render PDF files, Brave can render magnet links and torrent files. They're just another type of content that the browser natively supports.

One of the co-founders of Brave is actually Brendan Eich, the creator of JavaScript, the language we wrote WebTorrent in, so we think it's pretty cool that Brave chose to integrate WebTorrent.

Why did you choose to build WebTorrent Desktop on Electron?​

Есть мема, что приложения Electron "bloated", потому что они включают весь модуль контента Chrome в каждом приложении. В некоторых случаях это частично верно (инсталлятор приложения Electron обычно ~40MB, где установщик приложений для ОС обычно ~20MB).

However, in the case of WebTorrent Desktop, we use nearly every Electron feature, and many dozens of Chrome features in the course of normal operation. If we wanted to implement these features from scratch for each platform, it would have taken months or years longer to build our app, or we would have only been able to release for a single platform.

Just to get an idea, we use Electron's dock integration (to show download progress), menu bar integration (to run in the background), protocol handler registration (to open magnet links), power save blocker (to prevent sleep during video playback), and automatic updater. As for Chrome features, we use plenty: the <video> tag (to play many different video formats), the <track> tag (for closed captions support), drag-and-drop support, and WebRTC (which is non-trivial to use in a native app).

Not to mention: our torrent engine is written in JavaScript and assumes the existence of lots of Node APIs, but especially require('net') and require('dgram') for TCP and UDP socket support.

Basically, Electron is just what we needed and had the exact set of features we needed to ship a solid, polished app in record time.

What are your favorite things about Electron?​

The WebTorrent library has been in development as an open source side project for two years. We made WebTorrent Desktop in four weeks. Electron is the primary reason that we were able to build and ship our app so quickly.

Just as Node.js made server programming accessible to a generation of jQuery-using front-end programmers, Electron makes native app development accessible to anyone familiar with Web or Node.js development. Electron is extremely empowering.

Do the website and the Desktop client share code?​

Yes, the webtorrent npm package works in Node.js, in the browser, and in Electron. The exact same code can run in all environments – this is the beauty of JavaScript. It's today's universal runtime. Java Applets promised "Write Once, Run Anywhere" apps, but that vision never really materialized for a number of reasons. Electron, more than any other platform, actually gets pretty darn close to that ideal.

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

In early versions of the app, we struggled to make the UI performant. We put the torrent engine in the same renderer process that draws the main app window which, predictably, led to slowness anytime there was intense CPU activity from the torrent engine (like verifying the torrent pieces received from peers).

We fixed this by moving the torrent engine to a second, invisible renderer process that we communicate with over IPC. This way, if that process briefly uses a lot of CPU, the UI thread will be unaffected. Buttery-smooth scrolling and animations are so satisfying.

Note: we had to put the torrent engine in a renderer process, instead of a "main" process, because we need access to WebRTC (which is only available in the renderer.)

In what areas should Electron be improved?​

One thing we'd love to see is better documentation about how to build and ship production-ready apps, especially around tricky subjects like code signing and auto-updating. We had to learn about best practices by digging into source code and asking around on Twitter!

Is WebTorrent Desktop done? If not, what's coming next?​

We think the current version of WebTorrent Desktop is excellent, but there's always room for improvement. We're currently working on improving polish, performance, subtitle support, and video codec support.

If you're interested in getting involved in the project, check out our GitHub page!

Any Electron development tips that might be useful to other developers?​

Feross, one of the WebTorrent Desktop contributors, recently gave a talk "Real world Electron: Building Cross-platform desktop apps with JavaScript" at NodeConf Argentina that contains useful tips for releasing a polished Electron app. Обсуждение особенно полезно, если вы находитесь на этапе, где у вас есть базовое рабочее приложение, и вы пытаетесь перейти к следующему уровню польского и профессионализма.

Watch here:

Slides here:

DC, another WebTorrent contributor, wrote a checklist of things you can do to make your app feel polished and native. It comes with code examples and covers things like macOS dock integration, drag-and-drop, desktop notifications, and making sure your app loads quickly.

This week we met with Aprile Elcich and Paolo Fragomeni to talk about Voltra, an Electron-powered music player.

What is Voltra?​

Voltra is a music player for people who want to own their music. It’s also a store where you can discover and buy new music based on what you already own. It’s ad-free, cross-platform for desktop and mobile. It also doesn’t spy on you.

Who is Voltra for?​

Anyone who listens to music.

What motivated you to create Voltra?​

Radio has has always had a big share of listeners. It’s moving off the airwaves and onto the Internet. Now you can rent music on demand — it’s a radio revival! A lot of new products and services have emerged because of this, but streaming radio still leaves someone else in control of your music and how you experience it.

We wanted a product that was entirely focused on music you own. Something that made it easy to discover and buy new music directly from artists or labels.

Is there a free version?​

The desktop player is completely free. Selling your music is also free! We are not ad-supported.

Since the app is free, we may open source it later on. Right now we don’t have the bandwidth to manage that. We also have very specific ideas for features and the direction we want to take things. We have an active beta community and we take our feedback to heart.

How do you make money?​

We have premium features!

Our Voltra Audio Archive is a cloud-backup service designed specifically for music. We don’t compress or share data blocks. Your music collection is physically backed up for you.

For artists and labels, our Pro Membership offers tools to help them reach more relevant audiences, such as analytics and professional artist webpages.

What makes Voltra different?​

Design and usability are incredibly important to us. We want to give listeners a distraction-free listening experience! There are a some interesting music players and stores out there. But many of them are more advanced and harder to use than their creators realize. We want to make Voltra accessible to as many people as possible.

We also don't take a cut from the artist or the label. That’s a key differentiator for us. It’s really important because it lowers the barrier for artists to get their music to market.

What are some design & technical decisions you made?​

While designing Voltra, we considered UI conventions from native apps and the web, we also thought a lot about what we could remove. We have an active private beta group who have given us critical feedback over the last few months.

We found that album art and photography are really important to people. Many players are just lists of files. One of the cool things about owning physical albums is the album art, and we wanted to put emphasis on this in the Voltra desktop app.

We also made sure not to mess with people's files. We use file watching so you can put your files wherever you want, and we don't rename them or move them for you. We have an embedded database to track the state of the watched directories so that we can track what's new, even when the process isn't running.

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

We spend a lot of time focused on performance. We started with frameworks but moved to vanilla Javascript. In our experience, the generalized abstractions they provide outweigh the performance penalties and ceremony that they introduce.

We handle very large collections pretty well at this point. Large collections means possibly tens of thousands of images! Having Node.js’ file system module directly available from the render process made it really easy to lazy load and unload lots of images super quickly based on DOM events.

В целом setImmediate и requestIdleCallback были супер важными инструментами для выполнения большого количества обработки, сохраняя пользовательский интерфейс. More specifically, distributing CPU-bound tasks into separate processes really helps to keep the user interface responsive. Если говорить конкретно, то распределение задач, связанных с процессором, в отдельных процессах действительно помогает поддерживать гибкость пользовательского интерфейса.

Why did you choose to build Voltra on Electron?​

Песочница браузера слишком ограничены для нашего приложения. But we are also developing a web player. So it’s a huge win that we can share almost 100% of the code between the two implementations.

We actually started by building a native app with Swift. The main problem we found was that we were reinventing a lot of things. The web has the world’s largest open source eco-system. So we pretty quickly switched to Electron.

Also, and most importantly, with Electron you develop once and it should Just Work™ on all the major platforms. It’s not guaranteed, but the cost of coding natively for each platform definitely outweighs any other costs that electron introduces.

What are your favorite things about Electron?​

GTD!: Having Node.js’ networking stack and Chromium’s presentation layer packaged together is a recipe for getting things done.

Competency: It’s just the web stack, so literally our whole team is involved in actually building the product.

Community: There is a highly organized community that knows how to communicate really well! We feel pretty great about developing with support like that.

In what areas could Electron be improved?​

We would like to see Electron endorse a single packager. The packager is as important to Electron what the package manager is to Node. There are multiple packagers in user-land, each with interesting features but each with bugs. Consensus by the community would help to direct the energy being spent by contributors.

What's coming next?​

We‘re currently developing a mobile app, and working with artists and labels to add their music to the Voltra shop. Hey! If you’re an artist or label, sign up now! We plan on opening up the shop when we reach our goal of 10 million tracks.