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.

6254dc2b7e4f26b2ab5d05c560834671?s=128

Chris Ball

March 10, 2015
Tweet

Transcript

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

  2. Hi cball_ ! cball.me "

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

    say that?)
  4. Why Rails? Rails adds conventions to Ruby that make you

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

  6. Lots of talk about front-end frameworks.

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

  8. What We’ll Cover History: Rails + JavaScript The problems with

    Rails Views SRP: UI vs. Domain Layers Why Ember? Changes to developer workflow # # # # #
  9. A Brief History: Rails + JavaScript #

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

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

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

  13. link_to_remote 'refresh emails', :update => 'emails' RJS - Ignore the

    fact its JS. page.insert_html :bottom, :tasks, :partial => 'task', :object => Task.new
  14. Wait, let’s make everything a jQuery plugin! Photo courtesy of

    Flickr Creative Commons: Cayusa
  15. Allows you to execute JavaScript from a server rendered view.

    Still the “preferred” Rails way. js.erb (aka sprinkles)
  16. Store state, initialize values, all on a <div>. data-all-the-things!

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

    server.
  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.”
  19. Backbone was great, but no conventions. Bring Your Own Framework.

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

  21. Angular, Ember, React

  22. The problems with Rails Views #

  23. Rails is slow at rendering. Does this look familiar? Completed

    200 OK in 1749ms (Views: 1725.7ms | ActiveRecord: 23.3ms)
  24. Solution 1: Caching Fragments and Russian Dolls

  25. Solution 2: Turbolinks AJAX every request, replace <body> with new

    html leave the rest as is. Option ————
  26. js.erb scatters code JavaScript code for an action can be

    in multiple places. js.erb or event listener/function?
  27. Spaghetti ©

  28. How do we store state? * In the DOM with

    data-whatever * On the server (session, db) * Set JavaScript variables on page
  29. On JavaScript heavy pages, what happens if user refreshes?

  30. They start over.

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

    front-end”
  32. It’s not enjoyable because you’ve fought with it.

  33. Let’s fix that!

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

  35. If we take away the UI layer, Rails is really

    good at a lot of things.
  36. Let a front-end framework handle the UI Layer.

  37. Let Rails handle the Domain Layer. “The heart of your

    app” “The shit that gets you paid” “The special sauce”
  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
  39. The Domain Layer * Handle API Requests * Database access

    * Background tasks * Algorithms, calculations * Whatever makes your app special
  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 ⋆ ⋆ ⋆ ⋆
  41. Why should you choose Ember? #

  42. An awesome mascot.

  43. Conventions = Powerful If there is one thing Rails has

    taught us, it’s this.
  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.
  45. Focus on URLs. Ember Router maps URL to application state.

    Helps avoid the refresh issue.
  46. The Ember Inspector

  47. Ember Data ❤️ Active Model Serializers

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

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

  50. Connect to multiple APIs with adapters.

  51. Handle non-standard JSON responses with serializers.

  52. ES6 support out of the box Eliminates the need for

    CoffeeScript and adds additional features. http:/babeljs.io
  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.
  54. Write less code. If not defined, Ember will generate code

    by default for Routes and Controllers.
  55. addons ≈ gems Ember addons are very similar in concept

    to gems. http://emberaddons.com http://emberobserver.com
  56. Get that “$@#% that’s awesome!” moment you got learning Rails.

  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! ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆
  58. Too long, didn’t listen. Demo https://github.com/cball/ember-vs-rails-app-example

  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"}}
  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
  61. How do you transition to Ember? #

  62. None
  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
  64. None
  65. More benefits to separating front-end #

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

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

  68. Designers = Developers. Designers are more likely to write code.

    Handlebars easier to grasp than erb, designers know JavaScript.
  69. Faster Rendering Templates only downloaded once, switching between them is

    fast.
  70. Challenges of separating front-end #

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

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

  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?
  74. CI Configuration Depends on repo choice and mocking in tests,

    may or may not be an issue.
  75. npm & bower != bundler We’re spoiled with bundler. NPM

    and Bower can be a little finicky.
  76. If you ignored the past 30 minutes… #

  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.
  78. Start enjoying working on the front-end.

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

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

    on staying awesome.
  81. Thanks! cball_ ! cball.me " fromrailstoember.com "