Saturday, November 5, 2016

Rails Isn't A Full-Stack Framework Any More

Rails is a terrific framework. Its emphasis on programmer happiness and convention over configuration makes building apps easy and fun. But it has some areas of cognitive dissonance. For instance, Rails bills itself as a full-stack framework, and I think that just isn't true any more.

The Rails solution for the front end is jQuery, unobtrusive JS, and CoffeeScript. These are great technologies, but each and every one of them is showing their age.

jQuery's the most egregious example. JavaScript systematically adopts its most successful open source projects and turns them into language features. Because of this, a lot of jQuery's functionality is now provided by browsers, including the fundamental thing of querying the DOM and modifying pieces of it. For sophisticated, modern use cases, jQuery can give you slow performance, especially on mobile devices, and it carries significant risks of brittle, unmaintainable code.

Unobtrusive JS is the idea that your JavaScript should provide decoration, not functionality. It came to Rails in 2010, the same year jQuery did, and each of these things was great for 2010. Rich single-page apps had existed since Gmail debuted in 2004, but in 2004, you kind of had to be a Google to pull it off. Even in 2010, unobtrusive JS was a reasonable, pragmatic default.

Today, however, it's just one of many examples in the history of Rails and its many ways to avoid writing JavaScript.

CoffeeScript is still pretty cool in my opinion, but here's the downside with CoffeeScript. A few years ago, Jen Fong-Adwent created a cool JavaScript project called Meatspace. It's a text chat client which creates an animated GIF of your face, using your webcam, every time you say anything in the chat. It's kind of dead now, but when she created it, it was full every night, with tons of people having fun. So I went in there and I decided I should read the code, to figure out how it worked. And I had a much harder time of that than I wanted, because Meatspace used new features of JavaScript that I hadn't seen before. Despite years of experience, I felt totally out to sea.

And that was a few years ago. Since then, ES6 has made JavaScript into an entirely new (and better) language. So while I still really like CoffeeScript, I also consider it kind of a dangerous choice, where you might be sacrificing your skill level for the sake of a little comfort.

This is the motivation behind my new book. If you're a Rails developer, and you want to do modern front-end work, you know Rails just basically skips the whole question. Which front-end tech should you use? How should you use it? You might be used to Rails setting you up with really useful defaults, but that's not what it does when it comes to front-end development. So my book gives you the necessary context to make these kinds of decisions, and walks you through several alternatives for modern front-end development.

Rather than sell you on it, though, I'd prefer to just tell you what I heard from somebody who bought it. Andrew Stewart, a Rails developer from the UK, wrote the PeepCode videos on Vim back in the day — they're now on PluralSight — and he said I could quote this awesome email he sent me. So here it is:
Hey Giles,

I just finished your book (v0.2) and I thoroughly enjoyed it.

I run a little SAAS Rails app and I'm always working on features, simplifications, i18n, support, etc.  I rarely find or make the time to upgrade the underlying stack.  As a result it's way behind; the front end is asset pipeline circa Rails 3.2 with jQuery v1.11.0, Coffeescript, SASS, some CSS I haven't converted to SASS yet, and a large amount of crappy 2007-style JavaScript I haven't touched for years.

Your book is exactly what I need!

I like how it's full of stuff I can do immediately to modernise everything.  I now intend to replace the asset pipeline with webpack, drop jQuery, and rewrite the old JavaScript in ES6.  Eventually I'll replace the Coffeescript with ES6 too.  Having said that, I'm looking forward to your Elm chapter...  (The React and Om chapters helped me decide to steer clear of them for now.)

Just one suggestion for v0.3 - a table of contents would be nice.

Anyway, I can safely say this is the most helpful programming book I've bought for years.  Thank you!


There is a table of contents coming, by the way, and the Elm chapter's about half-written. I have the code but it's not in a repo you can see yet. Sorry -- I write the code for these books in separate repos first, to figure out what I'm doing, and then re-write them for the book repo. This way I can make sure my commits are structured in a way that is more logical and easier to follow. I want reading the git repo to be as clear for my readers as reading the book itself.

Also, the React chapter might convince you to give React a shot. It's about thirty pages, and the last ten pages are all about the tradeoffs you have to consider when it comes to giving React a thumbs up or a pass. Those tradeoffs are different for different projects.

Regardless, I was obviously thrilled to get Andy's email, and I hope you found my own email useful.

Click here to learn more about my book.

Or, to buy it directly: