A New Sense of Purpose for Rails

I’m glad to see Rails supporting multiple architectures. The stuff they’re adding into Rails 5 will give developers a lot more flexibility when it comes time to build a front-end for their application (or multiple front-ends for apps that need separate web and mobile apps). That’s a good thing.

I took issue with this, though:

But if you’re a “prepper” (to borrow a term from DHH’s
keynote, a team of one or two people building a product that competes with much larger teams), I think you’d be wise to bet on an architecture that allows for offline support, fast client-side routing, and user interaction on par with native apps. Anecdotally, all the preppers I know are betting on a backend built with either Rails or Node.js, paired with a JavaScript frontend.

In my roughly 20 years of web development, I’ve never had a client say to me, “You know what our app really needs? Fast client-side routing.” Nor have I had any who were interested in providing a web-based interface that matched a native client in terms of features. When clients want native performance, they get a native app. And they understand the limitations of a web-based interface.

This sort of justification for JavaScript-based front-ends comes from a place of pure nerdery. Bleeding edge technology doing things that barely work within the constraints of a browser just because we can. It’s a bad practice, and folks need to stop advocating for it.

Complicating a codebase with more JavaScript just to do something that could easily be done on the server with less code and fewer hoops to jump through does little for the user experience while making the application harder to maintain. The majority of users won’t know the difference between an interface written with Ember and an interface rendered on a server. Writing an app with a JavaScript-based framework satisfies the nerds on the team who really want to use the latest tech; it does little for the user.

“But the interface renders slightly faster with a JavaScript-based client!” Sure, but at what cost? Extra hours spent writing JavaScript that could have been avoided? If you have the time to invest, well, okay then. But if you’re passing that cost on to a client, I doubt they’d appreciate it.

Look, your application isn’t Twitter. It’s not Facebook. It doesn’t have nearly as many visitors. Odds are very good that your app isn’t operating at a huge scale, and–sorry to break your heart–it probably never will. If your pages are loading slowly, benchmark your code, find places to make improvements. You’ve likely done something wrong if an app that gets even moderate traffic is running slowly on a modern back-end framework like Rails. Painting bad code with JavaScript isn’t going to fix your problem.

It’s worth pointing out that the author of this article is also the creator of Ember, one of the most popular JavaScript-based application frameworks. So I understand his goal here is to promote his product. And that’s fine. But let’s be honest: you don’t need to build your interface in JavaScript to make your web application future-proof.

Supporting multiple clients, though, is absolutely worth thinking about if that’s what your users need. Rails 5 is going to make these architecture decisions easier, and that’s pretty exciting.