A new major version of Electron is in the works, and with it some changes to our versioning strategy. As of version 2.0.0, Electron will strictly adhere to Semantic Versioning.
This change means you'll see the major version bump more often, and it will usually be a major update to Chromium. Patch releases will also be more stable, as they will now only contain bug fixes with no new features.
Major 版本增量
Chromium 版本更新
Node.js 重大版本更新
Electron 突破性 API 变更
Minor 版本增量
Node.js 次要版本更新
Electron 无突破性 API 变更
Patch 版本增量
Node.js patch 版本更新
修复相关的 chromium 补丁
Electron bug 修复
Because Electron's semver ranges will now be more meaningful, we recommend installing Electron using npm's default --save-dev flag, which will prefix your version with ^, keeping you safely up to date with minor and patch updates:
npm install --save-dev electron
For developers interested only in bug fixes, you should use the tilde semver prefix e.g. ~2.0.0, which which will never introduce new features, only fixes to improve stability.
Electron has a new website at electronjs.org! We've replaced our static Jekyll site with a Node.js webserver, giving us flexibility to internationalize the site and paving the way for more exciting new features.
We've begun the process of internationalizing the website with the goal of making Electron app development accessible to a global audience of developers. We're using a localization platform called Crowdin that integrates with GitHub, opening and updating pull requests automatically as content is translated into different languages.
Though we've been working quietly on this effort so far, over 75 Electron community members have already discovered the project organically and joined in the effort to internationalize the website and translate Electron's docs into over 20 languages. We are seeing daily contributions from people all over the world, with translations for languages like French, Vietnamese, Indonesian, and Chinese leading the way.
If you're multilingual and interested in helping translate Electron's docs and website, visit the electron/electron-i18n repo, or jump right into translating on Crowdin, where you can sign in using your GitHub account.
There are currently 21 languages enabled for the Electron project on Crowdin. Adding support for more languages is easy, so if you're interested in helping translate but you don't see your language listed, let us know and we'll enable it.
As of today, any Electron app can easily have its own page on the Electron site. For a few examples, check out Etcher, 1Clipboard, or GraphQL Playground, pictured here on the Japanese version of the site:
There are some incredible Electron apps out there, but they're not always easy to find, and not every developer has the time or resources to build a proper website to market and distribute their app.
Using just a PNG icon file and a small amount of app metadata, we're able to collect a lot of information about a given app. Using data collected from GitHub, app pages can now display screenshots, download links, versions, release notes, and READMEs for every app that has a public repository. Using a color palette extracted from each app's icon, we can produce bold and accessible colors to give each app page some visual distinction.
The Homebrew package manager for macOS has a subcommand called cask that makes it easy to install desktop apps using a single command in your terminal, like brew cask install atom.
We've begun collecting Homebrew cask names for popular Electron apps and are now displaying the installation command (for macOS visitors) on every app page that has a cask:
We've moved the site from electron.atom.io to a new domain: electronjs.org.
The Electron project was born inside Atom, GitHub's open-source text editor built on web technologies. Electron was originally called atom-shell. Atom was the first app to use it, but it didn't take long for folks to realize that this magical Chromium + Node runtime could be used for all kinds of different applications. When companies like Microsoft and Slack started to make use of atom-shell, it became clear that the project needed a new name.
And so "Electron" was born. In early 2016, GitHub assembled a new team to focus specifically on Electron development and maintenance, apart from Atom. In the time since, Electron has been adopted by thousands of app developers, and is now depended on by many large companies, many of which have Electron teams of their own.
Supporting GitHub's Electron projects like Atom and GitHub Desktop is still a priority for our team, but by moving to a new domain we hope to help clarify the technical distinction between Atom and Electron.
The previous Electron website was built with Jekyll, the popular Ruby-based static site generator. Jekyll is a great tool for building static websites, but the website had started to outgrow it. We wanted more dynamic capabilities like proper redirects and dynamic content rendering, so a Node.js server was the obvious choice.
The Electron ecosystem includes projects with components written in many different programming languages, from Python to C++ to Bash. But JavaScript is foundational to Electron, and it's the language used most in our community.
By migrating the website from Ruby to Node.js, we aim to lower the barrier to entry for people wishing to contribute to the website.
If you've got Node.js (8 or higher) and git installed on your system, you can easily get the site running locally:
git clone https://github.com/electron/electronjs.org cd electronjs.org npm install npm run dev
The new website is hosted on Heroku. We use deployment pipelines and the Review Apps feature, which automatically creates a running copy of the app for every pull request. This makes it easy for reviewers to view the actual effects of a pull request on a live copy of the site.
We'd like to give special thanks to all the folks around the world who have contributed their own time and energy to help improve Electron. The passion of the open-source community has helped immeasurably in making Electron a success. Thank you!
electron npm 包现在包含一个 TypeScript 定义文件，提供整个Electron API的详细注释。 这些注释可以改进您的 Electron 开发 感受 ，即使您正在编写原版JavaScript 只需要运行 npm install electron 就可以在您的项目中获得最新的 Electron 类型注释。
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. 首先，我考虑使用 GitHub 的 通知 API。 However I noticed that it does not support certain use cases. 此后，除了通知API外，我考虑使用 问题 API 和 合并请求 API。 But it never became what I wanted. 然后在思考各种方法时，我认识到轮询GitHub的 搜索 API 将提供最大的灵活性。 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?
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. 如果你处于一个基本的工作应用程序的阶段，并且你正在试图将它带到一个更高水平的打造和专业水平上，这个话尤其有用。
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 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.
一般来说， 设置立即 和 requestIdleCallback 已经成为在保持界面响应的同时进行大量处理的超重要工具。 More specifically, distributing CPU-bound tasks into separate processes really helps to keep the user interface responsive. 例如，我们将实际音频环境移动到一个单独的过程中。 通过 IPC 与它通信，以避免忙碌用户界面可能出现的中断。
浏览器的沙盒对我们的应用过于限制。 但我们也正在开发一个 web 播放器。 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.
libchromiumcontent 项目是由 @aroben 为此目的创建的。 It builds the Content Module of Chromium as a shared library, and then provides Chromium's headers and prebuilt binaries for download. 它构建Chromium的内容 模块作为共享的库，然后提供Chromium的标题 并预建二进制二进制文件供下载。
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.
第二次尝试由 @alespergll 到 从对象文件列表中生成自定义静态库。 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.
2015 年末,我们通过 Calypso 重建了 WordPress.com 站点, Calypso 是一个开源的使用 React 开发的现代化 JavaScript 应用. 我们开始研究 Electron，并且对 Calypso 进行了一些更改，使其能够在本地运行。 It was a compelling experience and we thought there was a lot of value in developing it further.
