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.
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.
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.
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).
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.
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.
trello.com, a.k.a. the "desktop" version, is device-agnostic so that it will actually work on any just about any laptop, smartphone, or tablet. You're getting the same code on every device, so it's cross platform in that sense. The custom scrollbars on the web are just a webkit thing. See: http://css-tricks.com/custom-scrollbars-in-webkit/
That said, we want to create the best experience for your device, and nothing beats the experience of a native app. Try them side-by-side. Each native app is written in its native language (Obj-C, Java, etc.). It's more code, but they just turn out better that way.
It's true that self-closing, non-void elements are not valid. With gzip, it's probably not even worth the savings in size. I know it's bad and we shouldn't do it and it will probably blow up in our face one day, but it doesn't seem to matter in practice and I just like the way it looks.
Ah, well copy protection is definitely not a concern for us, since we serve the raw TTF alongside the other formats. The fact that the WOFF file was about 30% smaller than the TTF was more of a deciding factor.
Awesome. This approach can definitely work for lots of people. We default to WOFF because it's essentially just a slightly more compressed OTF file, it's something all browser venders seem to agree on, and it just seems like The Right Thing To Do for the web. We serve raw TTF files for the stock Android Browser. I had so much trouble hinting the raw OTF font for Chrome on Windows that I gave up and used SVG. As I mentioned in the article, SVG fonts don't get mangled by the browser's font rendering engine or ClearType.