> If I owned a popular electron app, I would definitely be thinking about starting to write a Rust version or migrating to Tauri because if you're not then somebody will be. Once that Rust version hits feature parity with your core functionality people will end up jumping ship for the faster, shinier version, just like people jumped ship from Atom to VSCode.
Sublime Text was always faster than all of these (and still is) but that’s not why people are picking text editors.
Tauri is great for certain use cases but it’s not even close to a replacement for Electron at this point (having used both).
Optimizing for speed above all else is the kind of thing that appeals to a subset of programmers, but most people just don’t care about at all as long as it’s fast enough. Products like VSCode are more than fast enough for all but a few people who like to count milliseconds.
> Sublime Text was always faster than all of these (and still is) but that’s not why people are picking text editors.
Personally, I think VSCode has massive adoption because it's free and it's easiest to configure which both appeal to newcomers. The other camp that like VSCode are the nomads who like to work in the cloud. The senior devs I've met generally prefer either Jetbrains or Sublime, depending on if they like a maximal or minimal setup. And then there's the hardcore camp who can get on with Vim and Emacs. I don't know how the latter do it personally, I've tried multiple times to get something similar in functionality to Sublime/VSCode with them and it is always a monumentally frustrating fuck about.
> Tauri is great for certain use cases but it’s not even close to a replacement for Electron at this point (having used both).
I agree but it will definitely be ready within 5 years.
> Optimizing for speed above all else is the kind of thing that appeals to a subset of programmers, but most people just don’t care about at all as long as it’s fast enough. Products like VSCode are more than fast enough for all but a few people who like to count milliseconds.
I do agree with this to an extent but another reason I'm a big Sublime Text fan is the interface. I really appreciate the lack of screen clutter compared to VSCode and especially compared to Jetbrains.
> most people just don’t care about at all as long as it’s fast enough
People care about speed. Even non-technical people. Every non-technical person I know that has bought a new computer even though they already had one was because of performance. People care about performance so much that they are replacing their whole device! That costs a significant amount of money and comes with a real hassle of transferring their data.
I think people use VSCode over Sublime because of its features, not because they don't care about the speed. It's certainly what got me to migrate from Sublime to VSCode. Sublime is so much faster, but it just doesn't do the things that I want my editor to do. I would instantly switch away from VSCode to a faster alternative if it actually had the subset of VSCode features I care about.
An example of a feature I use very frequently would be find in files. Sublime does sort of have this, but the ergonomics are worlds apart.
In VSCode the search gets refined as I type, the results are in a sidepanel and clicking on a result will change the main editor's view to that location in that file.
In Sublime I have to first define which files are even subject to the search. There are options to add folders or to search all currently open files, however a bizarre omission of searching all the files in the currently open project, which is what I almost always want and how VSCode works by default.
Then I have to type out the search term, which is sometimes needlessly precise - because in VSCode thanks to the incremental search I sometimes already see that there are no results or just a few results when I've typed in only a small prefix of what I was going to.
Once the search is done, in Sublime the results are opened as a pseudo-file in a new tab and clicking on a result switches away to a different file tab. It works, sure, but it's very inconvenient for cases where I want to quickly click through a bunch of resulting files to see which is the one I actually wanted. Lots of switching back-and-forth between file tabs, as opposed to VSCode where it's all done in a single view context with the results always visible in the sidepanel. This is especially annoying in Sublime when a search result is in a file that I already have open but is very far from the search result pseudo-file tab. This means that to get back to the search results I can't even just switch the file tab, I need to first scroll through the open files tabs to even find the pseudo-file.
So in short, I guess I would describe Sublime's search as a sort of middle point between using grep and VSCode. It's serviceable, but annoying and wastes my time.
> In Sublime I have to first define which files are even subject to the search. There are options to add folders or to search all currently open files, however a bizarre omission of searching all the files in the currently open project, which is what I almost always want and how VSCode works by default.
Sublime 100% does this because I use it everyday. You just have to use command + shift + f, type whatever you want and hit enter and it will search all files in the open project by default. Only time it won't do this is if there's something in the "where" input from a previous search.
I find the VSCode search results packed in like sardines and like the greater amount of context you with Sublime tab which generally means I get to find what I'm looking for without having to click through to check. I've got a keyboard shortcut set to jump between the entries which makes it feel a bit snappier to cycle through results as well. All personal preference at the end of the day though.
Sublime Text was always faster than all of these (and still is) but that’s not why people are picking text editors.
Tauri is great for certain use cases but it’s not even close to a replacement for Electron at this point (having used both).
Optimizing for speed above all else is the kind of thing that appeals to a subset of programmers, but most people just don’t care about at all as long as it’s fast enough. Products like VSCode are more than fast enough for all but a few people who like to count milliseconds.