Please note that the videos are currently available only for the talks presented in Room 202. There were five other tracks, and the recorded videos will be published soon. Thanks go to Confreaks for recording all Rails talks!
DHH’s Keynote
David’s keynote, a must-watch:
David announcing Rails 5
Yaroslav: First and foremost, it’s hard not to /facepalm after seeing this:
As a team member of the Ruby NoName Podcast, a Ruby-and-everything-related podcast, I interviewed Aaron Patterson on his visit to RailsClub’2014. One of the topics (that, of course, just had to be discussed) was if Rails is still led by Basecamp development; and yes, Aaron confirmed—it’s still pretty much “Basecamp Rails” (and there will be no attempt at making, say, “RedHat Rails”, following Aaron’s new job at RedHat). David is the one calling the shots, plain and simple. While it’s been known for a while now, it’s still surprising—and it’s not a good kind of surprise—to see that while one of the most important Rails maintainers is trying to make a good Node-like API for Rails, the announcement of a full-stack Websockets support can be completely sudden even for him!
Second, the Rails 5 announcement itself. Mad props go to David for walking the audience through the thought process and decision-making process in deep. While both of main announcements (ActionCable and Turbolinks 3) do sound promising, it’s still impossible to try ActionCable out at the moment of writing (the release is due in a couple of months, I think). The Turbolinks 3 gem seems to be merged into the repository, and we are going to try it out a bit later.
The biggest problem with Turbolinks so far, of course, was its “resentment” to all and any JavaScript frameworks. An alumni of Evil Martians, Sasha Koss, tried to solve the problem with the jquery.turbolinks plugin, but wasn’t successful much. Still, the biggest question to Turbolinks 3 stays: it’s not about the increased list of features (they do look great for quick development and prototyping — as opposed to starting an application with a full-blown SPA approach), but if Turbolinks still breaks all cooperation attempts with other JavaScript frameworks. Even with the most basic applications you would eventually kill all Turbolinks-related code and switch to do-everything-yourself approach as it would be faster and cheaper than integrating Turbolinks with other frameworks. I hope that it is no longer the case, but I’m not too optimistic.
To finish, the pros and cons of these two new announcements (not talking about the --api app generator switch, that is in no way new) are that they are surprisingly not that important for Rails future.
If Turbolinks does annoy you (from my point of view, that is true for most Rails teams), just don’t use it — it does not matter much. If you like the approach and have an “allergy” for JavaScript as a language and for any JavaScript framework as a consequence of that — the update is definitely for you. I still wonder about how usable exactly ActionCable would be, but the truth is, a lot of Rails applications are already utilizing more than one language at the backend, and people (our team included) have been implementing WebSocket backends for a number of years now. You could go with Node.js, Erlang, a JVM-based language like Scala, Go, or whatever the favor-of-the-month language is. So far, it does not sound like ActionCable would fundamentally change the way things are in that department.
