Can an indie software company compete with a free product from Microsoft that seemingly everyone, myself included, uses… as well as other well-regarded indy products such as Sublime and BBEdit?
I’m a big, long-term fan of Panic software. It started with their MP3 player Audion—and bear in mind I had written my own MP3 playlist manager, QuickMP3, so using someone else’s was a bit of a statement. I remember exchanging ideas on the first release of Transmit with Cabel Sasser, which led to Transmit being the only FTP client I knew of that even attempted to grok timezones (if you synced to a US server from Australia, Australian timestamps would all be in “the future”.
I was also an early and enthusiastic user of Coda at a time when it perfectly matched the development experience I, and many others, lived with on a day-to-day basis: local PHP files lightly dusted with Javascript being run on MAMP (your “dev server”) and remote files on the actual “production” server. It had excellent integrated documentation for PHP, pretty good CSS support, and its Javascript support was… fine. But I had been living in this world for nearly ten years and I was about to “level up” into the world of… not PHP.
The thing about software development is that a lot of it is driven by personal enthusiasm. This is the reason, I think, that there are basically no good email clients. Programmers just aren’t excited about email, and so open-source projects like Thunderbird and even proprietary apps, like Outlook and Apple’s Mail, just seem stuck.
As a result of this, the world of programmer’s text editors is vibrant. BBEdit is still getting constant updates and improvements despite dating back to the 680×0 era. BBEdit has survived the transitions to PowerPC, OS X, Carbon, the end of Carbon, Intel, and now ARM. And it still has features no other rival matches (its multi-file regular expression support, and regular expression support is unequaled both in usability and power). I personally have used Textmate, Jetbrains products, Atom, Sublime, Visual Studio Code for extended periods.
Visual Studio Code is a tough product to compete against. (Even Microsoft which owns it and wants to subsume it back into an IDE is having trouble.) It’s supposedly just an “editor” but not only integrates terminal and version control, but is highly and deeply extensible. It has a huge ecosystem that includes tools and knowledge and examples, and most of it is free or freemium and open source. It has also, like Sublime but unlike BBEdit, borged most of the good ideas from Textmate.
Like Jetbrains products, it runs on a virtual machine (Javascript instead of Java) but in practice it actually feels lighter and more responsive than Jetbrains products and even many “native” options owing to the enormous amount of engineering that has gone into making javascript fast.
I’ve experimented with Nova, Panic’s successor to Coda, on several occasions, but recently decided to give it another shot after having spend quite a bit of time refining my visual studio code workflow only to discover visual studio code was starting to behave kind of flakily. Part of this is visual studio code’s slightly-too-tight attachment to the “consensus stack” that involves node and react. In particular, I found a lot of my package.json npm scripts would run reliably from the command line but not if I clicked them in visual studio code’s build-in script-runner. WTF?
Ironically, my first experience with nova involved running a npm package.json script (it seems to have executed the script in the wrong directory context somehow). and it failed bizarrely. I’m not sure what went wrong, but the problem has never recurred. So it may have been a race condition with pulling in environment variables. I don’t know, I’ll shut up now.
What’s Great About Nova
First off, Nova is small (at least on disk) and fast and beautiful. Despite having a huge amount of functionality, it weighs in at less than half the size of Visual Studio Code.
Next, Nova is much more self-contained than Visual Studio Code.
Nova’s git integration is superb and reduces my need to pop out to dedicated tools (I use both Merge and Github Desktop). To start with it just handles authentication really well.
Similarly, aside from one minor hiccup that has never recurred, using tabs for terminals is just better than what visual studio code does, but I wish I could split a single terminal tab into multiple panes. I don’t need giant terminals.
Having your test pages as tabs in your editor is also great. The fact it’s not trying to be a browser replacement (links open in your default browser) means that you aren’t spawning tabs constantly and your test page (e.g. localhost:1234) is part of the project UI and not also a bunch of tabs floating in Chrome that need to be closed down later.
I thought that I would be annoyed by the fact that Nova uses Webkit and hence Safari’s debug tools, but so far it hasn’t been a problem. Obviously, I can just view my test pages in Chrome, but using a single Nova window for everything is actually very doable, and wonderful for working on a laptop.
Another area where Nova might really suffer is text editing. A ridiculous amount of work has gone into Visual Studio Code’s syntax coloring, intellisense, but out-of-the-box Nova seems to manage to match Visual Studio Code’s presentation and functionality, while being better in many subtle ways, the integrated color picker in Visual Studio Code is, frankly, flaky as hell. Nova’s is superb—neither appearing nor disappearing at inopportune moments.
I did have a few initial gripes with Nova. Its keyboard shortcut for quickly opening a file by name is command-shift-O. I think the emerging consensus on command-P—both Sublime and Visual Studio Code default to this I believe—is sensible (printing is, after all, passé, especially for source code), and it’s part of my muscle memory at this point. (Edit: of course it’s super easy to change.)
Even worse, the search tools default to using some kind of horrible token system instead of regex. At first I feared there was no regex support (not being able to find things easily in Nova’s documentation strikes again) but turns out it’s easy to switch on and it even has some of BBEdit’s convenience features (like remembering previous queries).
Similarly, I feared there was an issue with build files not being ignored in searches, but while, once again, the system for adding ignore paths is not well-explained in the preferences pane and does not provide helpful examples (nor it is possible to edit entries—you need to delete them and add new ones). It took me several attempts to figure out that I need to ignore dist/** if I don’t want to see any files in dist. I fully expected this was a possibility (it’s one of the common path syntaxes), but better worded text with examples in a pretty much empty preferences panel would have been golden.
Your Mileage Will Vary
I try not to use very elaborate configurations of products. I find that I forget how the work, waste time debugging them, and have issues when I (inevitably) switch from machine to machine or some OS update breaks something somewhere.
Blockers?
Right now, I use github, eslint, Typescript, and prettier quite heavily, and not much else. Nova has super integrations for each of these. If you use lots of Visual Studio Code extensions then no, there’s no way of using them in Nova, so you’re either going to have to find a near equivalent or, more likely, do without. My guess is you know who you are and you’ve already rejected Nova for this reason if not for the fact it’s not free or it only runs on a Mac.
The fact is, I’m pretty nearly in this camp despite my relatively light customizations to visual studio code, and it comes down to two immediate issues.
Snippets. I have a snippets file I created for xinjs—visual studio code supports Textmate-style snippets—which makes it super easy to spit out boilerplate for web-components and specific optional methods within such components. I can type xincom and then TAB and then tab-through the class-name and so on and I have a fully declared component. It’s nice. It looks like Nova supports basically the same thing but its documentation is terrible. This is what I want from documentation:
- A really simple example
- A more complex example that shows the key things I’m likely to want
- Comprehensive references
(Edit: turns out Nova has a first class native user interface for creating, editing, and managing snippets. They’re just called “clips”.)
Custom Syntax. I will probably write a xinjs extension for visual studio code (or Nova) that supports my inline documentation syntax and the like (I’m sick of using /** */ and then getting jsDoc boilerplate when I just want to use markdown, so I’m now using /*! */ and just want to tell the editor that anything inside this is markdown, and, ideally, anything inside a <pre>js...</pre> code block is javascript, and so forth.
Again, Nova seems to support this stuff, but the documentation is abysmal. It tells me that the thing is possible but neither gives an example nor explains exactly how it might work. I get the idea that I probably need to find documentation on creating an extension, but I can’t find that. (Edit: I found the documentation!) I tried looking inside the Nova package to see if there are any syntax declaration files in it but no dice. I have literally no clue what the file should look like, nor what to do with it were I to create it.
Now, I haven’t spent weeks spelunking the documentation (as I have for Visual Studio Code) nor devoted serious time to understanding its extension architecture (as I have for Visual Studio Code). This isn’t fair. And I do see evidence that once I do penetrate the veil of documentation, Nova is actually going to turn out to have superb tooling for all this because of references I see to leveraging modern tools for defining parsers and syntaxes which look like things I briefly worked on after getting frustrated by tools like jison.
Not A Conclusion
All of my issues with Nova currently come down to documentation and examples. If I can figure out how to write a simple extension that will help me with writing documentation and a minimal amount of boilerplate, there’s really no downside to Nova and the reduction in Window clutter is simply amazing.
So, I’m continuing my experiment and will either discover that the extension situation is awful or too proprietary (I need to be able to support Visual Studio Code users even if I don’t use Visual Studio Code myself) or it will allow me to reuse most of the stuff I’ve done for Visual Studio Code and I’ll pay Panic their extremely reasonable subscription fee.
If I hadn’t spent six months working in the VS Code extension API when I was at Google and didn’t care about supporting VS Code users and being able to reuse or lightly adapt snippet and syntax definitions from VS Code, my guess is I’d be sold on Nova at this point.