While I'm using VSCode a lot more these days, I still like BBEdit a lot. It's a Mac-native programmer's text editor that manages to remain performant on large files.
I think part of the problem is that in order to make a good programmer's text editor, you need a large community of people who're able and willing to make good plugins for it, and any text editor with a userbase smaller than "half of all linux nerds" isn't going to have enough engineer hours put into all its per-language tooling. Visual Studio Code manages to attract enough developer attention to get people to work on compatible language servers and whatnot, but the granddaddy of all Mac text editors can't attract that much attention.
Plus, I get a _lot_ of mileage out of multiple cursors. Way more than I'd have expected ten years ago.
Not to nitpick an otherwise good argument, but the whole point behind LSP and language servers are that they are completely editor-agnostic.
A language server which enables great functionality in VSCode should be able to provide the same for other editors too.
Fair, I think what I meant is that Visual Studio Code has more IDE features than my emacs does (I know it's possible to have more but things seem less stable when I start using LSPs and such), but BBEdit has even fewer than emacs.
Maybe it’s for people like me that have never learned emacs.
This is a frustratingly hard assertion to defend, at least in very short form, but I've been a technical writer for years now, mostly working in Markdown, and I keep coming back to BBEdit. It's not one huge thing that it does better for me than other editors, it's a collection of little things: every editor has some kind of "open file by name via fuzzy searching" command, for instance, but BBEdit lets me open multiple matching files at once. (Yes, this turns out to be immensely useful for me.) It keeps a search and replace history and lets me save patterns with a meaningful name. Its "multi-file search" window isn't as fast as some other editors, but it's insanely targetable, and again, lets me save my criteria with names (i.e., "All but JSON"). The "Process Duplicate Lines" command lets me easily find "duplicates" defined with a match pattern in a 75,000-line JSON file (don't ask). I can build complex operations up and save them as a text factory. I occasionally do operations with its "Shell Worksheet" capability, sort of a weirdo hybrid between a built-in terminal and a persistent text file. (I also like that every project gets its own persistent shell worksheet and persistent "scratch file," which you can set to be any language type.)
I've tried a lot of other editors over the years, including VS Code, and either they don't have features that I use in my technical writing or they don't, at least to me, implement them as well. And as lame as some people undoubtedly think "it works like a Mac app" is as a feature, well, it's actually kind of refreshing to have a full-featured text editor that does that BBEdit works like a Mac app. It seems almost quaint to have an actual preference window come up in a text editor when you select "Preferences..." these days, but it turns out they're actually really good at, you know, setting preferences. (Modifying keyboard shortcuts is so much nicer in BBEdit than in any other editor I've used.)
Again, for coding, BBEdit has fallen behind the times; the structure is there for it to mostly keep up, but the ecosystem just isn't there and, barring a strange resurgence, probably never will be. Personally, I use MacVim for coding bigger projects now -- although I'll generally use BBEdit for short shell or dynamic scripts if it already happens to be open. But for managing huge honking websites with thousands of Markdown source files -- or even just dozens -- I just haven't found anything that beats BBEdit.
Yeah, I think perhaps this is what I'm missing. I'm a software engineer and at minimum in an editor I want syntax highlighting and code formatting (completion is a nicety but still largely a hassle outside of IDEs) and it's just not there for the languages I want to use.
I definitely appreciate the "works like a Mac app" angle, although in many ways it feels more like a Mac app from 25 years than I would like. It doesn't feel modern.
As for the modern aspect, I dunno. It doesn't look anything like Atom or VS Code, to be sure (let alone like MacVim or Emacs), but it's hard for me to look at the UI of BBEdit 13 and find anything that makes me go "oh, yeah, that widget right there looks really creaky." It doesn't have a tabbed interface for files, but I actually like its method of having a "currently open documents" list more than tabs. (When I've used VS Code, I configure it to do that, too!)
It's not so much this so much as it is not having the sort of Yosemite-esque translucency (I think vibrancy was the official name?) effect on sidebars and stuff which I've gotten extremely used to.
>One of the frustrating "what ifs" in the Mac editor world to me is: what if BBEdit's makers had added packages and, better yet, a package manager, to the editor a decade ago?
iirc it actually had/has a half-decent package format, but no manager or central repository for packages. The latter two are basically obligatory these days for a solid code editor, in my opinion.
>And code formatting is pretty much a dead end, even though I'm fairly sure it would be possible to set it up.
Really all that I want is a hook to run a shell script on save that runs the current buffer through mix format or rustfmt or whatever. Is that more feasible?
Yes, and yes, and yes. :)
> Really all that I want is a hook to run a shell script on save that runs the current buffer through mix format or rustfmt or whatever. Is that more feasible?
It would totally be possible, with the caveat that this is where you hit the one thing that does look really creaky: BBEdit's native scripting language is AppleScript. You can "attach" scripts to every single menu item, to several kinds of events (including both before and after saving a document), and the script could basically just be a wrapper around a shell script, but AppleScript will unavoidably rear its verbose yet inscrutable face.
I think studying old UX paradigms is super useful.
What Photoshop is to images, BBEdit is to text.
Yeah I get all these platitudes and stuff but I have used it and it doesn't seem more flexible than emacs here.
Loved that tag line.
I say this as someone who writes those apps.
Uh, I'm going to hard disagree on that. They take longer to open, they're slower to use, they take up more battery, and they don't behave in a consistent way with the rest of the OS.
No Electron app has ever even come close for me, certainly not VSCode that everyone seems to love so much.
Then there's performance...
But I would say the Slack UX, from a visual and performance perspective (not necessarily intuitiveness), is as good as nearly any native Mac app I've ever used. VSCode, from a visual and performance perspective, is better than any native Windows app I've ever used, and also as good as many native Mac apps.
I know people like to gripe about the memory usage and disk space usage of Electron apps, which, fine. But it's a fairly academic complaint. Those things don't honestly affect my experience as a user. The only time an Electron app has ever felt sluggish to me was Atom, fully loaded with plugins (~3 years ago), and I honestly suspect that had more to do with its naive and non-cooperative plugin architecture than with Electron itself.
Whether it's academic depends entirely on how much memory you have, and what else is using that memory. As with most resource-intensive software, you can brute force it with raw specs, but you're left with less computing power than you paid for.
I was watching The Verge's review of the new Macbook Air last night, and they were talking about battery life. I'm paraphrasing, but they said something like: "Apple claims 13 hours of battery life, and you can get that if you live in Safari and other Apple apps. But I'm living my life in Chrome and Slack, and with those apps open I get closer to five hours."
Chrome and Slack are, of course, the same thing.
As strongly as I dislike locked down platforms, situations like this do make me somewhat understand why Apple doesn't allow web rendering engines other than Safari on iOS.
What I'd like to see, personally, is for the three major desktop OSes to agree on a "desktop WebView" standard. Then they can use whatever browser internals they want when it comes to launching those web apps. They could even let you pick your own, the same way you can pick your default browser now. This would not only allow people to use desktop safari for their "electron apps" if they want to, it would avoid one of today's major problems which is shipping a whole copy of the browser with each app. Web-based desktop apps would be no larger than native ones, and depending on how the OS handles them they could be roughly as performant.
I understand where you're coming from, but when someone says says "Electron apps are slow resource hogs", they're fundamentally referring to the underlying engine that makes those apps slow. If that engine was fast and light on resources, the complaint wouldn't exist.
Apple _does_ allow developers to use Safari Webviews within desktop apps, but by using Chromium everywhere, developers don't have to deal with cross-browser issues. Case in point: Slack video calls don't work in any web browser other than Chromium, because they don't implement WebRTC properly.
Firstly: in that case you'd have to compare it to the weight of the entire desktop environment. I would bet money that Gnome + your GTK app is not meaningfully lighter-weight than Chrome + an Electron app. It's just that the former has a privileged place in the OS, and is a dynamically-linked dependency instead of a statically-linked one (using those terms loosely).
Secondly: The web itself is not fundamentally slow. People who aren't web developers love to repeat this mantra, but it's simply not true. That's what I'm trying to get to the heart of here:
1) JavaScript is slower than C++, but it's very rare that enough actual work is being done in JavaScript for it to become a bottleneck (on the UI side), even in complex web-apps. Most of the grunt-work, including recalculating layout, is implemented in C++ as part of the browser.
2) Layout calculation can be slow-ish in extreme cases, but that's a direct tradeoff for the benefit of using the world's most advanced UI layout system, which provides real value.
3) Under normal circumstances an entire web page runs in a single thread, which can be a problem when the occasional expensive operation blocks other ones, but Electron gives you several options for moving expensive operations to separate threads. By default the web view runs in a separate thread from the "main" process, and you can spin up workers or even split your UI into separate web views so each panel gets its own thread.
I think the origins of this myth are:
1) Websites have become much slower than they need to be with the increase in JavaScript dependencies. 90% of this is due to ads and analytics, which couldn't care less about their impact on page performance. The rest has mostly to do with the initial load-time of that 1-2MB script, rather than the runtime of the actual JS code.
2) As with any technology that lowers the barriers to making things, there's been a dilution of less-skilled developers putting things out into the world, decreasing the overall perceived quality of the space. But this isn't an indictment of the technology; if anything, it's a complement. It has to be distinguished from the actual merits of the tech.
> but by using Chromium everywhere, developers don't have to deal with cross-browser issues
I think it has more to do with being able to build and ship copies for all systems through a single channel. Building a "first-class" Mac app (a dock icon, hooks into system APIs, etc.) that uses Safari's web view right now would probably mean opening XCode and writing quite a bit of actual Swift as a wrapper around the web UI. People don't want to do that; it defeats a lot of the purpose. My proposal in my last comment would solve this problem.
There've been a couple attempts to build electron-like frameworks that use the OS's native webview, but they don't seem to have gained that much traction. Deskgap is probably the most mature of them, relatively speaking.
Additionally, I have yet to encounter a single native Cocoa app that has such a strong effect on battery life.
* VS Code is just as quick to use as Xcode, actually more responsive in many actions, demonstrating effectively that it’s the algorithm which must change for a serious speed up
* MBP batteries are laughable in the first place and they’re basically portable desktops that need to stay plugged in all the time
* The rest of the OS hasn’t behaved consistently with itself the whole time I’ve been using it, just like every other OS I’ve used for the past 25 years; consistency was a pipe dream
Probably because you’re using so many electron apps. This is not the case in lab testing by MacWorld, etc.
"Counting seconds" may mean little to you but by proxy you can look at conversion statistics for web stores vs response time and see a pretty clear correlation
VSCode's 'performance' is the result of an obscene amount of tuning the base framework, far more than most applications would need. Most other Electron apps do not see anywhere near this level of optimization (and they desperately need it).
MBP batteries on a new machine are respectable. Like all li-ion batteries they decay with use
Mac OS apps behave very consistently when they are native. True, Apple's user interface guidelines allow for pretty wide latitude in some areas (like skeumorphism) but all the basic OS/interaction contracts are intact. One can expect menus to behave the same way, file open/save dialogs to behave the same way, and so on.
Consistency is a sliding scale but Electron is a whole new (lower) level. Extremely basic interactions like "the menu bar highlights to acknowledge key equivalents" are missing.