The Everlasting App - No SPAs Allowed

I’m often embarassed by one of my applications. It’s old; git blame is ruinous to my developer ego; it’s “designed” in Bootstrap 2.3; the UX…needs improvement.

Luckily, it solves real problems for my customers and that’s what matters. But one feature of the application doesn’t embarrass me: its code durability.

Some background:

It’s a mostly server-rendered Rails application.

The frontend is all jQuery/CoffeeScript (the horror!) and some Mustache templates (remember those?).

It contains my own javascript “framework,” which I wrote before there were such things.

So what? you say. Have you ever left an Ember/Angular/React/framework-of-choice project alone for a while and tried to come back after 2 months, 6 months, a year? How long did you spend upgrading everything in sight, fixing broken dependencies, realizing certain addons/packages are no longer supported, and generally being angry at the world just so you could add one tiny feature or fix some bug?

In my application, I’ve noticed I have none of those problems. I can leave most of the codebase completely untouched for years (and I have), and then jump right back in and add features. No yak shaving. No upgrading. When a new developer works on the project, the architecture (including my custom JS “framework”) can be explained quickly and easily.

This isn’t a post to congratulate myself. I’ve had this lurking suspicion about huge, not-so-hidden costs in opting for the new hotness (read: highly complex, ever-changing dependency) in web dev. Lord help the person who wants to revive a 5-year-old webpack config file for someone’s React application. Ember has slowed its pace a bit, but for a while it was tough to keep up with framework changes with a team working on the app full time. We had some damn fine animations, though.

As developers, it seems like we’ve adopted the iPhone mindset for application development: it’ll be obsolete in 6 months anyway, so who cares? With many developers never experiencing the kind of stability I’m talking about, it just becomes assumed that this is the way it is.

You might argue these frameworks add productivity that can’t be reproduced without them. There is a kernel of truth there, but 80% of those benefits can be duplicated rather easily with good design and plain javascript (or Dart, CoffeeScript, etc) and the tradeoffs are huge. Maybe React, et al. make sense in the fast-paced, idea-testing world of fledgling startup MVPs. It also might be less cumbersome for large companies with abundant resources to throw at app maintenance. Speaking for myself, I prefer to write code I can forget about until I need it again.

Want more?

I'm Garrett Lancaster. I co-founded and developed a moderately successful SaaS app you've never heard of. I mainly work on projects using Ruby on Rails, Ember, React, and "VanillaJS". If you liked this article and want to hear about the next one, click below. I don't spam and I respect your privacy.