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 full-size slide

  2. Hi
    cball_
    !
    cball.me
    "

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. Lots of talk about
    front-end
    frameworks.

    View full-size slide

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

    View full-size 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 full-size slide

  9. A Brief History:
    Rails + JavaScript
    #

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  21. Angular, Ember, React

    View full-size slide

  22. The problems with
    Rails Views
    #

    View full-size slide

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

    View full-size slide

  24. Solution 1: Caching
    Fragments and Russian Dolls

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. They start over.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  32. Let’s fix that!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. 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 full-size slide

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

    View full-size slide

  39. 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 full-size slide

  40. Why should you
    choose Ember?
    #

    View full-size slide

  41. An awesome mascot.

    View full-size slide

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

    View full-size slide

  43. 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 full-size slide

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

    View full-size slide

  45. The Ember Inspector

    View full-size slide

  46. Ember Data
    ❤️
    Active Model Serializers

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  49. Connect to multiple APIs
    with adapters.

    View full-size slide

  50. Handle non-standard JSON
    responses with serializers.

    View full-size slide

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

    View full-size slide

  52. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  55. Get that “$@#% that’s
    awesome!” moment you
    got learning Rails.

    View full-size slide

  56. 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
    $@#% that’s awesome!








    View full-size slide

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

    View full-size slide

  58. 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 full-size slide

  59. 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 full-size slide

  60. How do you transition
    to Ember?
    #

    View full-size slide

  61. 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 full-size slide

  62. More benefits to
    separating front-end
    #

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  67. Challenges of
    separating front-end
    #

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  70. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  73. If you ignored the past
    30 minutes…
    #

    View full-size slide

  74. 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 full-size slide

  75. Start enjoying working on
    the front-end.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide