
Rant: Backbone, Angular, Meteor, Derby - lefnire
https://gist.github.com/4454814
======
davidw
I have a rant coming about these things too.

* I started out with Backbone. It seems ok as far as it goes, but a bit annoying in that there's enough "magic" and stuff going on that I don't quite understand it completely, but without enough magic to really make things simple and easy.

* Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: [http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date...](http://www.grobmeier.de/angular-js-binding-to-jquery-ui-datepicker-example-07092012.html) \- how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being.

Also: a lot of these tools have tutorials that don't really walk me through
all of what I want to do, which initially involves a fairly straightforward
"CRUD" type of application. I want to see how the framework deals with both
'make me a new one' and 'edit an existing one' forms, for instance. I found
that very irritating about the Angular tutorial, which is otherwise _very_
nicely put together.

Now I'm testing out jquery-pjax, and... so far I'm happier. It behaves more
like a web application that I'm used to, sending around HTML, and staying out
of my way. And, seeing as how all of these things require that the server do
its job in any case, it has more of a "don't repeat yourself" feel to it:
click on the button, and the server gives us some new data, without repeating
the whole MVC cycle on both the client and server. I got the idea from this
post: [http://37signals.com/svn/posts/3112-how-basecamp-next-got-
to...](http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-
damn-fast-without-using-much-client-side-ui)

~~~
dustingetz
backbone? magic? backbone is 1534 lines of straightforward, well written, well
documented javascript. backbone is about as simple and un-magic as MVC gets,
by design.

~~~
jtchang
I hardly feel that backbone is well written and straightforward.

This is one of the lines in backbone.js:

if ((callback && callback !== (ev.callback._callback || ev.callback)) ||
(context && context !== ev.context))

I feel stuff like this takes a lot of mental power to understand the context
that it is being executed in and what exactly it is doing. It feels like I am
knee deep in some obfuscated C code.

~~~
ams6110
It's not that hard when you know the idioms. && is a guard and || is a
default. With a little bit more context and experience in writing concise
javascript, it's actually pretty clean.

~~~
nailer
callback._callback seems a little obscure to me.

------
bejar37
Recently decided to use Backbone as a JSMVC Framework on my team. Although I
looked at Ember and Angular, which obviously both have many more features than
backbone out of the box, We chose to use Backbone because it seems to have
such a large and vibrant community behind it - seems like angular and ember
are both lacking in this respect.

However, as our Backbone application grew in complexity, we noticed that
Backbone is so bare in terms of functionalities that we had to build our own
half-baked framework on top of it to make up for the gaps.

I think the Backbone project needs to make Backbone's intentional feature
sparseness clear. I've come to realize that backbone is more of a library
which provides a basis to make a client-side framework rather than a something
that can be used standalone by app developers.

If I could go back and change our original choice, I definitely would have
gone with one of the Backbone-derived frameworks (chaplin, marionette) or just
gone with something more fully-featured like angular. While backbone is
beautiful and elegant for small projects, it just doesn't provide much
convenience as a stand-alone library for larger applications.

~~~
blissofbeing
I have found the Angularjs community to be thriving and most helpful. Check
out their google group (1), g+ page (2), g+ community (3), irc room (4) and
youtube channel (5) for an excellent place to get help. I usually get help as
soon as I need it, amazing. Also I have been impressed with the active
community projects AngularStrap (6) and AngularUI (7)

1) <https://groups.google.com/forum/?fromgroups#!forum/angular>

2) <https://plus.google.com/110323587230527980117/>

3) <https://plus.google.com/communities/115368820700870330756>

4)
[http://webchat.freenode.net/?channels=angularjs&uio=d4](http://webchat.freenode.net/?channels=angularjs&uio=d4)

5) <http://www.youtube.com/user/angularjs>

6) <http://mgcrea.github.com/angular-strap/>

7) <http://angular-ui.github.com/>

------
debergalis
[meteor dev] Please come help us with this! We have six engineers at Meteor
and dozens more contributors in the community working on the platform every
day. The plan to 1.0, including REST, is at <http://roadmap.meteor.com/>.

Here's the guiding principle behind Meteor. There should be a dramatically
faster, more accessible way to write applications. Improving that developer
experience means rethinking some things: autopublish and minimongo, so you can
jump right into a new app's UX in the first five minutes; one-line
authentication (<http://meteor.com/authcast>); synchronous APIs that are more
comfortable for a lot of developers; dirt-simple reactive templates; hot code
push.

Focusing on that kernel of development experience means some other things --
REST, routing, form building -- need more time to fully bake, with hacks like
__meteor_bootstrap__ and phantom for apps that need them now. We think that's
a good tradeoff pre 1.0.

~~~
d0m
I was excited using meteor but was sadly disappointing after a couple days of
"banging my head on every simple things I tried". As far as I'm concerned,
Meteor is a big "Screw everything that exist, it sucks. We're better and we've
got the time and money to re-build all the life from scratch".

So, in a way, that's _great_! An mental orgasm for any nerds out there. But in
the real life when shit needs to get done, I'm still using _everything else
that sucks_.

Now, before people start saying I don't know what I'm talking about, here are
a few examples: \- It does NOT use npm (!) -> Basically, you can't use
anything without first converting it to Meteor. \- It does NOT use Express (Or
connect) as its base -> Basically, the standard in the Node community. That
means I can't just plug-in the 20 or so awesome plugins built explicitly to be
used by any kinds of node application that support connect.js \- The current
Asynchronous (following node's philosophy) wasn't good enough for them; so the
re-created a whole new Mongo version acting synchronously.

But most importantly, it's just extremely annoying to hack with it. It's like
a big black box.. you're not very sure what it does and you hope it works. But
when it's not working, you can't just hack it your way or read the source.
It's a little bit like Django or Rails (but in worst) as you _can_ use
SQLAlchemy in Django, or you _can_ use different template engines, but then no
project from the django community will work with your app.

The good news is, the meteor team is working hard. Maybe in a couple years it
will be stable enough and iterated fast enough to provide a platform where it
will be fun hacking and building web apps. But for now, I sadly prefer to stay
in the "Everything else sucks" world and hack my way in the node jungle.

(For those interested, I have also tried Derby. As said in the article, it's
not yet fully stable and the documentation is really Meh. _But_ I think it's
going to be big really soon and I'll be more than happy to give it another
fair try. So far, I'm sticking to a basic express (Or locomotive.js which is
nice.) I'm also using Angular.js on the front-end. It's something _amazing_ as
I feel very productive and it saves a tremendous amount of time.. but at other
moment, I just bang my head against the table as I want to do something simple
and it's just impossible so I need to use all kind of hacks to do what I'd
have done in a couple lines in Vanilla Javascript. Oh well. Hard to be a
hipster web developer trying all new technologies :-))

~~~
debergalis
What blocks you from digging into the source? I want to make that easier for
you.

Nearly all of the Meteor code is broken out into various packages. They
implement components like publish/subscribe, client-side data caching and
snapshotting, reliable remote method invocation, live page updates, and hot
code push. They're the building blocks for a rich client application.

Now, we have some work to do on better separating those components so that you
can pick and choose the parts you want, like using livedata
(publish/subscribe) with Angular, or using Spark (our reactive page update
engine) with a legacy REST endpoint instead of livedata. Those combinations
are technically possible today, but not particularly accessible. They should
be.

(That is one of the two front-burner project we have going today. The other is
scaling.)

~~~
d0m
What blocks me from digging into the source is mostly that even if there are
separated components, I still need to understand all the aspects of Meteor. I
can't just open the file and change it. Will it screw up the deploy system?
Will all the data-binding continue to work as expected? Maybe yes, maybe no.
Unless I totally understand the system, I can't really know.

You say "like using livedata (publish/subscribe) with Angular", but that's the
problem I'm talking about. You need to tweak the system to make it work with
Angular. But what about the hundreds of other smaller angular-like libraries?
Or tomorrow's most popular one? I can't just <script src="it">, I'll need to
create a meteor package and make sure it works good with all the rest of the
system (Which unless I'm a Meteor expert, I have no way of knowing).

That could actually be a good blog article, "How to use MooTools, django
template system and MySQL with Meteor". I.e. Going through what's needed to be
tweaked to make it work. Compared to say, express, I could tell you use the
mysql node library, normally include mootools in your html files and use
mustache (Or whatever library already exist to mimic Django's libraries).

------
jashkenas
"It seems that most people today, when thinking about their next JS project,
will use Backbone because it's the most popularl framework when it shouldn't
be." (sic)

Here's a long list of examples why _maybe_ it should be:

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

In comparison, here's the public list of interesting apps built with Angular
and Derby:

<http://builtwith.angularjs.org>

<https://github.com/codeparty/derby/wiki/Community-Projects>

What you want to look for in a library goes beyond feature checklists and
magic datepickers. Lots of client side developers have been burned in the past
by JavaScript frameworks that promise the world and end up getting in the way
more than they help.

Backbone tries to provide the barest useful essentials -- the main business of
building your app is up to you.

~~~
dmvaldman
You use this argument a lot, but the ranter suggests that the reason many turn
to Backbone is because of a self-selecting bias of it being the most popular.

~~~
jashkenas
It's certainly my favorite argument. Folks sometimes forget that pre-Backbone,
there was a cornucopia of rich JavaScript framework options: YUI, SproutCore,
Dojo, EXTjs, UkiJS, JavaScriptMVC, Cappuccino, and so on. If Backbone has
become a bit popular over the last couple years, perhaps it's _because_ it
tries to do less than the excellent pre-existing alternatives.

------
jtchang
Try knockout. I wrote a quick intro to it a few days ago:

[http://returnbooleantrue.blogspot.com/2012/12/architecting-k...](http://returnbooleantrue.blogspot.com/2012/12/architecting-
knockoutjs-applications.html)

I personally don't like backbone that much. I don't know why so many people
love the damn thing. It is hard to understand and not even that great.

~~~
johnnymonster
I personally use knockout all the time. Can't stand backbone or angular after
using knockout.

~~~
thibaut_barrere
I have the same question as @hnwh: I'm using Knockout and really, really like
it (more suited to my way of working than say Backbone), but considered that
Angular could be a more advanced/featureful Knockout.

Can you elaborate a bit? Thanks!

~~~
jtchang
If you use Knockout please consider being more vocal about it. It is a
fantastic mini-framework/library but doesn't have the crazy PR behind it like
backbone.

Angular is great but the problem is you really need to use client side
templating for it to be useful. It also has the same syntax as django's
template language by default. All this is workable but Angular is great for
projects that you are starting. Knockout is better to integrate with existing
projects.

~~~
nateweiss
Thanks to all in this part of the thread for talking so pretty about Knockout
- it got me to try incorporating it tonight on a simple interactive page I
started recently, and it's a pleasure to use so far. Works nicely in
combination with coffeekup, which I also enjoy a lot.

------
heyitsnick
I wanted to use Ember, and I started going down that road, but I just didn't
click with it. I didn't progress past the tutorial! I can't remember what
exactly I didn't get working, but I just felt very lost and overwhelmed, and
that was spending a couple of days reading around online, looking at the code
and examples.*

I switched to Backbone and got going right away, in half a day of reading the
docs and watching a couple of peepcode videos and I was off and didn't look
back.

Maybe the Ember docs have improved in the last couple of months but at the
time it was just a non-starter for me.

edit: I believe the issue was around Ember Data/REST. Out of the box it didn't
support polling data on a REST interface, which seemed absolutely
critical/fundamental to a JS framework. I found a plugin I believe called
Ember Data, but documentation was very sparse and I couldn't even get a simple
example going. This is going on memory so this could be slightly wrong or
different today.

~~~
securingsincity
I actually just had this same experience this past weekend. Hours spent
banging my head against the wall trying to figure out why Ember-Data wasn't
working. I don't know what wasn't clicking but I decided to switch to backbone
for this project. Literally minutes of work to get backbone going and have my
data appear properly.

~~~
samratjp
Ember Data is a heavy hard-hat area and no wonder you were frustrated. Really,
just start with your own data layer and get used to Ember first. Ember has a
very Rails-ish philosophy and just like in the Rails world - magic happens
(but ya should know how it happens anyways). This blog post is a good intro to
how Ember works - <http://trek.github.com/> (though routing has come a long
way since - <http://emberjs.com/guides/routing/defining-your-routes/>

~~~
heyitsnick
> Ember Data is a heavy hard-hat area and no wonder you were frustrated.
> Really, just start with your own data layer and get used to Ember first

So why is that? This was my big head-scratcher with Ember; surely the access
to a data layer is the whole point of these javascript frameworks? I mean all
backbone is really is a layer between REST and client-side javascript. I guess
i'm missing a whole class of JS applications that don't need access to a
server-side data layer, but for me that's the fundamental reason to be looking
for a JS framework in the first place. So to come across one so highly
regarded which doesn't have it baked in was very jarring.

~~~
steveklabnik
The idea with Ember-Data and Ember in general is the same as Rails:
Conventions give you power. Conventions and a happy path are good. That said,
until you _learn_ the happy path, it's harder going.

It's not 'baked in' because Ember is modular: Ember-data has all of that layer
in it, so the rest of Ember doesn't have to care. That said, I disagree with
your parent: you shouldn't be writing your own data layer.

~~~
samratjp
ah yes, you're right - meant to say that handle the serialize/de-serialize
yourself at first to get your feet wet.

------
joshontheweb
Ok, you like angular. I don't. It has too much magic and forces you to pollute
your html with ng attributes. Blanket statements about frameworks like this
grow old. So much of the decision comes down to individual preference and the
needs of the project. No need to rant about it. I can't really speak on derby
vs meteor but I imagine it's the same.

~~~
lefnire
It's not like that. I'm saying use Angular, Ember, Knockout, whatever - just
not Backbone. Unless you _know_ Backbone is what's needed for your project, or
you yourself really love Backbone. What I'm discouraging here is its
popularity as the de-facto client MV*. I'm under the impression that most
people today, when thinking about their next JS project, will use Backbone
because it's the most popularly-touted framework where It shouldn't be. It's a
great framework, and die-hards & specific projects should indeed use it. But
the majority should use one of the other frameworks.

~~~
ricardobeat
Ember, Knockout, Angular, Batman, all have data-binding in their core.
Backbone doesn't. If you like writing client code where you have control over
rendering and DOM manipulation, Backbone is the best choice short of building
your own framework.

~~~
joshontheweb
Agreed. Also backbone gives you the flexibility to use it on the backend or as
the data models behind a canvas app or other kinds of non-html rendering.

------
freshhawk
> It’s like Gentoo users proselytizing Gentoo to the masses, perpetuating it
> as most common Distro; where all this time, Ubuntu would have saved everyone
> countless hours.

I find this a pretty good metaphor for the backbone/angular/ember distinction,
highlights that this complaint is the old "I can't imagine anyone needing more
flexibility than I do, so those other people are obviously wasting their
time". Nice parallels to PG's famous blub paradox essay as well.

------
danenania
I'll chime in with the requisite "90% of the time, don't use an mvc framework
in the browser." Don't build up a mountain of state for no reason. Use
functions and composable, lightweight, short-lived classes.

If I had to choose the 'best' javascript development framework, I'd choose
clojurescript, not because it's such a great tool in itself (it is a great
tool, though still a bit immature), but because it forces the developer to
write javascript in the best possible way: functionally, only holding onto
state when it's absolutely necessary.

It's good that there are solid mvc frameworks out there for when they are
truly needed, but when the average developer picks one up for a routine web
app just because it's the hot new thing, he/she's walking into a minefield for
no good reason. Javascript is at its best when it's just a dumb, fast bridge
between your server and your ui.

------
aioprisan
actually, Meteor is not like Derby. For one, you don't need to deal with
callbacks when data is changed. Meteor can automatically figure out what data
sources are bound to certain containers in the template being rendered and
when you make a change in the database, the data is pushed to all the clients.
Here are some good details on the differences:
<http://news.ycombinator.com/item?id=3842525>. Also, Meteor now has a REST
package built-in <https://github.com/crazytoad/meteor-collectionapi> and
additional modules that you can install, like
<https://github.com/tmeasday/meteor-router>

~~~
lefnire
!! Those REST packes enable server-side routes? I remember the last time I
checked, when Meteor had it's new "server pages" it was Phantom generated
snapshots of client renders, which blew my mind. I'll explore those packages,
that was my _biggest_ gripe and may motivate me to take down my post.

~~~
debergalis
[meteor dev] The `spiderable` package is just our hack to let search engines
index our own website. It works surprisingly well for that, but it's certainly
not the long-term solution.

There's a fuller explanation of our routing / REST plan here:
[https://trello.com/card/page-model-server-side-rendering-
res...](https://trello.com/card/page-model-server-side-rendering-rest-
endpoints/508721606e02bb9d570016ae/7)

------
hellopat
I'm working on an app which uses Ember 1.0.0pre-2. Over the past few weeks
I've been lazy / busy doing other things so the project was set aside for a
bit. I came back to it yesterday, opened the guide page
(<http://emberjs.com/guides/>) and noticed it had been updated. I was excited
and immediately checked the Router section. The guide reflects a brand new
router API, which from what I've read makes it much easier to control the
state of your application.

The problem with Ember right now is the documentation doesn't align with the
most recent public version, which will confuse the heck out of newcomers and
frustrate people who are still learning Ember. You can however, check out
master to get the new router implementation.

I'm personally making the jump to the bleeding edge for two reasons: 1\. The
old router API is very hard to grasp. A lot of unknowns as far as where domain
code fits when building your application using the router. 2\. I don't want to
be stuck struggling to find documentation for an already difficult API to work
with.

With all that said, Ember is worth taking a look at as far as an 'improved'
MV* experience, but you have to be careful as it is in a state of flux.

~~~
rxcfc
Sorry about this, we're going to be cutting a new release soon so that should
resolve this discrepancy.

------
sgdesign
I can only speak for myself, but the reason I use Meteor (<http://telesc.pe>)
is because I believe that while it's not perfect right now, it has a bright
future ahead of it.

The Meteor devs themselves will acknowledge that some features are lacking (I
imagine that's why it's not 1.0 yet), but the roadmap looks very promising and
I believe Meteor also has the right team to make all this come true.

~~~
doctorpangloss
The reason I used Meteor (<http://redacted.meteor.com> /
<https://github.com/doctorpangloss/redacted>) is because it is fast,
exceedingly simple, and gets you a working program in five minutes.

------
jacquesc
Agreed on Backbone. It's awesome, but have had transition to Ember as I take
on more complex UI frontend work. Trek summed it the best I could hope for:
<http://trek.github.com/>

------
shuzchen
Straight from the backbone faq: "Backbone.js aims to provide the common
foundation that data-rich web applications with ambitious interfaces require —
while very deliberately avoiding painting you into a corner by making any
decisions that you're better equipped to make yourself."

I think the problem is people come into Backbone.js thinking it's a full
fledged MVC framework for in-browser apps, instead you should think of it as a
minimalistic set of tools with which to create your own framework (and in
fact, a few actual frameworks have been released that are built on top of
backbone.js).

One way to taxonomize frameworks is on how opinionated it is - Backbone.js is
on the far end of the unopinionated side. If that's what you like, then
Backbone.js is for you. If you want something more out-of-the-box, you should
be considering the other options.

------
coenhyde
Marionette (a framework built on backbone) offers a nice solution. It still
keeps things pretty light but does a lot of the groundwork you would normally
have to do with backbone for you. Eg cleaning up event bindings, provides a
region/view manager and an application wide event bus.

~~~
krebby
I'd also recommend looking into Chaplin for stronger routing / app design.
It's got a great CollectionView, which is one of the most common use cases for
Backbone (also seems to solve a lot of the gripes with plain Backbone

~~~
drivebyacct2
Chaplin is a mess. I need node, npm, build a bunch of stuff from scratch? I've
already lost interest (I looked at Chaplin a few months ago and honest to God
couldn't even figure out what the hell it did besides download various crap to
a /lib/ dir. Aren't there six dozen tools that do that?)

------
taylorbuley
Backbone is a thoughtfully minimalistic approach to prototypical binding.
There's no magic.

If you need more than that -- automagic binding using HTML data attributes via
Angular -- it's OK to use another library.

------
marknutter
I've been using angular.js for a while now and there are a few reasons why
I've really liked it:

\- dependency injection: because everything is injected, it makes writing
isolated unit tests very easy. It also makes it very easy to swap
functionality in and out without affecting other parts of the app.

\- two-way data-binding: most of the pain of being a javascript developer
comes from managing and manipulating the DOM. After using angular, there is no
way I will ever use a framework that doesn't automate this tedium by providing
two-way live data-binding (knockout, meteor, and ember all do this). The best
part about having less DOM manipulation code is that it makes writing
automated tests easier and makes those test much less brittle.

\- extending HTML: this is often a main complaint of angular. People say that
directives "pollute the DOM" which I find to be a strange complaint, given
that HTML is a declarative (sometimes) semantic language to begin with. HTML5
added a ton of new attributes and features yet nobody complained that these
new tags were "polluting HTML". Angular simply allows you to extend HTML's
functionality even further, and in doing so it makes it very easy to
understand what an HTML template is trying to do without having to dig through
any JS code.

\- testing: the angular team made testability a priority, which I was
something I always really appreciated about the Rails team. If you're not
writing tests for your javascript code, you need to start. Having full test
coverage in both end-to-end tests and unit tests has been a major source of
stability for me and my team.

~~~
wilmoore
_because everything is injected, it makes writing isolated unit tests very
easy_

I agree with that statement regarding DI; however, have you evaluated whether
you _NEED_ a DI container or just DI?

Angular forces you into a container even if you don't need it. Is that what
you really wanted? If so, fine, just be sure :)

------
idan
Same post, easier on the eyes (particularly on mobile):
<http://gist.io/4454814>

------
danso
How did this get so many upvotes? It's a short rant that basically boils down
to "Fuck Backbone, use Angular instead"

In fact, here is a verbatim quote: "Angular is awesome. That is all."

And here's the technical basis of why Angular is better than Backbone: "Now,
I'm not suggestion people don't use Backbone. Use it if it's what's needed for
your project, or you yourself are a Backbone ninja. What I'm discouraging here
is its popularity as the de-facto client MV*"

I've played around with Backbone and appreciate its structure. I've never used
Angular but have seen many compelling posts on HN arguing why it is a better
choice in certain use cases. This rant offers no evidence or elaboration. Is
it now cool just to hate the popular thing just because it's popular? Even
rants against Facebook and Apple have more substance than the OP.

~~~
lefnire
It got upvotes (1) because nobody's talking about Meteor v Derby, (2) because
people _agree_. I'm not the only one wondering why Backbone is de-facto - look
at all these responses, 80% of them are agreement. That surprised me, I
thought this thread would be buried. Many (like you) think this as insular and
inane. I left out detailed explanations of Backbone cons and Angular pros just
to get the conversation rolling, and indeed the comments took care of that
entirely.

------
conradfr
As a _mediocre_ Javascript dev, AngularJS was the first library that clicked
for me and helped me avoid the jQuery soup code I was doing more and more as a
result of less code on the server and more on the client.

It can be a bit daunting when you are not a JS rockstar : directives and
services code architecture, designing views without straight conditional
logic, understanding the full power of filters and expressions (I still
don't), using jQuery plugins with it etc.

I don't even use routes or forms yet but I had no problem integrating it into
a "classic" web app.

The docs need some work though, maybe with more example on certain part. But
you can find great code snippet and videos elsewhere.

------
stesch
Apache Derby? <http://en.wikipedia.org/wiki/Apache_Derby>

Am I missing something here? Maybe next time put some links into your rants.
Apache Derby was the only one I found on Wikipedia.

~~~
callmevlad
<http://derbyjs.com/>

------
lefnire
Cached at <https://gist.github.com/4454814> if down (my Drupal server has been
miserable lately and I'm currently migrating to DocPad)

~~~
dustingetz
please provide more context about what type of app you're building. searching
for "ember sucks site:news.ycombinator.com" and "backbone sucks
site:news.ycombinator.com" is evidence enough that this isn't a simple
comparison.

~~~
lefnire
I think it often _is_ a simple comparison. Meteor & Derby, for example, are
the exact same use-case - and I think in the end, one will survive the battle
and the other lose steam.

People say Backbone & Angular are different use-cases, but I find so many
people "graduating" Backbone and wishing they'd chosen a more robust
framework. They say they want to start minimal, so they pick Backbone. You can
be minimal with Angular. It's like saying "ms paint or photoshop? Well what
are you trying to do?" There's only 1 or 2 people really trying to draw
something in Paint, the rest "think" they want minimal, non-bloated software.
The answer to the question is Photoshop.

Now, Rails v Node v Java, something like that - there are tons of questions to
ask before making such a decision, there's no one-size-fits all. But I think
there is a one-size in this particular case.

~~~
dustingetz
let me put it this way - right now, this month, im evaluating stacks for an
enterprise-y amazon-y feeling thing. Say $XX million dollar budget, ~100k LOC
with ~10 engineers (mostly cranky and old) for 7 months.

i'm not sure if you're freelancing an app as a sole developer, or if you're an
early stage startup, or if you work on amazon.com store. and where your
project is, in this spectrum, is incredibly relevant context when you're
dissing a framework.

~~~
lefnire
That's a very good point.

------
adolph
Discusses Derby: <http://derbyjs.com/>

Not Apache Derby: <http://db.apache.org/derby/>

------
dignifiedquire
I switched from backbone to angular about half a year ago. It was the best
thing that ever happened to the project I was working on. I've rebuilt the
complete interface using angular in 2 days. The original backbone version took
me weeks (I learned both frameworks from the ground up while writing the
interface) It was just a joy to see how databinding and promises where working
hand in hand to make my life as a developer so much easier.

~~~
EdwardMSmith
As a person that switched from Backbone to Angular, can you explain models in
Angular (from a Backbone standpoint)?

I've looked over the docs, and as far as I can tell there really _isn't_ a
model in Angular - not anything concrete anyway.

The docs seem to explain that any JS object is a model as long as you make
some reference to it.

Or, is an angular Controller (+ some JS data structure) really a model.

Its quite confusing to me.

~~~
lopatin
I can't explain in terms of Backbone but I'll do my best to clear things up
for you anyway. In Angular, you have a magic $scope variable that is available
both in your controller function, and in the section of HTML that the
controller is bound to. Now I can set any attributes I want to the $scope
variable and they will act like models for that controller.

For example. Within my controller, I set $scope.username to "alex" and this
will update any HTML bound to the value "username", within the scope, to
"alex". Similarly, I can set, say, $scope.settings = {user: {username:
"alex"}} and this will update any HTML elements (within the scope) bound to
settings.user.username to "alex".

These are very simple examples, but they show the beauty of having plain JS
objects as your "models".

------
sergiotapia
We use Backbone at my place of work but Angular.js looks sooooo clean, it
makes me wish it would have come out sooner so I could have pushed for
Angular.js.

------
sontek
It doesn't make sense to compare Backbone to any of these. Backbone is a low
level library for getting you started.

If you are looking for something easy to use to get you going you just use one
of the frameworks built on top of Backbone, I suggest Marionette.

------
cookingrobot
Derby looks interesting, but their sample apps (chat and todo) crash and hang
safari on my iPhone. Are folks sure its acceptable for mobile focused web
apps? Is this a known problem or something unique to me?

~~~
lefnire
That's that public-face failure bit I pointed out in my post. My own Derby app
<https://habitrpg.com> is smooth-sailing, but people's first impression
Derby's home-page examples. For a lot of people, the buck stops there -
unbeknownst to them, it's quite stable at HEAD

------
lefnire
@KaoruAoiShiho where did you go?? That was a great response, put that back up

------
sunwukung
similar growing disenchantment with Backbone. Minor gripe re: Angular - if
you're working with a server side templating language (i.e. Flask/Jinja) you
have to configure it to use alternative tags, which could cause problems if
working with any 3rd party libs.

~~~
ganarajpr
Regarding Angular : You can use the data-ng-* way of adding the ng-
attributes. Since data-ng- is HTML5 compliant most major server side
templating systems should let it pass through.

If you are using custom elements, then you have to figure out a way for your
templating system to let it through. In grails for example, you can override
it in the taglib's to do that.

------
hhuio
angular code is a joy to write and read!

------
dotborg
all of them will become obsolete once ecmascript.next kicks in

~~~
lefnire
Do tell

~~~
dotborg
I'm just reading HN and in discussions between one of news about ES.next, the
conclusion was that it will happen... complete rewrite of everything and it's
not like it will happen immediately, we need some time to discover best
practices with new language features

