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

The reason Angular JS will fail

okmaya.com

Post reply on HN
Print view View original

81–85 of 85 posts

Re: The reason Angular JS will fail

#81

Post by novagenesis »

numbsafari wrote: post #36
theschwa wrote: post #26

Earlier quoted context omitted.

I wish there was more discussion of the core concepts in Angular instead of just the implementation. Custom Elements + Two-way Data Binding + Services seems to be a pretty powerful combination.

That's what I was looking for when I found Angular. There are definitely two questions worth asking: 1) Is that combination really what we want? (I think it is) and 2) Is Angular's approach the only right way to do it? So far, they've got the mindshare and a serious head start.

#2 is the killer.

Databinding is a lock-in feature. Annoying as hell, but true. There's no databinding library that I've seen that does not reduce your ability to use other libraries. I've never seen one that jives at ALL with third-party client templates (like dustjs).

Re: The reason Angular JS will fail

#82

Post by novagenesis »

jcvandan wrote: post #12
iomind wrote: post #5

jQuery is fine for regular websites and the like, but inadequate for large scale client apps. That's what Angular is for. There is not much benefit using angular to build your marketing site. If you don't understand this, you understand neither Angular, nor jQuery.

He isn't comparing the features of Angular to the features of jquery at all, he is just comparing it to a framework that has stood the test of time due to it's simplicity. He doesn't explicitly say it but I am sure when he talks about 'easier' ways to do what you can do with Angular, I believe he means other similar frameworks e.g. Ember, Backbone etc.

Perhaps, but using Databinding comes at a price.

The moment you databind, you can't use nearly as many other libraries as easily or safely. This means you want as fully-featured a databinding library so you don't need other stuff.

There's tons of articles about providing Angularjs updating support when you use jQuery..it's (or used to be) just painful.

Re: The reason Angular JS will fail

#83

Post by ssmoot »

novagenesis wrote: post #80
ssmoot wrote: post #74

Earlier quoted context omitted.

Sure. But most if not all of that logic is on the server anyways. So to actually make it work that way would be (IME) a duplication of effort. Then you have to deal with the fact that some of these second-order effects may be dealing with thousands of options. Do you really want to be calculating cartesian products on the client in JS? Ignoring the performance concerns, you could be talking about preloading a ton of…

If that logic is on the server, you wouldn't use Angular for it... But from a strict MVC standpoint, it seems smart for that logic to be on the client. The server provides a getter API: /api/schools_by_state/CA for example. The client does an ajax call if you choose "California" to get the schools list, which it can do in under 100ms on a fast enough world...then it can cache California schools on the client side, so…

I think we're talking about the same thing.

Binding a select-box to an event that makes that request and fills it in is trivial. And that data comes from the server.

If you're saying that you bring back a coarse interface (of school -> (state, city, district)), well that seems like a reasonable way to tackle it to me. But then that's not really what the other poster was suggesting (at least as I understood it), and Angular really does practically nothing for you in this scenario. You still have to specify your endpoint. You're still binding the data. And the two-way aspect of it is at best useless since the selected value is right there in the Form to be serialized, and at worst harmful because you're building and keeping large objects in JS for... no practical advantage I can think of at the moment.

Even stepping into the territory of calling something like this a "pattern", something that's been really common and fairly trivial beginning from the very earliest examples of Prototype.js really serves to add needless complexity to something that's actually very simple IME.

IMO.

Post reply on HN