Should your web application be rich-client from day one?
For the sake of discussion, I'm going to make a recommendation about the state of web application development today:
I'm not saying I believe this idea 100%, mind you. But I feel like we may be reaching some sort of specific tipping point, and I'm interested in teasing out why this would or wouldn't be a good idea.
There's bad news, and there's good news
There are plenty of good reasons to avoid jumping on this particular bandwagon:
- Many of the tools, patterns, and practices are immature, and your development speed will be significantly slower than if you build your web app using more traditional techniques.
- There are way fewer serious front-end engineers than there are serious Rails/PHP/Python/.NET engineers, and if you have to hire into this codebase you're going to either pay more for those engineers or hire other engineers and expect some non-trivial ramp-up time.
- Although the Architects among us love nothing more than defining an API, I'm a firm believer that decoupling isn't free: When the code is brand new and the requirements poorly understood, it can waste engineering time and inhibit agility to have to make changes across architectural boundaries. Yes, passing an instance variable from a Rails controller to a view is sort of sloppy and will probably be insufficient one day, but when you're just getting started with a small codebase, that sloppiness works in your favor.
But no matter how rickety the wheels look, there are some good reasons to jump on this bandwagon right now:
- One day, you'll want all those APIs defined anyway, for iPhone apps, Android apps, mobile-optimized sites, partners, power users, etc. In fact, those of you starting mobile-centric products have the moral clarity of needing an API from day one, so this decision might already be made for you ...
- If you write both a traditional web app and an API, then you have two places where the business logic could end up living, which of course is a petri dish for code repetition. Yes, I know you are a smart and diligent enough programmer that you'd never copy and paste anything from one side to another when you're feeling rushed. But please spare a thought for your fellow coders, who aren't so blessed with your work ethic or your mighty intellect.
- Right this minute, there are successful, serious web applications whose teams are thinking "God, it would be awesome if we could rewrite this in Backbone/Ember/etc." But they might never do it, because they know the pain of that transition will be massive. So, it might make sense for your brand new site to future-proof itself by starting as a rich-client app from day one.
"You Aren't Gonna Need It" vs. "It's Gonna Suck To Get It Later"
A lot of this comes down to cost of change. If it were the case that you could make this transition incrementally, without stress, and without a ton of work, then maybe you could make the argument that going rich-client early on is just gilding the lily. But is that possible? Every time I've ever had the transition discussion with someone it ends up being vaguely stressy until we decide not to talk about it ever again.
Then again, there are probably teams taking this on right now, and they may discover good patterns to help the rest of us. Maybe we'll see a burst of blog posts titled "how we moved our traditional web app to Backbone.js without losing our hair or our money" in the near future. But if I had to bet, I'd guess that it will always be a tough nut to crack.
Nobody ever said "I like it, but I wish it involved more waiting around"
This all stems from my entirely subjective, unprovable opinion that rich-client applications are just better. Responsiveness doesn't just mean that the user can do things faster. It means that she'll like using the application more. It means she can can push ahead to her goal with fewer chances to lose focus. It means that the data and the interactions will feel more concrete and reliable. It means, fairly or unfairly, that she's going to trust the site more, and maybe even be more likely to pay for something.
This isn't some pie-in-the-sky futurism: Users are being trained to expect this right now. They don't even know what to call it, but applications like Gmail are feeding them the expectation that web sites should all be this responsive.
It wasn't long ago that making these apps was insanely difficult, so most of us shrugged our shoulders at Gmail and figured those sorts of problems were above our pay grade. But frameworks like Backbone and Ember are steadily pushing the cost of implementation downward. Your competitor may not have a rich-client app today, but maybe they'll have one tomorrow. When that happens, how many of your users do you think you'll lose?
I could just be jumping the gun here. But allow me a prediction (and feel free to tease me when it doesn't happen): In five years, the vast majority of significant web applications will be rich-client. I can't see any reason that the web wouldn't move forward in this way.
If that prediction is right, then right this minute we're in an uncomfortable position: We can see the future, but we can't see an easy path to it yet. Maybe it's on us to build it, or maybe we'd be better off to grit our teeth and stay back from the fray.
I'm not 100% sure what I think myself, but it's a topic worth discussing now. Thoughts?