blog.atom.io

Atom 1.20

2017-09-12T00:00:00+00:00

Atom 1.20 is available on the stable channel today and features numerous improvements in the github, find-and-replace, and language-php packages.

Git Integration Improvements

The way diff views get opened was reworked resulting in pending pane support and multiple simultaneous diff views:

We’ve also enabled composing commit messages in the main editor for those not into the whole brevity thing.

Find and Replace

Context lines are now optionally displayed with Find in Project results. You can set the number of available lines before and after matches in the package settings and modify their display inline when looking at the results.

Other Enhancements

Dozens of fixes for PHP grammar support were made in the language-php package.
CSS autocomplete now supports PostCSS.
Support has been added to bracket-matcher for code embedded in strings.
We’ve added an API for observing dock visibility.

Don’t forget to check out all the other improvements shipping with this version in the release notes! :memo:

Atom 1.21 Beta

Today’s beta release of Atom 1.21 features Language Server Protocol support, the first of many deeper language integration features, which we’re calling Atom IDE. It also includes a new, unified filesystem watcher API and build status indicators.

Language Server Integration and Atom IDE

Atom’s been straddling the fence between text editor and IDE for years. We’ve come to believe that a benefit of Atom’s hyper-modular architecture is that users who want more IDE features can have them without affecting the experience of those who don’t. Atom 1.21 takes the first step down this path with Language Server Protocol support and ready-made integrations with five existing language servers. Check out the Atom IDE post for details.

Filesystem Watcher API

Atom and its ecosystem of packages use a number of npm packages to watch the file system for changes. As we worked on the Git integration and Language Server support this patchwork approach left us wanting something simpler and more reliable across platforms. Atom 1.21 includes the first version of this new API. While the underlying implementation is still under development the API itself is stable and ready for use and feedback from package authors.

More GitHub PR Events and Build Status

The GitHub integration continues to get richer in this release. We’ve added new PR timeline events and PR build status.

Other Notable Changes

MacOS native tabs are now supported.
We restored Atom’s ASAR archive to improve performance in several scenarios, most notably installation on Windows.
Lots of language-specific grammar improvements were made, including the addition of TypeScript.

There are many more fixes and enhancements detailed in the release notes.

Get all these improvements today by joining the Atom Beta Channel!

Introducing Atom-IDE

2017-09-12T00:00:00+00:00

GitHub, in collaboration with Facebook, are pleased to announce the launch of Atom-IDE - a set of optional packages to bring IDE-like functionality to Atom.

The start of this journey includes smarter context-aware auto-completion as well as a host of code navigation features such as an outline view, go to definition, find all references as well as other useful functions such as hover-to-reveal information, errors and warnings (diagnostics) and document formatting.

Our initial release includes packages for TypeScript, Flow, JavaScript, Java, C# and PHP that utilize the power of language servers to provide deep syntactical analysis of your code and projects. The language server protocol is being adopted by a number of organizations including Microsoft, Eclipse, Sourcegraph, Palantir, Red Hat, Facebook and now GitHub too!

Get started

We strongly recommended you use Atom Beta 1.21 as it includes the necessary file monitoring and process control to ensure the underlying language servers are running properly.

You’ll need to install at least two packages - the user interface for Atom IDE and a package that support the language you wish to use:

Bring up Atom’s Install Packages dialog (Settings View: Install Packages and Themes)
Search for and install the atom-ide-ui package to bring in the IDE user interface
Install the IDE language support you need (e.g. ide-typescript) - a summary of the ones available at launch include:

TypeScript & JavaScript (ide-typescript)

The ide-typescript package takes advantage of the Microsoft TypeScript server wrapped up in a language server protocol thanks to the work of the team at SourceGraph. While targeted at TypeScript it also works great with JavaScript providing you with autocompletion, document outlines, diagnostics and errors, etc.

Flow (ide-flowtype)

Our good friends over at Facebook have published ide-flowtype to bring the power of the Flow type annotation system to Atom.

C# (ide-csharp)

One of the earliest examples of a language server was OmniSharp for the C# language. By taking advantage of the node-omnisharp package we are able to bring many IDE-like features into Atom for C# via ide-csharp.

Java (ide-java)

The Eclipse foundation and Red Hat have been a big proponent of language servers and the Java package shows! You will need a Java 8 runtime installed to get going but then can enjoy much richer editor facilities. Check out ide-java.

PHP (ide-php)

The ide-php utilizes a PHP language server by FelixFBecker to provide support for the PHP scripting language. (Requires the PHP 7 runtime installed.)

Using Atom-IDE

Each of the IDE packages expose a selection of functionality that is dependent on the underlying language server and is activated when you open files it supports. (Some take a few seconds to start-up and others like ide-java and ide-php will take a short while on first open to download the language server itself.)

Here’s a quick summary of how these features are exposed within Atom IDE:

Autocomplete

Autocomplete is enabled in all the ide packages we are shipping today. Start typing to get improved results. Some providers may require you to manually trigger autocompletion by pressing CtrlSpace for performance reasons.

Diagnostics

You can see diagnostics by clicking the red exclamation mark and yellow warning triangle at the bottom left of your Atom window. This will open the new Diagnostics pane that shows you the errors and warnings and allow you to click them to jump right to that location in the code. You will also see indicators to the left of line numbers in the editor itself.

Find all references

Position the text cursor in the class or variable you are interested in then activate Find all references either from the right-mouse button menu or Find References: Activate from the command palette.

Some providers allow you to reformat the document. Simply select Code Format: Format Code from the command palette.

Formatting

Go to definition

Ctrl click on a class or variable reference to be taken directly to where it is defined within your project.

Hover

Hover the mouse pointer over a type or other supported object and you can see some additional information relating to it.

Outline view

Many providers let you see a tree-based outline view of the current document which you can search and then click to go right to that area of code. You can toggle the new Outline View from the View menu or the Outline View: Toggle command.

Reference highlighting

Some providers let you see immediate references to the variable or object you are working on. Positioning your text cursor within that variable can highlight other references instantly.

Future plans

This is just the start of our journey. With the help of our community, we plan to expand the number of languages that Atom-IDE can support and make it possible for you to run and edit applications, making Atom-IDE a true IDE.

We hope to see future language support for the great languages out there including Rust, Go, Python, etc.

If a language server exists for your favorite language it is incredibly easy to create your own Atom-IDE package that takes advantage of it by using our atom-languageclient npm library that provides common automatic wire-up of the major features as well as helper tools such as downloading support files and conversions.

Atom 1.19

2017-08-08T00:00:00+00:00

Today’s Atom 1.19 release offers improved performance and responsiveness via major architectural updates and an upgrade to Electron 1.6.9.

Improved Responsiveness and Memory Usage

Atom 1.19 introduces a native C++ text buffer implementation that improves responsiveness and memory usage. Saving a file now happens asynchronously without blocking the UI, so that you can move smoothly from one task to the next. Large files now consume less memory, marking another step in our continued drive to provide an excellent experience for all files big and small.

Editor Rendering Layer Rewrite

This release includes a full rewrite of the text editor’s rendering layer. We revisited all of our DOM layout and script interactions with the goal of improving performance, reducing complexity, and taking advantage of new APIs such as intersection observers, resize observers, and CSS containment boundaries. We did an in-depth post about it last month.

Other Notable Changes and Fixes

Don’t forget to check out all the other improvements shipping with this version in the release notes! :memo:

Atom 1.20 Beta

Atom 1.20, released on the beta channel today, features numerous improvements in the github, find-and-replace, and language-php packages.

Git Integration Improvements

The way diff views get opened was reworked resulting in pending pane support and multiple simultaneous diff views:

We’ve also enabled composing commit messages in the main editor for those not into the whole brevity thing.

Find and Replace

Other Enhancements

Dozens of fixes for PHP grammar support were made in the language-php package.
Support has been added to bracket-matcher for code embedded in strings.
We’ve added an API for observing dock visibility.

There are many more details in the release notes.

Get all these improvements today by joining the Atom Beta Channel!

A new approach to text rendering

2017-06-22T00:00:00+00:00

In Atom 1.19, we’re landing a complete rewrite of the text editor’s DOM interaction layer that improves rendering performance and simplifies the code. Prompted by the availability of some valuable new DOM APIs with the upgrade to Electron 1.6, we decided to start over from the beginning and take a critical look at the structure and performance of every aspect of our DOM interaction. You should observe the biggest difference when scrolling. Here is a typical frame after scrolling by 15 lines before and after the rewrite:

Before: Scrolling 15 lines in Atom 1.18 (~30ms):

After: Scrolling 15 lines in Atom 1.19 (~16ms):

About a 50% improvement, give or take some noise on any given frame.

You should also experience more responsive typing. Here’s a before-and-after for a typical frame following a character insertion:

Before: Rendering a character insertion in Atom 1.18 (~8ms):

After: Rendering a character insertion in Atom 1.19 (~5.7ms):

In this case the speedup is around 30%. We’re seeing similar improvements for other common updates such as cursor and selection movements.

In the rest of this post, we’ll share some highlights from this rewrite to give you a sense of how things have changed.

Back to a virtual DOM

Building a text editor on top of the DOM requires a disciplined interaction with the document. To minimize overhead for style recalculation and layout, we only render the lines that are actually visible on screen in a given frame. In addition, we use absolutely-positioned elements to render cursors, selections, and overlays like the autocomplete menu. This requires us to measure horizontal character positions directly from rendered content in order to support mixed font weights, variable-width characters, and ligatures, which means we need to break each frame into a pre- and post-measurement update. We also recycle the nodes making up the lines and line numbers to minimize pressure on the garbage collector. For all these reasons and more, we deliberately stuck to a rather low level of abstraction for the previous editor implementation.

Since that time, however, we have developed a small, focused library for DOM manipulation called Etch that was largely inspired by our experience with Atom’s text editor. We’ve been using it in many of Atom’s bundled packages for a while now, but this is the first time we have used it in core. The main idea behind Etch is to offer a React-like abstraction based on tree diffing for updating the DOM, but with a strong focus on encapsulation and clean interoperation with other libraries in a multi-tenant document. Mixing manual DOM manipulation with declarative code feels very natural in Etch, and while JSX is supported, Etch is also designed to be used without a transpiler.

Using Etch, we switched the majority of our manual DOM manipulation code over to a virtual DOM and removed a ton of boilerplate in the process. We continue to construct lines and line numbers manually with imperative DOM APIs to obtain the best possible performance for our most intensive update paths and to recycle DOM nodes.

Intersection and resize observers

As we mentioned earlier, we only render the visible lines in any given frame. This means we need to measure the dimensions of the editor and the height of our lines, and we need to respond when these dimensions change due to font size changes or changes to the document’s structure. If we decide to re-measure and the editor isn’t currently visible, we need to wait until it becomes visible again before performing our measurements.

Prior to Electron 1.6, however, there weren’t a lot of tools for detecting these kinds of changes to the document. A simple solution would have been to expose methods on the editor that could be manually called to update dimensions, but that would have been annoying and error-prone for package authors that want to use editors outside of Atom’s panes. So unfortunately, the best solution we could come up with prior to Atom 1.19 was a global MutationObserver that scheduled lightweight measurements whenever the document changed. While that approach worked and we were never able to measure a serious performance consequence, globally associating any amount of work with DOM manipulation made us uneasy, and we were anxious for better APIs that could enable a more targeted solution.

With improvements to the IntersectionObserver API and the introduction of the ResizeObserver API behind a flag in Chrome 56, however, we finally have a sane approach to detecting changes to editor dimensions and visibility in a fine-grained way. We now use intersection observers to detect when editors are hidden and shown and resize observers to detect when editors change size. We’ve deleted the global mutation observer and any potential performance tax it was imposing on DOM manipulation.

CSS containment

Another valuable feature that’s become available since we last worked on editor rendering is CSS containment declarations, which allows us to tell the browser that the contents of a particular element don’t affect the layout and painting of external elements. This leads to the browser performing work on smaller subtrees of the document when elements are updated.

In our rewrite, we used contain: strict on as many elements as possible, basically whenever we were able to assign an explicit height and width on an element. For example, we break the lines and line numbers into explicitly-sized tiles that contain six lines each, then apply strict containment to the tiles. This means that for a given edit, only a subset of the lines in the editor will be invalidated.

New decoration APIs

Soon after getting the rewritten editor into a usable state, we learned that our changes ran afoul of some monkey-patching being performed in the vim-mode-plus and pigments packages. Rather than having them port their monkey-patches to the new rendering system, we decided to add support for what they were trying to achieve via official decoration APIs.

To support the pigments package, which changes the foreground and background color of CSS color expressions, we added text decorations. These are similar to highlight decorations, in that you associate a class or inline style with a marker’s range, but text decorations are rendered by injecting spans around runs of text that intersect the marked range. This makes it easy to apply arbitrary styling such as changing the foreground and background colors or font weight. However, font size won’t work for now because we don’t yet support variable line heights in the editor.

For vim-mode-plus, we added cursor decorations, which allow you to apply classes or inline styles to Atom’s cursors by decorating a cursor’s associated marker. You can also create and style your own synthetic cursors by passing a non-selection marker, which might be useful for packages that implement pair programming.

Next steps

Rendering has improved a lot and things should feel smoother, but there’s still room for improvement. Let’s take another look at a typical frame when scrolling downward by half a screen (around 15 lines).

One frustrating component of the above breakdown is the time spent recalculating styles. At this point, it looks like the only way to solve this within the current paradigm is to use CSS less and reduce the number of selectors in the application, but that’s going to be a hard fought battle given the huge number of themes in the ecosystem. Another option is to skip CSS entirely for the purposes of applying syntax highlights and use a proprietary system to render inline styles, but that would raise the barrier to entry for theme developers and break Atom’s huge ecosystem of existing themes. Instead, it’s looking like our best option might be to continue to support CSS selectors for theming, but to implement our own custom code path for matching them against nodes in our syntax tree. This would allow us to render fewer overall nodes and reuse work across nodes with a common syntactic ancestry.

But if we’re going so far as to bypass Chrome’s CSS engine, maybe we should try to bypass the DOM entirely. If you look at the above flame graph, a huge percentage of our frame time is going to DOM manipulation (highlighted in yellow) and DOM-related overhead (highlighted in purple). If we could eliminate this work, rendering a frame would only involve executing some domain-specific update logic and painting, which could be fraction of the current time. Next time we cycle back to this area of the code base, we’d like to explore using the canvas API to render the most intensive parts of the editor such as the lines and line numbers. Now that our text storage has been ported to C++ (which also landed in 1.19), we could even move the rendering code to C++ (along with the DisplayLayer’s spatial index) to minimize overhead even further.

For now, however, we need to move on to improving other areas of the system. If anyone reading this is interested in contributing and would like to give canvas a shot, please reach out to us on Slack or open an issue and we’d be keen to facilitate if you’re serious.

Atom 1.18

2017-06-13T00:00:00+00:00

Today’s Atom 1.18 release introduces Git and GitHub integration right inside your editor!

Git and GitHub Integration

We’re thrilled to be shipping rich integration with Git and GitHub in Atom 1.18! This is merely the first release but we’re excited about what it already brings to the editor. Check out posts here and on the GitHub engineering blog for more details. Or get a peek at some of the features on github.atom.io.

More Improvements

Don’t forget to check out all the other improvements shipping with this version in the release notes! :memo:

Atom 1.19 Beta

Atom 1.19 includes two major architectural updates and an update to Electron 1.6.9.

Native Text Buffer

Atom 1.19 introduces an implementation of Atom’s underlying text buffer in native C++. File saves are now asynchronous and will never block the UI. Memory usage for large files has been reduced.

Editor Rendering Layer Rewrite

Other Notable Changes and Fixes

There are many more details in the release notes.

Get all these improvements today by joining the Atom Beta Channel!

Docks Deep Dive

2017-05-23T00:00:00+00:00

This is a guest post written by Facebook’s Nuclide team member @matthewwithanm. He tells the story how the new docks got introduced to Atom and how package authors can make great use of them.

One of the things that the Nuclide team has always really loved about Atom is how it lets us extend and experiment with UI. Tools like Outline View, Console, Diagnostics, and the Debugger all need custom UI and, up until recently, their natural home was Atom’s Panels. Located at the edges of the window, panels are a great place for these kind of graphical tools but they have a couple of issues.

They stack, and can easily end up consuming a lot of valuable screen real estate.
Though most panels need to be closable, they each have their own UI for it.

In addition to these UX issues, they also require extra work from developers. For example, the Atom tree view had special logic that allowed users to show it on either the left or right side of their screen. Anybody wanting similar functionality for their package had to duplicate this logic.

To get around these limitations, Nuclide introduced collapsible pane containers—now called “docks”—at the edges of the window. Each dock can hold multiple items, which users can reposition in order to get their layout of choice. Thanks to help from the Atom team, we’ve contributed this functionality upstream for Atom 1.17. We’re super excited for the community to start taking advantage of them but, before you do, we figured we should tell you how they work 😊

Opening Items in Docks

At their core, docks are just new places that workspace items can go in. What’s a workspace item? The most common example is a text editor, but there are plenty of others: the settings view, search results, and welcome guide are all workspace items. Knowing that, it probably won’t be too surprising that we haven’t added much new API to Atom—instead, we’ve built on the APIs that already existed for managing these items. The most basic of these is atom.workspace.open(). Traditionally, this method has accepted a URL which Atom then associates with a view. This functionality maintains intact, but you can also open an item directly now:

const item = {
  element: document.createElement('div'),
  getTitle: () => 'My Awesome Item',
  getURI: () => 'atom://my-package/my-item',
  getDefaultLocation: () => 'right'
};
atom.workspace.open(item);

You’ve probably noticed the item’s getDefaultLocation() method. This is a new (optional) method that returns one of 'right', 'left', 'bottom', or 'center' depending on where you—the package author—want your view to appear initially. The difference between this and something like atom.workspace.addRightPanel() is that it’s only a suggestion; if a user moves the item to a new location, their preference will be remembered and used the next time an item with the same URI is opened. Of course, sometimes you may want to limit the locations that users can move your item to. For that, you can add a getAllowedLocations() method to your item:

  getAllowedLocations: () => ['left', 'right']

Other newly supported item methods include getPreferredWidth() and getPreferredHeight(), which determine the initial size of the dock.

Toggling Items

When you have multiple items sharing a single dock, toggling an item isn’t as straightforward as just open()ing and destroy()ing it. If your item isn’t visible, it should be made visible, but if it is, the entire dock should be hidden. It can be tough to get this logic right (not to mention a pain to have to implement it every time), so we added a new API for doing it: atom.workspace.toggle(). Just pass it an item or URI and it’ll do the rest. In Nuclide, we use this to create “toggle” commands:

atom.commands.add(
  'atom-workspace',
  'my-package:toggle',
  () => {
    atom.workspace.toggle(item);
  },
);

If the item is visible and in a dock, the dock will be collapsed; if it’s in the workspace center, the item will be destroyed. Like open(), toggle() accepts URIs as well as items. This is useful for when you can have multiple copies of your item in the workspace—for example, if you want to allow users to split your item and create a duplicate. Instead of having to keep track of the items yourself, just make sure their getURI() methods return the same URI. Passing that URI to toggle() will Do The Right Thing.

Digging Deeper

So far we’ve just looked at the API for dealing with items. In general, they work like this: items declare things about how they want to be displayed and Atom (taking into account user preferences), displays them. This relationship is really important because it gives users more control over their workspace and Atom the ability to make innovations without requiring any updates from you.

However, for those occasions where you just can’t handle giving up control, there are imperative APIs for interacting directly with docks: atom.workspace.getLeftDock(), atom.workspace.getRightDock(), and (you guessed it) atom.workspace.getBottomDock(). The returned object allows direct control over the dock with methods like show(), hide(), and toggle(), as well as manipulation of its panes and pane items via methods like observePanes() and getActivePaneItem(). A similar object, which represents the center of the workspace and normally houses your text editors, is returned by atom.workspace.getCenter().

Conclusion

Docks have been an important addition to Nuclide. Not only have they made the experience more consistent, but they’ve also given developers here at Facebook more control over their editor’s real estate. We’re really excited to have been able to collaborate with the Atom team to bring this feature to everybody…and even more excited to see what you build with it! Why not get started now by checking out the Active Editor Info tutorial?

Git and GitHub Integration comes to Atom

2017-05-16T00:00:00+00:00

A text editor is at the core of the developer’s toolbox, but many other useful pieces of software coexist along with it, such as Git and GitHub. Starting today, Atom adds Git and GitHub integration directly in Atom via the GitHub package. This is a new core package included with Atom and is available right now in today’s 1.18 beta release. Be sure to check out github.atom.io for more information!

Git goes Atomic

Git is an essential part of many developers’ workflows, but dropping to the command line or another GUI application in the middle of writing code can take you out of the flow. The GitHub package provides a dock item and status bar widgets to give you access to some of the most common Git operations without leaving your editor. Stage changes and create commits, create and switch branches, and even resolve merge conflicts directly in Atom’s UI.

GitHub breaks out of the browser

If you use GitHub to share and collaborate on code, pull requests are an integral part of your workflow. The GitHub package displays the pull request associated with your current branch in the sidebar, and can display a detailed view of any issue or pull request right alongside your code.

Integration with GitHub is still very early stage, and we’ve labeled it as a “preview;” we hope to have improvements in this area for you soon.

So much more to come

Today’s release of the GitHub package marks the first step toward realizing its core goal: reduce context switching and increase productivity by bringing core workflow tools directly into your editor. @kuychaco, @smashwilson, and @BinaryMuse are hard at work on this, and we hope to have improvements and new features to share with you soon.

The GitHub package is available in today’s 1.18 beta release. Check it out and tell us what you think by dropping us a line in Slack or by creating an issue in the package’s repository on GitHub! And if you’re curious about how we implemented our Git integration, be sure to checkout our post on the GitHub Engineering blog.

Atom 1.17

2017-05-16T00:00:00+00:00

Today’s Atom 1.17 release comes with the introduction of docks, faster startup time with V8 snapshots, farewell to jQuery and other improvements.

Introducing Docks

Docks are an extension of Atom’s pane system designed to hold interface elements that you want to quickly toggle into and out of view. This is a common pattern for tool panels such as the tree view, debugger controls, terminals, consoles, regex railroad diagrams, etc.

Docks provide a high-level API that makes it simpler for package authors to implement this kind of easy-to-toggle panel and give users a lot more control over how their panels are arranged. Just like panes in the center of the Atom workspace, panes within docks can be split and resized in arbitrary ways, and since dock panes can contain multiple tabbed items, it’s now possible for tool panels written by different package authors to coherently share screen real estate at the periphery of the workspace.

For now, the tree-view is the only part of the default Atom UI that will make use of docks, but we’d love for package authors to start experimenting during the beta period. At the API level, you add items to docks in much the same way you’ve always added items to the center of the workspace, via atom.workspace.open. Dock items are just like regular pane items, but they also need implement the getDefaultLocation() method and return 'left', 'right', or 'bottom' rather than the default value of 'center'. We’ve also made it possible to pass items directly to atom.workspace.open instead of forcing you to specify a URI and custom opener. So, to summarize, a minimal code snippet that adds an item to a dock looks like the following.

const item = {
  element: document.createElement('div'),
  getTitle () { return 'My Fabulous Div' },
  getDefaultLocation () { return 'left' },
}
atom.workspace.open(item)

Also check out this tree-view PR for an example of converting a panel to a dock item. One major thing worth noting is that panes and items within docks are now included in various global workspace methods such as getActivePaneItem, observeActivePane, etc. If you want to limit your scope to just the center of the workspace as was the case before docks existed, you’ll need to interact with the new WorkspaceCenter class, available via atom.workspace.getCenter().

A huge thanks to Facebook’s Nuclide team for developing docks and taking the time to upstream this feature into the core of Atom.

Faster startup time with V8 snapshots

We’ve dramatically reduced window load times by using V8 custom startup snapshots to shift work that was happening on window startup to happen during Atom’s build instead.

Farewell to jQuery

We have now removed jQuery completely as a dependency of Atom’s bundled packages, which will result in improved performance by avoiding some forced reflows during DOM manipulation. Here are some of the PRs.

Other Improvements

Fix for middle-mouse-button paste on Linux. Thanks to @dietmar for fixing a long-standing issue!
Restore the Atom environment when adding project folders to a fresh window

Don’t forget to check out all the other improvements shipping with this version in the release notes! :memo:

Atom 1.18 Beta

Git and GitHub Integration

We’re thrilled to be shipping rich integration with Git and GitHub in Atom 1.18! This is merely the first release but we’re excited about what it already brings to the editor. Check out posts here and on the GitHub engineering blog for more details. Our very own Phil Haack is putting it through its paces in a talk at GitHub Satellite next week in London!

More Improvements

There are many more details in the release notes.

Get all these improvements today by joining the Atom Beta Channel!

Improving Startup Time

2017-04-18T00:00:00+00:00

Over the last months, the Atom team has been working hard on improving one of the aspects of the editor our users care about the most: startup time. We will first provide the reader with some background about why reducing startup time is a non-trivial task, then illustrate the optimizations we have shipped in Atom 1.17 (currently in beta) and, finally, describe what other improvements to expect in the future.

For a long time, we’ve been wanting to have more control over Atom’s startup code. In November of last year, as part of this effort, we created an in-depth issue that carefully described where time was spent when opening an Atom window. We realized that many of the operations happening during startup were redundant and that we could use the information we knew at build-time to minimize their cost.

V8 snapshots

V8 snapshots allow Electron applications to execute some arbitrary JavaScript code and output a binary file containing a serialized heap with all the data that is left in memory after running a GC at the end of the provided script.

This perfectly suits the startup scenario described above because snapshots can be used to eagerly perform work when building Atom; then, at runtime, we can simply reuse the JavaScript objects that were created as part of the snapshotting phase, thus reducing the amount of work needed to load a window. The tricky part of using this technology, however, is that the code is executed in a bare V8 context. In other words, it only allows us to run plain JavaScript code and does not provide access to native modules, Node/Electron APIs or DOM manipulation.

While this constraint was remarkably restrictive, we still saw a great potential in using snapshots as a tool to make our startup situation better, and so we started experimenting with different approaches that could allow us to use them in Atom. One of them was to try using V8 native APIs to load Node/Electron into the snapshot context so that we could work around the limitation of not being able to use modules like path, fs, etc. This turned out to be non-trivial though, especially because some of the modules that Electron and Node access when they boot up rely on native code, which is very difficult to deal with in snapshots.

Therefore, in order to circumvent some of the restrictions discussed above, we started exploring a simpler approach. Specifically, we decided to defer the usage of forbidden APIs until runtime so that all the other computation could still happen as part of the snapshot script. To do so, we set out to create a tool that automated this process without compromising code readability: electron-link.

electron-link

electron-link is a node module that takes a JavaScript file (typically the entry point of an application) and a list of modules that need to be required lazily (see Atom’s build scripts for an example). Then, starting from that file, it traverses the entire require graph and replaces all the forbidden require calls in each file with a function that will be called at runtime. The output is a single script containing the code for all the modules reachable from the entry point. This file can be then supplied to mksnapshot to generate the snapshot blob, which will be eventually used by Electron.

electron-link can also determine whether a module can be snapshotted or not. For instance, the following code can be snapshotted:

const path = require('path')

module.exports = function () {
  return path.join('a', 'b', 'c')
}

And generates the following code:

let path;
function get_path () {
  return path || path = require('path');
}

module.exports = function () {
  return get_path().join('a', 'b', 'c')
}

You can notice that the above code is valid because the forbidden module (i.e. path) is used inside a function that doesn’t get called when requiring the script. On the other hand, when trying to process the following code, electron-link will throw an error because it is trying to access a forbidden module right when it gets required:

const path = require('path')

module.exports = path.join('a', 'b', 'c')

Being a tool based on static analysis, however, electron-link is unable to detect all the cases where a piece of code can’t be included in a snapshot. Therefore, as part of the build process, Atom will run the generated JavaScript file in an empty V8 context (similar to the one provided by mksnapshot) and catch any invalid code that potentially slipped through.

Custom Elements and jQuery

As you may remember from the previous section, requiring native modules or using Node APIs is not the only forbidden operation in V8 snapshots. In fact, DOM APIs can’t be accessed either when requiring a script. This was quite challenging from a technical standpoint, because many of our bundled packages used jQuery or HTML custom elements. The former used some feature detection techniques that relied on DOM globals, while, in order to use the latter, objects needed to extend the HTMLElement class, which is not available when generating a snapshot.

To solve both of these issues we could have taken some shortcuts by, for example, patching jQuery to stop performing feature detection at require time. However, we realized that neither jQuery nor custom elements were providing any tangible benefit to our users. In the case of jQuery it was quite the opposite, as sometimes it would cause unnecessary DOM reflows and a slower user experience. As such, we decided to take this as an opportunity to remove them from the codebase and improve Atom’s code quality.

For the most curious, #13254 provides a summary of all the work that went into this process, along with the relevant pull requests.

Improving `require` time

All the tasks illustrated in the sections above laid the groundwork for finally reducing startup time. After dealing with all those roadblocks, we started addressing one of the major sources of slowness when opening Atom: calling require. Requiring a module involves the following steps:

Resolving the module, as explained in Node’s documentation.
Reading synchronously its contents.
Compiling it.
Executing it.

Each of them has a cost, and in a big codebase like Atom’s this cost is even more emphasized. For instance, take the following CPU profile of the initialization code:

You can notice how a lot of it is spent in Module._compile and require. On average it took ~ 0.9s-1.0s to load a stock Atom window and activate its packages when no editor was open and the tree-view was closed. By using snapshots, we were able to cut this cost down to ~ 0.7s-0.8s, thus improving startup time by 15-20%.

For more details, please check out #13916.

Eagerly constructing the `atom` global

Atom exposes many of its functionality through the atom global. This object is an instance of AtomEnvironment and, when created, takes care of loading the workspace, keymaps, configuration, etc. This is summarized by the following CPU profile:

Even though some of these tasks are dynamic (e.g. reading the user’s configuration), others are repeated every time a new window is created and, thus, waste CPU cycles and I/O resources. Similarly to what we did for requiring modules, we used snapshots to improve this code path, making it two times faster.

For more details, please check out #14024.

Optimizing style sheet loading

After the improvements described above, all the noise related to requiring modules and constructing the AtomEnvironment disappeared from the graph, which emphasized other problems that were affecting startup time. Specifically, we started noticing that reading style sheets was causing significant slowdowns, especially on machines with a slow hard drive:

Almost every package that ships with Atom has a style sheet that customizes its appearance; considering that we ship 58 packages, we decided to bake all the core style sheets into the snapshot in order to make them already available when loading core packages at runtime. This resulted in a ~ 100ms improvement on a fast machine with an SSD but, since most of this work was I/O bound, we expect it to be even more noticeable on slower hardware.

For more details, please check out #14038.

Preloading bundled packages

The last optimization that could be achieved thanks to snapshots was to reduce the cost associated to loading and activating bundled packages. This involves reading keymaps, settings, menus, etc. and registering them. As shown in the CPU profile below, doing this work in the snapshot allowed us to save ~ 60-90ms:

This is confirmed by Timecop, which highlights how packages loading alone became almost instantaneous:

For more details, please check out #14080.

Conclusion

This marks the end of the first round of performance improvements to startup time. Overall, on a stock installation, we made loading Atom almost 50% faster and snapshots were a crucial tool that enabled some otherwise impossible optimizations.

Performance continues to be one of the concerns the Atom team cares about the most. We believe there are still many things we can do to reduce startup time even further and, in the future, we would like to explore an approach where we take full advantage of Electron’s multi-process architecture. Specifically, the main process (which was not affected by the improvements described in this blog post) and the renderer process could load almost in parallel, as opposed to the current situation where we fully load the main process first and only then spawn child renderer processes.

As always, we will keep you posted as we make progress on these enhancements. In the meantime we hope you will enjoy opening your editor faster with Atom 1.17 Beta! :zap:

Atom 1.16

2017-04-12T00:00:00+00:00

Today’s Atom 1.16 release comes with two more macOS title bar options, a push to remove jQuery and other improvements.

More title bar options (macOS)

On macOS you can now choose between two more title bar options (Settings > Core Settings > Title Bar).

Option 1: custom-inset adds a bit more padding around the “traffic lights”. This might not seem that useful on first glance, but the “traffic lights” will look more aligned when combined with something that needs more height. For example when the title bar gets replaced with a tool bar.

Option 2: hidden completely removes the title bar for people that like things minimalistic or want to save an extra 22 pixels. To drag the window the status bar can be used.

Note that by enabling these options some functionality will be lost. Especially when the title bar is hidden managing the window needs to be done with keyboard shortcuts or using the menu.

Don’t forget to check out all the other improvements shipping with this version in the release notes! :memo:

Project search performance

We’ve improved the performance of displaying project search results by only rendering visible DOM nodes.

Atom 1.17 Beta

Introducing Docks

const item = {
  element: document.createElement('div'),
  getTitle () { return 'My Fabulous Div' },
  getDefaultLocation () { return 'left' },
}
atom.workspace.open(item)

We’ve added a new tutorial to the flight manual that covers docks. You can also dig into the API for other facilities such as the ability to limit items to specific locations, specify default dimensions, toggle dock item visibility, and more. Until 1.17 lands on stable and we update our official API documentation, you’ll need to consult the source code to do so… here are the relevant classes:

You can also check out this tree-view PR for an example of converting a panel to a dock item. One major thing worth noting is that panes and items within docks are now included in various global workspace methods such as getActivePaneItem, observeActivePane, etc. If you want to limit your scope to just the center of the workspace as was the case before docks existed, you’ll need to interact with the new WorkspaceCenter class, available via atom.workspace.getCenter().

A huge thanks to Facebook’s Nuclide team for developing docks and taking the time to upstream this feature into the core of Atom.

Faster startup time with V8 snapshots

We’ve dramatically reduced window load times by using V8 custom startup snapshots to shift work that was happening on window startup to happen during Atom’s build instead. We’ll have an in-depth post on this next week.

Farewell to jQuery

Other Improvements

Fix for middle-mouse-button paste on Linux thanks to @dietmar for fixing a long-standing issue!
Restore the Atom environment when adding project folders to a fresh window

There are many more details in the release notes.

Get all these improvements today by joining the Atom Beta Channel!

blog.atom.io

Atom 1.20

Git Integration Improvements

Find and Replace

Other Enhancements

Atom 1.21 Beta

Language Server Integration and Atom IDE

Filesystem Watcher API

More GitHub PR Events and Build Status

Other Notable Changes

Introducing Atom-IDE

Get started

TypeScript & JavaScript (ide-typescript)

Flow (ide-flowtype)

C# (ide-csharp)

Java (ide-java)

PHP (ide-php)

Using Atom-IDE

Autocomplete

Diagnostics

Find all references

Formatting

Go to definition

Hover

Outline view

Reference highlighting

Future plans

Atom 1.19

Improved Responsiveness and Memory Usage

Editor Rendering Layer Rewrite

Other Notable Changes and Fixes

Atom 1.20 Beta

Git Integration Improvements

Find and Replace

Other Enhancements

A new approach to text rendering

Back to a virtual DOM

Intersection and resize observers

CSS containment

New decoration APIs

Next steps

Atom 1.18

Git and GitHub Integration

More Improvements

Atom 1.19 Beta

Native Text Buffer

Editor Rendering Layer Rewrite

Other Notable Changes and Fixes

Docks Deep Dive

Opening Items in Docks

Toggling Items

Digging Deeper

Conclusion

Git and GitHub Integration comes to Atom

Git goes Atomic

GitHub breaks out of the browser

So much more to come

Atom 1.17

Introducing Docks

Faster startup time with V8 snapshots

Farewell to jQuery

Other Improvements

Atom 1.18 Beta

Git and GitHub Integration

More Improvements

Improving Startup Time

V8 snapshots

electron-link

Custom Elements and jQuery

Improving require time

Eagerly constructing the atom global

Optimizing style sheet loading

Preloading bundled packages

Conclusion

Atom 1.16

More title bar options (macOS)

Project search performance

Atom 1.17 Beta

Introducing Docks

Faster startup time with V8 snapshots

Improving `require` time

Eagerly constructing the `atom` global