This is a bitchy, snarky review of Coda 2, a snazzy new web development program that doesn’t deserve quite so much ire, but gets it from me because I am so disappointed: I was really hoping I could move into this app and live and work there for many years. It could have been a big deal for me, improving the feel and flavour of 40-60 hours of work every week. I’m aggrieved that it isn’t going to work out.
This might even be the harshest review of Coda 2 out there. So: apologies to the gang at Panic Software. They are crazy talented, and I love what they are trying to do with Coda — obviously, or I wouldn’t be so disappointed — and I have for years. I wanted to love the first version (2007), and bought and played around just for the hell of it, even though I knew there was no real hope that it could compete with the power of BBEdit — my publishing draft horse for a decade now (only half the product’s lifespan).
Things started well. I quickly determined that certain Coda 1 (and 1.5) deal-breakers had been addressed, and I was impressed by several things right out of the box, like the clever pairing with Diet Coda in my iPad for previewing. My hopes soared…setting me up for even more disappointment.
Unfortunately, after an investment of “only” a couple full days of trying to get going with Coda 2, I easily accumulated a list of new deal-breakers (and smashers). And I don’t just mean that it doesn’t suit me. My opinion is that Coda has quite a few flaws that should concern nearly any kind of user. It sure aims high, but the result is just not all that good.
The most general problem is that Coda 2 is obviously bogged down by eye candy. It’s pretty, sure, but even on the best iMac money can buy it drags its pretty little feet. BBEdit is ready for input in less than two seconds, almost too fast to count. Coda takes at least five. On this machine, that’s pretty sad. Lots of things are a little laggy. Git refreshes, for example, are particularly slow. What is it doing? I have other two other Git GUIs that update in the blink of an eye!
And there’s a related, deal-murdering performance issue: for “large” documents, Coda automatically turns off critical features like syntax colouring, code completion and even — I love this one — line wrap. It tells me this in a modal dialog sheet, for a file I have to open about fifty times a week, one of the eight books I’ve written. I clearly cannot edit this bad boy in Coda. And yet I work on it in BBEdit constantly. In fact, I often use BBEdit to tinker with files an order magnitude bigger than that! BBEdit grunts when lifting a 5MB text file, but it does not stagger.
Finally under the performance heading, Coda 2 be buggy.
Sure, it’s a point-oh release, but oh snap: it’s also one they’ve had in the oven for literally years. It’s impossible to say how buggy is too buggy, but it feels too bucking fuggy for me. For instance, several crashes on quit sure makes a sour impression. I am under-impressed.
But I really lost my patience with the bugs when I discovered that assigning any keyboard shortcut to any clipping crashes the app. Every. Single. Time. That’s not really minor, and it’s sure not polish. I use shortcuts for clippings in BBEdit about seven hundred times per day. Coda 2 isn’t going to be useful for seven minutes without them.
Could I get some help around here?
Coda 2’s documentation blows. It’s super thin. If it were printed, I think I could probably still mail it in a #10 envelope.
Panic seems to think it should be obvious how to use their app, and so it doesn’t really need to explain it. For example, there are no examples. For instance, I can’t recall seeing a single “for instance.”
For instance, the introduction (“Getting around in Coda”) pretty strongly implies that the “Sites” metaphor is loose, and directs the reader to the “Using sites” section for more, but the “Using sites” section is absolutely bare bones and doesn’t have so much as “boo” to say about use cases, let alone anything meatier. I could write more substantive documentation in an hour.
I tried to find information in the docs on the relatively trivial chore of re-enabling syntax highlight and line-wrap in my big documents. Chuckle. As if! Maybe it’s not documented because it’s just so nice and obvious in the UI? Um, no. I couldn’t find any way of toggling those features in the UI, and it seems like the kind of thing that isn’t even on Panic’s to-do list for the docs.
Spartan docs are acceptable for a less mature product. But for Coda 2? Give some goddamn detail. It’s not that hard to “elaborate.” You put the key points up top, and then you expand. Journalism 101. Technical writing 101. Sheesh.
Epic clipping fail
Back in the bug rant, I mentioned that I can’t assign shortcuts to clippings in Coda 2 without a kee-rash. Well, that was just the beginning of the clipping woes. Clippings are terribly important, and nicely done in other apps, so I’m going to ranting about them quite a bit. (For the few people reading this who aren’t totally up on text editor features, a clipping is a frequently used chunk of text/code with some brains. They are pretty much essential.)
Maybe autocomplete can make up for the (presumably temporary) lack of functioning shortcuts? Nope: Coda has code completion that does not recognize its own clippings. There’s a clipping completion feature, but it has to be explicitly, “manually” configured for each clipping and is triggered in a different way. It’s not so horrible, but it suffers quite a bit in comparison to BBEdit, which dutifully looks for clippings that match anything you type and offers to complete it for you — d’oh.
And it gets weirder still with the clippings. That last thing? That’s a cranky quibble. This next thing made me yell at the screen, “Really? Really?” (I don’t do that for quibbles.)
There’s are no common inline HTML clippings available by default. None. Not one. It’s as if the app is saying, “C’mon, make a few dozen basic clippings from scratch … it’ll be fun! You can get to your real work tomorrow!” Why would someone make an eye-candy heavy website-building app, but not bake in a way to cook up an anchor element? What kind of HTML editor doesn’t give you the ability to wrap some em tags around some text?
I just don’t get it, Panic. Either I’m going to be so embarrassed when I finally realize that the functionality was right there all along, or it’s one of the oddest neglected features I’ve ever seen in v2 software.
Hey, maybe there are some basic clipping collections available from some industrious internet denizen? Nyope. Googling for "coda clipping collections" did not save the day. (By far the most significant source of Coda clippings, coda-clips.com, offers only an incomplete and eclectic smorg, completely lacking any basics. And everyone else just links to them. “Check out these awesome coda clippings most people don’t need!”)
Hey, maybe I could import clippings from BBEdit? They’re just text, with a simple and highly translatable syntax! And there’s a tantalizing “import” button in Coda’s clipping pane! But … no. No, you cannot do that either. Coda cannot parse that. Coda only imports it’s own exported clippings.
Hey, I’m a “power user,” la dee da: what if I just took a wee peek at Coda’s clipping syntax and whipped up (translation: 2 hours of cussin’) a batch conversion of my BBEdit clippings into Codaspeak? A little bbedit2coda clipping conversion ack-shee-on? And then, um, get them into Coda without an import feature? Alas, I couldn’t readily examine Coda’s clipping syntax, because its clippings are not stored in the obvious place. There is a “~/Library/Application Support/Coda/Clippings” folder … but it remains stubbornly empty as you create clippings. (So what is it really there for?) I guess they’re somewhere else, for some incomprehensible reason. Oh, and when you export them, Coda creates an opaque file, blocking reverse engineering for any casual tinkerer.
Dear user: all your base are belong to us.
That’s when I lost interest in the clipping problem. I was hours in at that point, and still couldn’t wrap me some em tags around some ever-lovin’ text with a nice little cmd-i. As I write this — in BBEdit, natch! — as far as I can see, the only way I can have a couple hundred convenient clippings in Coda is to build them from scratch, one by one, in Coda’s GUI. Without shortcuts. Between crashes.
Oh, could I please?
So that’s clippings. I delved because the process of trying to solve that problem revealed so much about Coda 2 that I was disappointed to learn.
But there’s so much more to complain about.
So where’s iCloud sync to the awesomely named iPad companion app, Diet Coda?
It was incredibly natural to assume that would be there. Yes, I could graciously say that I’m sure it will be along soon. And it probably will be. But it really, really, really seems like an obvious, major point of having iCloud sync. If you’re going to advertise iCloud sync, and make a big freakin’ deal about offering a somewhat surprising iPad version of your app, how about syncing them up to any degree whatsoever? So I’m not cutting Panic much slack for this weird omission.
Also, I left “gracious” bleeding in an alley about ten paragraphs back.
Coda 2 does sync site settings between copies, and this is something I need. I pretty routinely want to take my publishing show on the road. But of course iCloud sync of my site settings went muy, muy poorly on my iMac/laptop. Here’s a shocker: duplicates! How novel. Never seen that before in a janky sync feature. After seeing that, I felt less surprised that sync is AWOL from Diet Coda, but also less forgiving.
From Panic’s change notes for 2.0.1: “Hopefully improved the reliability of iCloud.” No shit, because it’s pretty horrid right now.
Barely there SQL
The SQL options are amusingly limited. There’s really nothing there. Seriously, who is going to use that? If you know enough to use it, you don’t need it. If you don’t know enough to use it, if offers not one single advantage over far, far nicer standalone SQL front ends (like the excellent Querious, which I use daily).
File upload sync
Another example of something that isn’t just one problem, but a piling up of issues that add up to a disappointment: there’s no FTP sync, so I still have to run Transmit (o irony!) or rsync. Hrm.
That’s mildly disappointing in itself. But the site publish feature is intended to duplicate sync functionality by showing you only changed files and letting you upload them and them alone. Nice idea. Very source-controlly. Only … the feature isn’t actually paying attention to the files themselves, and will ignore file changes made by other tools. It’s a completely internal feature. So if you modify your code using anything other than Coda — i.e. an external script, or even just another editor for some specialized task, something I do, oh, constantly — you are SOL.
Meanwhile, in the immediately adjacent source control pane, is another large dollop of irony: Coda “knows” full well, via Git, that I’ve changed 32 files with a script, and that information about changed files is right there. But flip over to that publishing pane … nothing. It’s not that I exactly expect those two features to talk to each other, but it’s got a so-close-yet-so-far stench that makes the lack of an explicit sync feature much more exasperating.
I’m a little embarrassed to admit that I really did eagerly wait years for this product, assuming all along that it would probably become my new default working environment.
As powerful and good as BBEdit is, it has never once seemed like the tool I really want for the job of publishing and maintaining a big website. In fact BBEdit does do the job, and sometimes I wonder if there is anything BBEdit can’t do, but to this day it still feels like it’s more for pure coders and the web publishing stuff is tacked on, and many web publishing possibilities are neglected.
Coda looked very much like what I always had in mind to replace BBEdit. But it’s just not, and the dream of is dead. I won’t be holding my breath for the next version — despite the many genuinely neat ideas in this tool, there are too many things in Coda that are worse than just “wrong for me.” Le sigh.