Too bad that the Atom developers seem to be completely disrespectful of Windows users. They impose arbitrary rules that go against the philosophy of the OS and users' common sense:
* They don't allow the user to select where to install Atom, instead proposing mucking with symlinks, while at the same time crying "simplicity". Uhm, yeah...
* They don't understand what portable software is, and refuse to provide a self-contained installer (settings and all). They propose setting a global environment variable to point to the settings directory instead. Seriously?
If you want to release software for multiple platforms, you should get off your high horse and show some respect.
Yeeep. Same reason I prefer Hg over git. It's simpler and is a first-class citizen on Windows, whereas I have to use Cygwin/MSSys and the sometimes ancient dependencies (OpenSSH from like 2008 or something ridiculous).
Edit to make comment more civil and substantive while retaining its content, can't apply it anymore though. (versioned comments without edit lock would be nice)
"
I don't see how having a philosophy and applying it into software they develop is disrespectful.
If anything, I find it disrespectful to demand change to something they publish free of charge in such a tone,
after all you are free to fork and adapt their work however you please.
Additionally it is not their fault that the windows philosophy clashes with the unix world,
which is something I'd hold microsoft accountable for.
Unix tools are hard to get right on windows, see git, which basically installs its own userland on windows.
I wouldn't judge them for picking a way and sticking with it.
"
In the interest of being more civil and adding to my comment too, I agree with most of what you have said.
I only disagree with the snarky Windows development comment. :) Visual Studio is hands down the best IDE I have ever used. The DirectX API is very nice (just ask any game developer and they'll tell you how much of a pig OpenGL is to work with). I use OSX at work and Windows at home, I much prefer development on Windows.
Atom still has an inconvenient bug: if you use an European keyboard layout on Windows, one which maps important characters like @ and <> to an "AltGr + something" chord, you will be in pain as Atom uses a lot of Ctrl+Alt+something keyboard shortcuts for its functions, and that appears to be non-rebindable, so there is no clean way to get those characters in Atom! The canonical solution for this on the Windows platform is to never use Ctrl+Alt shortcuts, ever.
Indeed, I just installed it again to check and it is still unusable with french layouts, e.g. it is impossible to type a ']' (AltGr + ')') in any environment.
I used the auto keymap generation feature (you just type the caracters that have issues in a textbox and it generates/saves a keymap) and I don't have problems with my fr-FR keyboard anymore.
Honestly, what made me switch to Atom from Sublime was how easy making a package is compared to Sublime.
For years I used Sublime with a customized fork of some emacs-like package that mimicked emacs' open-file behavior. However, because Sublime seems to limit how you can show things to the user and the documentation for making packages is mediocre, I was stuck with showing a list of filenames in the status bar, which scales to like 10 filenames at most.
When I finally decided I was going to Atom full time, I decided to take a stab at making my own package for opening files as I couldn't find anything that did quite what I wanted. Within hours I had forked and adapted an existing package to do exactly what I wanted[0].
It's shocking to me just how easy it is to make a package, especially if you're already familiar with web development. Within the past month and a half I've published 4 different packages[0], probably only spending about two weeks total time working on them.
I'm confident that, as the performance issues that some people hit are ironed out, this flexibility will make Atom hugely popular.
>I'm confident that, as the performance issues that some people hit are ironed out, this flexibility will make Atom hugely popular.
It's a DOM based editor -- and they already did 2 rounds of optimizing the rendering. The performance issues wont be ironed out in the foreseeable future.
I think MS Visual Studio Code has set the bar pretty high for what's possible. The DOM may be an inhibitor, but Code has shown you can still get very good performance.
I have tried to use Atom many times. It is built in open - source spirit and has a very friendly community. So I download every release which is even slightly talked about and try it (including 1.0) , and every time I end up wishing it was faster like Sublime and switch back.
I code in Python/Go, both of which have very exhaustive plugins in Atom, but it turns out autocompletes are noticably slow. I do not mind if I type a few characters and they appear a bit later on screen, but like 5 seconds after pressing enter <I use enter for autocomplete> is kind of unfair, esp when you see things happening almost spontaneously in Sublime.
However, I would like to say that it is getting better (version 1.0 is way better than the first one I tried) and has the potential to become the next emacs. But its not right now there. I will not wait till then to switch, but unless Atom gets faster, I am not taking a plunge. I think Sublime is the undisputed leader for me till this happens.
Have you tried Adobe's Brackets editor? It's similar to Atom (uses chrome + node) but much better performance, IMO.
I refuse to use any editor with a noticeable delay when I type. My 7mhz Amiga 500 did not have a delay when typing, but some how Atom manages to cause lag on my 8 core 3ghz machine.
I liked it when I downloaded an early release, but I didn't see any reason to change from Sublime Text.
Atom has the advantage of having many people working on it, as opposed to one in the case of Sublime Text, so perhaps in time will ship features I didn't know I wanted. Will try again.
My rationale for stay with Sublime Text is that it's still a lot faster than Atom, and I've found it to generally be more stable. But I'll probably switch to Atom once it has a significant number of features or plugins that make it worth the 'cost' in performance.
Visual Studio Code is extremely promising, and at some point may become my primary editor. However, it is still VERY early in the preview stage. There's no plugin system yet (so no Vim mode, or other things that people often find essential).
Also, while free-as-in-beer, its licensing status is currently proprietary... a significant turn-off for the audience that Microsoft is targeting with this. Every rumor suggests that they'll be open-sourcing it eventually, and that the process just takes awhile to work its way through legal, since Visual Studio Code borrows its editor code from their commercial Visual Studio Online product. But it's still an open question.
Overall, I am "intrigued-and-cautiously-optimistic" right now (its startup time and responsiveness are MUCH faster than Atom's!), but I'm not ready to switch over full time just yet. I'm looking forward to seeing where they are with it by early next year, when all of the other cross-platform .NET stuff is ready for general availability.
They use the underlying core, but the code is their own. One benefit I see is that Microsoft gets to provide bugfixes to Electron that Github may find useful. As well as Microsoft may just end up porting some of their products (Office) based on their experience learned by developing for multiple platforms.
I know many people reason like this, but I simply can't understand it. I can't claim to work on huge projects, but even when working on quite big ones the only "slowness" i notice is the launch time.
Surely launch time is basically insignificant for a text editor which you might only launch a few times in a day?
Back when I had a mid-2010 mac mini, there was a noticeable lag between resizing an Atom window and the contents redrawing - when sublime and gedit were fine with the same files.
That was a comparatively slow computer; someone with a higher performance computer probably wouldn't think the performance was all that poor. I can only assume the Atom developers find the performance tolerable.
Still, it reminded me of the old joke [1] that the speed of software halves every 18 months.
>Atom has the advantage of having many people working on it, as opposed to one in the case of Sublime Text, so perhaps in time will ship features I didn't know I wanted. Will try again.
Yeah, but unfortunately they are Web people, working with Web technologies. Not what I really appreciate on my editor...
Even if they come up with some great idea conceptually, it will still have all the baggage from being implemented in a web engine...
Atom v1.0 is lot better than beta releases, but not as good as Sublime. Atom is open source unlike Sublime which is closed source, so in the long run atom is definitely going to be the winner. For Now, Sublime is much better than Atom and there is lot of gap in terms of performance. Lets hope, Atom gets better & better with releases.
>Atom v1.0 is lot better than beta releases, but not as good as Sublime. Atom is open source unlike Sublime which is closed source, so in the long run atom is definitely going to be the winner.
No, it's just going to remain open in the long run. That's the guarantee from Open Source. Not that it will be "the winner".
GIMP hasn't matched Photoshop in ages, Gnome and KDE are not up to par with OS X and Windows 10 even after all these years, OpenOffice never matched Office in speed and stability, the list can go on...
What makes a winner? Everyone I know has purchased Sublime and will likely purchase 3 when its out of beta. It must generate millions of dollars in revenue, and has an incredibly active community, just judging from the package control website.
Open source doesn't magically "win" over closed/commercial just by the nature of being open source.
I didn't mean that way, open source wins over closed source every time; Atleast Atom has lot of contributors and being pushed very quickly, which has something of around 155 releases in a year (from public beta to stable 1.0). That's really a good sign, not sure if it continues; if it does, it's going to be really good editor in the long run.
edit: I realize OP says that he admits all the Atom packages are ports from ST, and he isn't really arguing for Atom > ST, just that "I guess I just wanted to try something new and so far I'm quite happy with it"...I guess I was thrown off by one of his initial statements:
> Atom 1.0 will greet you with a nice splash screen on start. The first you will notice is that Atom is actually a lot more user friendly than Sublime Text.
...and then he proceeds to explain how you have to dig through two menus to enable the basic "Preview Tabs" menu.
----
I appreciate the writeup but the OP doesn't seem to be experienced or knowledgable enough about ST to make a reliable judgment.
The very first feature he mentions is "Preview Tabs":
> Preview Tabs allow you to open files, have a look at the code and then open another file, whilst automatically closing the previous one, if no code changes have been applied.
Doesn't Sublime Text have this feature? You click on a file in a project and its name will appear italicized in a new tab, indicating that it's not quite open. Click on another file, and that new file will take the previous file's spot. Double click a file name and the tab title will no longer be italicized. What am I missing here? Even if ST didn't have this feature...this seems like a weak feature to start off a piece about why Atom is different/better than Sublime Text.
All of the plugins that OP mentions seem to already exist in ST. OK I can't say that for sure, since I haven't tried every single one, but this is what OP says about the Pigments plugin:
> Now this is actually something I never managed to do in Sublime Text, but in Atom it just works. Pigments pulls in the HEX, RGBa or HSL value and applies it as the background colour of your code. Great if you’re like me and can only tell the colours of two values, #000 and #fff…
This is a feature of the popular ColorHighlighter package (which also has a built-in color picker): https://github.com/Monnoroch/ColorHighlighter. ColorHiglighter does not highlight all colors by default, but perhaps OP didn't read the README where it says you can enable that feature in the standard Tools dropdown?
Hi,
Sorry to confuse you. The post is actually meant to be for people who come from ST and move over to Atom. There is no particular useful feature I am aware of (except maybe the git integration) that requires everyone to make the switch. I just wrote this post to show how I use Atom now and that it basically capable of everything I liked about ST. It's not really this is better than that, it's just that I have now two editors that work great for me :)
I've been using Atom (now Nuclide) for a year. It's reasonably good.
I believe in something like `react-native-desktop` based editor. Only JS Threads + UI Native Thread. It's a huge task to implement all these APIs, yes, but I couldn't imagine how fast and responsive Atom would be without Chrome inside.
This is a easy switch for me since I really never got into learning the advanced stuff sublime can do and for the bulk of my work I'm hopping in and out of the terminal. Though I'm sure there are plenty of devs that will hold onto sublime to the grave.
New people are born every day, and when they are deciding what tools to use, they should try to pick the best ones, not the ones that you personally aren't willing to invest in.
* They don't allow the user to select where to install Atom, instead proposing mucking with symlinks, while at the same time crying "simplicity". Uhm, yeah...
* They don't understand what portable software is, and refuse to provide a self-contained installer (settings and all). They propose setting a global environment variable to point to the settings directory instead. Seriously?
If you want to release software for multiple platforms, you should get off your high horse and show some respect.
Link: https://github.com/atom/atom/issues/7095