What distinguishes atom.io from brackets.io?


#1

At a high level, atom.io and brackets.io seem quite similar. Brackets.io is extensible with HTML/JS/CSS which is what atom.io is claiming to have as a big feature. What was the motivation behind atom.io? Is there something really different that it provides that I’m missing?


#2

The main difference is that Brackets is intended for web development while Atom is intended for development in all languages and not only web languages. Other than this, they are very similar in many ways. Another difference is that Brackets is free and entirely open source while only a big part of Atom will be open source and GitHub will charge for it.


#3

If that is the case then what prevented Atom from being implemented as a collection of extensions to Brackets? Don’t get me wrong, I love GitHub and what they contribute, but this seems like a case where they could have just as easily contributed to an existing project instead of writing their own. However, as you said, GitHub will be charging for Atom. Hopefully having both Atom and Brackets will introduce some good competition and drive innovation in both.


#4

Atom uses its own editor, while Brackets uses CodeMirror and contributes to it. Atom is more modular, while Brackets has a more transparent development model (so far). Atom is developed by GitHub while Brackets is developed by Adobe, which uses it as the base for its Edge Code software, which they charge for.

I don’t think Brackets aims at this point to expand over web development, because that is where Edge Code stops. That is unfortunate, and I’m sure GitHub could have contributed to Brackets instead, but then they wouldn’t have been able to charge for it.


#5

I think a big difference is the way both editors use Node. Atom executes Node in the same context as the frontend JavaScript code while Brackets hides Node behind some APIs. Btw this is my major complaint about Brackets and I’m glad Atom chose the node-webkit way to embed Node.


#6

They could, Brackets is MIT licensed.


#7

I am a bit confused. The differences seem trivial at best. Brackets could easily be expanded to cover more languages (there are already extensions that do this). Brackets also has a large community of contributors and users, so the comment about Edge Code is slightly disingenuous (that’d apply if Adobe was the only contributor, which it isn’t). Also, you mention that Adobe charges for Edge Code when, in fact, it is free. You have to sign up for Creative Cloud, but only the free account and, once you do, Edge Code is available - free of charge.

Here are the other differences according to the above:

  • Atom uses its own Editor instead of CodeMirror (it’s not clear why this is preferable)
  • Atom handles Node slightly differently (if this is better, and perhaps it is, that easily could have been a change to Brackets rather than necessitating an entirely new product)
  • GitHub plans to charge for Atom (as noted by pritambaral above, Brackets is MIT licensed, so you could have charged for your improved version and perhaps still contributed back to the underlying project).

#8

AFAICT, atom.io development could predate brackets.io by quite a bit. Archive.org has brackets.io showing up in 2012, whereas the first git commit for atom.io appears to be in 2008


#9

There’s a thread on here that also suggests (from an IRC chat with one of the Atom devs) that Atom will be open sourced down the road. So it might be free.

EDIT: Scratch that, sounds like it won’t be free, even if it is open sourced


#10

I believe I was misunderstood: I am not defending Atom, and I would actually prefer Brackets if it was as modular as Atom and was not limited to web development. I do not think it is preferable that Atom uses its own editor: I would prefer if it used CodeMirror and contributed to it so that all web components using CodeMirror would benefit. I would also have preferred contributions to Brackets rather than a completely new editor, and that GitHub plans to charge for Atom while Brackets is FOSS is a major reason that would make me want to use Brackets instead of Atom if it had support for other languages than only web languages. Finally, I was wrong about Adobe Edge Code not being free.


#11

in reply to @Rastus_Vernon

sorry as far as I can see, atom is purely a case of NIH. I don’t see anything that makes it better to brackets, yet on the cons side, theres plenty:

  • NOT open source - brackets is MIT
  • immature - brackets has hide wide usage for over a year
  • no community - brackets has dozens of external contributors
  • only available atm on a single platform - brackets is on 5 and growing

Also I doubt that they have thier own editing component, its most likely a fork of ACE.

On being more “modular” than Brackets, its hard to know with them not releasing the code, but from my experience, Brackets is well architected, easily extensible and already has a very rich eco system of add-ons from the user community.

And Brackets is focused on web-development, but not to the exclusion of dev in other languages, it supports all of code mirrors modes and the adobe team are open to contributions for other langs and as I said its very extensible via add ons.

Honestly to my mind, I just see no valid reason for atom expect GH wanting to make more money, and definitely no reason why anyone would spend a second of their time contributing to it it vs an actual open source text editor.


#12

As you say, their statement says it will never be completely open source, so at this point its a total write-off given there are existing, Better alternatives that are (Brackets, Caret).


#13

Fyi, Adobe Edge Code is free too.


#14

I love love love(d) brackets so it pains me to say it, but, as it stands at the moment Atom is simply faster.

I generally work with fairly modestly sized projects but Brackets was starting to creak. I occasionally need to open minified code to poke around, Brackets hates this and chugs. My latest ‘beast’ of a file was only just over 1000 lines (mainly comments) and again Brackets would chug. There used to be a file limit in Brackets (not sure if that still stands) but certainly large-ish projects with many files seem to make it bawk. A caveat here is that it could be something in one of my many plugins for Brackets and not Brackets itself.

In contrast, I accidentally opened Atom in my Downloads folder earlier which is around 14gb, no problem. Opened up the actual file I wanted just fine, no delay (above normal). Stuck in a massive old minified file (1 liner), again, no discernible problems.

Atom also does more straight out the box, albeit via already installed plugins. With Brackets you have to find those yourself and the ecosystem is strong so you often have a choice and its often difficult to gauge a plugins validity until you’ve used it for a while. Depending on your point of view this is either a win for Atom or for Brackets.

Brackets code hinting is better. Much better.

Creating themes in Atom is easier.

To be honest, both are ruddy great and its going to be great to see them treading the same boards and pushing each other on. I love the philosophy and openness of Brackets but Atom isnt a slouch in that respect.


#15

The difference between the two is well listed, actually. I find it very interesting that Atom uses the plain libchromiumcontent; lets just call it a more low level implementation than Chromium Embedded Framework. I have taken my time to search and peak into the source tree, and soon found exactly what they use. Replicating Atom might not be very easy for a developer, but it is pretty possible. Therefore I am a bit stunned that they want to set Atom to be paid for…?
Brackets has a lot of nice extensions, but it feels a bit like the editor is “weak”… I dont know how to express it, really, but I find Brackets to have some annoying side effects. If i just want a code editor, I do not want to spawn a whole bunch of windows and such. Thus, one of my projects has a long list of subfolders, so loading a file from within Brackets takes forever.

I really hope Github changes their mind on Atom; because releasing it as open source would be a big contribution. In fact, Atom’s inner “Atom Framework” is essentially what I have been trying to create off CEF; a framework to allow as-native-as-possible app development with javascript, html and css. As they even included libuv (nm’d the framework binary), they must’ve not just integrated nodejs into the editor, but actually completely vice versa; they integrated an editor into the uv event loop. That however, is just what I got from poking around with lldb, nm and such.

So to summarize.

  • Atom uses a whole different scheme of working with nodejs; one I would call genius!

  • Brackets uses CEF and a separate NodeJS executable.

  • Atom can work with any language (tested with ObjC++ and it looks cool!), whilst Brackets is very limited in languages; and I cant find a good way to integrate other languages.

So, the engines are different, the work model for modules is different, and the general way of workflow is a whole different one.

Is there anything I forgot to mention? ovo


#16

I gotta say, I came across Brackets because of the release of Atom, and I like Brackets a lot.

Atom definitely feels like it’s aiming towards the Sublime user base, which is definitely great for muscle memory, but Brackets actually feels like there is more vision behind it.

Sure, that vision is web development, so it can’t hit all use cases, but I’m a web developer so that works out for me. :smiley:

Some things are easily done in Atom, but since Brackets is Open Source, you can just open your instance of Brackets in itself and change what you don’t like. It’s laid out pretty well, and well commented. Really interesting.


#17

After reading this I actually tried brackets - It’s pretty nice, even though the animations feel a little strange, at least on OS X. What really bugged me, though, was that theming brackets is a real pain in the… . Sure, it can be done, but it’s really annoyingly difficult for an editor that is based on web standards where this pretty much comes for free if you put a little thought into it (see atom).
If Atom grows over the coming months and especially gets some features like auto completion and window/tab management that are as good as brackets I think I’d prefer atom… but this is just personal taste.


#18

only a big part of Atom will be open source and GitHub will charge for it.

Not trying to necro but have a question related to this.
I do not see any Atom component that is not opensourced , so this information is wrong Now ?
A year ago which part was not opensourced?


#19

At first both Electron (formerly atom-shell) and Atom core were private repositories on Github. Hence all the discussions about licensing and such.

Now, given the momentum gained by Electron in the last few months (with Nuclide by Facebook, VSCode by MS, Slack using it for its windows client, etc.) open-sourcing it was clearly the best choice and I’m glad they did it. I’m also using Electron for internal project as well and it’s amazing at which pace you can get a well-polished product with everything you can dream about (auto-updates, state serialization, keybindings, etc.).


#20

Yeah i am also planning to use Electron when porting my scientific , python web apps as Desktop client.
Thanks a lot for the clarifications! I also see alot of interest in Electron , i think this is gaining a lot more momentum vs NodeWebkit.