On Coda 2 and Diet Coda | Hacker News Reader

On Coda 2 and Diet Coda

jeffcroft.com

26 pointswhalesalad30 comments

From the article:

"...but choosing to build a MySQL editor into a web development package just furthers my impression that Coda is basically designed for the php crowd."

I'm not sure why that is a problem.

This article by Croft is a pretty good summation of almost all of the negative commentary surrounding both the original version of Coda and the upcoming release of Coda 2. The rest of the article is full of digs at people who work in a way different than what Jeff Croft does. It is incredibly condescending.

The reason why I can't stand reading nerdy tech blogs anymore is because everyone is convinced they are right and the rest of the plebes using antiquated (read: different) technology are morons.

I would argue that there are enough people doing things the way Coda best supports to make the creation and marketing of the software justifiable. Otherwise they probably wouldn't be days away from releasing a major new version they appear to have spent a lot of time, money and thought on.

If there's enough demand for software like Coda shouldn't we all just take a big step back and acknowledge that's ok? There's more than one way to operate as a developer today and maybe we should all leave our thousand word treatises that chastise people for doing things the way they want in our "drafts" folder.

I'm sorry, but if you're a professional web developer you need to stop editing files directly on remote servers. Period. Full stop.

Apologists post in threads like these time and time again, whether the argument is for them using PHP, SVN, or whatever. My reply boils down to this:

Sure, you can construct a home using nothing but straw and mud. And because the house is still standing at the end of the first day, you convince yourself that those are good materials for your next job. But don't kid yourself. Straw and mud are not good, modern tools for construction. You're going to be looked down upon by the rest of your industry that moved on to wood, brick, and cement. Deal with it.

At least with one or two clients of mine, I have tried for months to try and change their workflow to allow local development but they resist. Because they give me limited access to the production files, I can't export the database to bring it to my localhost. Thus, I have no choice but to edit the files on the server. Most of the sites I work with aren't live production sites, but it's still a slow and outdated workflow.

Your reply just reiterates my point because you're doing the same thing the post author does. In between the talk of version control, his post is laced with allusions that people working with technologies he doesn't (PHP & mySQL in this case) are a bunch of dumb baddies.

Why would someone possibly care enough to go out of there way to write a blog post condemning them. I just don't get it. This seems like a popular tactic in the Ruby and Python communities although it's toned down enough over the last few years that I thought this movement was about over. This post just helped remind me it isn't.

It's no use debating with someone that absolutely refuses to admit the possibility that their tools are sub-par.

If your feelings get hurt: good. Maybe if it happens enough times you'll move on to better tools and technologies, you'll have an easier time building better products, and your customers will be more happy.

I'm shocked at the disdain people on HN have for certain tools. I was always taught that it's not the tool, it's how you use it. I think Panic is a perfect example of that axiom. Their website (at least the older versions) has been emulated by web developers many times over. They were one of the first sites I know that enabled drag and drop icons to download files; they nailed scrolling content with tab browsing, and everyone quickly copied it. I assume they use their own tools, so while it may not sound like a cutting edge tool, they are certainly able to produce cutting edge results.

PHP is like the old rusting hand saw to Python/Ruby/etc's laser-guided table saw.

Sure, we're all cutting wood. But some of us are doing it with faster and safer tools. Maybe the consumer doesn't notice the difference, but the carpenter sure as hell does.

Building on the LAMP stack is still worthwhile when you don't have the time or money to devote to sysadmin tasks.

I use Rails, Django, raw PHP, whatever makes the most sense for the job at hand.

For the record, I use MySQL every day and still do some PHP work. So maybe you don't know as much as you think you do about me.

As long as the remote files are not in production and are under version control, what's wrong with editing them directly?

Sometimes it is hard to effectively duplicate the server environment (OS, RDBMS, ODBMS, web server, reverse proxy, other web server, caching tier) on a local machine. Particularly in a test deployment (as opposed to dev) you want to be very close to the production setup.

You're right about that first sentence but wrong on the rest. Editing files on the servers is pure idiocy even if you're using the system Panic does with an exact clone of the production server for dev changes and script that syncs them. Even in that scenario you can still easily end up with a FUBAR situation.

However, as wrong as that is, your comment tells me you're living in some kind of bubble. There are no right and wrong workflows or tools. Yes, there are objectively better and worse ones but not right or wrong ones. The fact is that the vast majority of developers actually do develop the way that Coda2 encourages. I don't agree with it and I know there's a better way just like you but Panic is just giving the people what they want. I just interviewed at a dev shop that actually had this exact setup: A development server. That's it. You'd edit on the dev server and hope to god you didn't screw it up. Yeah, real live, profitable, established companies do this. So do millions of developers.

No one is being an apologist. You're simply being an elitist. The world of professional web developers doesn't consist of what we all read on HN and see in the Valley. Real world development workflows would probably make someone like you puke but its reality.

People aren't convincing themselves that their tools are best. They simply have a preference for them and that's that. They don't care about all the bullshit minutiae that every HNer loves to navel-gaze about. They don't care if PHP is inconsistent and insecure - they build working apps with it that people love. I don't even know why MySQL is now a target of the hipster crowd. Is it because its too popular now? Seems like it.

But I digress. The point is that there really are as many ways to do things as there are developers and Panic shouldn't apologize for not pandering to the hipster set. Honestly, I was disappointed with Coda2 too. I used the original some years ago when I was learning and loved it. I moved on to better tools eventually but I will never say that your tool is wrong and mine is right. You build with what lets you build and I'll do the same. Some developers get by using tools some of us look down on because they simply haven't run across situations where they've hit their limits and the tools have become more of a hassle than a help. Not everyone takes the same path in their journey. Not everyone wants to be the best. Some people are cool with mediocre. Some are hobbyists. Whatever. Let them have their tools. Like I said, there's no right or wrong. Just good, better, and best (and even those come with their fine print).

For the record, I (as the author of the original article) agree with all of this. My point wasn't to say that Coda is bad, but rather to explain why it's never felt like the right tool for me.

What many critics don't really understand about Coda is that it's not necessarily trying to compete with the Textmates, Sublime Texts or Vims out there. As I've used it for years, I believe this tool is built with front-end developers in mind who primarily work with HTML and CSS amongst others.

Rather, I'd make the argument that Coda is the replacement for Dreamweaver. They have similar feature sets but Coda is less clunky than Dreamweaver has traditionally been.

Coda could become an amazing development tool if they allowed something like Sublime Text's Package Control and extensibility of the plugins from that type of architecture. When I go to other editors like Sublime Text, sometimes I sorely miss a Coda's code hinting, default file browser and GUI FTP client.

Hey, Jeff Croft (author of the article) here. I'm not sure you read the whole thing, or read it very closely, because I agree with what you're saying, and I said so in the piece. There's a market for the product, and I don't begrudge them making it -- it's just not for me. I wish Panic would make a product for me, because they make damn good products. It's like if I needed a pickup truck but loved BMWs. Coda isn't what I need, but I really, really want to like it because I love Panic's stuff so much.

I'm right there with you, man but what got people riled up is the way you mentioned PHP and MySQL. It came off a lot like a lot of posts by people who just really enjoy insulting anyone who doesn't use Ruby/Python and Postges/Any NoSQL DB. I'm sure you didn't mean it to come off that way but, unfortunately, to some people it did (including me I'm afraid).

I made no comment on which tools or languages are better or worse than others. I only pointed out that many modern apps are not built with PHP/MySQL, and Coda feels like it only really caters to those that are.

I can't argue with you. It's not what you actually said, it's how it was perceived. What we say and what others hear in their heads as they read are often out of sync. I really wouldn't worry about it though. Despite that minor issue some have the rest of your point still got across for the most part.

Heres where this article misses:

You don't HAVE to edit directly on the server with Coda, but it is an OPTION. You can just as easily work locally/commit and then sync with the dev server.

Also, not everyone works on projects hosted on a vps. ftp/sftp is very much still relevant in the real world.

Diet Coda is not meant to be a replacement for your macbook, that is why it is 10 bucks. Also recreating a virtual local file system with git inside an ios app is probably not worth the effort. I for one welcome the "quick hack" nature of the app. Its not meant to be an ide replacement.

"Much as I love Panic, I’ve never used Coda" then why are you writing a critique on software you have never used?

> Also, not everyone works on projects hosted on a vps. ftp/sftp is very much still relevant in the real world.

Those two things are not mutually exclusive.

you know what i mean.

I'm sort of confused. How does a vps differ from a regular server in terms of FTP usage?

If you have your own server then of course you can do fancy deployments, but locked down shared hosts make it harder. Ftp is lowest common denominator to get your stuff up. I'm just saying that many people need to work in these environments and don't have the luxury of being able to deploy in cute ways.

Also I find developing wordpress/drupal sites that working directly on the dev server is fine, and committing from there is the best flow. It can be a big pita and time waster trying to maintain these sites in different places just for shits and giggles.

moondev assumes that someone who uses a VPS is more likely to use SSH/version control rather than FTP.

Okay, I wouldn't really call his article a "critique". He's just presenting his thoughts on an app that hasn't even been released, and his points seem valid based on the initial feature list of the app.

You do have to edit files directly on the server with Diet Coda, and that's the product I was talking about when I made the point about editing files directly on the server.

And it wasn't a critique of software I've never used, it was an explanation of why it has never appealed to me.

"Much as I love Panic, I’ve never used Coda"

Just stop reading the article after this because whatever is said doesn't matter. If you aren't the audience for Coda and have never used it, then you aren't going to want their updates.

"Although Coda 2 looks like it has some great new features...it still feels like it continues this trend of catering to developers from five years ago."

Who says software (most especially code editors) should appeal to every single kind of developer? Look, it may not fit your work flow, but it sure as hell does mine and all of my coworkers. I know I'm not alone on this either.

Steven Frank of Panic, responds to Jeff in the comments: "There’s no way we could be a perfect fit for everyone’s workflow, so we concentrated on what we perceived to be the most common workflows, and those that would the most generally adaptable."

Bingo.

Nice of you to quote Steven's comment but not my reply where I clearly state how strongly I agree with him.

I had a whole response ready, but it looks like Steven Frank - one of the founders and devs at Panic - replied in the comments and addressed all the issues:

"We edit directly on a server — but not our production server. We have a staging server which is an identical clone of the production server, and also a Subversion working copy. A deployment script syncs everything over to production when it’s ready, which is a separate operation from committing it to the svn repo.

Ever since we shipped Coda 1, we’ve learned that there are as many ways to set up a web development infrastructure as there are web developers. There’s no way we could be a perfect fit for everyone’s workflow, so we concentrated on what we perceived to be the most common workflows, and those that would the most generally adaptable."

http://jeffcroft.com/blog/2012/may/22/on-coda-2-and-diet-cod...

I'd suggest that a very significant proportion of devs are of the variety Jeff describes. Panic is a business, and they've identified a market segment to serve and serve very well. It's not their job to encourage developers to improve their workflow.

diet coda will introduce a new class of developers - the touchvoper.

Reply on news.ycombinator.com