A little Coda 2 plugin

I made a little Coda 2 plugin for fun: wrapping js-beautify. You can download it here

Pay close attention to the documentation; the script environment doesn’t do what you think it does, and so you’ll be very grouchy.

I want to love Coda a lot; as I mentioned in my review of Komodo IDE, I mention as one of its downsides it’s so very not-native. Coda is extremely, wonderfully, beautifully native. So there’s that.

But it’s ultimately an app for cranking out WordPress plugins, not doing serious work. If you want to build serious, production web applications – and especially in something other than PHP – look elsewhere.

Komodo IDE 7

The Good:
Here’s the tl;dr and the bottom line to my ramblings:

There’s probably not a better IDE for working with dynamic languages, specifically Perl, Python, PHP, Ruby, or JavaScript, and the web stack in general.

The entire application is deeply knowledgeable about web and system development with those platforms. (As usual, Java-based dynamic languages like Clojure and Groovy will probably want to stick to a Java-based IDE.)

A long time ago, I mused that the perfect modern editor/IDE was like Emacs, but instead of a Lisp, it would use JavaScript. Komodo is that editor: there’s the addition of a little Python but for the most part, it’s JavaScript most of the way down (in the way that Emacs is built on top of a Lisp runtime in C).

Komodo one-ups this idea by building on top of  XUL. That means it’s crazy-extensible. I mean, it’s so extensible that between macros, run commands, snippets, and full-on extensions, you could do about 80% of IDE in Edit (It would be hacky and awkward and hard to maintain, so it’s probably not the best idea ever in terms of productivity, but it’s probably at least possible). There’s a fair number of really good extensions available already, and it contains a template for making new ones.

If it’s doable with a dynamic language, and you need to do it, it’s probably in Komodo. Debugging, profiling, HTTP inspector, regular expression toolkit, the works. Code completion is fantastic, and doesn’t rely on tag files (actually I think it does, but it builds its own transparently in the background, instead of you needing to update or manage them; other implementations exist). 

Developers are responsive and helpful. Bug tracking is accessible; developers encourage you to use their Bugzilla to log feature requests and track the status of bugs. Documentation is very good, albeit a little obtuse at times.

IDEs have a reputation for being “Angry Fruit Salad“: lots of panes with little space devoted to the editor. Usually my editor looks like this:

Screen Shot 2012 06 19 at 6 44 06 AM

and I have macros and keybindings to show/hide things as needed. At a glance, most people assume it’s Vim or Emacs or something.

Scintilla is a more capable editor component than it gets credit for, and the Activestate folks have really pushed it beyond “text editor widget”. Just look at the docs for creating user-defined languages: that’s some really powerful stuff there. It’s way complex but I imagine it’s pretty much impossible not to support your favorite language, be it code or markup. It also supports split views.

There’s a bunch of other functionality, like the Regex toolkit, integrated testing, and tons more.

The Not-so-Good:
Not native.

I know, I know. Just a minute ago I was raving about XUL. And it’s based on the Mozilla platform, so of course it’s native!

Mozilla is mostly native and easily the gold standard for “write once or twice, run in most places”. Still: this stuff matters to Mac users, quite often, and to simply hand-wave it away isn’t enough. It will almost certainly lack the tiny details that Mac users love. It will almost certainly trail somewhat far behind the cutting edge of Mac development. It will always be “a little weird”. If you’re counting on it instantly fitting in with your toolchain of other Mac OS X apps, you may be heartbroken or at least slightly miffed. It is so worth getting past that, because it’s really a powerful tool.

On the other hand, if you’re a Firefox die-hard, you probably stopped caring forever ago, and JavaScript is always better than Applescript for doing real work. 

Can be a little flaky at times. If you’re used to a rock-solid editor that never crashes or even acts weird, it’s a tad frustrating. This improves every time the Mozilla people improve the underlying components, and 7 is quite stable; but I can’t even remember the last time Vim crapped on me. Like, ever. I know Emacs people that consider restarting their editor an unclean act. If you’re one of these people, yeah, it’s going to make you sad.

Although it’s crazy-extensible, I find the Firefox extension-building process somewhat daunting. YMMV, but it’s an important consideration when thinking about “how can I bring over my workflow from another editor”. Most tasks can be handled by scripting, though; it’s probably not likely you’ll need to create a real extension, and I secretly hope they’ll have something similar to Mozilla Jetpack in a future version to make extensions easier to work with. Macros are super-powerful, though, so don’t think you’re forced to wade into extension development just to do something small.

The Other Stuff:
Most IDEs have a pretty large learning curve, and often aren’t as written-about as Vim, Emacs, or Textmate; so discovery of features, especially scripting, can take a while. The forums/knowledge base/FAQ is pretty good, though.

Vi emulation is not bad. It has a few rough edges (visual block mode, anyone?) but it’s certainly workable for your middle-of-the-road Vi user. (An example of things that might make a long-time Vim “power user” grouchy: there is no concept of a “leader”, as such, so if you remap your leader to something like , to avoid the default and slightly inaccessible \, you might not be able to get the results you want).

Publishing and remote browsing are workable but could use some improvement; publishing assumes a simple 1:1 mapping of a project on your machine to the remote machine, so some complex projects can’t use it. 

I really want a shell. Yes, it has language REPLs built-in (which is great!), but I want a real terminal. Sometimes you just need a shell, you know?

If you have an editor like Vim/Emacs/Textmate that you’re used to using for both code and prose, it’s unlikely to replace it for prose. It’s just not a prose editor, as such. It’s certainly adaptable but it’s forte is not, say, rendering your exquisite markdown in real-time. (But as I’ve said a million times, you can make it bend to your will – I have a macro to work with Marked.app, and it works great)

Things I didn’t get to use:

  • Collaboration. Everyone at work that uses Komodo either uses Edit or isn’t on IDE 7.
  • Stackato. I’m not in the OMGCLOUD business right now; we deploy to physical hardware, and we’re currently building out our own cloudy thing. It sure looks great but I don’t have a lot of reason to expend effort on it at this time.
  • Database stuff. We use CouchDB at work, so I have no need for a SQL editor.

The Bottom Line:

I guess I already gave away the big finish: there’s no better code editor/IDE for the web stack.