Live data from Hacker News

Coding the Angular Tutorial App in Backbone

blog.42floors.com

21–30 of 71 posts

Re: Coding the Angular Tutorial App in Backbone

#21
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)

Re: Coding the Angular Tutorial App in Backbone

#22

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

There's a big difference: 800k of code that somebody else is maintaining is very likely to be way less hassle than 2.4x the code that you have to maintain.

As a slightly hyperbolic example, imagine comparing code that uses the filesystem with code that directly writes bytes to the disk - sure, it's probably only 5x more code but nobody would seriously entertain doing it...

Re: Coding the Angular Tutorial App in Backbone

#23

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

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.

Re: Coding the Angular Tutorial App in Backbone

#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 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.

Re: Coding the Angular Tutorial App in Backbone

#25
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.

Re: Coding the Angular Tutorial App in Backbone

#26
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.

Re: Coding the Angular Tutorial App in Backbone

#27
post #13

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

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.

Re: Coding the Angular Tutorial App in Backbone

#29
post #22

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

There's a big difference: 800k of code that somebody else is maintaining is very likely to be way less hassle than 2.4x the code that you have to maintain. As a slightly hyperbolic example, imagine comparing code that uses the filesystem with code that directly writes bytes to the disk - sure, it's probably only 5x more code but nobody would seriously entertain doing it...

I dunno. angular is pretty complex.

I'm willing to bet that there's going to be a bug somewhere in that 800kb of code that is truly going to fuck up your day.

At least that 2.4x amount of code _could_ have more straight forward bugs.

Re: Coding the Angular Tutorial App in Backbone

#30

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

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.

Post reply on HN