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

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

Hi cball_ ! cball.me "

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

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

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

Lots of talk about front-end frameworks.

Will I have to stop using Ruby or Rails?

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

A Brief History: Rails + JavaScript #

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

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

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

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

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

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

Store state, initialize values, all on a <div>. data-all-the-things!

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

“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.”

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

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

Angular, Ember, React

The problems with Rails Views #

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

Solution 1: Caching Fragments and Russian Dolls

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

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

Spaghetti ©

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

On JavaScript heavy pages, what happens if user refreshes?

They start over.

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

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

Let’s fix that!

SRP: The Single Responsibility Principle # A nod to ^

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

Let a front-end framework handle the UI Layer.

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

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

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

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 ⋆ ⋆ ⋆ ⋆

Why should you choose Ember? #

An awesome mascot.

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

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.

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

The Ember Inspector

Ember Data ❤️ Active Model Serializers

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

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

Connect to multiple APIs with adapters.

Handle non-standard JSON responses with serializers.

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

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.

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

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

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

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! ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

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

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"}}

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

How do you transition to Ember? #

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

More benefits to separating front-end #

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

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

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

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

Challenges of separating front-end #

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

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

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?

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

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

If you ignored the past 30 minutes… #

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.

Start enjoying working on the front-end.

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

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

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

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

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

More Decks by Chris Ball

Other Decks in Programming

Featured

Transcript