Embrace JavaScript

Keynote from RailsConf 2013.

Transcript

1. Embrace JavaScript
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”
3. 2005 I've been doing web programming since 2005.
4. The Dark Ages When I started, Internet Explorer 6 had about 85% market share.
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
7. Browsers Sucked
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
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
11. Documents JavaScript people talked a lot of smack about HTML during this time frame.
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.
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
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
17. Canvas WebGL WebRTC IndexedDB raw audio raw video File and Blob FileSystem
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.
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.
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
21. Mental Models While there's no diagreement about whether to use JavaScript, there's still disagreement about how to think about your
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.
23. JavaScript Code Too often, we think of JavaScript code as a necessary evil. It's not part of how we hone our skills.
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!).
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
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.
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
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.
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.
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.
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"
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.
33. Documents But what about "document-oriented" sites, like BaseCamp or Discourse?
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?
35. Omakase Strategy
36. • Cache Everything • Cached documents have everything in them • Use JavaScript to "decorate" your cached documents
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.
38. <% if admin? %> <p>Secret stuff</p> <% end %>
39. <div data-visible-to="admin"> <p>Secret stuff</p> </div>
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(); });
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
42. The Ember Strategy
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)
44. Timestamps The Omakase Strategy
45. Last updated <time data-time-ago="" datetime="2013-04-23T19:38:06Z"> Apr 23, 2013 at 7:38pm </time>
46. bcx.on("page:update", "convert time tags", bcx.timeConversion.convertTimes);
47. bcx.on("page:update", "convert time tags", bcx.timeConversion.convertTimes);
48. Timestamps The Ember Strategy
49. Last updated {{time project.date type="ago"}}
50. Ember.Handlebars.helper('time', function(date) { // Handle different types, like `compact`, etc. return moment(date).fromNow(); });
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>
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.
53. HTML? + JS = HTML
54. HSON? + JS = HTML
55. JSON + JS = HTML Bonus: You may already need JSON for an API or iPhone/Android app. DRY it up!
56. JSON + template = HTML
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(); } });
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}}
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...
60. Be Proud of Your JavaScript Or embrace reality, and end up with JavaScript code you can be proud of.