Discussion  - 
 
Are there any examples or case studies out there of content-heavy websites built on Angular? Especially in which not all content can be easily pegged into the same-looking view templates? 

Let's say that I'm building a huge website where there is about 100 unique views with corresponding controllers (resulting in about 1000+ pages). Much of the content is coming from a REST-exposed CMS.

Based on what I know of AngularJS, this would make a huge JS file that needed to be downloaded upfront because of all the controllers, and the routeProvider would be very, very long.

So I'm wondering if my assumptions are wrong and Angular apps can be defined/loaded more modularly.... And if there are any solutions are out there on how to architect such a site with the Angular framework.
22
2
Dan Menard's profile photoEaswar Prasad's profile photoBrian Ford's profile photoFred Chu's profile photo
16 comments
 
I would also be interested in knowing if it's possible to load controller files only when the controller is needed. 
 
I haven't been able to find the specific moment in this video but +Miško Hevery seemed to suggest that Angular.js team was interested in exploring incremental loading of code (like controllers) in large apps. It didn't seem like there was anything official yet, but you may be able to use a tool like Require.js to load your Angular application in pieces.

AngularJS MTV Meetup: Best Practices (2012/12/11)
 
+Mark Bennett Thanks, I'll re-watch that one. I feel like a few things coming down the pipe (like the discussion of server side compilation) would be useful for making files even smaller.

Right now I'm playing around with the idea of creating four Angular apps: 1 for the homepage, and 3 more for each of the 3 distinct sections of the website. (Since it's unlikely that a user will want to switch to a new section mid-way through their visit.)

The things that would be common among the 3 sections would be user profile stuff (based on whether or not they are logged in), but I'm sure that can be offloading to serverside programming.
 
+Pearl Chen when you say server-side programming do you mean something like Node, or something like GWT?
 
+Pearl Chen I was thinking of doing something similar, defining a few different "apps" for my top level navigation nodes and group the subpaths underneath as relative routes.

This might even make sense since an Angular "app" is geared toward a single page application model, so if I'm going to do a full page load at the top levels, each one of those can be treated in distinct fashion. 

I'm not sure if this is correct, but it does seem like one way to segment things.
 
Google Double Click for Advertisers is by far the largest #AngularJS app I know of. It has 100s of views and controllers.Lazy loading is in the works.
 
+Miško Hevery In the meantime, do you think that breaking it out into 3-4 separate Angular apps makes sense?

All Directives and Filters could be built like a common library file and included into each of the projects.

My concern with file size is only because the website must be mobile friendly.
 
+Pearl Chen One important point on initial file size is that the javascript files tend to be much smaller with AngularJS than with other libraries, so this may be less of an issue than one might think.
 
I'd say try writing it as one app, and see how that goes. From a software engineering standpoint, your application should be decoupled enough that if you write it as "one big app" and initial load time gets too large on mobile, you can break it apart without too much difficulty. And as Joshua said, Angular apps usually aren't that big.
 
I worked on an enormous Sencha Touch app once, and we hacked in lazy loading ourselves with a framework called Ensure:

http://ensure.codeplex.com

It was immensely helpful, and I bet you could roll a solution for AngularJS with it as well.
 
As I understand it, lazy loading is not fully working right now. Routes have to be registered during config phase and the same holds for directives (and probably filters and services; didn't try it). There are some hacks how you can do it. E.g. store $route variable globally and use later, but this is not official solution.
 
Because a controller is not instantiated until there are called upon to first "manage" a view, you could initially register a "controller proxy". Later on you can lazy load the actual controller which then registers itself with a "lazy load cache".  When the "controller proxy" is instantiated it can look up its "real self" in the "lazy load cache".  Since a typical use case is formost the of the controller's members and methods to be registered on $scope, when the controller is first instantiated - you typically won't have to define stubs on the proxy.  I've tried this for a very simplistic case using Google Closure compiler modules (code-splitting and advanced optimization) and it works.
Add a comment...