Big huge [Citation Needed] there. Is there seriously any evidence presented to support this?
Nobody I know personally or work with daily uses Sublime Text. Therefore I could just as easily declare Sublime Text a "unknown and unused text editor relegated to obscurity".
Being a "text editing champion" doesn't mean anything anyway. Are we talking number of users? Features? Number of blog posts mentioning it with clickbait titles?
That's most probably the correct list. But again that's a perception. At least in the 'ruby' community 'vim' reigns supreme. Of course VIM and Emacs have ~20+ years of life, might not be exactly 'fair' for other editors.
Now a dispute could be made about JavaScript developers, since you need really tons of plugins to make vim (jslint, syntax, etc.) and you always need a browser to test your code (most dev are interested in client-side JS development).
This is what I was expecting. And, I think this is very much just a perception, as you say. I think it's rather unlikely that VIM and Emacs are actually the most used editors, or even among the most used.
I think it's interesting that you put quotes around both words surrounding community but not around the word community itself. I think what you perceive as the ruby community is actually a very small subsection of the actual ruby community and that is only a very small subsection of the entire community of people that use plain text editors.
I just think that people in this community too often think of themselves as the norm, when our very presence on a site like Hacker News places us very much outside of the norm. Outside even the norm for people in the tech community.
This is the exactly the problem though. We aren't speaking about niches, we're speaking about all text editor users. And in that case, I think Vim and Emacs don't do nearly as well as some may think.
> I think it's rather unlikely that VIM and Emacs are actually the most used editors, or even among the most used.
Apparently there is enough demand for Vim key-bindings that it seems most text editors and IDE's have them available.
> The learning curve for VIM and Emacs is so high as to almost be prohibitive for what is probably the vast majority of users.
Vim is probably more widely used by developers and system admins than say... writers. If you have been able to tackle the learning curve of learning to program or learning to administer Linux then the VIM learning curve is just another day at the office.
No one is saying that Vim key-bindings aren't incredibly useful, I'm saying that there is a reason those key-bindings are in most text editors and IDE's... because people are using those editors instead of Vim.
Also, most developers are not Linux administrators... It's not that learning Vim or Emacs is hard, what's hard for most users is increasing one's productivity enough to warrant learning Vim or Emacs, especially in the short term. So most developers/users don't; they use text editors that have much more in common with word processors, which many have been using their entire lives.
> I think it's interesting that you put quotes around both words surrounding community but not around the word community itself. I think what you perceive as the ruby community is actually a very small subsection of the actual ruby community and that is only a very small subsection of the entire community of people that use plain text editors.
Your insights are spot on :-)
ps. I thought being part of the 'HN community' is the norm for a but maybe it's not. I can't really tell without numbers...
I'm not sure how relevant search traffic is for usage of an editor, since most people won't be googling most of those (unless it's "gvim installer", etc.) as most are mostly handled through package managers. Maybe in the best case for the search results argument, they google a wiki/blogs/etc a few times (to initially find, or if they are on an unfamiliar computer and have forgotten the URL), plus searches for an installer package where necessary, and the odd search for how to do an obscure or tricky operation, which still implies long periods of 'silent' use between.
I develop mostly on Windows and I use Sublime Text and Eclipse. I can't stand Visual Studio, it feels to clunky for web stuff to me and I miss the Sublime Text command palette. I also can't easily integrate a lot of my toolchain into it; looks like that parts getting better from the current state of the extension gallery though.
Let's use search queries statistics instead of using flawed perception of ours:
1. Notepad++
2. Vim
3. Sublime
4. Emacs
Haha, nobody might have guessed Notepad++ is the leader. Of course, we all are the Windows haters, and my post is so going to be downvoted for pointing this out.
P.S. Its maximum of 5 search terms, but I tried different variations. Play around, google trends has many gems to be uncovered.
Let's not forget IDEs like Eclipse, which is much much higher than any of the text editors, and Visual Studio, which has recently become a close second.
When you're at a "Windows-Only" place Notepad++ is not a bad choice. I still have a copy of PFE around and I must admit I do miss its easy macros, remove trailing spaces option, and templates on OS X.
Especially since it seems to have been abandoned for a while now according to their website. The last beta build was 5 months ago, and the one before that over a year. (Obviously your editor doesn't need to be updated regularly, but it seems to be history repeating itself a la Textmate.)
Well as you say an editor doesn't need updating that much. I used VIM for ages but had an hiatus in programming and when I came back I start using sublime. And now I switched back to textmate. Like textmate it's simple sufficient bundles. Looks pretty.
And with getting older. It's just an editor that makes me type text. Yeah yeah productivity but as I think more than I type it's not such an issue as long as I can do most of the basic editting ;)
Agree, I am impressed with how Textmate development has been going since it was opensourced, but my point really was that OS issues, bugs and incompatibilities can quickly add up over the course of a year or two, without any active development. The advantage of something like VIM or emacs is that they're first and foremost terminal based, and are shielded from a lot of these issues.
Lets also not forget that Sublime text isnt free, and i am sure paying users dont really want to be left in the dark for 6 months to a year.
I almost bought Sublime, but realized it was a bad idea just in time. I decided to give emacs another shot, this time jumping headfirst into Lisp too, and it's amazing. Really nice.
I don't know about Windows editors, but for web development in Linux that statement is absolutely true. Both Atom and Brackets don't even come close to SublimeText, at least yet.
Vim is nice, but some things are better done with the mouse. Selecting and moving text down a few lines is so much faster in ST. And there's a Vim plugin for it anyway, so you can have the benefits of both Vim controls and a good interface. ST really is a great editor and to get Vim even close in terms of functionality, it takes way too much time configuring it.
I have to say I was of the opinion that Sublime was pretty much as good as it gets, but I've recently started using Webstorm and I am definitely impressed. I do think it is probably one of the best for JavaScript development IMHO.
Every web developer I know is using Sublime and all the videos you see on Youtube about frameworks are also using Sublime. So it's clearly one of the favorite text editor here.
It's enormously popular in web development, especially front-end development. It's probably the most popular with modern web developers who don't use Vim/Emacs. It certainly appears to have long overtaken Textmate, which I only rarely see referenced.
Of course, this is all anecdotal. It's likely that the vast majority of working developers never post screencasts or really discuss their editor of choice, and just get on with their work. So in terms of code actually created, it's a very poor assessment.
Atom now has its own installer (no more Chocolatey on Windows for example), has an update manager for itself and its themes and plugins, and has gotten more stable as of late.
However... It is slower than SublimeText 3, noticeably slower. I tend to keep applications open for weeks, using "sleep" mode overnight, and Atom still tends to crash after several hours. This means I don't use it for real work, yet.
While Atom does indeed keep getting better, ST3 is becoming more and more frustrating as package updates now have a tendency to vomit errors when ST3 starts up. It complains about not being able to load a config file for the package (like Rust mode or the Cobalt theme). When this happens, ST3 disables the package, but a restart will clear the hiccups.
SublimeText is clearly the better editor, yet there has been no progress on the beta. Worse, this has caused a division of effort among third party providers who have to support ST2 and ST3, with no clear end in sight for an ST3 stable release.
I just skimmed the title, missing the Sublime part, so naturally I thought they would be comparing Atom to Spacemacs. Imagine my surprise!
Putting aside trolling, it's hard to see the value in a blog post like this. It's the same tired Emacs vs Vim arguments warmed over. Emacs / Vim / Sublime / whatever are all basically the same. It just doesn't really matter.
People care about their development environment- that's why this is on the front page. GitHub has put a lot of work into Atom and it is rapidly becoming a compelling IDE for web development.
If you don't care about improving developer experience, then get off MY lawn.
I'm sure atom will be fantastic for some people but I found it really started to chug when opening some of my larger files (as you would expect with a giant DOM). Hopefully performance improves as I liked the UI a lot.
Atom runs like a dog. If ever there was an argument for native apps, Atom makes it. The one thing you want, nay .. expect, from a simple text editor is that it doesn't LAG.
The git source tree highlighting and the image previews are the only two things I liked about it.
Agreed atom looks good I especially like the fact that it is MIT licensed but the fact that it is non native makes me very reluctant to use it.
I always thought browsers and development for the web is more complicated then it should be so bringing that mess over to the desktop is just a bad idea.
I really wish Sublime would be Open Sourced already the developer should have gotten its moneys worth by now and is clearly not investing much time into it so let the community take over.
This coming from someone who actually payed for Sublime since i considered i got enough value from it.
Its quite embarrassing how badly Atom performs, how many subprocesses it opens and how much memory it will happily leak during the X hours its in use. I really wouldn't consider using anything NW/node-webkit or the like for all but the most trivial of applications.
There are definitely ways to incorporate Javascript into "native" programming. In Yosemite you can write Javascript that directly loads and calls native frameworks (like you can with Python/ Ruby). If you wanted you could write an entire application in Javascript, but taking shortcuts and trying to use HTML and the DOM for your interface only leads to these sorts of severe issues when doing anything nontrivial.
I would like Atom to be it but it's just not there yet. Takes a long time to start, something really really important for a text editor. Also not really responsive (as compared to sublime).
Does anyone know why the Atom developers opted to make their own editing component, as opposed to going with CodeMirror?
For one thing, CodeMirror is a hell of a lot snappier, especially for larger files. I use Light Table a lot (which does use CM) and while Atom is miles ahead UI-wise, LT is just so much smoother.
On top of that, with CodeMirror Atom could support some of LT's more interesting features, like interactive eval and inline results. Could've been such a great combination. (Though maybe their editor could support some of this – is there an API reference somewhere?)
Atom itself maybe, but they've recently rewritten the editor component with React.js for performance (that could only have started relatively recently) and it's still slower than CM. Maybe there's a reason for that, but if it's just NIH syndrome that's a real shame.
Sorry for the late reply. My problem with the Adobe cloud integration in Brackets is that
1) it requires you to be online and on a very fast connection (psd files are huge)
2) it's absolutely unnecessary for this feature and doesn't provide an advantage for the user
I was wondering where the catch is with Brackets and it seems like it's only meant to get people to use the Adobe cloud. Reading psd files from the text editor is great for web developers and Adobe knows that.
I hope other editors will implement this without the cloud requirement. When they do, Brackets will be cancelled in no time.
I've been alternating between these two editors for the past number of months. Atom's plugin architecture is the big selling point, it's pretty straightforward to create a plugin and leverage the huge number of libs on NPM.
Using APM and stars, I can also keep my Atom plugins in sync across different computers on different platforms (mac/ubuntu) running Atom.
There are still a number of annoyances though.
Something that immediately comes to mind: I'm using Polymer.js at the moment and I have a lot of inline CSS/JS in my HTML Components, when I comment out some CSS/JS (using cmd + /) it always uses a <!-- HTML comment -->. I've now learned this behaviour but it's still a pain in the ass. Lots of little issues like this.
Performance of Atom is decent enough on my new MBP and it hasn't been a big issue for me. I'm not working with large documents though.
@6 months ago I tried Atom for a few days -- too much lag, bye bye.
I tried Sublime shortly thereafter -- too much nag (buy, buy, buy popups starting within hours of install), bye bye.
Settled on VIM, split buffers and a few handy plugins: CtrlSpace, Golden Rule, Neocomplete, etc. This ancient editor packs a punch, it's my go-to for client-side development, well happy.
I really want to see more articles like this one to get a feel for both editors. But I think the author doesn't know text editors all too well. Fast search&replace is a quite old feature. You could do that with line editors already, meaning you could do that _before_ there even were text editors. Also it's quite clear that Sublime is not the champion of text editors, but one of the several competitors, which the author might not know about?
What I take from it is that Atom has improved a lot since the last report I have been reading, e.g. you can now compile it on Linux, the speed is still slow but it seems to be usable now, it takes reasonable features from other tools like Sublime, and the plugin idea seems to be working quite well. And I am quite surprised that the git support does not seem perfect yet. I would expect a team at Github to have an editor integrate especially well with git.
The community argument from the article is a good one. While Sub has a big community now, because of its closed source nature the community is not free to grow as it likes. A free, plugin focussed editor might be able to take its place.
But also one that seems to have been forgotten for a while. I've used many text editors that where much much slower at search&replace than the trusty Unix tools of old. If a modern text editor comes along and rediscovers those old tricks again then that is definitely worth mentioning.
too bad Github didn't acquihire the SublimeText and Package Control developers and re-release those tools with free licensing and direct integration to Github.
You've posted things like this multiple times. I realize that, to be pedantic, you're correct. But in every instance I've seen it's plain from context what is meant - I haven't heard file sizes referenced in bits in, I was going to say a long time, but ever.
Similarly with a comment on downloads on cellular networks and caps - again, if someone says "I have a plan that limits me to 4Gb", who actually, sincerely thinks that that means "four gigabits, i.e. 500 megabytes" as opposed to 4 gigabytes?
I guess I fail to see what value you're adding to the conversation, particularly given the tone. It's clear you know exactly what the poster meant, but rather than acknowledging it, you've offered some fairly unhelpful, sarcastic remark instead.
> if someone says "I have a plan that limits me to 4Gb", who actually, sincerely thinks that that means "four gigabits, i.e. 500 megabytes" as opposed to 4 gigabytes?
While usage caps are typically in MB, GB or "Unlimited", bandwidth is usually measured in Megabits and Gigabits. It might seem pedantic, but why not use the correct units in the first place to avoid potential confusion?
> It's clear you know exactly what the poster meant, but rather than acknowledging it, you've offered some fairly unhelpful, sarcastic remark instead.
I didn't mean for my comment to come across as sarcastic. I haven't tried Atom myself so I don't know if the limit is actually 2Mb or 2MB. Even the latter is a very small limit for any text editor. Would you not agree?
Do they have Atoms performance issues under control now?
I always read Python is much slower than JavaScript, but Sublime just is an instant experience and Atom feels like starting WebStorm, just with lesser features...
74 comments
[ 1.7 ms ] story [ 138 ms ] threadThat's a bold statement. Of ignorance.
Nobody I know personally or work with daily uses Sublime Text. Therefore I could just as easily declare Sublime Text a "unknown and unused text editor relegated to obscurity".
That's most probably the correct list. But again that's a perception. At least in the 'ruby' community 'vim' reigns supreme. Of course VIM and Emacs have ~20+ years of life, might not be exactly 'fair' for other editors.
Now a dispute could be made about JavaScript developers, since you need really tons of plugins to make vim (jslint, syntax, etc.) and you always need a browser to test your code (most dev are interested in client-side JS development).
I think it's interesting that you put quotes around both words surrounding community but not around the word community itself. I think what you perceive as the ruby community is actually a very small subsection of the actual ruby community and that is only a very small subsection of the entire community of people that use plain text editors.
The learning curve for VIM and Emacs is so high as to almost be prohibitive for what is probably the vast majority of users. What I've seen from only a few minutes of googling is that, in the surveys I've found (https://blog.codeanywhere.com/most-popular-ides-code-editors... & http://www.sitepoint.com/best-php-ide-2014-survey-results/, for example), VIM and Emacs are really no where near the most used editors. And I think that should probably be expected.
I just think that people in this community too often think of themselves as the norm, when our very presence on a site like Hacker News places us very much outside of the norm. Outside even the norm for people in the tech community.
Apparently there is enough demand for Vim key-bindings that it seems most text editors and IDE's have them available.
> The learning curve for VIM and Emacs is so high as to almost be prohibitive for what is probably the vast majority of users.
Vim is probably more widely used by developers and system admins than say... writers. If you have been able to tackle the learning curve of learning to program or learning to administer Linux then the VIM learning curve is just another day at the office.
Also, most developers are not Linux administrators... It's not that learning Vim or Emacs is hard, what's hard for most users is increasing one's productivity enough to warrant learning Vim or Emacs, especially in the short term. So most developers/users don't; they use text editors that have much more in common with word processors, which many have been using their entire lives.
Your insights are spot on :-)
ps. I thought being part of the 'HN community' is the norm for a but maybe it's not. I can't really tell without numbers...
2. Emacs/Nano
3. Notepad++
I also believe there's a correlation between beard length and emacs usage.
1. Visual Studio.
2. Everything else.
Unsurprisingly, Visual Studio is therefore not at the top: http://www.google.com/trends/explore#q=%2Fm%2F07zh7%2C%20%2F...
I understand that there are huge software houses that develop using MS Technologies, but I'm certain that it is not the majority.
[1] http://en.wikipedia.org/wiki/.NET_Framework
1. Notepad++
2. Vim
3. Sublime
4. Emacs
Haha, nobody might have guessed Notepad++ is the leader. Of course, we all are the Windows haters, and my post is so going to be downvoted for pointing this out.
P.S. Its maximum of 5 search terms, but I tried different variations. Play around, google trends has many gems to be uncovered.
(Thanks to @necrodawg for the google trends idea)
Goolge Trends - http://www.google.com/trends/explore#q=%2Fm%2F01yp0m%2C%20%2...
And with getting older. It's just an editor that makes me type text. Yeah yeah productivity but as I think more than I type it's not such an issue as long as I can do most of the basic editting ;)
Lets also not forget that Sublime text isnt free, and i am sure paying users dont really want to be left in the dark for 6 months to a year.
Vim is nice, but some things are better done with the mouse. Selecting and moving text down a few lines is so much faster in ST. And there's a Vim plugin for it anyway, so you can have the benefits of both Vim controls and a good interface. ST really is a great editor and to get Vim even close in terms of functionality, it takes way too much time configuring it.
Of course, this is all anecdotal. It's likely that the vast majority of working developers never post screencasts or really discuss their editor of choice, and just get on with their work. So in terms of code actually created, it's a very poor assessment.
Could Atom have moved into the lead?
However... It is slower than SublimeText 3, noticeably slower. I tend to keep applications open for weeks, using "sleep" mode overnight, and Atom still tends to crash after several hours. This means I don't use it for real work, yet.
While Atom does indeed keep getting better, ST3 is becoming more and more frustrating as package updates now have a tendency to vomit errors when ST3 starts up. It complains about not being able to load a config file for the package (like Rust mode or the Cobalt theme). When this happens, ST3 disables the package, but a restart will clear the hiccups.
SublimeText is clearly the better editor, yet there has been no progress on the beta. Worse, this has caused a division of effort among third party providers who have to support ST2 and ST3, with no clear end in sight for an ST3 stable release.
Putting aside trolling, it's hard to see the value in a blog post like this. It's the same tired Emacs vs Vim arguments warmed over. Emacs / Vim / Sublime / whatever are all basically the same. It just doesn't really matter.
P.S. Get off my lawn.
If you don't care about improving developer experience, then get off MY lawn.
Still, back to sublime for now...
The git source tree highlighting and the image previews are the only two things I liked about it.
I always thought browsers and development for the web is more complicated then it should be so bringing that mess over to the desktop is just a bad idea.
I really wish Sublime would be Open Sourced already the developer should have gotten its moneys worth by now and is clearly not investing much time into it so let the community take over.
This coming from someone who actually payed for Sublime since i considered i got enough value from it.
There are definitely ways to incorporate Javascript into "native" programming. In Yosemite you can write Javascript that directly loads and calls native frameworks (like you can with Python/ Ruby). If you wanted you could write an entire application in Javascript, but taking shortcuts and trying to use HTML and the DOM for your interface only leads to these sorts of severe issues when doing anything nontrivial.
I feel editors are taking a step backwards recycling and repackaging the same ideas many previous editors had before plus eye candy.
For one thing, CodeMirror is a hell of a lot snappier, especially for larger files. I use Light Table a lot (which does use CM) and while Atom is miles ahead UI-wise, LT is just so much smoother.
On top of that, with CodeMirror Atom could support some of LT's more interesting features, like interactive eval and inline results. Could've been such a great combination. (Though maybe their editor could support some of this – is there an API reference somewhere?)
For api docs see https://atom.io/docs/api/v0.175.0/TextEditor
Thanks for the link, btw.
Also has things like in-line editor (super useful!) and you can open .psd files and get CSS hints from it.
Don't know what's your problem with Creative Cloud©. If you want to use the CSS hinting you don't need to pay for it, just to sign up and upload the .psd.
1) it requires you to be online and on a very fast connection (psd files are huge)
2) it's absolutely unnecessary for this feature and doesn't provide an advantage for the user
I was wondering where the catch is with Brackets and it seems like it's only meant to get people to use the Adobe cloud. Reading psd files from the text editor is great for web developers and Adobe knows that.
I hope other editors will implement this without the cloud requirement. When they do, Brackets will be cancelled in no time.
Using APM and stars, I can also keep my Atom plugins in sync across different computers on different platforms (mac/ubuntu) running Atom.
There are still a number of annoyances though.
Something that immediately comes to mind: I'm using Polymer.js at the moment and I have a lot of inline CSS/JS in my HTML Components, when I comment out some CSS/JS (using cmd + /) it always uses a <!-- HTML comment -->. I've now learned this behaviour but it's still a pain in the ass. Lots of little issues like this.
Performance of Atom is decent enough on my new MBP and it hasn't been a big issue for me. I'm not working with large documents though.
I tried Sublime shortly thereafter -- too much nag (buy, buy, buy popups starting within hours of install), bye bye.
Settled on VIM, split buffers and a few handy plugins: CtrlSpace, Golden Rule, Neocomplete, etc. This ancient editor packs a punch, it's my go-to for client-side development, well happy.
What I take from it is that Atom has improved a lot since the last report I have been reading, e.g. you can now compile it on Linux, the speed is still slow but it seems to be usable now, it takes reasonable features from other tools like Sublime, and the plugin idea seems to be working quite well. And I am quite surprised that the git support does not seem perfect yet. I would expect a team at Github to have an editor integrate especially well with git.
The community argument from the article is a good one. While Sub has a big community now, because of its closed source nature the community is not free to grow as it likes. A free, plugin focussed editor might be able to take its place.
But also one that seems to have been forgotten for a while. I've used many text editors that where much much slower at search&replace than the trusty Unix tools of old. If a modern text editor comes along and rediscovers those old tricks again then that is definitely worth mentioning.
I'll pass, thanks.
2 Megabits (0.25 MB) sounds like an incredibly small file size limit for any modern text editor. Is that actually true?
Similarly with a comment on downloads on cellular networks and caps - again, if someone says "I have a plan that limits me to 4Gb", who actually, sincerely thinks that that means "four gigabits, i.e. 500 megabytes" as opposed to 4 gigabytes?
I guess I fail to see what value you're adding to the conversation, particularly given the tone. It's clear you know exactly what the poster meant, but rather than acknowledging it, you've offered some fairly unhelpful, sarcastic remark instead.
While usage caps are typically in MB, GB or "Unlimited", bandwidth is usually measured in Megabits and Gigabits. It might seem pedantic, but why not use the correct units in the first place to avoid potential confusion?
> It's clear you know exactly what the poster meant, but rather than acknowledging it, you've offered some fairly unhelpful, sarcastic remark instead.
I didn't mean for my comment to come across as sarcastic. I haven't tried Atom myself so I don't know if the limit is actually 2Mb or 2MB. Even the latter is a very small limit for any text editor. Would you not agree?
I always read Python is much slower than JavaScript, but Sublime just is an instant experience and Atom feels like starting WebStorm, just with lesser features...
https://news.ycombinator.com/item?id=8678339.