FWIW, Trello didn’t launch with an API. It’s something we added in the first few months after launch. Just about everything goes through the API now since the mobile apps also use it, so you could say it’s an API first design NOW.

It’s true that Trello never supported IE8, but we never promised or intended to add IE8 support. We wanted to support the browsers of today and tomorrow, which was IE9 at launch.

I stand corrected then, you never even tried to get the IE crowd.

But my point that you're misreading numbers remains. You see low IE9 usage because you don't have IE users, because, in the previous years, up to 80% of them couldn't use your product.

And now you're using these numbers to back your decision that you don't need IE9. Guess what? You won't see IE adoption grow much over the next years as well.

IE users means enterprises. By dropping IE9 now, you're again running faster than them. That's perfectly fine and I'm actually jealous, I wish I could do the same. At the same time, I'm sure it has a measurable impact on the potential market of your Trello business class product.

This makes a lot of sense. If you don't ever support a browser, then there's no apology required when you remove support of it.

Everyone runs dev environments locally and tests. A dev environment is really easy to set up with mongo and node. Occasionally, we’ll put stuff on a staging environment if we want to test a database or infrastructure change. Big, experimental client changes go to the alpha channel on production.

So when you have 2 features/bug fixes in the same area, built in 2 different branches and deployed to isolated dev/test environments... the first time you might find out that they dont work well with each other is in Staging? Why wait for that when you could deploy to a common environment and catch issues sooner?

Btw... I am trying to get some teams in my company to get out of branching. So trying to understand your view (which is exactly what these teams are doing), hence these questions...

That rarely happens in our experience. With our internal board, we know who is working on what and in what area of the code. Plus, all code is reviewed by someone working in the same area.

It was a joke. =)

I reread that paragraph. In context, it doesn't seem so.

Read more than just the paragraph. The entire article is written in a "fun", joking style.

> The revelation could result in a rippling shockwave that knocks you off your seat and may have troubling, unpredictable consequences for the time-space continuum. Possibly.

> You’ve probably downloaded our iOS, Android, Kindle, and/or Windows 8 apps, and are saying to yourself, “These are very well polished apps which I have rated or will rate favorably in their respective app stores

> The Trello API is well-written, has no bugs, and is totally rock solid. Or at least it doesn’t change very often. [Goes on to only reference the fact that it doesn't change very often]

I like the passion for the product. Shines through very well.

You figured it out. They secretly don't have any bugs. Shhh.

When it's nobody's job, nobody does it. Any developer COULD do it, though.

If there are necessary API changes, we just need to push updates to the API ahead of time. The API needs to be stable and backwards compatible anyway for the mobile apps (and all third party apps).

Yup. More about the tech stack here http://blog.fogcreek.com/the-trello-tech-stack/

Right. The there is only one version of the API. Multiple clients.

I hope Doug writes a more technical post about the multi-client build/release process. We have unit tests for the whole API and very few automated tests for the front-end. Client builds are stored in S3. We use mongoDB and will do backfills if necessary (pretty rare). Rolling back the client is just pointing the stable branch to another build.

Bobby, you said every app is a client of the API. I notice Trello.com consumes API from https://trello.com/1/xx while an OAuth client (from one of your Jsfiddle examples) consumes from https://api.trello.com/1/xx?key=xx&token=xx. I suppose the former just passes through to the later? If so, does the former needs to pass over the key and token (I suppose you can generate on the fly based on auth cookie)? I'm trying to get my head around the fact that your app provides OAuth for other clients and at the same time (from what you're saying) your app is also one of such clients. Not sure how it really works.

If you control both the OAuth client and server (that is, the client is always trusted and doesn't need manual authorization), you can dispense with request tokens and just issue access tokens directly, and forget about the whole authorization flow.

api.trello.com is just a CNAME to trello.com, in case that difference was confusing you. The authentication part is taken care of differently depending on the kind of tokens we get (the web client uses a cookie) but we turn that data into a standard authentication object and the rest of the route uses the same code regardless of request type.

Got you. This is very helpful, thank you!

Trello dev here.

The web client (trello.com) has a cookie that has the auth information. The actual code executed for both examples is identical.

Please ask Doug to write that ASAP :D (just kidding).

NodeJS community (and to some extend, the RDBMS/NoSQL crowd that wonder how to support different version of the model) would probably learn greatly from that type of article.

er, by stable branch, i mean stable _channel_. or whatever channel.

Yes, this was in perceived rendering time, and yes, the trade-off was worth it. We kept the async rendering stuff localized so it doesn't complicate the app much.