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

61–70 of 71 posts

Re: Coding the Angular Tutorial App in Backbone

#61

Post by mcv »

n1ghtmare_ wrote: post #54

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

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

Possibly the biggest advantage of Angular is what it does for code organization. With JQuery, you've got to organize it yourself, and while some things are easily organized, others can easily turn into a big mess.

Angular is very big on separation of concerns, modules, dependency injection, etc. Basically, what Angular does, is provide a lot of mature code organization concepts that have been common place on the server-side for ages, to browser-side code. Javascript has long been the domain of little ad-hoc scripts. Stuff like JQuery makes it easier to work with fairly standalone libraries, whereas Angular does for the browser what frameworks like Spring and Wicket did for the server.

Is it what you need? Depends on whether Spring and Wicket are what you need.

Re: Coding the Angular Tutorial App in Backbone

#62

Post by mcv »

watty wrote: post #16
elwinmurton wrote: post #11

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.

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.

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

They are, but one of the things that makes Angular so powerful is that it kinda defines its own DSL. Most of your work may not even be in javascript, but in the enhanced HTML that Angular defines for you (and which you can expand by making more directives).

Re: Coding the Angular Tutorial App in Backbone

#63

Post by colemorrison »

kevincennis wrote: post #17
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…

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.

Huh? I've written quite a few large scale angular apps...and I haven't written a bunch of code to do any of that. If you have something that needs to be checked outside of angular, it belongs in a directive.

Re: Coding the Angular Tutorial App in Backbone

#65

Post by Jgrubb »

n1ghtmare_ wrote: post #54

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

xtrumanx said it well. What you learn while picking up any one of these newer frameworks will serve you well.

3 months ago I'd never touched any of them, at least not successfully. Then I got a project to build an app-like mobile website for my company on top of Drupal. I spent a few days trying to figure out how to fake it with jQuery and prefetching, all the while knowing that one of these frameworks was the better way to go. I spent a morning spinning up a couple of JSON feeds in Drupal and the afternoon learning enough Angular to get something to show up on the page, and I think it's fair to say that in the 2 months since that day my developmental worldview (and my productivity) has shifted considerably.

Regardless of how long Angular sticks around (though I suspect it'll be a little while), what I've learned from working with it nonstop for the last 2 months has definitely made me a better developer overall.

Re: Coding the Angular Tutorial App in Backbone

#66

Post by Bahamut »

corford wrote: post #60
Rygu wrote: post #40

Earlier quoted context omitted.

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…

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

Angular's source is pretty clean, minus compile.js and select.js

Re: Coding the Angular Tutorial App in Backbone

#67

Post by acjohnson55 »

n1ghtmare_ wrote: post #54

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

Even if not writing SPAs, I think frameworks can be great for building pieces of interactivity as cohesive modules. To me, this is a great use case for Backbone or React.

Re: Coding the Angular Tutorial App in Backbone

#68

Post by dragonwriter »

peterhunt wrote: post #58
modarts wrote: post #50

Earlier quoted context omitted.

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

I mean REST has its place. For example, it has very predictable performance and well-known cache characteristics. The problem is when you want to fetch data in repeated rounds, or when you want to fetch data that isn't expressed well as a hierarchy (think a graph with cycles -- not uncommon). That's where it breaks down. I think you can get pretty far with batched REST, but I'd like to see some way to query graphs in…

How is REST problematic for cyclic graphs? I mean the Web is a graph with many cycles and the Web is the defining instance of a REST application. HATEOAS, a pillar of REST, seems, among other things, to be particularly apt for dealing with arbitrary graphs.

Re: Coding the Angular Tutorial App in Backbone

#69

Post by dustingetz »

peterhunt wrote: post #58
modarts wrote: post #50

Earlier quoted context omitted.

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

I mean REST has its place. For example, it has very predictable performance and well-known cache characteristics. The problem is when you want to fetch data in repeated rounds, or when you want to fetch data that isn't expressed well as a hierarchy (think a graph with cycles -- not uncommon). That's where it breaks down. I think you can get pretty far with batched REST, but I'd like to see some way to query graphs in…

I think REST is orthogonal to relational data. (Actual REST, that adheres to HATEOAS and a real REST standard. If one rolls his own JSON services, it's not REST.) HATEOAS puts no constraint on how your data is shaped. A specific implementation of REST may or may not have a nice way to navigate graphs.

[0] http://restcookbook.com/Basics/hateoas/

RESTful Web APIs (2013)[1] is a very, very good book about this stuff. The book has a mailing list with some good discussion about this stuff [2].

[1] http://www.amazon.com/RESTful-Web-APIs-Leonard-Richardson/dp... [2] https://groups.google.com/forum/?fromgroups=#!searchin/colle...

I'm still exploring this stuff myself so maybe I am wrong or misunderstanding you.

Re: Coding the Angular Tutorial App in Backbone

#70

Post by Rygu »

corford wrote: post #60
Rygu wrote: post #40

Earlier quoted context omitted.

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…

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

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

Post reply on HN