

Why I switched to Spine.js - arnklint
http://destroytoday.com/blog/reasons-for-spinejs/

======
marknutter
This is the same reason I was turned off to backbone. Being a Rails guy, and a
guy who takes 5 minutes to pick a candy out of the machine, I'm much more
attracted to an opinionated framework, which is why I've jumped on the
angular.js bandwagon.

In fact, on a current project me and another guy are building identical
prototypes in angular and backbone to compare notes on which framework we end
up going with. He's running into the same issues mentioned in this article -
namely, trying to figure out just how he should structure things. Some people
love that freedom and flexibility, others find it paralyzing.

~~~
webjunkie
Yeah, I'd rather have several clear choices of inflexible things than fuzzy
choices of stuff that is so flexible that I ask myself what to do with it.

------
dasil003
The thing that makes Backbone unfriendly to noobs is its lack of prescribed
structure. Personally I love this approach because I know Javascript pretty
well, but I haven't written a ton of huge JS apps yet, so I'm still
experimenting with ways of architecting them. Backbone provides a lot of
essential functionality in a flexible way that forces me to think critically
about how I want to structure the app. I see that frameworks like Angular and
Ember give me more out of the box, but they impose a lot of structure which I
am not sure about yet. I'm sure sometimes that structure is ideal and
sometimes it may be the wrong tool for the job. Eventually after I build out
more Backbone.js apps in different ways I'll be in a much better position to
evaluate the more heavyweight frameworks.

It's not unlike how I fell in love with Rails immediately in 2005 having spent
the previous 5 years working in PHP, it was obvious why Rails was the way it
was. But without that prior lower-level experience I would have been more
skeptical.

~~~
mgkimsal
"I'm sure sometimes that structure is ideal and sometimes it may be the wrong
tool for the job. Eventually after I build out more Backbone.js apps in
different ways I'll be in a much better position to evaluate the more
heavyweight frameworks."

Somehow you saw immediate benefit in Rails in 2005, grokking that having
defined structure coupled with out of the box functionality was a good
starting point. Why do you not have the same reaction in the JavaScript world,
instead feeling like you need to 'tough it out' for a few apps first?

Replace "backbone.js" with "php" and you get the argument I hear from PHP
beginners and noobs as well. "After I do a few PHP projects really hacky and
crappy, learning on my own as I go along, then I'll be able to judge the
quality and useful of a mature framework". That's the reality of what happens
to many (most?) devs, and they leave a mountain of legacy stuff behind that
someone (sometimes themselves!) have to maintain for a long time.

~~~
dasil003
I was neither a web beginner when Rails came out or a javascript beginner when
I started working with Backbone, so your use of the word grok is ironically
appropriate.

But to answer your question about why I was quicker to jump on board with a
full-stack opinionated framework like Rails as opposed to equivalent JS
frameworks. The reason is because there's a much larger common footprint of
what a website needs to do than what javascript needs to do. Is it a single
page app or a full site? How much JS code is there? Is it a lot of CRUD or is
a more minimal crafted UI? Is it progressively enhanced or not? What other
technologies are in the mix?

All of these affect the needs of a particular site's JS implementation, and
even assuming that all JS framework authors are smarter and more knowledgeable
than me (which is a dubious assumption btw), they may or may not have taken
into account any of the conditions and constraints that are now staring me in
the face.

As to leaving crappy legacy stuff behind, well, frameworks don't save you from
that. For a simple app written by a beginner there's a good chance I'd prefer
maintaining the 10-year-old PHP version to the 5-year-old Ruby version. But
even assuming a framework _is_ a good idea, how is the noob to know which one
to use? You could just as easily end up with a dead-end Access database as
something that can be coerced into stable software.

------
thornofmight
For #4, "Let’s say you fetched a record in one view of the app. Then you fetch
and update that same record in a different view. In Spine.js, both records
will update." This sounds like completely standard Backbone.js functionality
to me. It just seems like the guy writing this post wasn't familiar enough
with the framework to even begin making "why I switched" posts.

------
brendanobrien
+1 Backbone. For me the more open-ended approach has allowed space to try
different approaches to see where they fail, and refactoring. This open-ended
approach seems to jive well with the spirit of js, and has definitely made me
a better dev.

~~~
littlejim84
I am completely with you on this.

------
ryaf
We just switched from backbone to angular. The thing that sold me was data-
binding. You could write your own with backbone but it's done so why bother.
Also the code reduction was about 1/3.

~~~
jscheel
You don't need to write your own data binding in backbone. Several smart
developers have already written plugins for this very thing. I usually forget
about backbone plugins when workin on a new problem, and get halfway down my
thought process before remembering to check
[https://github.com/documentcloud/backbone/wiki/Extensions,-P...](https://github.com/documentcloud/backbone/wiki/Extensions,-Plugins,-Resources).
To be fair, the backbone website does a terrible job of promoting these
resources.

~~~
xanados
Thank you very much for posting this. I've been working on a Backbone app and
have never seen this before!

~~~
jscheel
You're welcome. Good luck!

------
jperras
Previous discussion: <http://news.ycombinator.com/item?id=4002105>

------
hyuuu
like you, I also came from backbone.js and since then I have switched to
CanJs. Backbone.js open endedness if I may compare to UX concept, is too open
ended that it can cause analysis paralysis. There is no defined path for
programmers to take. Of course this is not a bad thing, it's just different
from what I would like.

CanJs takes care of live binding, memory management, syntatic sugar, etc, it
feels to me it's like a backbone with everything that I want already built in.
I have tried other frameworks too such as ember or angular, and I have to say,
even though they are all in the same family (javascript mvc framework) but
they target different types of customers (developers) and variety is good.

------
rjzzleep
damn i knew i shouldn't have gone for backbone.

point 6 sold me. everything else i can live with, but just google ghost views
with backbone.js and you know what i mean.

i don't really see the problem with 9's code. as long as you bind correctly
you can get the clicked element. i guess the problem might occur if you want
to access some random model from the dom. not sure when that would happen.

10 is also not a problem since you can easily extend underscore or backbone
stuff.

3 is really up to you and not really an issue per se.

------
danso
This is an old post, as Backbone's Ashkenas rebutted here:
<http://news.ycombinator.com/item?id=4003069>

