

Coding the Angular Tutorial App in Backbone - bernardjhuang
http://blog.42floors.com/coded-angular-tutorial-app-backbone-took-260-code/

======
freyr
The Angular Tutorial App is an excellent demonstration of Angular's off-the-
shelf features. In fact, it's designed precisely to demonstrate Angular's
strengths. Angular reduces boilerplate but it's a heavier, more opinionated
framework. The price you typically pay for less boilerplate is higher
complexity when you need to alter the framework to fit your needs.

This is an extremely common (neccesary?) tradeoff. Think Rails vs. Sinatra or
Django vs. Flask. Django gives you a great off-the-shelf backend that's
perfectly suitable for most jobs. But I don't want to go under the hood to
bend Django to fit an atypical project, and for those I'll use a minimal
framework like Flask.

My issue with Angular is that I _really_ want to avoid looking under the hood
because the complexity is so high. Backbone is just a small, modular, well-
documented library that invites you to look under the hood. If Angular doesn't
fit my project, I'm happy to have Backbone in my toolkit, and I know the
additional boilerplate up front will pay off down the road. Yes, it'll force
me to think more up front about how to organize and architect my app, and
that's not a bad thing.

------
djacobs
Backbone Marionette would make the LOC comparison a fair one and is worth
looking into if you haven't already. Marionette is an especially good answer
for people who like the Backbone way of organizing apps but hate
boilerplate/non-declarative view bindings.

My favorite part of Marionette is that it has opinions about things like
model/view management -- so it avoids a lot of boilerplate -- but it can
almost always be molded/tweaked to fit your specific needs (animations, lazy
loading, views partially rendered on the server). It lets you 1) mix and match
pieces build to work with Backbone (ModelBinder for declarative model-view
bindings, Relational for client-side relations, etc.), 2) scale state change
management up and down as appropriate for your app (via model changes,
controller interactions, route events), and does not force you into a fully
single-page architecture if you don't want it.

Anyway, I think Marionette is a pretty great way to write small, modular,
readable code without sacrificing high-level abstractions.

------
dustingetz
> but I’m really fond of the less restrictive nature of Backbone, so I’ll
> probably end up sticking with Backbone.

Backbone is terribly devious in that it tricks you into thinking that it is
unrestrictive and unopinionated. Backbone manages state with mutable models
and model change callbacks, so Backbone's opinion naturally is that models and
change callbacks are a good way to organize your application. "I want to write
hundreds of callbacks to keep everything in sync" said no UI developer ever.

~~~
kevincennis
That's sort of a weird way to frame it. I could make the same argument against
Angular:

"I want to write a bunch of gross code to perform dirty checking of objects to
keep everything in sync" said no UI developer ever.

That's the point of libraries and frameworks. They do the repetitive or "ugly"
or "hard" things that we don't want to do over and over.

~~~
nateabele
> _" I want to write a bunch of gross code to perform dirty checking of
> objects to keep everything in sync" said no UI developer ever._

Except that this is in no way an equivalent comparison. With Backbone, you
actually have to write the hundreds of callbacks _in your application code_.

Whereas with Angular, you attach a value to a scope, and declare it in a
template. In that case, the framework actually does take care of the 'ugly'
for you.

Backbone keeps the ugly in front of your face, it just gives you a slightly
neater way to organize it (i.e. as compared to jQuery soup).

~~~
kevincennis
My fault. I guess I misunderstood the point being made.

------
quack
A better comparison would be Angular vs Backbone Marionette or vanilla Angular
(no pre-built directives) vs backbone. I'm looking at you ng-repeat.

I love angular as much as the next person, but comparing two frameworks by LoC
does not do much to move the discussion along.

~~~
Rygu
Marionette is terrible. The code is a mess: prototypes defined within
instances [0]. Uninformed use of design patterns: controllers are what, just
namespaces? [1] Unmodular internals, almost like globals [2].

It's not worth a comparison.

[0]
[https://github.com/marionettejs/backbone.marionette/blob/mas...](https://github.com/marionettejs/backbone.marionette/blob/master/docs/marionette.application.module.md#basic-
usage)

[1]
[https://github.com/marionettejs/backbone.marionette/blob/mas...](https://github.com/marionettejs/backbone.marionette/blob/master/docs/marionette.controller.md#on-
the-name-controller)

[2]
[https://github.com/marionettejs/backbone.marionette/blob/mas...](https://github.com/marionettejs/backbone.marionette/blob/master/docs/marionette.renderer.md#custom-
template-selection-and-rendering)

~~~
corford
I'm sorry but [0] and [1] are complete non-issues and I'm not sure I fully
understand your point with [3].

The code is very far from terrible. Go look at Marionette's source on github -
you'll find it's extremely easy to understand and reason about. Now try and do
the same with Angular or Ember...

~~~
Rygu
How are [0] and [1] non-issues? I like my libraries "SOLID" and "Clean" (look
em up). I have worked with Marionette's source, and it's neither.

Point [2] means, to use a different renderer you need to replace Marionette's
internal renderer completely like it's a global (globals are bad).

------
ctoestreich
I will post this here as well for posterity. I appreciate the time you took to
compare and contrast the frameworks and your article is very thorough. We
started with backbone on a few large projects and found angular late. We have
switched to using angular where ever possible given the reduced code and
testability.

I think another good comparison to make that is missing from both demo
application stacks is testing. It becomes increasingly difficult to test
backbone with the side effects of having jQuery selectors, html elements and
general DOM operations directly in your view models. One of the great
advantages of angular is it's attempt to make invert your thinking about dom
binding compared to other frameworks. Meaning it tries to keep the DOM and the
MVVM separated so there aren't unintended side effects if you add or change
html node ids or classes. Backbone more tightly couples you to a specific html
model and makes testing your javascript code complex and coupled to also
looking for changes to the physical DOM during tests.

In the end, the more complex problems see to cause equal headaches in both
frameworks, but at least angular give you less lines of headaches.

------
jakecraige
I made an Ember.JS version of this since we have a few different posts
comparing all the frameworks today. Still need to split it up into steps but
it's there as an example of the implementation right now

Lines of Javascript: 92

Lines of Javascript(without ember-data model definition): 63

[https://github.com/jakecraige/ember-
phonecat](https://github.com/jakecraige/ember-phonecat)

------
n1ghtmare_
Man, I'm a bit frustrated with this whole JS situation in recent days. There
are so many frameworks, recommendations, hype - it keeps confusing me.

I mean I don't want to spend time learning a framework that might be dead 2
years from now (remember prototype ?). I really don't see a fit for Angular in
my practice. However I'm not sure if I'm just saying that because of pure
ignorance. Most of my client side code is pretty much jquery (that I try to
keep organized), and it works most of the time. Then I see people referring to
that practice as "jquery soup" and I'm starting to think I'm doing it wrong.

A lot of the web apps I write consist of pages with ajax sprinkled here and
there (where it makes sense). I think a framework like Ember, Angular or
Backbone is an overkill in my case. I don't write SPAs, but then again I see
people using it everywhere these days.

Honestly, for my scenario I feel that a framework such as Knockout or ReactJs
is a lot more "fitting". I'm sure other devs have been where I am, I wonder
what you guys think.

~~~
xtrumanx
> I mean I don't want to spend time learning a framework that might be dead 2
> years from now (remember prototype ?)

2 years ago I jumped ship from KnockoutJS to AngularJS. Backbone was also
quite hyped out around the same time. All three of them are still around and
frankly speaking it wouldn't have been a problem for me if the one I picked
died by now. The skills I learned in Knockout helped me quickly learn Angular.

Think of it this way, learning on its own, regardless of what you're learning
is valuable. My suggesstion, take a day and examine whatever frameworks you've
heard of and pick one and learn it.

------
hit8run
I am currently writing an app in angular and I really enjoy how it supports my
workflow. Before choosing angular I did a very thorough evaluation of
Javascript Frontend Frameworks. My stomache told me to use backbone because it
is simpler to understand the whole codebase and I personally like to know how
something works behind the scenes. Also the built with backbone section is
pretty impressive. BUT getting started with backbone was not so convenient as
in angular. I dont like the fact that I have to extend things and then
instantiate them. Also the whole jquery event binding + underscore stuff made
me feel as if I was plugging together thousand movable pieces. Angular on the
other hand makes your life pretty easy when you stay in the defined
boundaries. Angulars has some drawbacks in my opinion: it is very complex
behind the scenes (the size alone makes it more difficult to read and
understand the source), it doesn't feel like the javascript you know (good or
bad?), for almost everything there is a specific angular way.

~~~
ulisesrmzroche
Yeah, that's one of those things that's hard for people to get at first, that
the front-end turned out to be a more difficult problem than writing the back-
end.

But people judge an app by its cover, so what can we do.

------
rguzman
This is really useful and good, esp since the source is on GH. Thanks for
putting it together, OP!

That said, lines of code is really the wrong metric to gauge the merits of the
frameworks. Fewer lines of code may mean better abstractions, but it also may
mean more 'magic'.

A metric that may be more useful would be to have one developer write half the
project and have another finish and then compare the time they take to the
time they take to do the same project with angular.

~~~
atrk
I think LOC is actually a great proxy measurement of productivity. 3x the code
is 3x the code that can break and 3x the code you have to wade through while
debugging or adding features.

I see what you're getting at with "magic" abstractions, but it's like
comparing Python and C. I don't know everything that happens under the hood in
Python off the top of my head, but I also don't care. I could learn it if I
needed to (e.g. needing to use the FFI, or if I find a framework bug). Not
knowing is not the same as not being able to know.

~~~
phleet
The difference here is that in Python vs C, you almost _never_ actually need
to know what's going on under the hood[1]. Whereas in every framework I've
_ever_ used, I eventually need to dig into the guts of them because of some
leaky abstraction. For instance, automatic data bindings are great until you
want to do animation[2].

I do agree that LOC for a _non trivial_ application is a reasonable measure,
though I disagree that Angular:Backbone is Python:C.

[1]: Serious performance optimization is the exception here, but in building
CRUD apps, this honestly did come up infrequently, and usually the right thing
to do was to improve algorithmic complexity or fix slow DB queries, not fix
python constructs that were unexpectedly slow.

[2]: I haven't spent much time with Angular specifically, but definitely
remember this being difficult in other automatically bound frameworks, like
Meteor in its initial release.

~~~
ulisesrmzroche
automatic data bindings for animation are still great though, and its
internals should definitely always be hidden from user-land, but I totally
agree with you, performance and ease-of-use vary wildly in javascript-land and
needs to get better.

------
elwinmurton
I am not a Backbone expert, but telling coding a piece of software with
Backbone takes more lines of code than AngularJS doesn't really tell you
something.

We could say that a Hello World code in Java is 5 times bigger than in Python,
and both has it's pros and cons. Same thing happen with tools and frameworks.

~~~
watty
Java and Python are not the same language. AngularJS and Backbone are both
Javascript frameworks.

LOC is certainly a useful metric in this case. It doesn't necessarily mean one
framework is superior than the other but can and should be used when comparing
frameworks.

~~~
elwinmurton
Java and Python are both General Purpose Programming Languages.

If I had to choose between frameworks, tools or languages. LOC is not the
reason why I would choose A or B. Another thing is comparing one of the
following: support, active community, features, future improvements,
documentation.

------
adamcw
There are quite a few places in the code where it appears the author took a
longer way around than is necessary, which upped the line count a bit.

An example of this would be restating the DOM tagName on each view
instantiation. This appeared to also be done with the className, which didn't
appear to change (Although I admit I didn't look particularly hard).

There were some other areas that looked like they could be optimized by
removing unnecessary glue. The render function in PhonesFilterView looks to be
doing a lot of work to choose the selected option. Unless I'm reading it
wrong, you could just pass in this.model.get('sortBy') to the JST and let it
do the comparison to select the correct value. Quick value compare instead of
a model compare.

I appreciate the work that goes into these types of comparisons, I'm still
lead to believe that it shows more about how well you know a framework than it
does about the framework itself.

Thanks for posting OP, it was an interesting exercise.

~~~
204NoContent
Thanks for the insight. When I first started coding the tutorial I was really
trying to minimize line count. I had originally wanted to write a post that
said something like "Backbone only takes you 10 more lines of code", because
that was what my gut was telling me. But when it became clear that I was not
going to be able to get close to the same line count without doing
exceptionally weird things, I thought better of it and coded the app like I
normally would.

Your point is totally valid about some of the extra stuff I did. The one thing
that irked me is that I added some lines because I didn't like the data
structure, like the stuff in your example. In real life I would go change the
data, but I felt like that might be slippery slope. For example if I changed
the data for the phones show view I could have just done a loop over a 10 line
template instead of the ridiculously long ~100 line template (although the
Angular peeps could have also done the same thing).

In the end I decided to stick with the data provided by Angular and just
massage it when necessary. It increased the line count and added complexity,
but it made it feel like a Backbone app to me.

------
Cthulhu_
One thing this tutorial / thing doesn't highlight is that Angular is ~800 KB
(unminified, ~200 KB gzipped, including some modules), versus Backbone's ~60KB
(unminified, ~20KB gzipped).

So it does take 240% more lines of code to do sort of the same thing as the
angular tutorial, but the angular library is 1000% as big. If my math's
correct.

(disclaimer: I like Angular, and for big projects like the one I've worked on,
both backbone and angular, I really prefer angular. If bandwidth is a major
concern though, and you know how big your app's going to end up, consider
library size)

~~~
nsp
I don't know we're you're getting those numbers - angular is 36k minified,
backbone is ~10, and includes much less code (no rendering/binding library
etc). Still a nontrivial distance, but a far cry from 700kb/10x

~~~
Rygu
Continuing this point, Backbone requires rendering, binding, and probably
relational models libraries. Not to mention the boilerplate and configuration
code you have to write to tie all those libraries together. Less may end up
being more.

Another point is that with all those libraries, how do you sanely manage the
security and quality of your application? With the exception of just a few -
almost every Backbone add-on library I've tried is badly programmed (un-SOLID
/ weird JS / no tests), not documented enough, and unmaintained solo-projects
that just so happen to be on GitHub.

------
atrk
I did a similar thing when I was seeking out a MVC framework for my company's
JavaScript. I built a page using the same manual JQuery and JS I was using,
then I built it with Backbone JS, and finally Angular JS (after learning each
one in a tutorial and using TodoMVC as a guide).

Each step I reduced the code size by 50-75%, particularly the boilerplate of
tying user interaction events to updating the logical model in JS. Angular's
automatic 2-way data binding was definitely the selling point for me on the
framework.

------
lukasm
After a few months with Angular I find that it shines with complex SPA. Having
said that I think everybody should ask himself/herself a question "Do I want a
complex app in the first place?"

------
elwell
You can cherry pick examples that make either framework look better.
Furthermore, LOC isn't the only factor in framework choice, and it certainly
isn't the most important.

~~~
204NoContent
Recoding the Angular tutorial is definitely going to favor Angular in parts.
There are multiple times in the backbone-phonecat tutuorial where I had to
write some code simply to make Backbone work slightly differently, and not
necessarily any better. For example, case insensitive ordering.

------
allthatisgold
If I'm working with a RESTful backend API I use Backbone, if not I use
Angular. Does anyone use a different criteria?

~~~
lucisferre
I can't say I understand why the criteria makes sense. Having used both I can
say I don't use Backbone at all anymore. If I'm doing something where SPA
makes sense and there will be complex logic on the client side I use Angular.
If I just want to enhance what's already there I use jQuery in a components
style that's very similar to Bootstrap.

I'll admit I don't really like Backbone much though.

------
salimmadjd
Please fix the URL to "PhoneCat tutorial app" you're pointing to angular.org
not angularjs.org

~~~
204NoContent
Thanks! Fixed the link. Global replace got me.

------
flylib
Angular is easier for me to read and understand then the equivalent Backbone
code right from the start

------
AdrianRossouw
The backbone app might be more code, but only if you don't count the code used
by the libraries.

Angular is probably easier for a lot of people though

~~~
crystaln
They are both probably pretty similar if you count processor instructions.

Point being, having the code be in the library where it is stable, tested,
documented, standard, etc is the whole point.

