FYI, this reads like an ad for sublime, especially considering that the author only has 1 post on lobste.rs… this one.
Sorry if it came off that way. I’ve been working on writing some recently, and figured there may be some interesting discussion in regards to the vision and perspective on performance.
It’s super relevant to many fields of interest for me, so thank you for posting it! (Particularly, as an Australian programmer who’s worked for US companies, it’s refreshing to learn about the few people who do the opposite.)
I don’t think so, the author /is/ touting only the one thing that most people would associate with sublime - fast and not bloated. Interesting read, would’ve submitted as well.
Sublime Text is so nice to use compared to VSCode, (although that’s getting better). The thing that made me give it up however was that almost every plugin developer jumped ship to VSCode and the plugin ecosystem seemed to stall. I’m guilty of jumping ship, primarily for the Remote-X extensions but if I could get something as feature rich in Sublime I’d jump right back.
I absolutely love Sublime Text 3, primarily because it is so fast. Now granted, making it into the feature-rich “IDE-like” experience requires jumping through more hoops than VSCode, and the plugin API feels less intuitive than what Microsoft offers (I can’t really compare it to emacs or vim’s plugin systems, as I only really have surface-level experience with those), but I am more than happy to accept those tradeoffs in favour of a snappy editor that integrates just well enough into my operating system. Not to mention the rock solid stability.
For larger projects or legacy codebases, I will probably reach for a Jetbrains product, but ST3 + the right language server will go a long way.
Really appreciate all the effort that goes into it – the license payment was well worth it!
Not to sound snarky, but if you need a high performance text editor, your data probably shouldn’t be stored as text. Making an interface for non-textual data that performs decently can be easier and bring UI improvements.
To give a contrapoint, I think having a snappy editor is very important to me. This is why I absolutely hated Eclipse back when it was big (which seems to have been toppled by IDEA, which feels faster) and which is why I found Atom to be utterly unusable (likewise, toppled by VS Code which also feels faster).
I am actually thinking a lot about latency these days and I am sad that despite having so much more powerful computers in many ways they feel slower than devices back in the days with 1 MHz.
I wasn’t advocating for slow here. Responsive for most files is enough. I personally use VS Code for my work, because it is responsive while not sacrificing functionality. And I think that trying to make tools more responsive when dealing with larger files or larger structures is a bit backwards. Even with code - Smalltalk, and some Lisp machines employ custom storage formats (impossible to miss closing brackets for Lisp!) that allow for more efficient code browsing and writing.
To be honest, when speaking about performance I am talking about the 95% use case, which is reasonable size source code files.
Some users may not notice a difference in the responsiveness between editors, but then there are plenty of us who do.
That said, Sublime Text is also very performant while editing extremely large files, which can come in handy.
Some people have to deal with very large codebases.
I absolutely think structural editors (for code) are the right way to go, but they don’t really exist yet. Plus, large codebases tend to be legacy that have to keep compatibility with older OSes or language runtimes.
Oh, structural editors do exist, just popular languages aren’t designed for them. Smalltalk is based on that principle and it works great in that, but sadly it doesn’t have the traction.
Thanks for sharing your thoughts wbond! Sublime Text 2 was the main editor of choice for web dev when I was getting started in my career, so the background is quite interesting. Please keep writing!