Is this a sign of Sublime Text inching it's way towards open source? If Sublime Text went full on open-source would it decimate Atom? I'd like to think so.
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 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.
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?
Facebook is throwing it's weight behind Atom. They are not forking Atom, but rather contributing their improvements back to Atom. They are developing their Nuclide IDE with Atom packages. Atom is still young, but has a bright future. Free and open source is very attractive for lots of us.
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.
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.
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.
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.
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?
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 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.
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.
I don't know if 'adopted' is the right word, but it and its underlying platform or whatever are being used by Microsoft, Facebook and Slack among others
Visual Studio Code is based on Electron, not Atom. The editor component is Microsoft's and based on Monaco, the editor used in Visual Studio Online.
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).
Not to criticize the tools themselves here (Atom or Nuclide), but the process of building an enhanced X over some large base application code didn't work out well for a lot of Eclipse tools. Or at least my experience is with working with lots of Eclipse + "x" on top environments which were integrated once, then rarely touched the base Eclipse again... leading to lots of inconsistent annoyances between Eclipse/tool instances.
As an eclipse user for far to long, I understand the pain. I'd prefer if more languages/frameworks went the Golang approach and provided generic tools that can then be integrated into various editors to provide things like auto-complete and context support (oracle).
I emailed SublimeText offices a long time ago to push the concept of crowdsourcing the open sourcing of the project. It was blown out of the water.
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).
It seems to me a pretty realistic estimate that Jon is doing rather well off of Sublime Text nowadays. However, he's been working on it for over 8 years. I've gotten the impression that some of the early times were very lean and he took on contracts to keep it going. So why should he give up the resources that he justly earned? He worked his butt off, likely made lots of personal sacrifices, and now he should open source it once he's built a solid product that lots of people love?
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.
Literally, the difference between open source and proprietary is the license... nothing more.
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.
Well, how did you approach him? Did you ask him what kind of monetary figure it would take for him to consider open sourcing it? Or did you just ask him if he'd open source it for a crowdfunding effort?
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.
Indeed, an open source license does not ensure a better quality of product, and nor does a proprietary one. Free/Libre Open source software gives users various freedoms, which many people like (myself included). It also opens the door to a wide community of hackers, to help improve upon and speed up development.
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 tried Atom when it came out, it was painfully slow...on a whim I tried it a couple of weeks ago to test the go-plus package for go development and, and I was pleasantly surprised how much performance improved, personally when both editors are open, I don't see a speed difference anymore. If you have not tried Atom recently, give it a go.
I still find it fairly slow but I'm going to try and use it as much as possible, anyway.
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.
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.