First, let me say I love Sublime Text, it's being (and still is!) my go-to text editor for ages. We all know why it's good: it's an incredible piece of software with beautiful UI, powerful API, and unmatched performance.
However, we also all see how it's popularity is vanishing in favor of Visual Studio Code. Valuable members of the community are moving away from Sublime, some even going as far as proclaiming Sublime Text is dead. I certainly don't share this sentiment, but the combination of Microsoft sheer workforce and power of the open source community is hard to beat, no denying that.
VS Code has a ridiculous amount of useful features and an extremely fast development cycle. But this all comes at a cost. And this cost is performance. Even though it's the most performant and well optimized Electron-based app out there, it's still not even comparable to Sublime Text.
So... we have one ace up our sleeve and force against us we can't beat. Here is my plan.
The most important one
I believe debugger support in VS Code is the most popular reason why people are migrating to VS Code (dah!). It's just so much nicer to debug your code right here in the editor. Although we have a couple of plugins that add debug support for certain languages, they are hacky, have clunky UIs (different for every plugin!) and not well maintained. It's just not good enough. We need a native debugger interface and a good way for the community to add new debug targets.
What new way?
Instead of trying to beat something we can't, we should embrace it. VS Code is made using a very modular approach offloading language support implementation and debugger implementation to separate parts using Language Server Protocol (LSP) and Debug Adapter Protocol (DAP). We could and should benefit from these incentives. We need first-class support for both protocols in Sublime Text. Again there are admirable attempts to add DAP support to Sublime Text using plugins, but they are ultimately failing due to lack of native interface for the debugger, lack of APIs and consistent effort it takes to maintain it.
By adding native debugger interface to Sublime Text we are effectively countering the main reason why people moving away from Sublime. And by supporting DAP (and LSP!) we are ensuring automatic support for new and existing languages while consolidating community efforts in the meantime!
Do we even need a debugger? Sublime Text is a text editor, not an IDE.
There is definitely a spectrum between a text editor and a full-blown IDE with Sublime heavily leaning towards the former. However, I'd argue unlike other traditional IDE features like VCS and terminal integration, native debugger interface is a natural fit for the Sublime Text. You already have all of your project files opened in Sublime, it's just wasteful from the usability point of view to use a completely different environment for debugging the same project files which usually presented there in the same way as Sublime presents them. Compared this to Git integration, which requires a completely different representation of the same files, or terminal which literally just a terminal emulator inside a text editor window and doesn't really benefit of inclusion in a text editor.
Yes, that would be the most logical next step. Although Python API provides some benefits, it greatly limits the number of potential contributors and languages you can use to extend Sublime Text functionality. Every language has JSON serializer and usually, it's fast enough not to worry about the overhead it's creating.
This is a very very important point. Besides adding those features I've just mentioned, Sublime Text team needs to be more transparent about the development of the app. We need roadmaps and updates, we need to know what's coming next and rough expectation when. I cannot stress enough how important this is. The community needs to know what's going on and frankly, it needs a boost of morale. People need to be sure that we are on the same page with developers.
I hope the future of Sublime Text and its community is bright and exciting.