Hacker News Reader

Comment by DigitalSea | Hacker News Reader

I think ST3 really missed the boat. I used to love using Sublime Text 2 (occasionally I still do because it is fast), but I moved on when development stagnated and Jon seemingly disappeared off of the face of the planet, stopped responding to support requests and the like. There is no disputing ST is a great editor, but it has fallen behind in the face of Atom, Webstorm and Visual Studio Code (two of which are free).

View on HN

I disagree. I had tried out Atom for a little bit (after the v1 general release) and more than once I lost my entire workspace. Either through a computer crash, Atom crash, or something else. Maybe I didn't configure something right, maybe I didn't. Quite frankly I don't care, I think that always properly persisting all unsaved work should be a default. Sublime always persisted all of my workspaces and open tabs perfectly. Everytime where I would lose unsaved data, Sublime would prompt me. After losing my stuff like twice in Atom, I switched back. The new features and everything are great, but I prefer not losing my random unsaved code snippets.

I concur: Sublime Text's persistent workspace is really great.

This is what I love about sublime as well (I still use ST2). Have lots of tabs open that don't point to any file. It's just a workspace, notepad, ...

> ... but I moved on when development stagnated...

ST3 dev releases[1]:

2016: 14 versions

2015: 25 versions

2014: 4 versions

2013: 40 versions

While pace really slowed down in 2014, there was at least occasional updates every few months fixing major issues.

I know people love to complain about ST's "slow development", but really don't understand where the perception comes from.

For me the experience has been the opposite: I sometimes get annoyed by updates every other week.

[1] https://www.sublimetext.com/3dev

I think the perception comes from people who aren't on the Dev release channel. When I saw you list 14 releases in 2016 alone (!?), I wondered where on earth you made up that number... until I realized that's the Dev channel. On the Stable channel, the releases have been:

2016: 2 versions

2015: 2 versions (one just a patch for the other)

2014: 1 version

2013: 12 versions

https://www.sublimetext.com/3

Question: How frequent would you want the releases to be, considering that this is more-or-less a stable and finished project?

I'm mostly okay with the occasional releases. Once a year feels a little infrequent though? One of the IDEs I use has a quarterly bugfix release schedule.

To be honest, I'm less concerned about new features, and more that there will be paid upgrades so the developers keep maintaining the software. I'd probably expect a new major version every 2 or 3 years, with a discounted upgrade price... that would still only work out to $10-$20/year for Sublime Text, which is crazy cheap. I already budget about $100/year just for annual Parallels Desktop upgrades.

Genuine question:

What do Atom and Visual Studio Code offer that Sublime Text doesn't?

I have tried both within the last year and wasn't able to find any significant advantages (except for VS Code's excellent TypeScript experience), but they both ran slower and used more memory. Perhaps I should have used Nuclide?

(Not asking about Webstorm because I've used the IntelliJ family of IDEs and understand their advantages)

A better 'bus factor'.

It would greatly suprise me if either Atom of VSCode shut up tomorrow. They couldn't entirely shut up, as they are both entirely open source projects.

The Sublime Text website could just close tomorrow if one person got badly hurt / lost interest, and then the executable could not work on Mac OS X 10.11.6 for some reason, and it is done.

I've had too many pieces of software go that way to get another one which is so fundamentally important to me (text editor).

I use Atom over Sublime Text solely for the Hydrogen plugin (https://github.com/nteract/hydrogen).

That plugins are written in javascript (larger developer base) and allows more customization of Atom (more open plugin api) also yields more niche plugins.

In these threads I see "larger developer base" when referring to javascript developers over python. I wonder if that's true, and by what margin.

For what it's worth I would imagine more javascript devs would write plugins for Atom than python developers would write plugins for Sublime Text.

These resources are by no means perfect, but they're the best I can think of off the top of my head:

http://stackoverflow.com/research/developer-survey-2016#tech...

https://github.com/blog/2047-language-trends-on-github

If anyone has anything better, we can refine our collective thinking.

I wasn't aware of Hydrogen. Looks like it might be enough for me to try Atom again.

To be honest I use Atom mostly for writing Markdown. I am a paid subscriber for Webstorm, but I have found that I am using it a bit less lately and have been using Visual Studio Code a lot more, partially because I use TypeScript, love the intellisense and overall the editor is super fast and stable. Atom definitely has some slowness issues they need to overcome and ironically Visual Studio Code is based on Atom, but it is a great editor and there are a heap of plugins out there for it.

In terms of memory usage, Sublime would arguably win the fight (at least it feels that way). I think ST is also lacking in the plugin department these days as well, but I could be wrong about that. The interface of both Atom and VSCode is arguably better as well and maybe things have changed, but the ST3 betas have been pretty buggy in my experience as well. The native Git integration is also pretty great as well (especially in VSCode).

Sublime also lacks a native package manager of which VSCode and Atom have, but there is a third party package manager which works well, so it's a moot point.

> partially because I use TypeScript

Which WebStorm supports perfectly well?

More a clarification comment than a response, for those who don't know.

As a ST3 user, both Atom and VSC have superior git integration built in, no plugins needed.

That's really the only/main thing I miss.

It's a small thing, but I really love how Atom highlights the files that have changed in the tree view out of the box. Haven't figured out how to do that in Atom...

In Atom or in Atom?

Oh woops, I meant to say 'in Sublime'! It seems my brain detached from my brain in the process.

Atom has git integration built-in? I couldn't find it when I tried it a few months ago (and I was shocked, considering it's sponsored by GitHub).

Yes. When you open a directory that is a git repository, the files in the sidebar will have different color if they're modified, new, etc. When viewing actual files, edited/new/deletes lines will also have markers in the gutter.

They are free and development is much more active. Community is also getting stronger, as they are both open source. This means that plugins are always up to date.

I love Sublime but there is also a https://en.wikipedia.org/wiki/Bus_factor

Also if you have tried Atom at some point, try it again, they made it much better and faster. Only thing I miss is how incredibly fast Sublime Text is.

Atom does not handle large files well at all compared to ST. I like Atom, but get very serious hangs with it on large files.

in ST3 beta, one issue i faced was large files that changed frequently, like a log file. ST3 would neither keep the uncharged version, nor just append changes, but load the entire file from scratch and show me loading bar every time the file changed.

Notepad++ handled that surprisingly well. pretty much the only time i had to use another text editor besides ST

How large are you talking? I had similar issues early on with Atom, but I don't have them anymore (same project). Also, it would only hang for about a second when initially opening the file, later on it would work smoothly.

Big JSON files for one, with tens of thousands of rows. ST3 can load and regex replace nicely. Atom just was unresponsive.

To be fair, I forgot I got a new PC between the first time I used Atom and when I switched over to it.

However, I did try opening an 11 MB (JSON) file and it did indeed feel sluggish.

I'm using ST because I want to use the same editor for my code and data, and I rather frequently get 100mb-1gb textual data files, logs, tabular data in plaintext or json, etc - not big enough to require special tools to process (I mean, they're a small fraction of my RAM), so a text editor should allow to eyeball them and do some basic processing - edit a particular line, do interactive global regexp replacements to e.g. adjust the columns in a million-line file, etc.

I haven't tried Atom, but the Hydrogen plugin looks very interesting. How does it react to, say, being asked to do syntax highlight on a 100mb json?

Many-megabyte, probably; think an assembly dump of your browser, for instance.

Not sure why you're being downvoted. Sure, maybe you're not going to have a need to open an assembly dump of your browser very often, but plenty of projects have multi-megabyte text/data files that need to be opened now and then.

One of programs I develop uses a dictionary that when unzipped is ~8Mb. Sometimes I need to open that up in an editor and it's nice not to have to fire up a different editor to do that.

In fact this is one of the first things I do when trying out a new editor - see how well it can handle files > 1Mb in size.

Maybe if you're only working on small projects with small files this isn't such a concern, but there are plenty of people who have legitimate concerns if an editor can't open large files (and 1Mb isn't even large).

VS Code is great, Atom too but I wish it was less buggy. Regarding ST, I used to feel the same but lately I have seen more releases and it seems that development is now moving again. Also, I'm really struggling to find any aspect where ST "lags behind", I pretty much seem to get all the same goodies that I get in Atom and VS Code.

VS Code seems much snappier than Atom, as someone who uses both. And the Rust extension is much better. Switching between the different key-bindings is a pain though - I wish VS Code used ST bindings, but I'm guessing they went for consistency with VS?

> but I'm guessing they went for consistency with VS?

Yes you are right, although in some cases they also support the "ST-style" shortcuts, e.g. I just realised that I can do block selection with ctrl-alt

Reply on news.ycombinator.com