I just had to move back to Sublime for the third time because Atom would choke on a 400 line Ruby file. I was using vanilla Atom with RuboCop and it's linter, and stutter-city.
Should the owner decide to open source Sublime Text, it would instantly put it with the likes of Vim and Emacs in my opinion.
I just can't understand why people would even use a JS based text editor and expect it to perform. It will never happen. And it's not because of JS (which can have decent speed), it's mostly the HTML/DOM part.
If you don't like ST3 there's Emacs, Vim, TM2, Idea, and tons of other options. Atom, why?
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.
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.
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.
Why dismiss the two most popular alternatives?
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.
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...
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.
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.
Just because something could stop being maintained, doesn't mean it instantly becomes worthless.
I don't know, maybe I'm missing something?
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.
I don't think so. Keep in mind that Atom is used internally at Github, and is starting to be adopted by some big names. Things like that don't get chocked out by the competition. I'm not sure how much funding it'll loose internally if they aren't the #1 but I don't think it'll effect them as much as if Sublime Texts competitor got it's funding from sales for instance.
Uh who? About every other editor and IDE under the sun is leagues ahead of Atom. Honestly an editor based around a freaking browser is already too heavy for usage. No, I don't want to use a browser engine to run my editing environment, and a ton of "big names" are not picking up Atom at all.
Going to need to see some citations, not downvotes Hacker News. I don't care if it's the "hip new editor", being made by GitHub is not enough.
Electron is a souped up Chromium Embedded Framework, patched to make it easier to develop desktop applications. Atom is built on top of that.
So, Visual Studio Code only uses the "low level" components from the Atom project, but it doesn't use Atom itself (unlike Nuclide which is, instead, a set of Atom plugins).
One year ago, open sourcing ST could have prevented Atom from ever taking off, but now it's not going to change much.
Citation needed. All I hear about Atom is that people are giving up on it.
My team just voluntarily switched over from Sublime and no regrets so far.
I should imagine that even if they set a high goal, they'd do pretty well out of it. I'd happily pay a premium price to see the source released permissively (free software approved, ideally).
Ok, so let's say you don't buy the angle that he deserves the success he's had. Do you think Sublime Text's success is a coincidence? Jon is a single engineer who's built pretty much every aspect of it, from a custom cross-platform UI that doesn't suck, to a custom editor control, more recently a parallel custom regex engine to make syntax highlighting faster and more robust. He's taken performance seriously from day one.
By contrast, Atom started development in 2008 and had a team of engineers working on it. It has more community involvement and bells and whistles, but still seems a bit behind in performance.
I would argue that Jon and his priorities and decisions are one of the biggest reasons Sublime Text has been successful. Would open sourcing it help Jon keep up the focus and insight he has shown in the past? Or, would it likely take up a large amount of his time?
I don't have an insight that anyone else doesn't have. And I could be completely wrong, but I feel like if open source would ensure a better product, Lime would have taken off. Or there would be other, strong, cross-platform text editors written in desktop technologies.
There are plenty examples of excellent open source software, so I fail to see your argument on this. Proprietary ≠ better that open source.
There are plenty of great open source text editors, but Sublime happens to be leading the pack. It just so happens to be proprietary. I don't think that this is the sole reason for its success. The coder behind the project is evidently extremely gifted, he values his time and you're right, it is his choice to decide the license. I'm merely making the point that if Sublime Text was open sourced, it needn't spell the end of the line. I dare say it could pocket Jon a tidy sum, if it were kickstarter'd for say... £5,000,000? I know there are a LOT of coders out there who would splash out, in order to make this happen.
It's pretty much donationware as it stands, and it could still continue to use this method as a source of income, even if the license became permissive.
I think one of the main differences between Atom and Sublime is performance, and that is largely down to the technology stacks in use.
In his mind, he may be thinking "crowdsourcing? Why would I give you my baby for $20k"
If I were in his shoes, I wouldn't in my wildest dreams expect that someone asking me about kickstarter would be in talking about the 7 figure range.
If Linux remained the sole project of Linus, it would be nowhere near as effective as it is being out in the open, so to speak.
I like the core principle it's built on (completely hackable as everything is built on a scripting layer) which makes it more potentially powerful than Sublime, even if its slower now.