Beyond concerns about what might be in the processed slab in commercial microwave popcorn, my motivations were cost (a big jar of plain old popcorn is much cheaper) and the entertainment value for the kids.
Of Coda some have said essentially “Cool app. Too bad I can’t use it.” The reasons are varied but can mostly be generalized to ‘Coda doesn’t fit the work I do and/or doesn’t fit the way that I do my work.’1
Panic shouldn’t try to change Coda to please everyone. Doing so would ruin the product. It’s fine and good for the product vision to remain idiosyncratic and for some people to ‘not get it.’
I have no inside knowledge of Panic’s vision for Coda and I have no expectation of having any influence but that’s not going to stop me from sharing a few ideas about Coda.
I have issues with the way Coda manages sites.
Clearly Panic created Coda in part to scratch their own itch. Apparently their custom is to directly edit their live sites. A Coda ‘site’ is modeled on the idea of a production web server and a local copy of the files. With the v1.0.1 update, support was added for a local development web server.
I need a different ‘site’ model. When I build a website it’s generally for a client. In addition to development and production, I need a third server: a ‘user acceptance testing’ web server. Sometimes I need a fourth server for prototyping. (Of course I don’t need separate physical servers. Prototyping, development, and testing could be different directories and/or ports on one server.)
For Coda the live site is primary and there is one set of content for the site. For me the set of content is primary and there can be multiple deployments of the content.
According to Cabel’s blog in Coda’s first week of release subversion integration was a top request. If version control is used effectively the ‘authority’ for a web site’s content should be the version control repository, not the live site. Deployments to the live site should be based on a branch or a label in the version control system. Direct updates to the live site should, under normal circumstances, be avoided.
Site information appears to be stored as opaque data in the Coda preferences file. This means that site information is tied to Coda for a specific user account on a specific machine. Working on different machines or working with others as a team requires redundant copies of the site information.
A project file would allow for sharing and versioning site information. But I’m guessing Panic purposefully avoided the concept of a project file. Although others have referred to Coda as an IDE, Panic has not. Panic may envision Coda as something much less ‘industrial’.
It will be interesting to see how Coda evolves. (Here’s an idea: Add an embedded web server.) I wish Panic success with Coda but I have to say as of v1.01: Cool app. But I can’t use it.