So I have been using Sublime for two years now and I love it! However, I started trying out VScode again and it gives me a completely different feeling.
VScode gives me a feeling that it is evolving continuously due to the new feature rolling outs. However, I feel sublime is still the same ever since I started using it.
I am still a student now and mostly using Sublime Text for Java, C++ and Python development. I think it is awesome that Sublime is a “just editor”. However, I am wondering is this what the market wants? Looks like people are leaving and it hurts to see all those packages I use haven’t been updated for years.
Can anyone tell me which direction is Sublime heading to? Or maybe I just haven’t experienced the beauty of this editor? I really don’t want to switch but all those new features from other competitors are so luring to me now lol
For me, the main advantage of Sublime Text against Atom or Visual Studio Code are speed and security.
Not being a full time developer, in most cases I have the changes already done with Sublime Text while the Electron based monsters are still loading their files.
And talking of Electron - from a security point of view running a local server with a browser as frontend and hundreds (thousands) of libraries in the background seems to be a bad idea IMHO.
Yes, I can’t agree with you more! Sublime’s speed is one of the reasons that I am still sticking around. However, now I realized that I am worrying about the UX experience of the app, especially for package control feature and UI. It is such a pain that I need to go to the package control site every time for more details. Also I feel it will be awesome to have a built in marketplace in the editor like all those other apps. Is this possible? If not, or maybe some improvements to the existing site? What do you think?
I like how Sublime Text does only one thing: the code editor.
I compile and run my code directly from the terminal, because I want total control of what’s going on. And I don’t mind typing commands.
I like the Git integration through an external application: it’s the correct thing to do. This keeps the editor lean an light, it lets me to choose the Git interface I want. If a Git interface was integrated in the editor and I don’t like it, its weight and complexity (… and bugs) will be there even if I don’t use it.
I don’t expect extraordinary things from ST in the future, because there isn’t so much to invent anymore about the sole activity of code editing. I hope ST developers work for its stability (yes, sometimes ST crashes) and add a powerful plugin api - the current api is really limited.
I use ST like this too. I.e., only use it as a code editor and doing everything else (like compile, debug, etc…) in external terminal(s). If I need a IDE, I may just go JetBrains.
I write PHP more recently so what I talk below is for PHP only.
Mostly because (JetBrains’ PhpStorm) IDE provides excellent auto-completion, variable type hinting and help of refactoring. I feel the current ST+LSP combination is still not mature enough. It sometimes suggests nothing or wrong things for the same project and I do not know why.
I believe that the proper UX for navigating, searching and digesting information about packages is not to try and cram it into a desktop application. Then you have a text editor that is trying to be a web browser too, except it won’t ever be as good as a real web browser. With a real web browser you can change font sizes, bookmark pages, send links to users.
Now granted, I think the process of finding a package, and then getting it installed via clicking a button on the Package Control site could be a far slicker experience, but alas these days my little ones are top priority for my free time. Otherwise I’d probably see if I could come up with a secure way via web sockets for Package Control to interact with https://packagecontrol.io to invoke installs, like how Gnome Extensions work.
The following are some of my personal thoughts, and not an official position of Sublime HQ.
Overall, I think there are two general schools of thought on using tools to write code.
There is the IDE-like approach where you try to get every tool all integrated into a single window/user interface. Then you can accomplish everything you want without leaving your single window. You get integration, where you can invoke your debugger and it will open the file and line where the program crashes. You have extra panes and views for things like version control and invoking scripts. Some functionality will be possible that won’t be easily possible with separate tools. On the flip side, many will have to make small (or large) compromises to fit within the overarching IDE. Often times these IDEs feel a bit slower and more complicated because you need to have multiple independent teams building out each of these separate tools and trying to integrate them into a single user interface. Also, if you like the approach taken for each sub-tool, you’ll have a great experience. As soon as one tool doesn’t work for you, or is buggy, you can’t swap out that sub-tool. Additionally, the IDE-like approach requires a good amount of investment for each language that is supported.
The text editor-like approach is to have specialized tools for different purposes. A text editor to navigate and edit text. A terminal to invoke scripts to build and test your software. A debugger (GUI or command line). A tool to interact with your version control system (GUI or command line). Each of these tools tries to focus on having a complete set of functionality for the task they are to accomplish, and a UI that is designed for the task. Each tool can be selected by the developer. If the debugger is crashing, they can roll back to an older version and keep the latest version of their text editor and version control system. However, you don’t get some of the tight integration possible with an IDE. If you want that integration, sometimes you can build plugins or scripts to make it happen, and other times it is impossible. Adding support for new languages is usually easier, and mostly requires writing a syntax definition so the editor can highlight the code properly.
Then between those two schools of thought, on a continuum, exist the products built today. Many text editors today allow plugins, and lots of developers build plugins to make a more IDE-like experience. Many IDEs are trying to be more customizable and allow for new languages to be supported more easily, and to allow third-party programs to be plugged-in behind the scenes.
Identifying which approach you want to pursue in your tools is the best way to find something you’ll be happy with. I think from the descriptions above you can see that Sublime Text is definitely more of the text editor approach, and isn’t trying to be an IDE out-of-the-box. There are plenty of plugins that add IDE-like features, but adding version control, debuggers, terminals and a web browser to a text editor requires all sorts of different UI, and requires lots of compromises to get them all in there. Sometimes you can add a limited set of features from a tool, and you’ll get an improved experience without having to make lots of compromises to the text editing features. However, you are probably going to need a full-fledged separate app for the situations where you need to do more than a few high-level tasks.
Part of what make Sublime Text fast and efficient is that we write things with the current functionality in mind. We don’t have lots of abstractions in place for “what ifs” in the future. This gives us the ability to fix things as low-level as we need to. We generally don’t need to wait for some lower-level project to fix bugs for us. We can also accomplish things that aren’t really possible from a performance perspective if we were using some high-level abstraction. The down side is that it takes a little longer to new features to be added, because we aren’t just stitching a handful of pre-existing packages together.
Anyway, hopefully these thoughts will be useful to you as you ponder your tools.
I am absolutely in favor of Sublime Text remaining lean and mean and not trying to bring in everything under the sun. I mean, for context, I was an Emacs die-hard who only switched to ST in 2014 because I needed better autoformatting for Javascript, and I have come to love all of the syntax plugins that the community provides. I also love its intelligent autocomplete (which does only the barest minimum and that’s all that I want it to do), and I love how much easier it is to keep my settings and packages in sync across all my computers than Emacs did. Plus, Python is way easier to write than LISP.
I still very much recommend Sublime Text as my editor of choice and every time I try Atom or VSCode I just feel like they are buggy, laggy trainwrecks that use way too much memory and don’t give me the UX I want in return. Sure, it’s more expensive, but it’s the tool I spend about 90% of my working time in and finely-crafted tools are worth it. (I find it funny when some programmers will spend hundreds of dollars on each of their dozens of keyboards to try to find a little bit more efficiency or comfort, but never even consider trying out Sublime Text with its very generous trial based on it costing $80!)
FWIW, your approach to editors is the same as mine, and it’s what has paid off on the long run for me, having spent 25+ years on this road.
Before Sublime, I was a hardcore vimmer/gvimmer, and I still use it for quick editing in terminals. If there’s a window system, I use Sublime.
I’ve tried all kinds of editors, ATOM, VSCode, Pycharm, Jetbrains Idea, Netbeans and all the likes. Each time I try out something, I find myself gravitating back towards Sublime Text again. Bought the license, and would buy it again, if there would be time for it (which I think it is, considering the amount of money I earned with it).
All the newest hype about VSCode being the ‘next big thing’ is just garbage talk to me. It’s an awful slow monster to me. I can supplement ST with it, when ST doesn’t happen to work, but that’s the only time I’m willing to use it.
I don’t care about packagecontrol.io not being ‘streamlined’ enough or whatever the current buzzword is. We are developers, so if something breaks or doesn’t work, we should be able to figure out what it is. Not that if happens that often.
As far as I’m concerned, Sublime is the single best editor for windowing systems, and I’d like to keep it as is for a long time.
That said, is there a way go get our hands on the windowing system it uses?
I want to echo whole-heartedly what @wbond said about tooling philosophies. That continuum is a very important one to recognize, and it’s also important to understand that it’s not a continuum between “good” and “bad”. Everyone needs to identify where along that spectrum their workflow falls, and what they subjectively want.
I love Sublime’s minimalism. I love the fact that it’s extremely “batteries not included”. I even love the fact that Package Control doesn’t try to integrate a web browser or marketplace and basically just gives me the absolute minimum necessary to install things. That’s exactly what I want out of an editor.
In a sense, it’s kind of like a modern Emacs experience without (most of) the self-hosting or the performance issues. And that’s exactly what I want. It’s definitely not for everyone, and I think VS Code certainly falls at a different point along this spectrum and carries a different set of tradeoffs, but I am extremely happy with what Sublime does and how it does it.
And for the record, just as a marketing data point… I would gladly pay for a 4.0 license, today, even if the only major change to the editor was the addition of the minidiff. That’s partially a reflection of how awesome that feature is, but also a reflection of how happy I am with Sublime Text in general and how much I am in favor of supporting it.
If the vision for Sublime Text is simply “do exactly the same things we do today, in the exact same way we do them today, but slightly better and slightly faster”, I’ll buy that vision every day of the week.
If you see something on the market that you like, then that’s great. The answer for competitors in that market is not to be more like that thing you like. Instead it’s to find their own strengths and consider that not all people like the same things.
Sure, new editors are more exciting than old ones. VS Code will eventually stop being exciting too. Right now it’s not old enough to have packages that haven’t needed maintenance for years. It tries to do so many things that it can’t help but be busy playing catch-up with all the tools it tries to replace. Atom also has lots of releases all the time. Why? Because it also wants to be a git client. That’s awesome, and if you’re still new to the command line and git and debuggers and all the stuff you need to learn to use as a developer, VS Code is a great starting point. At some point you may want to use a real fully featured terminal, use more of git’s features than simply syncing changes, etc. And you may find your all-in-one solution falls short. Or not. But you will inevitably come to understand that not everyone likes applications that are on the IDE end of the scale.
I don’t code much, but ST is my editor of choice, for pretty much everything. I use it in vim mode (neovintageous) because I find vim not performant enough when you start adding auto-completion, snippets and all that. ST is the only non-FLOSS software I use on my machine. There is no good alternative to it.
Having said that, there is one feature for which I keep searching in the changelogs, which is a gutter API. From what I understand, it’s not possible to have true relative-numbers (which is something I use frequenty in vim) and it pisses me off. I wonder if @wbond plans to support that anytime soon?
So, probably, ST just doesn’t meet market demands anymore. And maybe the way to
do exactly the same things we do today, in the exact same way we do them today, but slightly better and slightly faster
is not the right one if ST wants to stay afloat.
My main concern is how to have all those plugins up to date if maintainers don’t see ST as something that is worth their time anymore. And without the community there is no product.
That’s a problem with any editor that has community plugins. But you can always fork a repository and support it yourself if one falls into an unsupported state.
Nah, it is still awesome regardless. There are a number of people that run Sublime with little to no plugins, and you can always write your own.
If you are really concerned about plugins no longer being supported, you can contribute monetary support or time to help keep them running.
Regarding package rot, I opened VSCode just now to quickly compare last-updated timestamps of some of my packages. I realised something and I’m wondering if it has been done by design.
Short: VSCode gives you more info in the editor to dissuade you from clicking on page or repo links. This info does not include any dates/age info. ST PackageControl gives very little info and you have to go to the website for more info and there immediately see date/age info.
The extensions view in VSCode contains a lot of informations. More than enough to prevent me from clicking on a link to go to the extension’s web site or repository. It does not show any dates. The Changelog, if an extension author bothers to create it, also will only show dates if the author puts them there. I think this is in anticipation of packages getting abandoned over the coming years and it is an attempt at dampening the “abandoned package” feeling.
With ST the package list is so minimal that you don’t expect to see any dates. You expect to have to go to packagecontrol.io to find any info that does not fit in the one in the list.
So, perhaps we can make a conclusion in favour of ST: ST - no delayed disappointment. In ST, I avoid installing an old package if there is a newer one or if I don’t really need it. This means all the packages in my active list work. If a package is old and I still want it, I try it anyway. Often packages I want are only about 10 lines of python code that I’m just too lazy to do myself. Such a package really doesn’t need updates every month and if it does, I’d worry what on earth could be wrong in those 10 lines. It’s also often easy to use such a package as reference and tweak it locally to do what I want.
VSC - delayed disappointment and undo. In VSCode I sort search results by install-count and start looking through them. The first one that seems to do what I want gets installed. If it’s an old extension I don’t know it, unless it doesn’t work. So I need to install, try and uninstall an extension that doesn’t work and then wonder why so many people have it installed if it doesn’t work. If it works, I never think about it again and happily use it.
Yeah, that’s true but in this case I have to do it. It’s like saying that I can always repair my car myself in case all the services in the area stop providing their service for this specific brand. It would be easier for me to just change the car. And that’s exactly what’s happening to the community. People are simply changing their editors.[quote=“facelessuser, post:16, topic:41822”]
Nah, it is still awesome regardless. There are a number of people that run Sublime with little to no plugins, and you can always right your own.
[/quote]
Yes, but that’s not what @zhongjis asked in his first post. The question was whether ST is going to last and for how long?
People who stop developing their plugins for ST do it not because of money, but because they don’t see ST making any progress in terms of API.
I’m a plugin developer. It would certainly help motivate me for some of my plugins. The underlying reason I developed then is not money, but I’m busy, and support a lot.
If I saw an answer like this from a product owner I would definitely reconsider whether I should spend my time and money on it. If the devs don’t have a plan for ST then they should either give it to the community or just shut it down. Otherwise the fastest editor on the planet is just going to fade away.
And I also wonder if this question is asked as much on other editor forums as here. I don’t find anything for Code::Blocks for example, and there are many more editors that have been around for a very long time without worrying about adding shiny new bullets to release notes.
