Tag Archives: frameworks

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.


I write Mac software, but over the last year I’ve increasingly been building Ruby on Rails web apps as well. Today I finally took a look at “RubyCocoa”:http://www.rubycocoa.com/. I wanted to whip up a quick Cocoa app that would involve some text parsing, and a dynamic scripting language like Ruby is a much better fit for text processing than C, C++, or Objective-C.

It turns out RubyCocoa works amazingly well. I have only scratched the surface with a small test app, but I was blown away by its ease-of-use, Xcode integration, example projects, and apparent maturity. You have full access to AppKit from Ruby-based controllers and views, and a single NIB file can even reference both Objective-C and Ruby classes. Fantastic stuff.

I don’t know if it’s ready for commercial software use yet. For distribution, I tested including the RubyCocoa.framework inside the application package and the app launches and runs correctly on a system without the full RubyCocoa install. There may be issues with requiring a recent version of Ruby, but otherwise it’s a fully native app.

My only disappointment was in the Objective-C calling conventions. There are two versions to choose from: a style using underscores to separate named values, and a slightly easier Ruby syntax using symbols and extra parameters. Here they are:


[my_window setFrame:r display:YES animate:YES]

Ruby Underscores:

my_window.setFrame_display_animate(r, true, true)

Ruby Symbols:

my_window.setFrame(r, :display, true, :animate, true)

In my opinion, a better approach would be to take advantage of Ruby’s trick of allowing the last parameter to be a hash supplied without the curly braces. This feels more readable to me and more closely matches the Objective-C equivalent.


my_window.setFrame(r, :display => true, :animate => true)

In any case, that’s a minor complaint and doesn’t take much away from the beauty of writing native Mac apps in Ruby.