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

Using AngularJS at Localytics

localytics.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Using AngularJS at Localytics

#41

Post by sgt »

"Directives are hard. Working with isolate scope and transclusion is tough, and Angular’s documentation on the subject doesn’t make it easier. We found that before jumping into writing an ambitious directive, it’s best to start by not writing a directive — just using normal templates and controllers"

I have the same experience. I also tend to do the occasional DOM manipulation from the controller, using jQuery. I know it's frowned upon in the Angular community, but it at least allows me to experiment and, as the quote implies, figure out what I want before I know exactly what I need.

That being said, I'm starting to use directives more and more, and they are certainly a powerful tool that cannot be ignored if you are going to build an Angular app.

Re: Using AngularJS at Localytics

#42

Post by sgt »

avolcano wrote: post #14
swah wrote: post #10

We used to write things like Then we realized it was bad to couple presentation and behavior, so we made our Javascript unobtrusive, keeping our templates clean. But now we’re back at it again, writing . Have we learned nothing? --- This seems like a good point that I can't refute - anyone?

Honestly, there's not a huge amount of difference between Show Help $("#show-help-link").click(function() { showHelp(); } ); And Show Help I mean, HTML has behavior in it. A link in itself is "behavior": when you click this tag, go to the page defined in the src attribute. So, as the author says, it's not really a bad thing that templates have behavior in them. In Ember.js, for example, you have an {{action}} handler…

You don't need the src="text/javascript". Only ... is required.

Re: Using AngularJS at Localytics

#43

Post by anton-107 »

swah wrote: post #10

We used to write things like Then we realized it was bad to couple presentation and behavior, so we made our Javascript unobtrusive, keeping our templates clean. But now we’re back at it again, writing . Have we learned nothing? --- This seems like a good point that I can't refute - anyone?

Well the most disturbing thing about this syntax is for sure the use of parentheses. Drop them and you will get old good ng-click="doSomething" which doesn't differ at all from class="ng-doSomething" or data-ng-click="doSomething".

But parentheses try to lookalike the onevent attributes, which a) everybody doesn't like and b) immediately invoke javascript code

In AngularJS point b) can't be the truth - there is for sure some layer of expression evaluation, and that is what disturbing - as an experienced javascript developer you know that this layer exists, but you can't easily see what happens inside that layer - AngularJS hides that from you.

In most cases in traditional JS development - nothing really happens in this layer, it's just a dumb method invocation in the context of the view and has dom event as a single argument - this is clearly visible in libs such as Backbone.

But in Angular this layer of expression parsing and evaluation does exist - and you don't know what kind of magic happens there and how thick, maintainable and overridable this layer is. This possibility of dirty magic - that really disturbs me in all the simple tutorials of AngularJS, so I don't have courage yet to give it a try in a serious project.

Re: Using AngularJS at Localytics

#44

Post by Narretz »

feniv wrote: post #39

I've been using AngularJS for a few months on a side project of mine and it greatly helped move a lot of the code complexity to the client side. Hooking it up with a REST API was simple and got rid of almost all of the server side rendering. Here's a particularly useful sample app, implemented in both Angular as well as Backbone. http://coenraets.org/blog/2012/02/sample-application-with-an...

This post is is so popular, my fork from half a year ago (very few additions), still gets starred approx. once a week.

Re: Using AngularJS at Localytics

#45

Post by avolcano »

sgt wrote: post #42
avolcano wrote: post #14

Earlier quoted context omitted.

Honestly, there's not a huge amount of difference between Show Help $("#show-help-link").click(function() { showHelp(); } ); And Show Help I mean, HTML has behavior in it. A link in itself is "behavior": when you click this tag, go to the page defined in the src attribute. So, as the author says, it's not really a bad thing that templates have behavior in them. In Ember.js, for example, you have an {{action}} handler…

You don't need the src="text/javascript". Only ... is required.

Heh, I meant to specify "type" and not "src", but you're right regardless.

Re: Using AngularJS at Localytics

#46

Post by euroclydon »

nicklovescode wrote: post #36
lennel wrote: post #30

Earlier quoted context omitted.

I think as mobile becomes more dominant angular will have to find a way to work tighter with the closure compiler in advanced mode (or something akin) to remain relevant.

why?

I'm not sure why the OP links advance compiling specifically to mobile. It's good to have smaller, faster code on any platform that isn't quad Xeon with a fiber connection.

The Closure ecosystem has their own templates (soy) which are compiled in Advance Mode (with renaming) by the Closure Compiler. It's not possible to do that with Angular attribute's which reference JS names.

See this conversation about Angular support in Closure: https://groups.google.com/forum/#!msg/angular/hePiqQA-MCI/uT...

Re: Using AngularJS at Localytics

#47

Post by jcromartie »

Is it just me or is Backbone just not that hard? I don't quite understand their data binding situation. You should not need to look at the DOM for elements with specific IDs, unless you have truly singular views at the top level.

I get the feeling that their form re-rendering headaches had to do with parent views that were listening to unnecessary events, like a collection view that listens to individual model events.

Re: Using AngularJS at Localytics

#48

Post by thatthatis »

ihsw wrote: post #37
swah wrote: post #10

We used to write things like Then we realized it was bad to couple presentation and behavior, so we made our Javascript unobtrusive, keeping our templates clean. But now we’re back at it again, writing . Have we learned nothing? --- This seems like a good point that I can't refute - anyone?

The alternative is a slew of loosely-coupled and opaque attributes (IDs and classes), especially where you're not sure if a particular class or ID is used for presentation (CSS) or functionality (JS). How do you handle refactoring when you use some classes for JS and some for CSS? With custom attributes there is no confusion, and although it goes completely against the separation of concerns and now your mark-up isn'…

if you have functionality class/ID, do you really have separate concerns or do you just have moderate/loosely coupled concerns?

Re: Using AngularJS at Localytics

#49

Post by warfangle »

marknutter wrote: post #33
swah wrote: post #10

We used to write things like Then we realized it was bad to couple presentation and behavior, so we made our Javascript unobtrusive, keeping our templates clean. But now we’re back at it again, writing . Have we learned nothing? --- This seems like a good point that I can't refute - anyone?

My best attempt: HTML already has a bunch of behaviors embedded in it. Links, styles, dropdown menus, input fields, radio boxes, etc. The angular devs are simply embracing the declarative nature of HTML and extending its available behaviors. In that respect, angular is actually treating HTML more like it was intended to be treated. And I agree with the OP's lamentations about the javascript being completely divorced…

data attributes are baked in to the html5 standard

Re: Using AngularJS at Localytics

#50

Post by jaredgeorge »

Our team in finishing a project to refactor a custom form builder in our app (similar to WuFoo) and our struggles sound very similar. We are adding plugins like Backbone Relational to fight with issues, and fighting issues with the plugins... And in fact, our tech lead has actually forked Backbone (still unsure as to the exact reason). At any rate, we have shattered (what used to be) a ~1,000 line jQuery/JavaScript file into nearly 130 individual fragments of models, views, collections, templates, and helpers. Throw RequireJS into the mix... We can't be Doing It Right (TM), can we? Or are we, and I just don't get it?

[edit] spelling

Post reply on HN