Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Don't worry, Ruby! We still love you.

Don't worry, Ruby! We still love you.

With the rise of client-side frameworks you might wonder if your days using Ruby are numbered. You came to Ruby for its expressiveness and beauty. You don’t want to leave that completely behind. Luckily, you don’t have to. With a nod to the Single Responsibility Principle we all love, this talk looks at how to leverage a front-end framework like Ember.js to handle application state at the UI layer and leave Ruby or Rails to do what it does best — everything else. Something to keep in mind: that everything else is the heart of your entire app.

Chris Ball

March 10, 2015
Tweet

More Decks by Chris Ball

Other Decks in Programming

Transcript

  1. Don’t worry, Ruby!
    We still ❤️ you.

    View Slide

  2. Hi
    cball_
    !
    cball.me
    "

    View Slide

  3. Why Ruby?
    Ruby makes developers happy.
    (how many languages can say that?)

    View Slide

  4. Why Rails?
    Rails adds conventions to Ruby
    that make you crazy productive.

    View Slide

  5. This is awesome! Let’s
    never use anything else.

    View Slide

  6. Lots of talk about
    front-end
    frameworks.

    View Slide

  7. Will I have to stop
    using Ruby or Rails?

    View Slide

  8. What We’ll Cover
    History: Rails + JavaScript
    The problems with Rails Views
    SRP: UI vs. Domain Layers
    Why Ember?
    Changes to developer workflow
    #
    #
    #
    #
    #

    View Slide

  9. A Brief History:
    Rails + JavaScript
    #

    View Slide

  10. Know any Rails developers like this?
    “I hate JavaScript”

    View Slide

  11. Rails apps with lots of
    JavaScript can be
    painful to work on.

    View Slide

  12. Here’s how we’ve tried
    to solve it in the past.

    View Slide

  13. link_to_remote 'refresh emails', :update => 'emails'
    RJS - Ignore the fact its JS.
    page.insert_html :bottom, :tasks,
    :partial => 'task',
    :object => Task.new

    View Slide

  14. Wait, let’s make everything
    a jQuery plugin!
    Photo courtesy of Flickr Creative Commons: Cayusa

    View Slide

  15. Allows you to execute JavaScript from a server
    rendered view.
    Still the “preferred” Rails way.
    js.erb (aka sprinkles)

    View Slide

  16. Store state, initialize values, all on a .
    data-all-the-things!

    View Slide

  17. Mustache and Handlebars
    Logicless templates, update html snippets
    without the server.

    View Slide

  18. “Backbone.js gives structure to web applications by
    providing models with key-value binding and custom
    events, collections with a rich API of enumerable
    functions, views with declarative event handling, and
    connects it all to your existing API over a RESTful JSON
    interface.”

    View Slide

  19. Backbone was great,
    but no conventions.
    Bring Your Own Framework.

    View Slide

  20. “Stop tying data
    to the DOM!”
    A big plus though:

    View Slide

  21. Angular, Ember, React

    View Slide

  22. The problems with
    Rails Views
    #

    View Slide

  23. Rails is slow at rendering.
    Does this look familiar?
    Completed 200 OK in 1749ms (Views: 1725.7ms | ActiveRecord: 23.3ms)

    View Slide

  24. Solution 1: Caching
    Fragments and Russian Dolls

    View Slide

  25. Solution 2: Turbolinks
    AJAX every request, replace with new html
    leave the rest as is.
    Option
    ————

    View Slide

  26. js.erb scatters code
    JavaScript code for an action can be in
    multiple places.
    js.erb or event listener/function?

    View Slide

  27. Spaghetti
    ©

    View Slide

  28. How do we store state?
    * In the DOM with data-whatever
    * On the server (session, db)
    * Set JavaScript variables on page

    View Slide

  29. On JavaScript heavy pages,
    what happens if user
    refreshes?

    View Slide

  30. They start over.

    View Slide

  31. “I’m not a front-end dev.”
    “I hate working on the
    front-end”

    View Slide

  32. It’s not enjoyable
    because you’ve fought
    with it.

    View Slide

  33. Let’s fix that!

    View Slide

  34. SRP: The Single
    Responsibility Principle
    #
    A nod to
    ^

    View Slide

  35. If we take away the UI
    layer, Rails is really good at
    a lot of things.

    View Slide

  36. Let a front-end framework
    handle the UI Layer.

    View Slide

  37. Let Rails handle the
    Domain Layer.
    “The heart of your app” “The shit that gets you paid”
    “The special sauce”

    View Slide

  38. The UI Layer
    * Remove logic from DOM and callbacks
    * Bring structure to application state (big!)
    * Handle css, JavaScript, images, fonts
    * UI = 1st class citizen, not leftover thought

    View Slide

  39. The Domain Layer
    * Handle API Requests
    * Database access
    * Background tasks
    * Algorithms, calculations
    * Whatever makes your app special

    View Slide

  40. A nod to SRP
    Bucket 1: UI Layer (front-end framework)
    Bucket 2: Domain Layer (Rails)
    Bring structure to application state
    Make the UI a first class citizen




    View Slide

  41. Why should you
    choose Ember?
    #

    View Slide

  42. An awesome mascot.

    View Slide

  43. Conventions = Powerful
    If there is one thing Rails has taught us, it’s this.

    View Slide

  44. Rails inspired features
    Generator in ember-cli:
    > ember g resource Post
    > ember g acceptance-test “User reads posts”
    helpers in templates, link-to, partials, etc.

    View Slide

  45. Focus on URLs.
    Ember Router maps URL to application state.
    Helps avoid the refresh issue.

    View Slide

  46. The Ember Inspector

    View Slide

  47. Ember Data
    ❤️
    Active Model Serializers

    View Slide

  48. Acceptance / Unit Tests
    The types of tests you’re used to but faster.

    View Slide

  49. Built in proxy
    > ember server --proxy http://localhost:3000

    View Slide

  50. Connect to multiple APIs
    with adapters.

    View Slide

  51. Handle non-standard JSON
    responses with serializers.

    View Slide

  52. ES6 support out
    of the box
    Eliminates the need for
    CoffeeScript and adds
    additional features.
    http:/babeljs.io

    View Slide

  53. Start with the UI.
    http-mocks allow you to mock out API so you
    can focus on the UI Layer first, and the
    Domain Layer second.

    View Slide

  54. Write less code.
    If not defined, Ember will generate code by
    default for Routes and Controllers.

    View Slide

  55. addons ≈ gems
    Ember addons are very similar
    in concept to gems.
    http://emberaddons.com
    http://emberobserver.com

    View Slide

  56. Get that “[email protected]#% that’s
    awesome!” moment you
    got learning Rails.

    View Slide

  57. Why Ember?
    Conventions = powerful
    Rails inspired features, feel at home
    Ember Inspector
    Map URLs -> state, proxy
    ES6 Support
    Easy to start with mocked API
    write less code, add ons
    [email protected]#% that’s awesome!








    View Slide

  58. Too long, didn’t listen.
    Demo
    https://github.com/cball/ember-vs-rails-app-example

    View Slide

  59. sortBy: ['createdAt:desc'],
    sortedMessages: Ember.computed.sort('model', 'sortBy'),
    unreadMessages: Ember.computed.filterBy('messages', 'read', false)
    Ember Snippets
    {{#with sender as user}}
    {{partial 'users/user-info'}}
    {{/with}}
    {{#link-to "message" message classNames="read-message-link"
    classNameBindings="message.read:read"}}

    View Slide

  60. messages: DS.hasMany('message', { async: true, inverse: 'recipient' }),
    fullName: function() {
    return this.get('firstName') + ' ' + this.get('lastName');
    }.property('firstName', 'lastName')
    markAsRead: function() {
    if (!this.get('read')) {
    this.set('read', true);
    this.save();
    }
    }
    }
    Ember Snippets

    View Slide

  61. How do you transition
    to Ember?
    #

    View Slide

  62. View Slide

  63. ember-cli-rails
    Render ember-cli apps from within Rails.
    Ability to transition an app in stages.
    https://github.com/rwz/ember-cli-rails

    View Slide

  64. View Slide

  65. More benefits to
    separating front-end
    #

    View Slide

  66. Vet your API.
    Your front-end uses it, you know it’s solid.

    View Slide

  67. Think about UI Separately.
    Less context shifting = higher productivity.

    View Slide

  68. Designers = Developers.
    Designers are more likely to write code.
    Handlebars easier to grasp than erb,
    designers know JavaScript.

    View Slide

  69. Faster Rendering
    Templates only downloaded once,
    switching between them is fast.

    View Slide

  70. Challenges of
    separating front-end
    #

    View Slide

  71. Additional learning curve
    Any front-end framework will have an
    additional learning curve.

    View Slide

  72. Necessary to define models in multiple
    places.
    2x Model Definitions

    View Slide

  73. Repo / Deploy Overhead
    * single repo w/ front-end and backend dirs
    * separate repos, develop + deploy w/ proxy
    * separate repos, separate domains
    Multiple ways to split, what fits your team?

    View Slide

  74. CI Configuration
    Depends on repo choice and mocking in tests,
    may or may not be an issue.

    View Slide

  75. npm & bower != bundler
    We’re spoiled with bundler.
    NPM and Bower can be a little finicky.

    View Slide

  76. If you ignored the past
    30 minutes…
    #

    View Slide

  77. Embrace a front-end
    framework!
    The sky is not falling. Not only can Ember and
    Rails/Ruby co-exist, they make an incredible
    team for app development.

    View Slide

  78. Start enjoying working on
    the front-end.

    View Slide

  79. Don’t worry, Ruby!
    We still ❤️ you.

    View Slide

  80. We’ve just found you a
    partner so you can focus
    on staying awesome.

    View Slide

  81. Thanks!
    cball_
    ! cball.me
    "
    fromrailstoember.com
    "

    View Slide