Zum Hauptteil springen

11 Beiträge mit "Showcase" markiert

Highlighting featured Electron use cases

Alle Tags anzeigen

Ecosystem 2023 Recap

· Die Lesezeit beträgt 5 min

Reflecting on the improvements and changes in Electron's developer ecosystem in 2023.


In the past few months, we've been cooking up some changes across the Electron ecosystem to supercharge the developer experience for Electron apps! Here’s a swift rundown of the latest additions straight from Electron HQ.

Electron Forge 7 and beyond

Electron Forge 7 — the newest major version of our all-in-one tool for packaging and distributing Electron applications — is now available.

While Forge 6 was a complete rewrite from v5, v7 is smaller in scope but still contains a few breaking changes. Going forward, we will continue to publish major versions of Forge as breaking changes need to be made.

For more details, see the full Forge v7.0.0 changelog on GitHub.

Wichtige Änderungen

  • Switched to notarytool for macOS notarization: As of 2023-11-01, Apple sunset the legacy altool for macOS notarization, and this release removes it from Electron Forge entirely.
  • Minimum Node.js increased to v16.4.0: With this release, we’ve set the minimum required Node.js version to 16.4.0.
  • Dropped support for electron-prebuilt and electron-prebuilt-compile: electron-prebuilt was the original name for Electron’s npm module, but was replaced by electron in v1.3.1. electron-prebuilt-compile was an alternative to that binary that came with enhanced DX features, but was eventually abandoned as a project.

Highlights

  • Google Cloud Storage publisher: As part of our push to better support static auto updating, Electron Forge now supports publishing directly to Google Cloud Storage!
  • ESM forge.config.js support: Electron Forge now supports ESM forge.config.js files. (P.S. Look forward to ESM entrypoint support in Electron 28.)
  • Makers now run in parallel: In Electron Forge 6, Makers ran sequentially for ✨ legacy ✨ reasons. Since then, we’ve tested out parallelization for the Make step with no adverse side effects, so you should see a speed-up when building multiple targets for the same platform!
Thank you!

🙇 Big thanks to mahnunchik for the contributions for both the GCS Publisher and ESM support in Forge configurations!

Better static storage auto updates

Squirrel.Windows and Squirrel.Mac are platform-specific updater technologies that back Electron’s built-in autoUpdater module. Both projects support auto updates via two methods:

  • A Squirrel-compatible update server
  • A manifest URL hosted on a static storage provider (e.g. AWS, Google Cloud Platform, Microsoft Azure, etc.)

The update server method has traditionally been the recommended approach for Electron apps (and provides additional customization of update logic), but it has a major downside—it requires apps to maintain their own server instance if they are closed-source.

On the other hand, the static storage method has always been possible, but was undocumented within Electron and poorly supported across Electron tooling packages.

With some great work from @MarshallOfSound, the update story for serverless automatic app updates has been drastically streamlined:

  • Electron Forge’s Zip and Squirrel.Windows makers can now be configured to output autoUpdater-compatible update manifests.
  • A new major version of update-electron-app (v2.0.0) can now read these generated manifests as an alternative to the update.electronjs.org server.

Once your Makers and Publishers are configured to upload update manifests to cloud file storage, you can enable auto updates with only a few lines of configuration:

const { updateElectronApp, UpdateSourceType } = require('update-electron-app');

updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
},
});
Weiterführende Informationen

📦 Want to learn more? For a detailed guide, see Forge’s auto update documentation.

The @electron/ extended universe

When Electron first started, the community published many packages to enhance the experience of developing, packaging, and distributing Electron apps. Over time, many of these packages were incorporated into Electron’s GitHub organization, with the core team taking on the maintenance burden.

In 2022, we began unifying all these first-party tools under the @electron/ namespace on npm. This change means that packages that used to be electron-foo are now @electron/foo on npm, and repositories that used to be named electron/electron-foo are now electron/foo on GitHub. These changes help clearly delineate first-party projects from userland projects. This includes many commonly used packages, such as:

  • @electron/asar
  • @electron/fuses
  • @electron/get
  • @electron/notarize
  • @electron/osx-sign
  • @electron/packager
  • @electron/rebuild
  • @electron/remote
  • @electron/symbolicate-mac
  • @electron/universal

Going forward, all first-party packages we release will also be in the @electron/ namespace. There are two exceptions to this rule:

  • Electron core will continue to be published under the electron package.
  • Electron Forge will continue to publish all of its monorepo packages under the @electron-forge/ namespace.
Star seeking

⭐ During this process, we also accidentally took the electron/packager repository private, which has the unfortunate side effect of erasing our GitHub star count (over 9000 before the erasure). If you are an active user of Packager, we’d appreciate a ⭐ Star ⭐!

Introducing @electron/windows-sign

Starting on 2023-06-01, industry standards began requiring keys for Windows code signing certificates to be stored on FIPS-compliant hardware.

In practice, this meant that code signing became a lot harder for apps that build and sign in CI environments, since many Electron tools take in a certificate file and password as config parameters and attempt to sign from there using hardcoded logic.

This situation has been a common pain point for Electron developers, which is why we have been working on a better solution that isolates Windows code signing into its own standalone step, similar to what @electron/osx-sign does on macOS.

In the future, we plan on fully integrating this package into the Electron Forge toolchain, but it currently lives on its own. The package is currently available for installation at npm install --save-dev @electron/windows-sign and can used programmatically or via CLI.

Please try it out and give us your feedback in the repo’s issue tracker!

What's next?

We'll be entering our annual December quiet period next month. While we do, we'll be thinking about how we can make the Electron development experience even better in 2024.

Is there anything you'd like to see us work on next? Gib uns Bescheid!

Projekt der Woche: Jasper

· Die Lesezeit beträgt 5 min

Diese Woche haben wir den Ersteller von Jasperinterviewt, einem Electron-basierten Werkzeug für die Verwaltung von GitHub Benachrichtigungen.


Hallo! Wer bist du?

Ich bin Ryo Maruyama, ein Softwareentwickler in Japan. Ich entwickle Jasper und ESDoc.

Was ist Jasper?

Jasper ist ein flexibler und mächtiger Issue-Reader für GitHub. Es unterstützt Issues und Pull-Requests auf github.com und GitHub Enterprise.

Jasper App Screenshot

Warum hast du es gemacht?

Wenn Menschen GitHub in ihren Job- oder OSS-Aktivitäten verwenden, neigen sie dazu, täglich viele Benachrichtigungen zu erhalten. Um die Benachrichtigungen zu abonnieren, bietet GitHub E-Mail und Web-Benachrichtigungen. Ich habe diese für ein paar Jahre verwendet, aber ich bin auf folgende Probleme gestoßen:

  • 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.

Wer benutzt 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!

Wie funktioniert Jasper?

Sobald Jasper konfiguriert ist, erscheint der folgende Bildschirm. Von links nach rechts können Sie "Streams List", "Issue List" und "Issue Body" sehen.

Jasper Start Screen

Dieser "Stream" ist die Kernfunktion von Jasper. Wenn Sie zum Beispiel "Issues, die @zeke im electron/electron Repository zugewiesen sind" sehen wollen, erstellen Sie den folgenden Stream:

repo:electron/electron assignee:zeke is:issue

Jasper Start Screen 2

After creating the stream and waiting for a few seconds, you can see the issues that meet the conditions.

Jasper Start Screen 3

Was können wir mit Streams tun?

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

Benutzer und Teams

StreamIssues
mentions:cat mentions:dogIssues that mention user cat or dog
author:cat author:dogIssues created by user cat or dog
assignee:cat assignee:dogIssues assigned to cat or dog
commenter:cat commenter:dogIssues that cat or dog commented on
involves:cat involves:dogIssues that "involve" cat or bob
team:animal/white-cat team:animal/black-dogIssues that animal/white-cat or animal/black-dog are mentioned in

involves means mention, author, assignee or commenter

Respositories und Organisationen

StreamIssues
repo:cat/jump repo:dog/runIssues in cat/jump oder dog/run
org:electron user:cat user:dogIssues in electron, cat oder dog

org is same as user

Attribute

StreamIssues
repo:cat/jump milestone:v1.0.0 milestone:v1.0.1Issues that are attached to v1.0.0 or v1.0.1 in cat/jump
repo:cat/jump label:bug label:blockerIssues that are attached bug and blocker in cat/jump
electron OR atomshellIssues that include electron or atomshell

Prüfstatus

StreamIssues
is:pr review:requiredIssues that are required review in cat/jump
is:pr review-requested:catIssues that are requested review by cat.
But these are not reviewed yet.
is:pr reviewed-by:catIssues, die von cat reviewed werden

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.

Ist Jasper ein bezahltes Produkt? Wie viel kostet es?

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

Warum haben Sie Jasper auf Electron gebaut?

Ich mag die folgenden Aspekte von Elektron:

  • Apps können mit JavaScript/CSS/HTML entwickelt werden.
  • Apps können für Windows, Mac und Linux-Plattformen gebaut werden.
  • Electron wird aktiv entwickelt und hat eine große 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.

Was sind einige Herausforderungen, denen Sie bei der Entwicklung von Jasper gegenüberstanden?

I had a hard time figuring out the "stream" concept. Zuerst habe ich über die Verwendung von GitHubs Benachrichtigungs-API nachgedacht. Ich habe jedoch festgestellt, dass sie bestimmte Anwendungsfälle nicht unterstützt. Danach habe ich die Issues API und Pull-Requests APIzusätzlich zur Benachrichtigungs-API in Erwägung gezogen. Aber es wurde nie das, was ich wollte. Während ich über verschiedene Methoden nachdachte, erkannte ich, dass das Umfragen von GitHubs Such-API die größte Flexibilität bieten würde. 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.

Was kommt als Nächstes?

Ich habe einen Plan, die folgenden Funktionen zu entwickeln:

  • Ein gefilterter Stream: Ein Stream hat einige gefilterte Streams, die Probleme im Stream filtern. Es ist wie eine Ansicht von SQL.
  • Mehrere Konten: Sie werden in der Lage sein, github.com und GHE zu verwenden
  • Leistung verbessern: Im Moment ist das Laden eines Problems in WebView in niedriger Geschwindigkeit als der normale Browser.

Folgen Sie @jasperappio auf Twitter für Updates.

Project of the Week: WebTorrent

· Die Lesezeit beträgt 9 min

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.

webtorrent homepage

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.

WebTorrent Desktop player window

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.

webtorrent desktop logo

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?

gaia app screenshot

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.

brave logo

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?

WebTorrent Desktop main window

Es gibt eine Meme, die Electron-Apps "geblockt" werden, da sie das gesamte Chrome-Inhaltsmodul in jeder App enthalten. In einigen Fällen ist dies teilweise der Fall (ein Electron-App-Installer ist normalerweise ~40MB, wobei ein OS-spezifischer App-Installer normalerweise ~20MB beträgt).

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. Der Vortrag ist besonders nützlich, wenn Sie sich in der Phase befinden, in der Sie eine grundlegende Arbeits-App haben und Sie versuchen, sie auf die nächste Stufe von Polnisch und Professionalität zu bringen.

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.

Project of the Week: Voltra

· Die Lesezeit beträgt 6 min

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.

voltra-artistview

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.

voltra-albumview

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.

Im Allgemeinen sind setImmediate und requestIdleCallback extrem wichtige Werkzeuge für die Durchführung einer Vielzahl von Verarbeitungen, während die UI auf dem Laufenden bleibt. More specifically, distributing CPU-bound tasks into separate processes really helps to keep the user interface responsive. Genauer gesagt, die Verteilung von CPU-gebundenen Aufgaben in separate Prozesse trägt dazu bei, dass die Benutzerschnittstelle auf dem Laufenden bleibt.

Why did you choose to build Voltra on Electron?

Die Sandbox des Browsers ist für unsere App zu beschränkt. Aber wir entwickeln auch einen Webplayer. 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.

Was kommt als Nächstes?

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.

Projekt der Woche: WordPress Desktop App

· Die Lesezeit beträgt 4 min

Diese Woche haben wir uns mit den Jungs von Automattic zusammengesetzt und über die WordPress Desktop App, ein Open-Source Desktopclient zur Verwaltung von WordPress-Inhalten, gesprochen.


WordPress Apps

Jeder kennt WordPress. Aber was ist WordPress Desktop?

The WordPress.com Desktop app provides a seamless cross-platform experience that allows you to focus on your content and design with no browser tabs to distract you — or to keep your sites sidelined but accessible. In combination with our browser support and mobile app you can build your site anywhere, in whatever way helps you get your work done.

Why build a Desktop app for managing WordPress sites? Couldn't it all be web-based?

It's actually using exactly the same technology you get when visiting WordPress.com in your browser. However, it's all locally hosted, so it has minimal load times. With the benefit of native features such as being in your dock, notifications, etc., you really can focus on your WordPress sites and blogging.

Why did you choose to build WordPress Desktop on Electron?

At the end of 2015 we rebuilt much of WordPress.com in the form of Calypso, an open-source modern JavaScript app using React. We started looking at Electron and with some changes to Calypso were able to get it running locally. It was a compelling experience and we thought there was a lot of value in developing it further.

We had several teams working on Calypso. To make a full multi-platform GUI client that matched this using traditional desktop technologies would have taken more work. By using Electron, a small team of 2-4 of us were able to leverage the other team’s efforts and build the Desktop app in a couple of months.

What are some challenges you've faced while building WordPress Desktop?

We got an initial version of the app running very quickly, but tuning it to behave optimally as a desktop app took a lot more time. One big challenge with the app is that you're actually running a copy of Calypso on your own machine - it’s purely an API driven UI. There was a lot of bridging work involved in this, and changes were fed back to Calypso itself.

Additionally a lot of effort was spent packaging the app for different platforms - we provide Windows, macOS, and Linux versions - and there are sufficient differences to make this tricky.

At the time Electron was relatively new and we kept running into issues that were shortly fixed (sometimes the same day!)

In what areas should Electron be improved?

Electron already provides most of what we need for the Desktop app, and it's progressed rapidly since we started using it. That said, there are some areas that are taken for granted in a desktop app, such as spell checking and find/replace, that are harder to replicate with Electron as-is.

We’d also love to see some of the newer Chrome technologies filtering down into Electron too. We’re particularly keen on experimenting with WebVR.

What are your favorite things about Electron?

The main reason we chose Electron, and it's biggest strength, is the very active and open community. Automattic has always believed in open source. It is one of our core tenets, and the Electron project and community follows a lot of the core beliefs of being very open and positive.

What's coming next in WordPress Desktop?

The great thing about our model is that the Desktop app benefits from any new Calypso feature - there are constant improvements. We’re hoping we can add additional features to the app such as offline support, which would really take the app into native territory, and better system notifications.

Are there any teams at Automattic working on other Electron apps?

Yes, after our efforts on the Desktop app, the Simplenote team decided to use Electron to build desktop apps for Windows and Linux (a native Mac client already exists). The Simplenote Electron app is also open source and available on Github.

We've also got an upcoming Raspberry Pi integration that uses Electron.

If any of that sounds interesting then we'd love to hear from you!

Any Electron tips that might be useful to other developers?

The process of shipping signed desktop software is relatively new to us, especially for Windows. we wrote up an article for Code Signing a Windows App which includes the process and a few of the hurdles we went through to do it right.

Projekt der Woche: Dat

· Die Lesezeit beträgt 7 min

This week's featured project is Dat, a grant-funded, open source, decentralized tool for distributing data sets. Dat is built and maintained by a geodistributed team, many of whom helped write this post.


A screenshot of the main view of dat-desktop, showing a few rows of shared
dats

Zunächst was ist Dat?

We wanted to bring the best parts of peer to peer and distributed systems to data sharing. We started with scientific data sharing and then began branching out into research institutions, government, public service, and open source teams as well.

Another way to think about it is a sync and upload app like Dropbox or BitTorrent Sync, except Dat is open source. Our goal is to be a a powerful, open source, non-profit data sharing software for big, small, medium, small-batch and big-batch data.

To use the dat CLI tool, all you have to type is:

dat share path/to/my/folder

And dat will create a link that you can use to send that folder to someone else -- no central servers or third parties get access to your data. Unlike BitTorrent, it's also impossible to sniff who is sharing what (see the Dat Paper draft for more details).

Now we know what Dat is. How does Dat Desktop fit in?

Dat Desktop is a way to make Dat accessible to people who can't or don't want to use the command line. You can host multiple dats on your machine and serve the data over your network.

Können Sie einige coole Anwendungsfälle teilen?

DataRefuge + Project Svalbard

We're working on a thing codenamed Project Svalbard that is related to DataRefuge, a group working to back up government climate data at risk of disappearing. Svalbard is named after the Svalbard Global Seed Vault in the Arctic which has a big underground backup library of plant DNA. Our version of it is a big version controlled collection of public scientific datasets. Once we know and can trust the metadata, we can build other cool projects like a distributed volunteer data storage network.

California Civic Data Coalition

CACivicData is an open-source archive serving up daily downloads from CAL-ACCESS, California's database tracking money in politics. They do daily releases, which means hosting a lot of duplicate data across their zip files. We're working on hosting their data as a Dat repository which will reduce the amount of hassle and bandwidth needed to refer to specific version or update to a newer version.

Electron-Updates

This one isn't concrete yet, but we think a fun use case would be putting a compiled Electron app in a Dat repository, then using a Dat client in Electron to pull the latest deltas of the built app binary, to save on download time but also to reduce bandwidth costs for the server.

Wer sollte Dat Desktop verwenden?

Jeder, der Daten über ein p2p-Netzwerk austauschen und aktualisieren möchte. Datenwissenschaftler, offene Datenhacker, Forscher, Entwickler. Wir sind super offen für Feedback, wenn jemand einen coolen Anwendungsfall hat, den wir noch nicht bedacht haben. You can drop by our Gitter Chat and ask us anything!

Was kommt als nächstes in Dat und Dat Desktop?

Benutzerkonten und Metadatenveröffentlichung. 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). Since many datasets are huge, we need a federated registry (similar to how BitTorrent trackers work). We want to make it easy for people to find or publish datasets with the registry from Dat Desktop, to make the data sharing process frictionless.

Another feature is multi-writer/collaborative folders. We have big plans to do collaborative workflows, maybe with branches, similar to git, except designed around dataset collaboration. But we're still working on overall stability and standardizing our protocols right now!

Warum haben Sie sich entschieden, Dat Desktop auf Electron zu bauen?

Dat wird mit Node.js gebaut, so dass es eine natürliche Anpassung für unsere Integration war. Beyond this, our users use a variety of machines since scientists, researchers and government officials may be forced to use certain setups for their institutions -- this means we need to be able to target Windows and Linux as well as Mac. Dat Desktop gives us that quite easily.

Was waren einige Herausforderungen, denen Sie beim Erstellen von Dat und Dat Desktop gegenüberstanden?

Figuring out what people want. We started with tabular datasets, but we realized that it was a bit of a complicated problem to solve and that most people don't use databases. So half way through the project, we redesigned everything from scratch to use a filesystem and haven't looked back.

Wir sind auch auf einige allgemeine Probleme der Electron-Infrastruktur gestoßen, unter anderem:

  • Telemetry - how to capture anonymous usage statistics
  • Updates - It's kind of piecemeal and magic to set up automatic updates
  • Releases - XCode signing, building releases on Travis, doing beta builds, all were challenges.

We also use Browserify and some cool Browserify Transforms on the 'front end' code in Dat Desktop (which is kind of weird because we still bundle even though we have native require -- but it's because we want the Transforms). To better help manage our CSS we switched from Sass to using sheetify. It's greatly helped us modularize our CSS and made it easier to move our UI to a component oriented architecture with shared dependencies. For example dat-colors contains all of our colors and is shared between all our projects.

We've always been a big fan of standards and minimal abstractions. Our whole interface is built using regular DOM nodes with just a few helper libraries. We've started to move some of these components into base-elements, a library of low-level reusable components. As with most of our technology we keep iterating on it until we get it right, but as a team we have a feeling we're heading in the right direction here.

In what areas should Electron be improved?

We think the biggest pain point is native modules. Having to rebuild your modules for Electron with npm adds complexity to the workflow. Our team developed a module called prebuild which handles pre-built binaries, which worked well for Node, but Electron workflows still required a custom step after installing, usually npm run rebuild. It was annoying. To address this we recently switched to a strategy where we bundle all compiled binary versions of all platforms inside the npm tarball. This means tarballs get larger (though this can be optimized with .so files - shared libraries), this approach avoids having to run post-install scripts and also avoids the npm run rebuild pattern completely. It means npm install does the right thing for Electron the first time.

What are your favorite things about Electron?

The APIs seem fairly well thought out, it's relatively stable, and it does a pretty good job at keeping up to date with upstream Node releases, not much else we can ask for!

Any Electron tips that might be useful to other developers?

If you use native modules, give prebuild a shot!

What's the best way to follow Dat developments?

Follow @dat_project on Twitter, or subscribe to our email newsletter.

Project of the Week: Ghost

· Die Lesezeit beträgt 5 min

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 Desktop Screenshot

What is Ghost?

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.

Is Ghost a for-profit company?

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.

What is Ghost Desktop?

Ghost Desktop allows writers to manage multiple blogs at once - and to focus on their writing. Einfache Dinge wie übliche Schreibverknüpfungen können nicht in einem Browser realisiert werden, sind aber in unserer Desktop-App verfügbar. Es erlaubt anderen Anwendungen, direkt mit dem Blog über deeplinks zu kommunizieren.

What is Ghost for Journalism?

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.

In what areas should Electron be improved?

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.

What are your favorite things about 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.

Is Ghost done? If not, what's coming next?

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!

What are some of your favorite Electron apps?

I'm a big fan of Kap, Felony, and Visual Studio Code.

👻

Projekt der Woche: Beaker Browser

· Die Lesezeit beträgt 4 min

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.


Was ist Beaker und warum hast du es geschafft?

Beaker is a participatory browser. Es ist ein Browser für Indie-Hacker.

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." It creates sites on demand, for free, and then shares them from the device. Kein Server nötig. Das ist unsere Innovation.

Beakers Protokolle

When you visit a Dat site in Beaker, you download the files. Die Seite ist für immer Ihre. You can save it, fork it, modify it, and share your new version for free. Es ist alles Open-Source.

So that's what it's about: We're making a browser for open-source Websites. Wir wollen, dass es ein Toolkit für Social Hacking ist.

Wer sollte Beaker verwenden?

Hacker. Modder. Kreative Typen. Menschen, die gerne basteln.

Wie erstelle ich ein neues Projekt, das Dat verwendet?

We've got a command-line tool called bkr that's kind of like git + npm. Here's creating a site:

$ cd ~/my-site
$ bkr init
$ echo "Hallo, world!" > index.html
$ bkr veröffentlichen

And here's forking a site:

$ bkr fork dat://0ff7d4c7644d0aa19914247dc5dbf502d6a02ea89a5145e7b178d57db00504cd/ ~/my-fork
$ cd ~/my-fork
$ echo "Meine Fork hat keine Rücksicht auf den vorherigen Index. > index.html
$ bkr veröffentlichen

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.

Warum haben Sie sich entschieden, Beaker auf Electron zu bauen?

It was obvious for this project. If I forked Chrome myself, I'd be writing C++ right now! Niemand will das tun. 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.

Was sind einige Herausforderungen, denen du beim Entwickeln von Beaker begegnet bist?

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.

In what areas should Electron be improved?

It'd be really great if I could dock the devtools inside a webview.

Was kommt als nächstes in Beaker?

Secure DNS names for Dat sites. A socially configurable URL scheme, called the "app scheme." More Dat APIs.

Für Leute, die sich für das Projekt interessieren, in welchen Bereichen braucht Beaker Hilfe?

Wir haben viele offene Fehler. Haben Sie keine Angst, mich anzupingen. #beakerbrowser auf Freenode. Wir haben eine -Seite für Mitwirkende und wir werden Sie hinzufügen. Und wenn Sie Austin besuchen, kaufe ich Ihnen ein Bier.

Any Electron tips that might be useful to other developers?

  1. Benutzen Sie die Build-Werkzeuge, die dort draußen sind. Sie wollen nicht mit Ihren eigenen Lösungen ringen, vertrauen Sie mir. Benutzen Sie electron-builder. Verwenden Sie eine Boilerplatten-Repo.
  2. 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.
  3. Read through all the guides and advanced docs at least once.
  4. Don't build a browser, it's a saturated market.

Project of the Week: Kap

· Die Lesezeit beträgt 7 min

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


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

Kap Screencast

What is Kap?

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

We have seen people of all age and backgrounds use it in educational settings, screencasts, tutorials... die Liste geht weiter. Even to create production assets! We're completely blown away by how well received our little side project has been.

Why did you build it?

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

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

Why did you choose to build Kap on Electron?

There were a number of reasons:

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

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

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

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

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

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

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

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

In what areas should Electron be improved?

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

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

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

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

What are your favorite things about Electron?

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

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

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

What's coming next in Kap?

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

What is Wulkano?

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

Any Electron tips that might be useful to other developers?

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

August 2016: Neue Apps

· Die Lesezeit beträgt 3 min

Hier sind die neuen Electron-Apps, die im August der Website hinzugefügt wurden.


Die Seite wurde mit neuen -Apps und Meetups durch Pull-Requests aus der Community aktualisiert. Sie können das Repository beobachten, um Benachrichtigungen über neue Erweiterungen zu erhalten oder wenn Sie nicht an allen der Änderungen der Seite interessiert sind, abonnieren Sie den Blog RSS-Feed.

Wenn Sie eine Electron-App erstellt haben oder ein Meeting veranstalten, erstellen Sie einen Pull-Request, um sie zur Seite hinzuzufügen und es wird die nächste Roundup.

Neue Apps

Code RPGifyRPG-Codierungsanwendung
PamFaxEine plattformübergreifende App zum Senden und Empfangen von Faxen
BlankUpMarkdown-Editor mit Übersichtlichkeit +1
RamboxKostenlose, Open-Source Nachrichten- und E-Mail-Anwendung, die verbreitete Web-Anwendungen in einer Oberfläche vereinigt
GordieDie beste App für ihre Kartensammlungen
Ionic CreatorErstelle erstaunliche mobile Apps, schneller
TwitchAlertsBehalten Sie Ihre Zuschauer mit schönen Warnungen und Benachrichtigungen zufrieden
MuseeksEin einfacher, sauberer und plattformübergreifender Musikplayer
SeaPigEin Konverter von Markdown zu HTML
GroupMeInoffizielle GroupMe App
MoeditorIhr Allzweck-Markdown-Editor
SoundnodeSoundnode App ist Soundcloud für den Desktop
QMUI WebQMUI Web Desktop ist eine Anwendung zur Verwaltung von Projekten, die auf dem QMUI Web Framework basiert
SvgsusOrganisieren, bereinigen und transformieren Sie Ihre SVGs
RammeInoffizielle Instagram-Desktop-App
InsomniaREST-API-Client
CorreoEine Menü-/Taskbar Gmail App für Windows, MacOS und Linux
KongDashDesktop-Client für Kong Admin API
Translation EditorEditor für Übersetzungsdateien für INTL ICU-Nachrichten (siehe formatjsio)
5EClient5EPlay CSGO Client
Theme JuiceLokale WordPress-Entwicklung leicht gemacht