Live data from Hacker News

The Future of AngularJS

docs.google.com

51–60 of 74 posts

Re: The Future of AngularJS

#51

Being able to avoid $scope.$apply() will certainly be nice. As it stands now, if you want to leave the Angular reservation and use something like the Parse JS SDK (which is a customized set of Backbone models) your code will be littered with $scope.$apply(). Not very DRY, and also adds, from the dev's point of view, a needless level of nesting functions.

... how does this have anything to do with DRY? You're calling $scope.$apply because you're re-entering AngularJs with new data and need to start off the dirty checking process.

This isn't repeated logic. This is a core function of the framework that's meant to be used exactly like that.

It's meant to be called that many times if you're doing that many things outside of Angular and need to sync your models.

Re: The Future of AngularJS

#52

Earlier quoted context omitted.

hahaha. Did you ust say "compatibility with older versions of IE". I'll probably get downvoted for this but. If you want to maintain "compatibility with older versions of IE" try an older version of HTML, an older version of CSS, an older version of javascript and an older x86 processor, and an older version of windows (95 sounds nice). Sorry. If future features should try to remain compatible with older versions of…

downvoted? No, you're totally right. We need to move on. see my rant below. upvoted.

I know. Browsers are free. What's the hold up?

Of course, its those creaky old IT departments.

Stop catering to these old browsers and people who want your app will download a capable browser or pressure their IT or just use their phone.

Re: The Future of AngularJS

#54
Personally, I liked that the slides are up there publicly, even if I don't get to see the talk to go with them - they function nicely as a brief overview to the future of Angular, letting good devs fill in the rest. Much of this isn't new, but I liked seeing some example code snippets comparing current and future syntax.

Re: The Future of AngularJS

#55
post #46

What I want to know about the future of AngularJS is: what is the state of server side rendering? We have some of our own ideas as to how this could work at https://starthq.com but I am hesitant to start implementing anything so as to avoid duplication of effort.

You should take a strong look at http://github.com/airbnb/rendr . I'm sure non-backbone adapters would be appreciated.

Re: The Future of AngularJS

#56
post #46

What I want to know about the future of AngularJS is: what is the state of server side rendering? We have some of our own ideas as to how this could work at https://starthq.com but I am hesitant to start implementing anything so as to avoid duplication of effort.

You should take a strong look at http://github.com/airbnb/rendr . I'm sure non-backbone adapters would be appreciated.

I couldn't find info on these adapters. From what I can tell this is very Backbone specific. Can you point me in the right direction?

Re: The Future of AngularJS

#57
does anyone know if there was a presentation that went along with these slides. it would be great to be able to see it. @briantford if you see this, we'd love to see more of the meat behind the bullet points. cool stuff though!

Re: The Future of AngularJS

#58

Being able to avoid $scope.$apply() will certainly be nice. As it stands now, if you want to leave the Angular reservation and use something like the Parse JS SDK (which is a customized set of Backbone models) your code will be littered with $scope.$apply(). Not very DRY, and also adds, from the dev's point of view, a needless level of nesting functions.

Parse.com has a perfectly capable REST API[1] that you can use with Angular's $resource. If you use Restangular, then your life becomes even easier. It won't be as convenient as using their JS SDK, but your code will end up looking much cleaner.

---

[1] https://www.parse.com/docs/rest

Re: The Future of AngularJS

#59
post #2

Neato. Angular reimplementing it's own module system (when many developers already have a large body of code in existing module formats, particularly AMD) was one of the things that turned me off when first looking at it. Do ES6 modules have all the dependency injection stuff the Angular developers wanted?

I don't know. In a large AngularJS application I want the Angular module system separated from other JS modules. They are completely different things if you ask me.
Post reply on HN