Have people had much success using Angular in production for largish client-side apps? The only large Angular client-side apps I've seen don't seem particularly well organized, which is ironic given Angular emphasis on modularization.
I'm about to start work the largest client-side app I've ever done. I had resolved to use Backbone with React, since I've used Backbone a lot in the past and it excels as an organizational tool.
But looking at what's now available in the Angular ecosystem makes me wonder if I could save a lot of time by using Angular and some of its many 3rd-party modules.
I've only used Angular for a couple of small projects. I liked it but it seems a bit overengineered and very Java-like. But this could just be my Java prejudices coming in to play.
Anyone know of a large AngularJS (say 5000+ LOC) app as an example?
I work on a medium sized angular webapp (10K+ LOCs), and have spoken to large teams in organizations that build their applications using angular that have 100K+ LOCs, but have not seen an open source application on this scale. Some problem/solutions I've seen:
* Programmers split work by taking ownership on modules, treat modules by other programmers as black boxes, and use bower with a company hosted server to manage dependencies.
* Some programmers I've spoken to have tried using requirejs or bower to manage dependencies, but most I've talked to dislike the overhead this causes.
* Large apps dynamically load routes on-demand. The core angularjs framework is not built for this, but numerous hacks have been put forward by the community to handle dynamic loading of javascript modules, and honestly, it's not that bad. Thankfully, built-in support for dynamic loading of components is on the angular roadmap.
* Personally, I annotate my files such that, for any dynamically injected reference, the reader can directly navigate to the source file. Google closure syntax, browserify, and requirejs also provide this support.
We use it for two separate apps that are both largish, and one baby app we expect to continue to grow in size. Code organization gets simpler if you use a fractal approach where each module follows a convention which you fractal down as much as needed. That typically mirrors the angular style much more efficiently than a rails style approach, for example.
We're at 32,809 LOC in an app we're working on (although that includes tests and the Grunt build system). We operate at scale, and there's a lot of revenue at stake.
To me, a huge part of Angular is the tools that it provides you to organize your code. But you have to have discipline and good practices to keep things organized. It's not RoR. If you do abide by best practices, then it's a pretty good experience IMHO.
We're also using Backbone for our model layer, thinly wrapped in Angular to use $http and make it injectable. Backbone's collections & models are way nicer than anything else currently available in the Angular ecosystem.
Angular 2.0's roadmap looks like it will finally change that, delivering a modular "offline-first" model layer that sounds really kick-ass.
My companies app http://cloudfindhq.com (not open source, so can't see the source code). We have 5 apps, but originally there was only 3 spent some time this week refactoring the code base to make it better structured. Followed the angular generator for yeoman as an example project structure
I think messy code bases can happen quite a lot in angular because it's so flexible, so always need to keep the app structure in mind when programming.
We use it for our core app, and now have a bit over 10K lines of application code.
Our general strategy is to organize the app by functional areas, each area of which is organized similarly to how most angular sample projects are: with a directives.js, controllers.js, services.js, etc. We use ui-router to tie this all together.
The README didn't do a good job (at least for me) of explaining what it offers over RESTangular. It just said some hand wavy things about ActiveRecord. What are the real benefits of Restmod over RESTangular?
My first thought when I saw this was to wonder how it might stack up to RESTangular, which I've toyed around with, but never really committed to because it didn't offer a ton of value over the in-built services and, really, just manipulating $http directly.
This, however, looks really solid, and excels in its very natural syntax. The way in which an object is called, manipulated and saved back is exactly how I expect an 'ORM' to work... at least until I get down to the "belongsTo" stuff, which is very Railsy -- that's fine, and the intro professes its attempt to mimic ActiveRecord, so it's even expected, just a little rough for me, as I left Rails for Django mostly because I preferred Django's ORM to Rails' ActiveRecord.
Regardless, I'll give it a shot.
In my skimming, I didn't see what versions of Angular it supports. I know that 1.2x has issues with PATCH operations (easily solved), and this didn't have any caveats for $.save() -- is it intended for 1.3+, or could I expect it to work on a 1.2x project?
Django's ORM still implements the active record pattern,just like this module.
I really think it is an anti-pattern especially in domain driven design. Since it basically couples domain models to a persistence library. The repository /model manager pattern is a better alternative as it doesn't care where objects come from and how they are created (used in Hibernate,EF,Doctrine,... ) ,and keeps the persistence layer and domain models totally decoupled.
Granted that it is way harder to implement it in javascript+async environment, since async operations are not implicit in JS,which breaks any possible encapsulation to begin with, but it's not impossible.
[+] [-] jnbiche|11 years ago|reply
I'm about to start work the largest client-side app I've ever done. I had resolved to use Backbone with React, since I've used Backbone a lot in the past and it excels as an organizational tool.
But looking at what's now available in the Angular ecosystem makes me wonder if I could save a lot of time by using Angular and some of its many 3rd-party modules.
I've only used Angular for a couple of small projects. I liked it but it seems a bit overengineered and very Java-like. But this could just be my Java prejudices coming in to play.
Anyone know of a large AngularJS (say 5000+ LOC) app as an example?
[+] [-] nfmangano|11 years ago|reply
* Programmers split work by taking ownership on modules, treat modules by other programmers as black boxes, and use bower with a company hosted server to manage dependencies.
* Some programmers I've spoken to have tried using requirejs or bower to manage dependencies, but most I've talked to dislike the overhead this causes.
* Large apps dynamically load routes on-demand. The core angularjs framework is not built for this, but numerous hacks have been put forward by the community to handle dynamic loading of javascript modules, and honestly, it's not that bad. Thankfully, built-in support for dynamic loading of components is on the angular roadmap.
* Personally, I annotate my files such that, for any dynamically injected reference, the reader can directly navigate to the source file. Google closure syntax, browserify, and requirejs also provide this support.
I hope those anecdotes help.
[+] [-] randall|11 years ago|reply
[+] [-] kvcrawford|11 years ago|reply
To me, a huge part of Angular is the tools that it provides you to organize your code. But you have to have discipline and good practices to keep things organized. It's not RoR. If you do abide by best practices, then it's a pretty good experience IMHO.
We're also using Backbone for our model layer, thinly wrapped in Angular to use $http and make it injectable. Backbone's collections & models are way nicer than anything else currently available in the Angular ecosystem.
Angular 2.0's roadmap looks like it will finally change that, delivering a modular "offline-first" model layer that sounds really kick-ass.
tl:dr; go for it
[+] [-] royka118|11 years ago|reply
I think messy code bases can happen quite a lot in angular because it's so flexible, so always need to keep the app structure in mind when programming.
Now our structure is like this
App/ Directives/ Controllers/ Filters/ Tests/ App.js
I think with angular just need to find a structure that works and stick with it, as long as it's consistent it probably doesn't matter.
[+] [-] psgibbs|11 years ago|reply
Our general strategy is to organize the app by functional areas, each area of which is organized similarly to how most angular sample projects are: with a directives.js, controllers.js, services.js, etc. We use ui-router to tie this all together.
[+] [-] bdcravens|11 years ago|reply
[+] [-] Oculus|11 years ago|reply
[+] [-] api_or_ipa|11 years ago|reply
[+] [-] bmelton|11 years ago|reply
This, however, looks really solid, and excels in its very natural syntax. The way in which an object is called, manipulated and saved back is exactly how I expect an 'ORM' to work... at least until I get down to the "belongsTo" stuff, which is very Railsy -- that's fine, and the intro professes its attempt to mimic ActiveRecord, so it's even expected, just a little rough for me, as I left Rails for Django mostly because I preferred Django's ORM to Rails' ActiveRecord.
Regardless, I'll give it a shot.
In my skimming, I didn't see what versions of Angular it supports. I know that 1.2x has issues with PATCH operations (easily solved), and this didn't have any caveats for $.save() -- is it intended for 1.3+, or could I expect it to work on a 1.2x project?
[+] [-] aikah|11 years ago|reply
I really think it is an anti-pattern especially in domain driven design. Since it basically couples domain models to a persistence library. The repository /model manager pattern is a better alternative as it doesn't care where objects come from and how they are created (used in Hibernate,EF,Doctrine,... ) ,and keeps the persistence layer and domain models totally decoupled.
Granted that it is way harder to implement it in javascript+async environment, since async operations are not implicit in JS,which breaks any possible encapsulation to begin with, but it's not impossible.
[+] [-] aswanson|11 years ago|reply