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.

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 “$@#% 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
    $@#% 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