Yeah, the only thing holding me back from trying out Sublime Text is that I don't want to invest time learning proprietary software when there's good open-source alternatives.
back
2 comments
But are there good open source alternatives? Besides Vim and Emacs, I mean, which seems to be what ST is most often compared to. Atom appears similar in features and whatnot, but it's still struggling heavily with performance issues, and mainly because they decided to use an incredibly complicated stack - html/js. Square peg / round hole approach.
> performance issues, and mainly because they decided to use an incredibly complicated stack - html/js
This sentiment, that Atom is not performant because it's built on web technologies, gets repeated a lot, but it's provably false.
Light Table and VS Code both use the exact same HTML/CSS/JS stack on top of Electron. Both are much more performant than Atom.
Whatever performance issues plaguing Atom are more likely caused by flawed architecture and/or lack of optimization. The underlying web technologies it's built on have been demonstrated to be capable of delivering highly performant text editors.
I'm not going to claim that you can't make performant editors with web tech but recent snapshots of Light Table and VC Code are not all that fast for me for files that get beyond a hundred lines or so. Same with Atom.
It seems to usually be the syntax highlighting engines on first load of a file, or if you're moving code around, a simple cut and paste will show this too. I'd happily turn off highlighting since I find it distracting 99% of the time but ironically these editors don't allow that. Some of the editors make highlighting async but it makes it even more obvious when interacting with the view. There's a distinct pop-in then style effect that often happens.
Now the question: Why is highlighting slow? It seems like a lot of these editors still run lots of logic including highlighting i the UI thread still. Web workers could potentially help but of course there are still limits to how values are exchanged with the UI so it's likely non-trivial work. So, remind me again why it's an advantage to use a browser engine for this application? Portability is about the only thing I can think of but that hasn't stopped Sublime Text obviously.
I just did a quick, unscientific test using a 3.5 MB bundled (but not minimized) .js file.
Sublime 3 results:
Opening the file took 13 seconds, of which only for the first 5 seconds the editor interface was unresponsive. Syntax highlighting was available throughout the entire file immediately after opening.
As an additional test, I tried doing a select all, cut and paste of the entire 3.5 MB source. The paste took 6 seconds. The editor interface was unresponsive during the entire time. Syntax highlighting became available immediately after the paste completed.
VS Code results:
File opened in 7 seconds. The interface was fully responsive for the entirety of this duration. Syntax highlighting took an additional split second, but this did not affect responsiveness either.
Cut and paste completed almost immediately, but syntax highlighting did not become available for another 7 seconds, but responsiveness is once again completely unaffected during the entire process.
So it looks like in terms of pure syntax highlighting speed, the two are rather evenly matched. However, it would appear that VS Code has an edge over Sublime 3 in both initial loading speed as well as in terms of UI responsiveness.
As for your question:
> So, remind me again why it's an advantage to use a browser engine for this application?
My own answer would be that it's simply the most accessible way to build cross platform applications. The web platform simply has had more optimizations and standardization work put into it than any other interface technology out there today.
It also happens to have a very simple model for concurrency that is very well suited for event-based UIs: the single UI thread with message passing through web workers. While it's true that the traditional, free-for-all multi-threading based concurrency model is more powerful, it also presents a much heavier cognitive load on the developer and is notoriously error prone to implement.
It was probably a much simpler task to implement Web Workers in VS Code than it would have been to architect Sublime 3 into a fully multi-threaded application on all the platforms that it must support, in order to have the UI be fully responsive during intensive tasks like in VS Code.
> The web platform simply has had more optimizations and
> standardization work put into it than any other interface
> technology out there today.
I just opened a 2.8 MiB file in ST3-dev (JS, using babel syntax def) and it opened sub 1 second. I think it must be the dev branch that has this sort of performance boost? Give it a shot.
It's probably just due to a difference in sheer processor power (I should have mentioned these tests were done on a lowly Core M ultrabook).
That makes sense. Still, it's good to know VS Code can load a file that size. It seems like the nicer of the web-tech based editors that I've toyed with.
> But are there good open source alternatives? Besides Vim and Emacs, I mean,
Why dismiss the two most popular alternatives?
The culture around both of those editors is offputting. There are way too many people who substitute an emotional attachment to their esoteric tool interface for an actual reason to use something, and then they evangelize. It's basically religious.
Using a tool only due to emotional attachment is bad engineering, but so is -not- using a tool because some are emotionally attached to it. Choose or discard tools based on their utility and merits. As engineers we don't have the luxury of ignoring an entire path of tool evaluation simply because a many people are annoyingly vocal about the value they see in it.
I use vim because I like the keybindings, speed, the ability to use it on any of the hundreds of systems I work on, across many different operating systems be it remote over ssh or locally. I need the ability to easily fix/modify it to meet my specific workflow needs and share my configuration across all my systems. (Example: https://raw.githubusercontent.com/lrvick/dotvim/master/scree... ) Being open source I know I can always use this tool how I like and port it to any future platform I care about.
Closed source GUI-only editors only work for a very limited number of use cases, and only for a period of time that the current maintainers feel like maintaining them. Vim and Emacs will remain maintained so long as there are enough people using them that care to port and patch. 20+ years is a good track record and thousands of contributors have come and gone over that time.
If the (single) author of Sublime gets hit by a bus in a few years, the chance of it ever being ported to a future version of the operating system you are currently using is now nonexistant. Worse, the years of you becoming efficient with that tool will now be for nothing.
Closed source is fine for entertainment, but when it comes to anything you rely on and are going to spend a lot of your time investing in... you should always have the control to take over the codebase yourself if needed.
Perhaps it appears that way to outsiders. But I have found that within editor communities the culture is mostly about getting things done.
Besides, why should the emotional attachment of some users reflect badly on the community as a whole?
For example this study argues that devoted fans of the Apple Macintosh appear to be like members of a religious cult [1]. But is that a good reason for someone to avoid Apple products?
And so what is different about editors?
[1] http://gulnurtumbat.com/GulnurTumbat/Research_files/The%20Cu...
I'd switch to sublime in a heart beat and pay twice what he wants now if it had a similar package manager to Atom.
That to me is the biggest draw.
I often try to pick sublime back up, but when I go to install packages I find I have to mess with too many configuration files and searching the third party package manager kind of sucks. It's faster though so I keep trying before getting frustrated and going back to the land of easy wins.
Kate is a great editor.
It used to be better in the past, nowadays there are some random bugs popping up from version to version.
Actually it was working best with KDE 3.x, KDE 4.x introduced performance problems, KDE 5.x fixed some and added more bugs. Minor stuff anyway and YMMV.
I genuinely don't get this argument. If it was that, if Sublime were to cease updates everything stopped, I'd get it - but in the 4/5 years that I've been using it, I've only ever once had an issue (with a dev build) that stopped me from working. I just downgraded.
Just because something could stop being maintained, doesn't mean it instantly becomes worthless.
I don't know, maybe I'm missing something?
I don't know you, so it's hard to tell, but it's possible you are missing something. An editor is an integral part of a programmer. You don't want to be thinking about the editor when you edit. You want to have a thought and have it appear in your editor.
Very good editors have a crazy number of features. Many of these features cover small corner cases that only show up once in a while. A programmer who really knows their editor can use all of these features without thinking about them. It can save you an hour when you really, really need that hour. It can also save you brain cycles when you really, really need brain cycles.
Switching editors is not impossible (I've done it twice in 30 years, though I'm moving my way back to my original editor, emacs). If you are a real expert in your editor you will lose productivity for however long it takes you to acquire the equivalent features of your original editor. My experience is that it takes months, if not years to get really, really good -- depending on how much time you have to fiddle with your editor.
Choosing an open source editor that works on a variety of different platforms and is supported by a large community of people gives you insurance that you won't have to change editors unless you have some really compelling reason to do so.
If Sublime were stop being maintained, sure you could continue to use it for a few years, but would you (could you) be using it 10 years from now? That seems unlikely without an active community making builds for the new platforms you are going to be working on.
I know a lot of the younger people I work with don't understand the benefits of learning your editor to the extent I'm talking about, so they don't understand the cost of switching. Pair programming with someone who is a true expert with their editor can be very illuminating.