A remote code execution vulnerability has been discovered in Google Chromium
that affects all recent versions of Electron. Any Electron app that accesses
remote content is vulnerable to this exploit, regardless of whether the
sandbox option is enabled.
We've published two new versions of electron 1.7.8 and 1.6.14,
both of which include a fix for this vulnerability. We urge all Electron
developers to update their apps to the latest stable version immediately:
npm i electron@latest --save-dev
To learn more about best practices for keeping your Electron apps secure,
see our security tutorial.
The electron npm package now includes a TypeScript definition file that provides detailed annotations of the entire Electron API. These annotations can improve your Electron development
experience even if you're writing vanilla JavaScript. Just
npm install electron to get up-to-date Electron typings in your project.
TypeScript is an open-source programming language created by Microsoft. It's
a superset of JavaScript that extends the language by adding support for
static types. The TypeScript community has grown quickly in recent years,
and TypeScript was ranked among the
most loved programming languages
in a recent Stack Overflow developer survey. TypeScript is described
as "JavaScript that scales", and teams at
GitHub,
Slack,
and
Microsoft
are all using it to write scalable Electron apps that are used
by millions of people.
TypeScript supports many of the newer language features in JavaScript like
classes, object destructuring, and async/await, but its real differentiating
feature is type annotations.
Declaring the input and output datatypes expected by your program can
reduce bugs by
helping you find errors at compile time, and the annotations can also serve
as a formal declaration of how your program works.
When libraries are written in vanilla Javascript, the types are often vaguely
defined as an afterthought when writing documentation. Functions can often
accept more types than what was documented, or a function can have invisible
constraints that are not documented, which can lead to runtime errors.
TypeScript solves this problem with definition files.
A TypeScript definition file describes all the functions of a library and its
expected input and output types. When library authors bundle a TypeScript
definition file with their published library, consumers of that library can
explore its API right inside their editor
and start using it right away, often without needing to consult the library's
documentation.
Many popular projects like
Angular,
Vue.js,
node-github
(and now Electron!) compile their own definition file and bundle it with their
published npm package. For projects that don't bundle their own definition file,
there is
DefinitelyTyped,
a third-party ecosystem of community-maintained definition files.
Starting at version 1.6.10, every release of Electron includes its own
TypeScript definition file. When you install the electron package from npm,
the electron.d.ts file is bundled automatically with the
installed package.
The safest way to install Electron is using an exact version number:
If you were already using third-party definitions like @types/electron
and @types/node, you should remove them from your Electron project to prevent
any collisions.
The definition file is derived from our
structured API documentation,
so it will always be consistent with Electron's API documentation.
Just install electron and you'll always get TypeScript definitions that are
up to date with the version of Electron you're using.
Once your editor is configured for TypeScript, you'll start to see more
context-aware behavior like autocomplete suggestions, inline method reference,
argument checking, and more.
If you're new to TypeScript and want to learn more, this
introductory video from Microsoft
provides a nice overview of why the language was created, how it works,
how to use it, and where it's headed.
There's also a
handbook
and a
playground
on the official TypeScript website.
Because TypeScript is a superset of JavaScript, your existing JavaScript code is
already valid TypeScript. This means you can gradually transition an existing
JavaScript project to TypeScript, sprinkling in new language features as needed.
When people use GitHub in their job or OSS activities, they tend to receive many notifications on a daily basis. As a way to subscribe to the notifications, GitHub provides email and web notifications. I used these for a couple of years, but I faced the following problems:
It's easy to overlook issues where I was mentioned, I commented, or I am watching.
I put some issues in a corner of my head to check later, but I sometimes forget about them.
To not forget issues, I keep many tabs open in my browser.
It's hard to check all issues that are related to me.
It's hard to grasp all of my team's activity.
I was spending a lot of time and energy trying to prevent those problems, so I decided to make an issue reader for GitHub to solve these problems efficiently, and started developing Jasper.
Jasper is used by developers, designers, and managers in several companies that are using GitHub.
Of course, some OSS developers also are using it.
And it is also used by some people at GitHub!
Once Jasper is configured, the following screen appears. From left to right, you can see "streams list", "issues list" and "issue body".
This "stream" is the core feature of Jasper. For example, if you want to see "issues that are assigned to @zeke in the electron/electron repository", you create the following stream:
repo:electron/electron assignee:zeke is:issue
After creating the stream and waiting for a few seconds, you can see the issues that meet the conditions.
Issues that are requested review by cat. But these are not reviewed yet.
is:pr reviewed-by:cat
Issues that are reviewed by cat
As you may have noticed by looking at these, streams can use GitHub's search queries.
For details on how to use streams and search queries, see the following URLs.
Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.
Apps can be built for Windows, Mac, and Linux platforms.
Electron is actively developed and has a large community.
These features enable rapid and simple desktop application development. It is awesome! If you have any product idea, you should consider using Electron by all means.
What are some challenges you've faced while developing Jasper?
I had a hard time figuring out the "stream" concept. At first I considered using GitHub's Notifications API. However I noticed that it does not support certain use cases. After that I considered using the Issues API and Pull Requests API, in addition to the Notification API. But it never became what I wanted. Then while thinking about various methods, I realized that polling GitHub's Search API would offer the most flexibility. 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.
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.
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.
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.
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:
We wanted a clean, lightweight, ad-free, open source torrent app
We wanted a torrent app with good streaming support
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?
There is a meme that Electron apps are "bloated" because they include the entire Chrome content module in every app. In some cases, this is partially true (an Electron app installer is usually ~40MB, where an OS-specific app installer is usually ~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.
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.)
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. The talk is especially useful if you're at the stage where you have a basic working app and you're trying to take it to the next level of polish and professionalism.
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.
The Electron 1.6.3 beta release contains initial support for the macOS Touch Bar.
The new Touch Bar API allows you to add buttons, labels, popovers, color
pickers, sliders, and spacers. These elements can be dynamically updated and
also emit events when they are interacted with.
This is the first release of this API so it will be evolving over the next
few Electron releases. Please check out the release notes for further updates
and open issues for any problems
or missing functionality.
You can install this version via npm install electron@beta and learn
more about it in the TouchBar
and BrowserWindow
Electron docs.
Big thanks to @MarshallOfSound for contributing this to Electron. 🎉
Below is an example of creating a simple slot machine game in the touch bar.
It demonstrates how to create a touch bar, style the items, associate it with a
window, handle button click events, and update the labels dynamically.
const{ app,BrowserWindow,TouchBar}=require('electron'); const{TouchBarButton,TouchBarLabel,TouchBarSpacer}=TouchBar; let spinning =false; // Reel labels const reel1 =newTouchBarLabel(); const reel2 =newTouchBarLabel(); const reel3 =newTouchBarLabel(); // Spin result label const result =newTouchBarLabel(); // Spin button const spin =newTouchBarButton({ label:'🎰 Spin', backgroundColor:'#7851A9', click:()=>{ // Ignore clicks if already spinning if(spinning){ return; } spinning =true; result.label=''; let timeout =10; const spinLength =4*1000;// 4 seconds const startTime =Date.now(); constspinReels=()=>{ updateReels(); if(Date.now()- startTime >= spinLength){ finishSpin(); }else{ // Slow down a bit on each spin timeout *=1.1; setTimeout(spinReels, timeout); } }; spinReels(); }, }); constgetRandomValue=()=>{ const values =['🍒','💎','7️⃣','🍊','🔔','⭐','🍇','🍀']; return values[Math.floor(Math.random()* values.length)]; }; constupdateReels=()=>{ reel1.label=getRandomValue(); reel2.label=getRandomValue(); reel3.label=getRandomValue(); }; constfinishSpin=()=>{ const uniqueValues =newSet([reel1.label, reel2.label, reel3.label]).size; if(uniqueValues ===1){ // All 3 values are the same result.label='💰 Jackpot!'; result.textColor='#FDFF00'; }elseif(uniqueValues ===2){ // 2 values are the same result.label='😍 Winner!'; result.textColor='#FDFF00'; }else{ // No values are the same result.label='🙁 Spin Again'; result.textColor=null; } spinning =false; }; const touchBar =newTouchBar([ spin, newTouchBarSpacer({size:'large'}), reel1, newTouchBarSpacer({size:'small'}), reel2, newTouchBarSpacer({size:'small'}), reel3, newTouchBarSpacer({size:'large'}), result, ]); letwindow; app.once('ready',()=>{ window=newBrowserWindow({ frame:false, titleBarStyle:'hidden-inset', width:200, height:200, backgroundColor:'#000', }); window.loadURL('about:blank'); window.setTouchBar(touchBar); });
Voltra 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.
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.
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.
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.
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.
In general setImmediate and requestIdleCallback have been super important tools for performing lots of processing while keeping the UI responsive. More specifically, distributing CPU-bound tasks into separate processes really helps to keep the user interface responsive. For example, we moved the actual audio context into a separate process, communicating with it over IPC to avoid potential interruptions from a busy UI.
The browser’s sandbox is too restricted for our app. 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.
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.
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.
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.
Electron is based on Google's open-source Chromium, a project that is not
necessarily designed to be used by other projects. This post introduces
how Chromium is built as a library for Electron's use, and how the build
system has evolved over the years.
The Chromium Embedded Framework (CEF) is a project that turns Chromium into
a library, and provides stable APIs based on Chromium's codebase. Very
early versions of Atom editor and NW.js used CEF.
To maintain a stable API, CEF hides all the details of Chromium
and wraps Chromium's APIs with its own interface. So when we needed to
access underlying Chromium APIs, like integrating Node.js into web pages, the
advantages of CEF became blockers.
So in the end both Electron and NW.js switched to using Chromium's APIs
directly.
Even though Chromium does not officially support outside projects, the codebase
is modular and it is easy to build a minimal browser based on Chromium. The core
module providing the browser interface is called Content Module.
To develop a project with Content Module, the easiest way is to build the
project as part of Chromium. This can be done by first checking out Chromium's
source code, and then adding the project to Chromium's DEPS file.
NW.js and very early versions of Electron are using this way for building.
The downside is, Chromium is a very large codebase and requires very powerful
machines to build. For normal laptops, that can take more than 5 hours.
So this greatly impacts the number of developers that can contribute to the
project, and it also makes development slower.
As a user of Content Module, Electron does not need to modify Chromium's code
under most cases, so an obvious way to improve the building of Electron is to
build Chromium as a shared library, and then link with it in Electron. In this
way developers no longer need to build all off Chromium when contributing to
Electron.
The libchromiumcontent project was created by
@aroben for this purpose. It builds the Content
Module of Chromium as a shared library, and then provides Chromium's headers
and prebuilt binaries for download. The code of the initial version of
libchromiumcontent can be found in this link.
The brightray project was also born as part of libchromiumcontent,
which provides a thin layer around Content Module.
By using libchromiumcontent and brightray together, developers can
quickly build a browser without getting into the details of building Chromium.
And it removes the requirement of a fast network and powerful machine for building
the project.
Apart from Electron, there were also other Chromium-based projects built in this
way, like the Breach browser.
On Windows there is a limitation of how many symbols one shared library can
export. As the codebase of Chromium grew, the number of symbols exported in
libchromiumcontent soon exceeded the limitation.
By taking this approach, though Chromium kept adding new exported symbols,
libchromiumcontent could still generate shared library files by stripping more
symbols.
Before talking about the next steps taken in libchromiumcontent, it is important
to introduce the concept of component build in Chromium first.
As a huge project, the linking step takes very long in Chromium when building.
Normally when a developer makes a small change, it can take 10 minutes to see the
final output. To solve this, Chromium introduced component build, which builds
each module in Chromium as separated shared libraries, so the time spent in the
final linking step becomes unnoticeable.
With Chromium continuing to grow, there were so many exported symbols in
Chromium that even the symbols of Content Module and Webkit were more than the
limitation. It was impossible to generate a usable shared library by simply
stripping symbols.
As introduced earlier there are two build modes in Chromium. As a result of
shipping raw binaries, we have to ship two different distributions of binaries
in libchromiumcontent. One is called static_library build, which includes
all static libraries of each module generated by the normal build of Chromium.
The other is shared_library, which includes all shared libraries of each
module generated by the component build.
In Electron, the Debug version is linked with the shared_library version of
libchromiumcontent, because it is small to download and takes little time
when linking the final executable. And the Release version of Electron is
linked with the static_library version of libchromiumcontent, so the compiler
can generate full symbols which are important for debugging, and the linker
can do much better optimization since it knows which object files are needed
and which are not.
So for normal development, developers only need to build the Debug version,
which does not require a good network or powerful machine. Though the Release
version then requires much better hardware to build, it can generate better
optimized binaries.
Being one of the largest projects in the world, most normal systems are not
suitable for building Chromium, and the Chromium team develops their own build
tools.
Earlier versions of Chromium were using gyp as a build system, but it suffers
from being slow, and its configuration file becomes hard to understand for complex
projects. After years of development, Chromium switched to gn as a
build system, which is much faster and has a clear architecture.
One of the improvements of gn is to introduce source_set, which represents
a group of object files. In gyp, each module was represented by either
static_library or shared_library, and for the normal build of Chromium,
each module generated a static library and they were linked together in the
final executable. By using gn, each module now only generates a bunch of
object files, and the final executable just links all the object files together,
so the intermediate static library files are no longer generated.
This improvement however made great trouble to libchromiumcontent, because
the intermediate static library files were actually needed by libchromiumcontent.
The second try was made by @alespergl to
produce custom static libraries from the list of object files.
It used a trick to first run a dummy build to collect a list of generated
object files, and then actually build the static libraries by feeding
gn with the list. It only made minimal changes to Chromium's source
code, and kept Electron's building architecture still.
As you can see, compared to building Electron as part of Chromium, building
Chromium as a library takes greater efforts and requires continuous
maintenance. However the latter removes the requirement of powerful hardware
to build Electron, thus enabling a much larger range of developers to build and
contribute to Electron. The effort is totally worth it.
This week we caught up with folks at Automattic to
talk about WordPress Desktop, an
open-source desktop client for managing WordPress content.
Everyone knows about WordPress, but what is 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!)
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.
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.
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.
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.
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.
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.
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.
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.
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.
Anyone who wants to share and update data over a p2p network. Data scientists, open data hackers, researchers, developers. We're super receptive to feedback if anyone has a cool use case we haven't thought of yet. You can drop by our Gitter Chat and ask us anything!
User accounts and metadata publishing. 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!
Why did you choose to build Dat Desktop on Electron?
Dat is built using Node.js, so it was a natural fit for our integration. 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.
What are some challenges you've faced while building Dat and Dat Desktop?
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.
We also ran into some general Electron infrastructure problems, including:
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.
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.
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?
This week we chatted with Felix Rieseberg, desktop engineer at Slack and maintainer of Ghost Desktop, an Electron client for the Ghost publishing platform.
Ghost is a fully open source, hackable platform for building and running a modern online publication. We power blogs, magazines and journalists from Zappos to Sky News.
What makes it different from other publishing platforms?
Ghost was founded in April 2013, after a very successful Kickstarter campaign to create a new platform focused solely on professional publishing. Our mission is to create the best open source tools for independent journalists and writers across the world, and have a real impact on the future of online media. It offers a simpler, more focussed experience: Our editor is designed solely around providing the best possible writing experience.
Compared to the all-time classic WordPress, it offers a simpler, more streamlined experience - it is easier to setup and maintain, comes with all important features out-of-the-box, and is dramatically faster. Compared to other online platforms, Ghost gives writers full ownership and control over their content, allows full customization, and enables authors to build a business around their publication.
This one is important to us: Ghost is an independent non-profit organisation. We build publishing tools for modern journalism & blogging because we believe freedom of speech is important. Our software is released under a free open source license, our business model is completely transparent, and our legal structure means that 100% of the money we make is reinvested into making Ghost better.
Ghost Desktop allows writers to manage multiple blogs at once - and to focus on their writing. Simple things like common writing shortcuts can't be realized in a browser, but are available in our desktop app. It allows other applications to communicate directly with the blog via deeplinks.
This year we're very excited to be dedicating our entire 10 person full-time Ghost team to helping grow three independent publications, along with $45,000 in resources toward their efforts. We're calling it Ghost for Journalism.
We've been building Ghost as the web's next great platform for independent publishers for about three and half years now, and we've now reached a really interesting inflection point. We started this journey to create a simple, well designed blogging platform which could be used by just about anyone. That was always going to be step one.
Long term, we want Ghost to be an incredible platform for the world's best journalism, and that means we need to build features to attract exactly those people. This year we're making a very conscious decision to focus on just that.
Why did you choose to build Ghost Desktop on Electron?
Ghost uses JavaScript and Node.js on both the backend and frontend, so being able to utilize the same technology and skillset enables our team to move faster, build more, and ultimately deliver a better experience. In addition, being able to share more than 95% of code between the macOS, Windows, and Linux version of the app allows us to focus on building a great core user experience, without having to maintain one code base for each platform.
What are some challenges you've faced while building Ghost Desktop?
Spellchecking is likely still one of the most difficult services offered - we could easily utilize one of the many online services, but correctly spellchecking text in multiple languages while guarding the privacy and autonomy of our users is not an easy task.
We would love to see Electron bring the operating system's native spellchecking capabilities to their apps. We're dreaming about a world in which an <input> field receives the same services as a NSTextView, but we are also intimately aware how difficult that is.
JavaScript is famous for being a vast ecosystem, involving countless tools and frameworks - but the convenience it affords us is hard to overstate. Building an app with Electron is only slightly harder than building a web app, which is an amazing feat.
Ghost Desktop is also an ongoing project - we're pretty far from being done. We have been talking for a while about bringing a full offline mode to our users, and we're getting fairly close. Other notable work areas are the extension and integration with other text editing apps (like Word or Atom), ultimately allowing people to write posts using their favorite tools. In general, once we've shipped the offline mode feature, we're looking for deeper integration with the operating system. If that sounds interesting to you, join us!
