

JavaScript Jabber: Backbone.js - jashkenas
http://javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas/

======
lukeholder
Something I thought was very interesting was the thoughts (augments) around
pure single page apps vs. progressive enhancement. I think Yehuda almost flat
out said its too much work to do progressive enhancement. (rendering views /
view partials on the server)

Progressive enhancement I think has really become a law of moses in recent
times, probably mainly due to the speed in which browsers have progressed, and
the powerful browsers on all modern phones - it just isn't practical.

To be honest, I think having your app work without javascript these days is a
little naive view about the future of the web. Javascript is here to stay and
not that many people will be on non javascript powered browsers.

Which also persuades me to really care even less about the semantic web.
Twitter bootstrap is a good example - it really is DIVitis, but really who
cares? its rapid application development, it make the web look and act far
nicer and more consistent, and it progresses the web as a platform.

Having your web app still work (through non Ajax'd GET, POST etc) for the 7
seconds it takes to download the javascript just isn't worth it - especially
with html5.

~~~
jashkenas
I think it's about more than just pain vs. gain.

Unless your web application happens to _actually be_ a series of <form>s, your
JavaScript probably starts to become your content. To use an example from
today, how would one go about building this without JavaScript? Without losing
the heart of it in the translation to static HTML?

[http://www.nytimes.com/interactive/2012/02/13/us/politics/20...](http://www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-
proposal-graphic.html)

~~~
lukeholder
exactly! why should we have that visualization be backed by a html table
within the page? Especially when you probably have that data backed by an API
anyway that could probably server up json, xml or whatever else.

~~~
luke_s
Why? Because not everybody is a human with 20/20 vision sitting in front of a
monitor.

Before I go off on to much of a rant, I do want to clarify - having the
javascript be the content is fine for a special 'once off' page like the one
in the grandparent post. In this case its probably replacing a flash
animation. Its also fine for applications where you have a tight handle on the
people and devices which will use it.

However as a general practice its a bad idea. A few very important cases that
this breaks:

* The googlebot and archive.org

* Vision impaired users

* Services such as readability and instapaper

All of these could be better served by having a symantec table of data, which
is then then enhanced and presented in a different manner by javascript.

~~~
secoif
Good points but I don't think witholding progress to support these services is
a good idea.

The solution is to come up with best-practices and tools that allow both
interactive and static versions to exist in tandem, with minimal overhead.

Catering to lowest common denominator means technology, for all humans, lags
behind. This is a massive issue. Either the tools for consuming static content
(e.g. google bot) need to evolve to embrace the modern internet, OR we need to
produce simple tools for dynamic sites that transparently serve the static
content for services that require it.

That said, there's a lot of simple elegance in a straight html page.

~~~
route66
Careful, you are arguing progress for the sake of it. If it does not serve a
lowest common denominator it's probably not worth it and only fancy.

Slightly interesting in this context:
<http://www.youtube.com/watch?v=D9_6G8J6VJg> (applications of simple sms based
services covering Kenya)

------
patrickaljord
I was expecting an XMPP/Jabber implementation in Javascript using Backbone.js

------
_harry
@jashkenas: Could you expand a bit about your thoughts on the growing
ecosystem of community made patterns and modules on top of Backbone and how it
might help direct [edit: 'help direct' is the wrong phrase, can I change this
to shape?] the future of Backbone?

(referring to your thoughts around 38:00-42:00)

~~~
jashkenas
Sure. To expand a bit...

Backbone has always been intended to give you the _smallest possible_ set of
functionality that you reach for every time you work on a JS-powered web app.
Model and Views and events to bind them together, collections with powerful
functions for filtering and aggregating data, and shareable URLs.

There are lots of other directions and other needs that JS apps may have, but
unless it's something that you're going to use pretty much every time, it
doesn't belong in Backbone itself -- it belongs in an extension, or better
yet, another standalone library. I'm talking about things like write-through
localstorage caching, pushing data over websockets, TreeViews, query syntax
for complex JSON, special cross-domain communication, specific HTML-generating
strategies, or "mobile" widgets that mimic iOS controls.

Fact is, JS apps are still the wild west when it comes to patterns that work
well -- there are plenty of fertile experiments to go around. You want a
library that gives you a foundation, so that your app can rise up to meet it
and extend it in new directions. I think that pretty much all of the apps in
this list fit that description -- going far beyond what Backbone provides out
of the box:

<http://backbonejs.org/#examples>

~~~
lukeholder
I think Yehudas point was, why do you want to have just the minimal
functionality when you are constantly grabbing for Backbone Addons just to do
the standard stuff.

Having a plugable architecture is great, but if rails never considered making
a good thing standard (think bundler, or sprockets) really makes moving
between rails apps so much easier.

For example I would say nested views, and view layouts is something that
should be standard \- isn't backbone built for the single page web app idea?

I have seen so many different layout managers, region managers etc.

~~~
dts
I would say that backbone wasn't built for the "single page web app idea". I
think of it more as an elegant nucleus for apps that have heavy client side
javascript. I think its the same approach that sets a project like node apart
from rails. A strong, un-opinionated core with a healthy modules community
which allows you to tailor all parts of your project.

------
jashkenas
For folks who don't have time to listen: The general topic was JavaScript Web
Apps, as viewed through the lens of what Backbone and Ember agree and disagree
about, specifically:

* Source of truth.

* MVC / MVVM / MVP / The model-ui spectrum.

* JavaScript pipe dreams.

* Arbitrary code vs. structured templating systems.

* Everything-is-public APIs. +Hooks

* Client Side Models are _not_ mirrors of Server Side Models

... and so on.

~~~
zalew
cool. is there a twitter/google+ feed for the podcast?

~~~
jergason
@JSJabber is the Twitter account. The RSS feed is right on the website.

~~~
zalew
I dropped rss and there's no twit link. thanks!

------
wavephorm
Yikes, that is a whole lot of pedantic argument over the semantics of MVC.

"Handlebars is a compromise between logic and logicless views... ladda ladda
ladda"

~~~
doubleconfess
Well, if you get a bunch of nerds talking about javascript MVC frameworks for
an hour, there is bound to be some pedanticism. Despite that, I love this
podcast.

~~~
iamgilesbowkett
apologies, and I'm proving your point, but there's no such word as
pedanticism. the word you were looking for is pedantry.

