← Back to Upcase

Feedback on the Hands-On Backbone.jS on Rails Workshop


(Scott) #1

Hi, I really liked the first half of the workshop. I coded right along with Sean Griffin, and it helped tons with my backbone comprehension and even a little with my Rails and vim skills. It was great, highly recommended.

Here are some thoughts on the videos without “Advanced” in the title…


My biggest question is this: where on earth is the testing? Do you guys really write Backbone apps with zero tests? The amount of “Cmd-R, and… it works!” in these videos is fairly shocking. That can’t possibly scale up to a real project with multiple developers, can it?


And my biggest request is, please commit more! And, for pity’s sake, use decent commit messages. The videos present coding nonstop, blurring the features together. After each feature, if the presenter took 5 seconds to commit and then continue coding, it would be a lot clearer what’s happening and why. It would also make the hands-on-backbone-js-on-rails-solution repository a lot more useful (18 videos but 13 commits…?).


The Validations video is problematic… The Backbone validation at 4:15 actually doesn’t work. Or, it works, but only when you click outside the note to blur it like Sean did. If you hit tab to leave the edit box, the class is added and removed instantly, preventing the error from ever being visible.

And, even if you do click outside the note to display the error, try clicking into and then outside the note again. The error condition still exists but the error is cleared! (This happens with both the backbone and rails validation techniques).

Ultimately, it makes BB validations look pretty opaque and brittle… I’m not sure if that’s true in real life.

I did like the console debugging though. It’s easy to forget that Backbone can be manipulated just by typing.


“Responding to Server-side Changes” should probably be renamed to something like “Reloading Records on Save”. I thought we were going to see some excellent long-polling or server push action, dynamically updating the BB app without any input by the user. Turns out all we did is reload the model from the server’s response. Yes, that’s useful, but it’s not actually responding to server-side changes.


And that’s it. Overall, it’s great. Anyone taking this workshop, I recommend stopping here and writing your own Backbone apps, you have almost everything you need.

As for the remaining videos, the ones with “Advanced” in the title… well, that’s another story.


(Scott) #2

Warning, this will be very negative, but it only applies to the last five or so videos in the series. I found them frustrating, confusing, and I felt less prepared to write a Backbone app after watching them. Wish I’d skipped them.

I wonder if some important bits have been edited out…? I coded right along with the first 10+ videos and had a great time, but I found that impossible on these last few. There were a bunch of times when Sean would pull up a Backbone view that had different contents from my view, or where my app’s behavior didn’t match his. Took forever to debug. This might be my mistake, of course, so I’m curious if others found this too.

Here are some random notes I jotted down while watching…


Advanced JSON Input and Output seems weird. Was it truncated? It was 100% unrelated to Backbone, and didn’t have much Rails content either. You might be able to replace the whole episode with one sentence spoken in this video, “we’re going to use ActiveModel::Serializer to render the json instead of JBuilder because it feels more natural and object-oriented to me.”

I promise it won’t take a week to understand this lesson!


The past few videos have been becoming increasingly poorly organized but Advanced Model and Relationships - Part 2 is a mess. It’s basically watching a skilled programmer just winging it. There’s no sense of design or planning, and a fair amount of time is spent on backtracking and bugfixing. It’s still interesting, true, but I think it’s a poor use of time for people like me who just want to learn Backbone and maybe Rails.

And, is it really best practice to implement the Backbone UI first, then go back and patch the rails model to match? That feels like cowboy coding. I understand why you’d want to do this in real life, especially if you’re prototyping something that you’ll rewrite later, but in a training video??


There’s an awful lot of dead air in these last few videos as Sean tries to figure out what’s going wrong. Don’t get me wrong – a few times is absolutely fine and lends an air of authenticity. Now, though, it’s getting extreme. I didn’t count, but it feels like 25% of the video is dead air, backtracking, or apologizing. Some editing or re-recording seems necessary.


Explanations and background have pretty much disappeared and Sean is doing the programming equivalent of reading the slides… He’s describing what he’s writing, but I can SEE what he’s writing. I want to know why he’s writing it!


A bunch of times you mention a more robust way to implement a feature. Sure, that sounds reasonable, but I’m worried that you’re mentioning it in passing while coding. Did you just now realize that you’re not implementing it correctly? Are you essentially dropping 'TODO: fix me later’s in your training video??

I feel like TDD would have helped here. Then you could just write the code to satisfy the test and future-proofing can come later.

Ultimately, yes, some of these design decisions do look a little short sighted. I understand that training videos need to take some shortcuts, but I want to hear about them up front during decision making, not as an afterthought!


Given the previous adventure with validations, the “Our validation here is apparently broken” comment at 6:10 of Advanced Backbone.js Behavior was kind of entertaining. Yep, we’ve been here! Now it’s feeling like something is really wrong with how backbone validations have been presented and I’m a little annoyed that apparently I have to figure it out on my own.


14:15 of Advanced Backbone.js Behavior: “Little bit convoluted but that’s OK”. No! No, that was very convoluted, and I’m not at all reassured. I have no idea why we just went on that adventure of writing stuff, backing it out, and writing some more. I don’t understand, what’s the lesson here?


The last half of “Advanced Backbone.js Behavior” is just a thrash fest.

Did you really change your implementation at 17:15 because you were blindsided by a bug? I can’t even follow what’s happening anymore, much less why.

You say, “there’s a little but of code that got funky. Particularly the way we’re saving todo lists and todo items could be better…” Well, that’s certainly true. But is this worth presenting? I’m getting the feeling I should unlearn the last 1/2 hour…

“I purposely made the Rails API a little convoluted…” Then, HOLY COW, mention this up front? I’m watching these videos thinking you’re demonstrating what I should be doing, trying like crazy to follow the decisions you’re making, then you tell me at the end basically what you did was intentionally weird and it probably shouldn’t be done this way. At the END?


So… The final app is unsatisfying. If this is an example of what I can do in a few hours with Backbone then I’m not real impressed. The pre-todos app was better. Sure, it was absurdly simple, but it worked and and had a decent UI.

I think I understand why it feels like you glued the todos models haphazardly onto the note model… It doesn’t seem like the feature was very well thought out.

I find it scary that adding the todos seems to have cause a surprising number of bugs and pitfalls, and produced some noticeable code churn and dead spots. I’d hoped Backbone was better at future-proofing than that. (I’m guessing it is, we just didn’t see it…)


Hm, Backbone.stickit is up to 0.8.0 (and 0.7.0 was released at the end of 2013) but backbone-stickit-rails is still at 0.6.3. It looks abandoned? I question the decision to include this gem in the training video.


So that’s that. Overall, I still liked the workshop. Stop before the Advanced videos and you’ll have a great time.