Slide 1
Slide 1 text
Embrace JavaScript
Slide 2
Slide 2 text
“I am noticing a common quality in
Katz' recent foray into JavaScript,
that being his desire that it be like Ruby,
the language for which he's best known”
Slide 3
Slide 3 text
2005
I've been doing web
programming since
2005.
Slide 4
Slide 4 text
The Dark Ages
When I started, Internet Explorer 6 had
about 85% market share.
Slide 5
Slide 5 text
The Mozilla Foundation and Opera
Software presented a position paper
at a World Wide Web Consortium
(W3C) workshop in June 2004,
focusing on developing technologies
that are backwards compatible with
existing browsers including an initial
draft specification of Web Forms 2.0.
The workshop concluded with a vote,
8 for, 14 against, for continuing
work on HTML
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
Browsers Sucked
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
Ruby and Rails
In this kind of environment, who wants to
rely on the browser for anything? As much
as possible, we wanted to take our destiny
into our own hands and do things on the
Slide 10
Slide 10 text
2007
IE7 was released in 2006, and soon
enough, people got the bright idea to
abstract the browser. Instead of writing
HTML and CSS, these frameworks had
you write your entire UI in JavaScript.
Needless to say, this sucked!
People were trying to emulate a
Flash-like developer
experience, but as DHH said
yesterday, that experience
Slide 11
Slide 11 text
Documents
JavaScript people
talked a lot of smack
about HTML during
this time frame.
Slide 12
Slide 12 text
But in 2007, something else
happened. The iPhone was
announced, and with it a
backlash against frameworks
like SproutCore, which were
too heavy for underpowered
mobile devices.
Slide 13
Slide 13 text
<3 HTML <3
All you really need to know
from that little story is that
JavaScript people in 2013
love HTML. The strand of
thinking that led to totally
abstracting the DOM has lost
and browser JavaScript today
looks nothing like that straw
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
The Web Today
The web today is a totally different
place than it was when Rails was
created, and even when I was
working full-time on Rails 3, but
we're still looking at things through
the cynical lenses of that era.
It has never been a better
time to be a web
IE no longer rules the
Slide 17
Slide 17 text
Canvas WebGL WebRTC
IndexedDB raw audio raw video
File and Blob FileSystem
Slide 18
Slide 18 text
Locus of Innovation
The locus of innovation has
moved. Today, the most exciting
innovations are happening not on
the server, but on the client.
In the right hands, these tools can
be used to build amazing
experiences on the web, and your
users are demanding them.
Slide 19
Slide 19 text
Agreement!
And DHH doesn't disagree with me
that modern applications need a
lot of JavaScript.
Rails is great for apps that leverage
browser templates. Think about what
% of your app involves generating
views vs. other business logic.
Slide 20
Slide 20 text
960 KB
I just want to emphasize: there is nothing
wrong with this. BaseCamp is a great
application that feels good to use. It just
shows that pretty much everyone who builds
great experiences uses a bucket of JavaScript
Slide 21
Slide 21 text
Mental Models
While there's no diagreement
about whether to use JavaScript,
there's still disagreement about
how to think about your
Slide 22
Slide 22 text
Craft
Many of us who write Ruby code
see it as a craft to constantly
hone and improve.
Ruby libraries and frameworks
help us develop a way of
thinking about our Ruby code
that we, as a community can
hone. This craftsmanship
approach is one of the things I
love about the Ruby community.
We're always improving the state
of the art, and letting the
lessons of the real world inform
both our own code, but also the
code we share as a community.
Slide 23
Slide 23 text
JavaScript Code
Too often, we think of JavaScript
code as a necessary evil. It's not
part of how we hone our skills.
Slide 24
Slide 24 text
“This is where a
sprinkle of JavaScript
comes handy”
We talk about "sprinkling"
JavaScript as if to hide the fact
that what we're really dealing with
is a megabyte of code (minified!).
Slide 25
Slide 25 text
Ad Hoc
When you try to hide a MB of
JavaScript behind "sprinkling", you
end up building ad hoc solutions
for each new problem that comes
Rails was great because it looked at a whole
bunch of problems that people were solving in
ad hoc ways and gave structure and sanity to it.
It gave us a clear way to think about new
features and eliminated a lot of the mental
overhead of solving the same problems over
Slide 26
Slide 26 text
Bad Timing
Of course, the people who work at 37 Signals
aren't idiots. They spent a lot of time looking at
JavaScript-based solution a few years ago,
mostly based on Backbone and similar home-
grown solutions.
Slide 27
Slide 27 text
Backbone
Backbone was small, so it could ship a stable
solution quickly. But this also meant it didn't
do much!
So if you were looking for a nice experience
that eliminated drudgery, you wouldn't find it
Slide 28
Slide 28 text
Ember
I wanted something on the client-side with the
same ethos as Rails, that eliminated a lot of
the drudgery, but these things take time.
When 37 Signals was evaluating the JS space,
Ember (and Angular) were in their infancy.
They weren't yet ready to adopt unless you
were willing to help build the framework. In
the short term, adopting Ember in 2011
wouldn't have provided advantages for
BaseCamp over the approach they used.
Slide 29
Slide 29 text
2012
The Year Rubyists Wrote Off JS Libraries
A lot of Rubyists bought into the hype in 2012,
but things weren't ready. Imagine someone
writing off Rails because they tried Sinatra and
didn't think it really solved any problems they
couldn't solve easily in PHP.
Slide 30
Slide 30 text
Stop Hiding From JS
Remember, your job title is web developer,
and even 37Signals delivers close to a
MEGABYTE of JavaScript to deliver the
experiences their users demand.
Slide 31
Slide 31 text
Things are Better
Things are better now. I
work on Ember, and it
took us a couple years to
get to a complete and
conventional solution for
building web applications.
But Ember is still
immature compared to
Rails, and you're familiar
with it. So why use Ember
when you can "just use
Rails"
Slide 32
Slide 32 text
BaseCamp Calendar
One case is straight forward: you're building an
application that's extremely interactive (i.e. not
document-based). I spent the last few months
working on Skylight, which allows you to interactively
select requests in your application and have a trace
update in real-time. Everyone agrees this is an
For what it's worth, the lessons of Rails, like
convention over configuration, absolutely do
apply in JavaScript-land, but like in Rails, they
really do need to be extracted from real world
applications. This is why it has taken a few years
to get to a nice place with Ember.
Slide 33
Slide 33 text
Documents
But what about "document-oriented" sites, like
BaseCamp or Discourse?
Slide 34
Slide 34 text
It's easy to look at Discourse and ask: why
make this a client-side app when you're just
putting some HTML on the page?
Slide 35
Slide 35 text
Omakase Strategy
Slide 36
Slide 36 text
• Cache Everything
• Cached documents have
everything in them
• Use JavaScript to "decorate"
your cached documents
Slide 37
Slide 37 text
Very Static Templates
If you're caching the hell out of it, your
templates become extremely static. They're
basically the same HTML for everyone.
Slide 38
Slide 38 text
<% if admin? %>
Secret stuff
<% end %>Slide 39
Slide 39 text
Secret stuff
Slide 40
Slide 40 text
$("[data-visible-to]").each(function() {
var list = $(this).attr("data-visible-to").split(/\s/),
creatorEl = $(this).closest('[data-created-id']),
creator = parseInt(creatorEl.data('created-id'));
var user = app.currentPerson;
if (_.include(list, 'admin') && user.isAdmin()) {
return;
} else if (_.include(list, 'creator') && user.id === creator) {
return;
} // handle account managers, group members
return $(this).remove();
});
Slide 41
Slide 41 text
Not "Like Rails"
What you're doing is using HTML as a data
interchange format and using JavaScript to
render it usable on the client. This is simply
not a small delta on top of what you're used to,
and actually involves more JavaScript than the
alternatives that embrace the reality of what's
Slide 42
Slide 42 text
The Ember Strategy
Slide 43
Slide 43 text
{{#if user.isAdmin}}
Secret stuff here
{{/if}} If you embrace what you're doing (sending data down the wire and reconstituting it via JS), you can get back your dynamic templates! (of course, templates in modern frameworks also do the work of keeping these templates up to date)Slide 44
Slide 44 text
Timestamps
The Omakase Strategy
Slide 45
Slide 45 text
Last updated
Slide 46
Slide 46 text
bcx.on("page:update", "convert time tags",
bcx.timeConversion.convertTimes);
Slide 47
Slide 47 text
bcx.on("page:update", "convert time tags",
bcx.timeConversion.convertTimes);
Slide 48
Slide 48 text
Timestamps
The Ember Strategy
Slide 49
Slide 49 text
Last updated
{{time project.date type="ago"}}
Slide 50
Slide 50 text
Ember.Handlebars.helper('time', function(date) {
// Handle different types, like `compact`, etc.
return moment(date).fromNow();
});
Slide 51
Slide 51 text
Slide 52
Slide 52 text
Data + JS = HTML
In both cases, you're shipping generic data
down the wire, then combining it with
JavaScript to produce the final payload.
Slide 53
Slide 53 text
HTML? + JS = HTML
Slide 54
Slide 54 text
HSON? + JS = HTML
Slide 55
Slide 55 text
JSON + JS = HTML
Bonus: You may already need JSON for an API
or iPhone/Android app. DRY it up!
Slide 56
Slide 56 text
JSON + template = HTML
Slide 57
Slide 57 text
App = Ember.Application.create();
App.Router.map(function() {
this.resource('photo', { path: '/photos/:photo_id' });
});
App.PhotoRoute = Ember.Route.extend({
model: function() {
return App.Photo.find();
}
});
Slide 58
Slide 58 text
{{title}}
by {{author}}
Taken on {{time takenAt}}
Slide 59
Slide 59 text
Stop Hiding
If you want to build an app that your users will
love, you will need to write a lot of JavaScript;
nobody disputes that.
The only question is whether you will do
everything you can to fight against it, and end
up with a giant ball of spaghetti...
Slide 60
Slide 60 text
Be Proud of Your
JavaScript
Or embrace reality, and
end up with JavaScript
code you can be proud
of.