Click here to load reader

Feels Like Ruby - Ruby Kaigi 2010

  • View
    1.797

  • Download
    1

Embed Size (px)

DESCRIPTION

Making JavaScript development suck less.

Text of Feels Like Ruby - Ruby Kaigi 2010

  • Feels Like RubySarah Mei

    Pivotal Labs

    @sarahmei [email protected]

    1

  • Hi everybody

    2

  • MEI Sarah

    Im Sarah Mei.

    3

    Mei Sarah

  • I dont speak Japanese very well, so thanks in advance for your patience.

    4

  • http://www.flickr.com/photos/sunrise/4064417/5

    San Francisco

  • Im American.

    http://www.flickr.com/photos/junewess/3756778580/6

    America

  • Im a Ruby & Rails developer.

    RubyRails

    Image copyright 2006-2010 Yukihiro Matsumoto7

    Ruby

  • I work at

    8

    Pivotal LabsPivotal LabsPivotal TrackerPivotal Labs.

  • I work at

    8

    Pivotal LabsPivotal LabsPivotal TrackerPivotal Labs.

  • 9

  • Feels Like Ruby

    9

  • Feels Like RubyMaking JavaScript a

    Real Language

    9

  • What I like about Ruby

    10

    I want to set the stage by talking about what I enjoy about Ruby. First and foremost, its the language itself. I love the expressiveness and accessibility. But as a working developer, what I appreciate the most is the ability to test-drive everything. Between rspec, test::unit, cucumber, capybara, webrat, shoulda, steak....I can pick the most appropriate test tools for each project.

  • What I like about Ruby

    The language itself.

    10

    I want to set the stage by talking about what I enjoy about Ruby. First and foremost, its the language itself. I love the expressiveness and accessibility. But as a working developer, what I appreciate the most is the ability to test-drive everything. Between rspec, test::unit, cucumber, capybara, webrat, shoulda, steak....I can pick the most appropriate test tools for each project.

  • What I like about Ruby

    The language itself. I can test-drive everything.

    10

    I want to set the stage by talking about what I enjoy about Ruby. First and foremost, its the language itself. I love the expressiveness and accessibility. But as a working developer, what I appreciate the most is the ability to test-drive everything. Between rspec, test::unit, cucumber, capybara, webrat, shoulda, steak....I can pick the most appropriate test tools for each project.

  • What I like about Ruby

    The language itself. I can test-drive everything.

    JavaScript

    JavaScript

    11

    So lets see how these options stack up in JavaScript. The language itself...?

  • What I like about Ruby

    The language itself. I can test-drive everything.

    JavaScriptXJavaScript

    12

    Well, Im never going to be able to change that. I dont dislike JavaScript, but Ruby fits my personality better. But what about test-driving?

  • What I like about Ruby

    The language itself. I can test-drive everything.

    JavaScriptXJavaScriptO

    13

    We should be able to test-drive JavaScript. But until earlier this year, I didnt. And some of the best Rails developers I know, who test-drive all their Ruby code, still dont test-drive their JavaScript. So the question is...

  • http://www.flickr.com/photos/petereed/49639295614

    Why not? Why do we make JavaScript development so painful?I think part of it is a philosophical mismatch in the way Rails treats JavaScript.

  • 15

    Web applications are fundamentally written in multiple languages. Heres a very generic representation of a Ruby web application. On the front end, theres HTML, CSS, and Javascript, and on the back end there is one (or more!) server languages, plus SQL. And of course, normal applications have other front-end languages too, like ActionScript or Objective-J, and other back-end languages interacting with Ruby, and usually additional data stores as well. I cant remember the last time I worked on an application that had ONLY a relational database for storage. But traditionally, in this setup, programming languages sit here in the middle. But frameworks try to extend on either side. Thats what Rails does.

  • Rails

    ActiveRecord

    16

    For example, Rails extends this direction, and abstracts away SQL with ActiveRecord. Its pretty successful with that. Even on really complex applications, I can get away with the generated SQL most of the time.

  • ActiveRecord

    Rails/gems

    erb

    rjssass

    Rails

    17

    But it also extends the way with erb and rjs to generate HTML and JavaScript. And with other gems, you can generate CSS too. And although this was a good idea with SQL and ActiveRecord, and it works decently well with HTML and CSS, RJS is kind of a disaster. Ill show you an example in moment.But first I want to point out that this is not a failing of Rails, or of the people who wrote it. This is the nature of Javascript. It might be the one language whose use is evolving even faster than Ruby. SQL has an ISO standard and a committee, and if they make any significant changes, well have five years notice. Moreover, the database products that implement SQL have committees, so as SQL end-users, were exceedingly well-insulated from any language churn.

  • JavaScript Developers

    http://www.flickr.com/photos/gem66/38740030618

    But Javascript...is the wild west. Its the frontier. While the language itself is relatively stable, its libraries and usage patterns are changing faster than that of Ruby, or of Rails, or of any other framework.What does that mean for us as web application developers, as multi-lingual programmers?

  • ActiveRecord

    Rails/gems

    erb

    rjssass

    Rails

    19

    It means we need to opt-out, to make an exception, and to handle JavaScript differently. Now, thats the philosophical reason - now I want to show you the practical reason.

  • 20

    In Rails 2, using RJS means you have little bits of Javascript all over your code. Heres an example I adapted from the complex forms railscast. This is a to-do list app, in which you can create a project with any number of tasks attached. This is the new project form. It has 3 task textfields, but you can add another one by clicking Add a task, and you can delete one by clicking the remove link thats next to it. Both of these are implemented as simple JavaScript that modified the DOM. For the purposes of this example, were going to focus on the remove link. So lets look at how thats implemented.

  • 21

    This is the partial that is rendered for each task. The important part is the link_to_function, where when we click remove, it calls that little piece of javascript.

  • 22

    Heres what the rendered HTML looks like. Youve got that little bit of inline javascript, which on its own, is fairly simple. But its not really testable. Sure, you could write a selenium test that tests that it actually removes the dom element. However, Selenium is slow. This is one simple interaction - in a typical modern web application, theres likely to be dozens of these on one page, if not hundreds. Testing them all with Selenium would mean youd have a test suite that never stopped running.Plus, Selenium is an integration test. If all youre doing is integration tests, youre doing it wrong. You need both unit tests and integration tests to probe all the behavior of your code.So how can we re-do this in a way that is testable and repeatable?

  • A different approach

    23

    1. Forget RJS - it gets in your way once you do anything beyond the very simple. 2. Put your JS in classes - of course JS is a prototype-based language instead of an inheritance-based language, but you can still organize your functions into sets. Ill show you what that looks like in a moment. 3. Organize your JS by behavior, and by location.4. Test-drive all your JS.

  • A different approach

    Forget RJS - write functions

    23

    1. Forget RJS - it gets in your way once you do anything beyond the very simple. 2. Put your JS in classes - of course JS is a prototype-based language instead of an inheritance-based language, but you can still organize your functions into sets. Ill show you what that looks like in a moment. 3. Organize your JS by behavior, and by location.4. Test-drive all your JS.

  • A different approach

    Forget RJS - write functions Put your functions in classes

    23

    1. Forget RJS - it gets in your way once you do anything beyond the very simple. 2. Put your JS in classes - of course JS is a prototype-based language instead of an inheritance-based language, but you can still organize your functions into sets. Ill show you what that looks like in a moment. 3. Organize your JS by behavior, and by location.4. Test-drive all your JS.

  • A different approach

    Forget RJS - write functions Put your functions in classes Organize classes by behavior and

    location

    23

    1. Forget RJS - it gets in your way once you do anything beyond the very simple. 2. Put your JS in classes - of course JS is a prototype-based language instead of an inheritance-based language, but you can still organize your functions into sets. Ill show you what that looks like in a moment. 3. Organize your JS by behavior, and by location.4. Test-drive all your JS.

  • A different approach

    Forget RJS - write functions Put your functions in classes Organize classes by behavior and

    location

    Test-drive your classes.

    23

    1. Forget RJS - it gets in your way once you do anything beyond the very simple. 2. Put your JS in classes - of course JS is a prototype-based language instead of an inheritance-based language, but you can still organize your functions into sets. Ill show you what that looks like in a moment. 3. Organize your JS by behavior, and by location.4. Test-drive all your

Search related