dhh

If you use something like jbuilder to build your JSON, then this exact same technique will work just as well.

You hit the DB for the top-level. So in step 6, we'll always hit the db for the latest project, but we will not hit the db for the todolists or the todos of those todolists if the project cache is fresh.

So you save the render plus any db calls that would be triggered as part of that render.

See step 6. The view is pulling the cache key straight from the domain model. It relies on being the informed as well about changes in its children to do that, which is what the setup in step 5 is about.

Because neither of those elements have any bearing on maintainability beyond what is customary for a Rails application. The wonders of pjax is that it doesn't require you to change your application style and structure at all, so it has zero impact on maintainability.

The granular caching scheme is similarly just a fragment caching setup using key-based expiration. Nothing new here, just that we used it to full effect.

So you're free to claim that writing Ruby on Rails applications are somehow inherently hard to maintain, but you'd be fighting against 8+ years of evidence to the contrary. Versus, you know, a very short amount of comparable evidence for JavaScript MVC applications based on current, recent frameworks.

On 50/50, yes, we write lots of JavaScript for Ajax. We've done that since 2005 with Tada list. The debate here is over whether going client-side MVC for everything is a pleasant experience. I contend that it is not.

The maintainability story with pjax+caching is exactly the same as its always been with a Rails app. We just celebrated 8 years with Basecamp. That's a pretty good run.

You can write shit, unmaintainable code in anything, but to point at pjax and granular key-based caching schemes as somehow specifically prone to this? What? That doesn't make any sense to me.

We also had a swanky in-house client-side MVC framework cooking with Cinco. We used it once for Basecamp Mobile and while it was a good experience and the end result was great, it did little to sway my thinking on client-side MVC being a step forward in programming happiness (one of the key things I evaluate platforms by).

Again, it's perfectly fine to have a different opinion. I don't like the aesthetics nor the sensibilities of Python code much, but I certainly respect that people can make cool shit with it and even that they might enjoy the process.

The hoopla here is over the terribly flawed notion that client-side MVC is somehow The Future of web development and if you don't follow that pattern, you're living in The Past. Ha.

Matt, I don't think there's all that much difference in money spent (you still need to buy servers either way and you still need to cache even if you return JSON). We crank out functionality faster when it can be done server-side because the development experience is better and because Ruby still beats even CoffeeScript (although not as thoroughly as it used to beat vanilla JavaScript) for productivity.

I find the complexity needed in having MVCs on both client and server side to be the main problem. Especially since much of what applications like Basecamp are not all that heavy on the UI-interaction. A few bits are, like a calendar, so we use it there.

But obviously you can make it work either way. Just like Facebook manages to make PHP work. And some crazy kids still use Java. You should pick a development environment and style that fits your brain and your sensibilities. If you think client-side development is lovely, then by all means, go to town. Some people even think JavaScript is still as well as Ruby and that you don't even need CoffeeScript -- peace be with them.

In terms of client-side MVC vs server-side renderings, the ration is more like 90/10 or 95/5. We have one major section that's all client-side MVC, which is our calendar. We have one tiny section as well, which is a little invite widget. Everything else is server-side renderings.

To me that's like how we in the past used Flash to play sounds in Campfire. Or reimplemented a poller in Erlang. Or use nodejs for the development Pow server. Use all the great tools available in the niches where it makes sense.

But the bulk of Basecamp is exactly the type of application that makes wonderful sense to do in Ruby and Rails. We've been sending down chunks of HTML in response to Ajax requests since we started doing these types of apps in 2005. So far I haven't seen anything to make me reconsider that approach for the majority cases.

Is that supposed to be a slam? I've been working on "custom" platforms for the better part of a decade.

I'm not sure what qualifies as sustainable or not in your book. We've achieved our speed goals (sub 100ms pages for the most part), our development goals (Ruby, Rails, server side pleasure), and our UI goals (app that feels like a web page, not just a single-page JS app).

I'm sure Flash or Silverlight or other RIA people would argue that anything that's not a compiled native experience isn't as flexible or as fast as whatever they're peddling. Meh.

Yes, it's great to occasional dip into advanced client-side when that's needed. Just like Flash had its legitimate use cases here and there. But for the bulk of the UI interactions we're giving people, it's just not needed (or desired).

I'm not sure I understand the pain point you're describing. What's "styled HTML"? We're sending HTML across the wire that looks exactly like the HTML we used to render the initial page. It has classes, ids, and custom data descriptors.

We have not experienced any pain doing this.

50-100ms is the time it takes to generate the response on the server. On top of that you have to add the ping time between you and server and whatever other network overhead there is.

That's why it's great to be closer to 50ms so you'll stay under 100ms even with the network overhead.

We've found that the additional overhead of sending HTML vs JSON is negligible in most cases. The additional speed gained by just sending JSON across is not worth the programming enjoyment hit of doing everything client-side.

When you get below 50-100ms per action, things are generally fast enough that this is not a key problem any more. The user cares greatly if you can go from 800ms to 100ms, but not so much if you can go from 100ms to 70ms.

Not for the time being. Stacker is specifically developed for this unique UI style that we're using for Next. We don't open source our UI elements.

We don't do that. We only discriminate against browsers we know will have problems. Like IE6-8. So what we're running is actually a blacklist.

If you show up with a browser that's not one of the big four, we're just letting you in on your own accord.

I completely agree that whitelisting for browsers is bullshit.

We certainly have! I would be embarrassed if we hadn't.

Also, that's why we're comparing uptime against big, established web applications. I would not hold these standards up to a 1 year-old, newly started business. You have far more important things to worry about than getting an extra 9 on your uptime.

Sounds good! Remember to setup transaction tracking, though. Just doing pings or http get and expecting 200 OK on a page is not enough for this to be interesting.

For Basecamp, we login, go to a project, and post a message, or something like that. So you catch as much as possible.

We do more than just login to the apps. We login and go to an expected spot. So it catches all of that.

This includes total downtime yes.

We configured all the benchmark apps to expect a response. So on Github we go and checkout a repo. On Freshbooks a known invoice. On Assistly the agents index. Etc.

This is "the app is functional" checking. Not just 200 OK.

Yes, we're launching with an API. The code stats include those for the API.

We will not support old versions of IE. We support IE9+.

I worked pretty much alone on the code base for the first three months. Then we were two people for another three-ish months. Then the last four months or so we've ramped up the team to have 4-6 programmers on, depending.

But we're also ruthless about keeping the code base small. In the beginning I would go through the entire code base every week and prune it. I still read through the entire thing every now and then and make sure there's no excess fat.

Don't hold your breath. We haven't revisited the mobile version of Basecamp since we released it and haven't started any other new projects based on Cinco.

I'm not sure when/if we'll have a chance to get back to it.

The UI has been designed to work great on tablets and it also works pretty well on a phone (albeit a tad crammed). We'll probably do something more dedicated for mobile after launch.

Andy, Basecamp Next does not have a one-screen app feel at all. We're still all about separate pages.

But we do rely heavily on JS for functionality, so it won't work without it.

Key-dependency is achieved using touch-parent-on-update.

This is all for HTML fragment caching using key-based expiration. I'll write up all the details soon.

I'll give away that secret right now: Key-based expiration.

Last I checked, I believe something like 20% of our customers were from the tech/startup scene. The vast majority of our customers are regular businesses.

But yes, we're still tiny compared to behemoths like Sharepoint. All the more reason to be excited about the next 20 years!

I thought of this after we hired @qrush. He instantly started arguing with everyone about everything from technology choices to feature selection and I thought to myself, "that's so awesome". And then I thought that we've had a long history of hiring people like that and how well it's worked out.

And at the same time, how less than stellar it worked out elsewhere both for myself and others who fell under the spark-on-the-first-day column.

All expenses are indeed tracked by virtue of using a credit card. Electronic receipts are forwarded to a shared email address. For everything else, we're willing to run the risk of an audit that might argue over the purpose of a lunch to save our employees the hassle of expense reporting.

Acceptable risk and cost of running the business.

Can you ask? I'm curious to learn what these background checks entail. Also, if they actually do prevent bad apple's from joining, why not do them to programmers as well (given that they have the power to program backdoors etc into systems).