Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding the Angular Tutorial App in Backbone

blog.42floors.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Coding the Angular Tutorial App in Backbone

#41

Post by coderzach »

nateabele wrote: post #20
kevincennis wrote: post #17

Earlier quoted context omitted.

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.

> "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 o…

Or you use a templating engine/language and write a simple reusable adaptor. An adaptor you have to write once, assuming one doesn't already exist.

Re: Coding the Angular Tutorial App in Backbone

#42

Post by solomone »

dragonwriter wrote: post #38
gumballhead wrote: post #23

Earlier quoted context omitted.

Yes. Backbone basically supplies CRUD mapping and an event bus. So it is opinionated about models. But CRUD is a solved problem that's easy to implement, and view / controller code ends up being the bulk of your application. I'd rather my framework give me a little help there. CRUD is even kind of an anti-pattern, because it prevents you from doing relations in your relational database.

> CRUD is even kind of an anti-pattern, because it prevents you from doing relations in your relational database. Please explain how doing CRUD operations -- which is, after all, what SQL INSERT, SELECT, UPDATE, and DELETE statements are -- prevents you from doing relations in your relational database. Because that's a seriously wierd claim.

Perhaps they meant an ORM instead of crud.

Re: Coding the Angular Tutorial App in Backbone

#43

Post by dclowd9901 »

dustingetz wrote: post #9

> 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 wr…

The way I see it is you craft those state changes for the objects that need them. You could create a base object that handles basic state changing, too, and just extend from that. On the opposite end of the spectrum, we can make as many assumptions as we like, and override as needed, or we can create an unassumptive mesh of mixins that coordinate and comprise complex objects.

I can do that with a framework that doesn't presume the best path from 0-F. The reason I like Backbone is because it treats me like a developer who knows how to architect an application.

Re: Coding the Angular Tutorial App in Backbone

#44

Post by 204NoContent »

adamcw wrote: post #24

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…

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.

Re: Coding the Angular Tutorial App in Backbone

#45

Post by daRomansky »

Rygu wrote: post #40
quack wrote: post #4

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.

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... [1] https://github.com/marionettejs/backbone.marionette/blob/mas... [2] https://github.com/marionettejs/backbone.m…

try the stickit framework by nytimes, works great for me

Re: Coding the Angular Tutorial App in Backbone

#46

Post by tonyhb »

Rygu wrote: post #40
quack wrote: post #4

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.

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... [1] https://github.com/marionettejs/backbone.marionette/blob/mas... [2] https://github.com/marionettejs/backbone.m…

Marionette is a solid framework. It has everything you need to build fast, and clean: regions (which were a great step in the right direction and will be improved in V2), composite/collection views, layouts... the basics are there for you to work with how you would like.

You've made three points which I can't see much fault with. Why the hate?

Re: Coding the Angular Tutorial App in Backbone

#47

Post by lelandriordan »

quack wrote: post #4

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.

You can't just take away the pre-built directives as they are a core module of "vanilla Angular" as stated on the front page of the API docs. From controllers (ngController), to models (ngModel), to looping (ngRepeat), to the actual app itself (ngApp), directives are fundamental to using Angular. Taking away core directives would be like taking away selectors from jQuery, or models from backbone; without them, the framework is pretty much useless.

Re: Coding the Angular Tutorial App in Backbone

#48

Post by peterhunt »

dragonwriter wrote: post #38
gumballhead wrote: post #23

Earlier quoted context omitted.

Yes. Backbone basically supplies CRUD mapping and an event bus. So it is opinionated about models. But CRUD is a solved problem that's easy to implement, and view / controller code ends up being the bulk of your application. I'd rather my framework give me a little help there. CRUD is even kind of an anti-pattern, because it prevents you from doing relations in your relational database.

> CRUD is even kind of an anti-pattern, because it prevents you from doing relations in your relational database. Please explain how doing CRUD operations -- which is, after all, what SQL INSERT, SELECT, UPDATE, and DELETE statements are -- prevents you from doing relations in your relational database. Because that's a seriously wierd claim.

I think REST is more accurate, and REST does a shitty job of efficiently expressing relational data.

Re: Coding the Angular Tutorial App in Backbone

#49

Post by 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.

Re: Coding the Angular Tutorial App in Backbone

#50

Post by modarts »

peterhunt wrote: post #48
dragonwriter wrote: post #38

Earlier quoted context omitted.

> CRUD is even kind of an anti-pattern, because it prevents you from doing relations in your relational database. Please explain how doing CRUD operations -- which is, after all, what SQL INSERT, SELECT, UPDATE, and DELETE statements are -- prevents you from doing relations in your relational database. Because that's a seriously wierd claim.

I think REST is more accurate, and REST does a shitty job of efficiently expressing relational data.

I know React is backend agnostic, but out of curiosity, what does your ideal server API architecture look like if not RESTful?
Post reply on HN