What do you like best about Brackets?
Live Preview was the feature that put Brackets in front of every other editor I tried at the time. I would open an HTML file, hit the preview button, and get a live connection straight to Chrome. Edit a CSS value and the page updated in the browser the moment I typed, no save and no manual refresh. The detail I appreciated most was that it highlighted the element I was working on directly in the browser, so when I changed a rule I could see exactly which block on the page it touched. For the kind of work I did most, building and tuning marketing pages and front-end layouts, that tight loop between the editor and the rendered page was the thing I missed immediately whenever I worked in something that did not have it.
Quick Edit earned its keep every working day. Put the cursor on an HTML element, press Ctrl+E, and Brackets opened the CSS rules attached to that element inline, right there in the same window. I could adjust the style and close it again without ever leaving the markup or hunting through a stylesheet for the right selector. It came with a colour picker built into the same inline panel, which meant testing a shade was a matter of dragging a slider rather than guessing at hex codes and saving to check. It worked for JavaScript functions too, opening the definition inline, though the CSS case was the one I used constantly. For front-end work where the markup and the styles are two halves of the same task, collapsing the switch between them saved a real amount of friction.
The weight of the thing was a quieter reason I kept it open. Brackets started in about a second on the machines I had, and it sat lightly in memory while it ran. I could open it for a thirty-second edit and not feel like I was waking up a heavy IDE to change one line. On the older laptops and shared machines I sometimes had to work from, that mattered more than any single feature, because a fast editor that opens immediately is one you reach for instead of avoiding.
The everyday editor mechanics were quick and predictable. Code hinting came up fast as I typed. Code folding let me collapse the parts of a file I was not working on, and multiple cursors turned a repetitive edit across a file into a single action. None of this is unique to Brackets, and that is rather the point. The basics that an editor lives or dies on were quick, and the code completion in particular never felt like it was lagging behind my typing the way some heavier editors did.
Preprocessor support fit the way I worked without extra setup. Brackets understood LESS, SCSS, and SASS, with code hinting in those files rather than treating them as plain text. On a LESS project it would compile to CSS on save, so for the smaller sites I built I did not need to wire up a separate build step just to see my styles applied. For anything past a quick project that is not how you would run a real pipeline, but for the scale of work Brackets was built for it removed a step I would otherwise have had to configure.
The extension ecosystem is where I made Brackets my own. The extension manager was built into the editor, so finding and installing add-ons was a search and a click rather than a trip to an external package registry. My standing setup pulled in Emmet for fast HTML and CSS expansion, Beautify for reformatting messy files, a Git extension so I could see status and commit without leaving the window, and File Icons so the file tree was readable at a glance. Each one was small, but together they shaped the editor around my process instead of forcing my process around the editor.
Hover previews were one of those small touches I only appreciated once I had them. Hover over a hex code and Brackets showed me the actual colour. Hover over an image path in the markup and it popped up a thumbnail of the file. When I was working through someone else's stylesheet or a template I had not written, those previews answered the obvious questions, what colour is this and which image is that, without my having to open files or guess. It is a minor feature on paper and a useful one in practice.
The interface stayed out of my way, and that is harder to get right than it sounds. Brackets was clean and quick to learn, with none of the wall of panels that a full IDE throws at a newcomer. I handed it to less technical colleagues a few times, people who needed to make a small content or style change without being walked through an editor first, and they got useful work done in minutes. A tool that does not intimidate the occasional user is rarer than it should be.
It was also free and open source under a permissive licence, with no account to create and nothing phoning home that I had to think about. For something this central to a daily workflow, not having a login or a subscription attached to it was one less thing to manage. Review collected by and hosted on G2.com.
What do you dislike about Brackets?
The honest answer has to start with the one that matters most now, which is that the project wound down. Adobe, which founded Brackets, ended its support back in 2021, and active development of the original editor stopped there. A community fork has kept the classic editor alive since, and the people behind it have pointed users toward a successor that carries the same ideas forward, so the lineage has not died outright. But the version most people still have installed is no longer getting the steady stream of fixes it once did, and that is the plain reason I now write about it in the past tense rather than as my current daily driver. If you are choosing an editor today, this is the first thing to weigh, and it is why I eventually moved my own daily work elsewhere.
Setting the sunset aside, the limitation I bumped into most while I used it was the narrowness of its sweet spot. Brackets was built for HTML, CSS, and JavaScript, and inside that lane it was excellent. Step outside it and the experience thinned out fast. Working in PHP or Python meant leaning on extensions to get decent support, and even then it never pretended to be an IDE with the debugging and project tooling those languages often want. I kept it for front-end work and used something heavier when a job needed server-side logic, which was the right division of labour but also a hard ceiling on how much of my work it could cover.
Performance on large files was the next rough edge. For the small and medium front-end projects it was aimed at, Brackets felt quick. Hand it a very large file or a heavy codebase and it could get sluggish, slow to open and slow to render, in a way a leaner editor on the same machine would not be. It was not a constant problem because most of what I opened was modest, but when it hit, it interrupted the flow that the rest of the editor worked so hard to protect.
Live Preview, as much as it was the headline feature, had a flaky side as well. It was tied closely to Chrome, so the experience in other browsers was not the same, and the live connection would sometimes drop mid-session and need restarting. When it worked it was the best thing about the editor. When it dropped, it was a reminder that I was relying on a moving connection between two programs rather than something rock solid.
The extension registry was more frustrating than the extensions themselves. The add-ons were useful, but the place you went to find them was one long undifferentiated list with no real filtering or categories, so discovering a good one meant scrolling and then clicking through to a GitHub page for nearly every candidate just to understand what it did. Once you had your set installed it was fine, but the finding was harder than it needed to be, and the variable quality across the ecosystem meant some add-ons brought their own performance or stability problems with them. Review collected by and hosted on G2.com.
