Tag Archives: ember

Rewriting in Rails 5

I’ve been doing Ruby on Rails work again. Although my indie web projects are all Sinatra, I generally recommend to clients that Rails is the way to go. Rails will be easier for them if someone else ever needs to take over the project.

I don’t like using 2 products that do the same thing, though. That’s why I consolidated my web app hosting to Linode, and my source code to GitHub. Why should I switch between 2 frameworks, especially since Rails has matured so well? I’m enjoying Rails 5.

David Heinemeier Hansson said in an interview on Slashdot, about the rise of JavaScript front-end frameworks:

But it seems like that’s one of the lessons people have to learn by themselves. Just try to string things together on your own a few times and you’ll quickly get an appreciation for what Rails provides as a backend framework. We’ve had tons of programmers try just that and come back for refuge.

It struck home because I’ve had some regrets with choosing Ember.js for my new app. Part of that is my own lack of experience with the framework. But also I’m no longer convinced that the heavily JavaScript-based view layout of something like Ember.js is better than Turbolinks, for example. I plan to rewrite my app in Rails and more classic Ajax at the earliest opportunity.

Using Ember.js

Brent Simmons isn’t totally convinced about the new crop of JavaScript frameworks:

“Part of me thinks those frameworks are overkill (even jQuery), and that writing regular-old JavaScript to do what you want is not that onerous a thing, and will make for leaner, better code.”

This was how I felt when I built Watermark. It uses jQuery and Bootstrap, but otherwise it’s pretty old-fashioned JavaScript. Even the parts that are Ajax just fetch and insert HTML that has been rendered by the server. There’s not much to do in the client.

For my latest project I’m using Ember.js. I want this app to be very fast, and I think putting more work on the web browser is the way to do it. I only know the basics of the framework so far, but already I like it. It feels lightweight to use, even if the actual JavaScript include is fairly large.

And 100k is really not that big of a deal anymore. You don’t want bloat for no reason. But look at a popular site like twitter.com and you’ll see several JavaScript files between 200k and 500k each. They get cached and no one complains about performance.