Embrace JavaScript

Embrace JavaScript

Keynote from RailsConf 2013.


Yehuda Katz

May 01, 2013


  1. 2.

    “I am noticing a common quality in Katz' recent foray

    into JavaScript, that being his desire that it be like Ruby, the language for which he's best known”
  2. 5.

    The Mozilla Foundation and Opera Software presented a position paper

    at a World Wide Web Consortium (W3C) workshop in June 2004, focusing on developing technologies that are backwards compatible with existing browsers including an initial draft specification of Web Forms 2.0. The workshop concluded with a vote, 8 for, 14 against, for continuing work on HTML
  3. 6.
  4. 8.
  5. 9.

    Ruby and Rails In this kind of environment, who wants

    to rely on the browser for anything? As much as possible, we wanted to take our destiny into our own hands and do things on the
  6. 10.

    2007 IE7 was released in 2006, and soon enough, people

    got the bright idea to abstract the browser. Instead of writing HTML and CSS, these frameworks had you write your entire UI in JavaScript. Needless to say, this sucked! People were trying to emulate a Flash-like developer experience, but as DHH said yesterday, that experience
  7. 12.

    But in 2007, something else happened. The iPhone was announced,

    and with it a backlash against frameworks like SproutCore, which were too heavy for underpowered mobile devices.
  8. 13.

    <3 HTML <3 All you really need to know from

    that little story is that JavaScript people in 2013 love HTML. The strand of thinking that led to totally abstracting the DOM has lost and browser JavaScript today looks nothing like that straw
  9. 14.
  10. 15.
  11. 16.

    The Web Today The web today is a totally different

    place than it was when Rails was created, and even when I was working full-time on Rails 3, but we're still looking at things through the cynical lenses of that era. It has never been a better time to be a web IE no longer rules the
  12. 18.

    Locus of Innovation The locus of innovation has moved. Today,

    the most exciting innovations are happening not on the server, but on the client. In the right hands, these tools can be used to build amazing experiences on the web, and your users are demanding them.
  13. 19.

    Agreement! And DHH doesn't disagree with me that modern applications

    need a lot of JavaScript. Rails is great for apps that leverage browser templates. Think about what % of your app involves generating views vs. other business logic.
  14. 20.

    960 KB I just want to emphasize: there is nothing

    wrong with this. BaseCamp is a great application that feels good to use. It just shows that pretty much everyone who builds great experiences uses a bucket of JavaScript
  15. 21.

    Mental Models While there's no diagreement about whether to use

    JavaScript, there's still disagreement about how to think about your
  16. 22.

    Craft Many of us who write Ruby code see it

    as a craft to constantly hone and improve. Ruby libraries and frameworks help us develop a way of thinking about our Ruby code that we, as a community can hone. This craftsmanship approach is one of the things I love about the Ruby community. We're always improving the state of the art, and letting the lessons of the real world inform both our own code, but also the code we share as a community.
  17. 23.

    JavaScript Code Too often, we think of JavaScript code as

    a necessary evil. It's not part of how we hone our skills.
  18. 24.

    “This is where a sprinkle of JavaScript comes handy” We

    talk about "sprinkling" JavaScript as if to hide the fact that what we're really dealing with is a megabyte of code (minified!).
  19. 25.

    Ad Hoc When you try to hide a MB of

    JavaScript behind "sprinkling", you end up building ad hoc solutions for each new problem that comes Rails was great because it looked at a whole bunch of problems that people were solving in ad hoc ways and gave structure and sanity to it. It gave us a clear way to think about new features and eliminated a lot of the mental overhead of solving the same problems over
  20. 26.

    Bad Timing Of course, the people who work at 37

    Signals aren't idiots. They spent a lot of time looking at JavaScript-based solution a few years ago, mostly based on Backbone and similar home- grown solutions.
  21. 27.

    Backbone Backbone was small, so it could ship a stable

    solution quickly. But this also meant it didn't do much! So if you were looking for a nice experience that eliminated drudgery, you wouldn't find it
  22. 28.

    Ember I wanted something on the client-side with the same

    ethos as Rails, that eliminated a lot of the drudgery, but these things take time. When 37 Signals was evaluating the JS space, Ember (and Angular) were in their infancy. They weren't yet ready to adopt unless you were willing to help build the framework. In the short term, adopting Ember in 2011 wouldn't have provided advantages for BaseCamp over the approach they used.
  23. 29.

    2012 The Year Rubyists Wrote Off JS Libraries A lot

    of Rubyists bought into the hype in 2012, but things weren't ready. Imagine someone writing off Rails because they tried Sinatra and didn't think it really solved any problems they couldn't solve easily in PHP.
  24. 30.

    Stop Hiding From JS Remember, your job title is web

    developer, and even 37Signals delivers close to a MEGABYTE of JavaScript to deliver the experiences their users demand.
  25. 31.

    Things are Better Things are better now. I work on

    Ember, and it took us a couple years to get to a complete and conventional solution for building web applications. But Ember is still immature compared to Rails, and you're familiar with it. So why use Ember when you can "just use Rails"
  26. 32.

    BaseCamp Calendar One case is straight forward: you're building an

    application that's extremely interactive (i.e. not document-based). I spent the last few months working on Skylight, which allows you to interactively select requests in your application and have a trace update in real-time. Everyone agrees this is an For what it's worth, the lessons of Rails, like convention over configuration, absolutely do apply in JavaScript-land, but like in Rails, they really do need to be extracted from real world applications. This is why it has taken a few years to get to a nice place with Ember.
  27. 34.

    It's easy to look at Discourse and ask: why make

    this a client-side app when you're just putting some HTML on the page?
  28. 36.

    • Cache Everything • Cached documents have everything in them

    • Use JavaScript to "decorate" your cached documents
  29. 37.

    Very Static Templates If you're caching the hell out of

    it, your templates become extremely static. They're basically the same HTML for everyone.
  30. 40.

    $("[data-visible-to]").each(function() { var list = $(this).attr("data-visible-to").split(/\s/), creatorEl = $(this).closest('[data-created-id']), creator

    = parseInt(creatorEl.data('created-id')); var user = app.currentPerson; if (_.include(list, 'admin') && user.isAdmin()) { return; } else if (_.include(list, 'creator') && user.id === creator) { return; } // handle account managers, group members return $(this).remove(); });
  31. 41.

    Not "Like Rails" What you're doing is using HTML as

    a data interchange format and using JavaScript to render it usable on the client. This is simply not a small delta on top of what you're used to, and actually involves more JavaScript than the alternatives that embrace the reality of what's
  32. 43.

    {{#if user.isAdmin}} <p>Secret stuff here</p> {{/if}} If you embrace what

    you're doing (sending data down the wire and reconstituting it via JS), you can get back your dynamic templates! (of course, templates in modern frameworks also do the work of keeping these templates up to date)
  33. 51.

    <article class="event chiral" data-bucket-identifier="project_2278188" data-datetime="2013-04-23T14:30:56Z" datetime="2013-04-23T14:30:56Z" data-event-id="153323896" data-behavior="format_timeline group_by_date"> <div

    class="time"> <span class="time_only"> <time data-local-time="" datetime="2013-04-23T14:30:56Z"> Apr 23, 2013 at 2:30pm </time> </span> <span class="time_ago"> <time data-compact="" datetime="2013-04-23T14:30:56Z"> Apr 23, 2013 at 2:30pm </time> </span> </div> <!-- ... --> </article>
  34. 52.

    Data + JS = HTML In both cases, you're shipping

    generic data down the wire, then combining it with JavaScript to produce the final payload.
  35. 55.

    JSON + JS = HTML Bonus: You may already need

    JSON for an API or iPhone/Android app. DRY it up!
  36. 57.

    App = Ember.Application.create(); App.Router.map(function() { this.resource('photo', { path: '/photos/:photo_id' });

    }); App.PhotoRoute = Ember.Route.extend({ model: function() { return App.Photo.find(); } });
  37. 58.

    <h1>{{title}}</h1> <h2>by {{author}}</h2> <p>Taken on {{time takenAt}}</p> <img {{bindAttr src=url}}>

    {{#if currentUser.isAdmin}} <button {{action "delete"}}>Delete Photo</button> {{/if}}
  38. 59.

    Stop Hiding If you want to build an app that

    your users will love, you will need to write a lot of JavaScript; nobody disputes that. The only question is whether you will do everything you can to fight against it, and end up with a giant ball of spaghetti...
  39. 60.

    Be Proud of Your JavaScript Or embrace reality, and end

    up with JavaScript code you can be proud of.