This article is going to take a look at Brackets, an open-sourced editor originally developed by Adobe. It may not have had quite the same level of publicity and hype as Atom, GitHub’s new lightweight editor, but it’s a promising option for the front end developer.
It’s worth pointing out that Brackets is primarily aimed at front end developers and web designers. Although it’s essentially a text editor and therefore suitable for coding pretty much anything, it’s optimized for HTML, CSS, and JS (as well as derivatives such as SASS, Less, CoffeeScript, and so on). Ruby, Python, PHP developers, and the like might be better served looking elsewhere, whether that be for a fully-fledged IDE or something more lightweight such as Sublime or, indeed, Atom.
What Makes Brackets Different?
Brackets can be downloaded from the website, and is available for Mac OSX, Windows, and Linux (32 or 64-bit). For the purposes of this review, I’m running the 37th “sprint”, on Mac OSX.
When you open Brackets for the first time, you’re thrown straight into an HTML-based tutorial file with accompanying CSS, which is a great way to start exploring.
The left-hand column lists the working files, and beneath that is a folder view. It’s like Sublime in that you can view a file with one click without actually opening it. A double-click opens the file for editing, adding it to the working files list.
The right-hand column contains icons for opening Live Preview (which we’ll look at shortly) and for the Extension Manager. Many third-party extensions create their own icons and place them in this bar, so it can quickly become an invaluable launchpad.
A Quick Feature Tour
Let’s look at some of the key features of Brackets.
The Live Preview feature launches a new Chrome window showing the current page that not only doesn’t require a manual refresh when you change a file, but also as you type. It’s essentially Chrome’s Web Inspector, but with all the benefits of a self-contained editor. It’s a truly great feature, particularly if you have a splt-screen setup. It doesn’t just work with HTML files, either. If you make a change to a linked CSS file which impacts the current page, that too gets reflected immediately in the browser. If you’re editing a CSS file used by the currently visible page, highlighting rules causes the preview to highlight elements which are affected by them.
The Quick Edit feature is context-specific. Let’s look at a few of its uses.
When you’re editing HTML, if you click a tag with a corresponding CSS declaration situated in a linked file and hit
Ctrl / Command + E, an inline editor appears allowing you to quickly edit that rule. This is probably best illustrated with the following screenshot.
Hovering over a color in a CSS declaration shows a small swatch of that color. Also, the same keyboard shortcut (
Ctrl / Command + E) gives you a pretty sophisticated color selector / converter, as illustrated below.
While unlikely to be used nearly as often as the CSS rule or color editor, the bezier curve editor is a hugely impressive little feature. Again, it’s best illustrated with a screenshot:
It looks like third-party extensions will provide additional contexts for Quick Edit, like the regular expression editor described later in the article. It will be interesting to see what’s produced; there are clearly many possibilities for it.
Because Brackets runs the JSLint process when you save, rather than as you go, it can feel a little unresponsive; you can correct something and the report remains on-screen because you haven’t saved it. However, the performance impact of doing it any other way would probably create its own problems.
As you’d expect from a code editor, Brackets implements code completion. And, it’s fast. Really fast. I’ve found a number of editors in the past to feel sluggish, which negatively impacts the experience, but not so here. That’s not to say it’s perfect. For example, when writing SASS it would be good if, once you start typing out a nested selector (i.e., with a period or a hash) that code completion would stop prompting you for a rule.
The true power of Brackets, I feel, lies in its potential for extension. There are already a significant number of extensions available. I’m going to take a look at a few that stood out for me.
The process of installing an extension couldn’t be easier. Simply click the “brick” icon on the top right, then you can search for and install them from within the application.
If you work with Markdown, you might find the Markdown Preview extension to be useful. When you open or create a Markdown file in Brackets, it splits the screen horizontally into two panels – one for editing, and one for a live preview. While this offers nothing a dedicated Markdown editor such as Mou doesn’t, one benefit is that you can edit a project’s Markdown files (GitHub READMEs, for example) without having to leave the editor. On the downside, it doesn’t do everything you’d expect, like have keypresses for bold or italics. A screenshot of this extension in action is shown below.
For Node.js developers, this extension allows you to stop and start your applications and view their output from within the editor itself.
If you work with files for whom the extension doesn’t give away the language, such as
.inc files, PHP files masquerading as
.module files, or indeed those without extensions, then the Language Switcher module may help. This module is shown below. It also means you can take advantage of language-specific features such as syntax highlighting on a new file before you’ve saved it.
If, like me, regular expressions can give you headaches then there’s even an inline regex editor. This works in the same way as the other Quick Edit contexts such as colors and beziers, suggesting that this is an area where contributions will be particularly active.
You can even run a terminal from inside the editor.
Brackets feels like an extension of Chrome’s Developer tools. The Live Preview feature is incredibly useful, combining the advantages of coding in the browser with those of a dedicated editor. Its other killer feature for me is Quick Edit, although it feels like that’s some way off from its full potential. However, by tapping into users’ knowledge of web technologies, it seems likely that any gaps will quickly be filled by contributions.
From a personal point of view, I can’t see myself switching to Brackets for the server side work I do using languages such as PHP. For more front end focused development I can see it becoming a useful part of my toolkit. If you’re a front end developer then I would urge you to take it for a spin, at least – and after all, it is free.