Adoption, API stability, and "Big Picture" Angular Opinions?

[matthew...@gmail.com]

I'm still learning about Angular before I commit to using it. So far, it continues to impress. Looking for thoughts on 3 things:

1) What is the adoption of Angular like? Any idea of how widespread it is becoming compared to Backbone, etc? It's not found in any client's "approved software" list that I can find. Has anyone had issues with companies allowing its use in big projects, especially since it's still a 1.0 release? When I first proposed it to maybe be used, the first reaction I got was "why do you want that, when we've already approved Backbone?"

2) How stable is the API? If I kick off a big year-long project based on Angular now, will I be able to update to new releases without re-writes? Or is it still changing too much to base a lot of code on it?

3) I'm grokking the individual concepts fine, and I intuitively see how they fit together. What I'm lacking is the "Big Picture" Opinion from Angular. When writing a big enterprise app with hundreds or thousands of screens, common navigation, lots of CRUD, many reports, etc - how is all that done in an Angular way? How are screens loaded and unloaded? How are dependencies loaded? How do I load and unload controllers, depending on what view I am on? Or do I just have one big monster controller? How do I handle navigation when I may have thousands of url endpoints that a user can jump tom from any number of screens?

Basically, let's say I have a typical business webapp that does round-trip page refreshes right now, and has maybe 100 screens that manipulate various attributes of a variety of entities.How do I transition that to an Angular model, either as a full Single Page App, or perhaps a hybrid? What does that look like? That's the piece I'm still missing.

So far, I'm convinced that this is the best solution I've seen. It's not just a component, but a solution, and it doesn't feel like the series of hacks that javascript has given us over the years (even jQuery, the ultimate hack). It feels solid, conceptually. I just want to be clear about exactly what kool-aid I am supposed to drink. :)

Thanks!

Matt Kruse
http://MattKruse.com

[Dave Merrill]

I'm also very interested in how Angular fits for large-scale apps lik eyou describe, since that's mostly what I work on.

I'm a long-time web dev, but quite new to Angular (as anyone noticing all my questions on this list will tell you!), so grab your grains of salt, but from what I currently understand:

Angular itself has no dependency management in the sense of actually *loading* js files that aren't in your HTML. Everything you want to inject has to be present at page load. This is a pretty serious limitation for large scale apps, or maybe not. I've been considering the possibility that each screen can be an independent Angular app. We currently load independent non-Angular HTML dlgs (over 450 currently, plus legacy round-trip stuff not yet migrated), mostly into iframes, and there's no reason I know what each of them can't be treated that way. Of course you won't be able to do transitions or share data between them, beyond what you can do without Angular, but each screen can benefit from Angular's technologies. I've looked for examples that went beyond SPAs, but haven't really found any.

Another consideration is how easy it is to get really fluent, and what your team thinks. Personally, I feel a lot like this post. It isn't coming particularly easily to me, significantly less so than I expected, but it is coming along, and it's pretty amazing. Different people have different reactions, and maybe I'm thick, or stuck in other paradigms.

As to whether it's wise take the plunge on an app at this scale, others should answer (~_~). I haven't tried to sell it here myself, don't know it well enough by a long shot.

Dave Merrill

[bdi...@gmail.com]

Hello Matt,

1) What is the adoption of Angular like?

I believe the adoption of Angular is good. It hit it's 1.0 release not too long ago, and there are already about 1,500 questions regarding it on stackoverflow. Compare that to backbone, which has about 6,500. I've been using Angular for the past 3 months, and I can see the community behind it growing very quickly.

2) How stable is the API?

In the past 3 months of use, I haven't run into any bugs.

3) What I'm lacking is the "Big Picture" Opinion from Angular.

Angular addresses many of the use cases you mentioned. AngularJS is a purely client side framework. It works best when you use RESTful services as your back end.

You can accomplish common navigation through the use of routing and ng-view. It has create support for CRUD (two way data binding, $http service, and resource classes). Dependency injection is used to resolve dependencies.

If you are using Angular to create a larger application, I would personally use a singe page application with routing. It makes things very fast. You shouldn't be returning HTML from the server, but rather JSON, which is then used as your view model.

I've used both Backbone and Angular - once you learn Angular you will be much more productive. It is a more full blown solution than back bone is. 

On Tuesday, January 8, 2013 11:58:05 AM UTC-5, matthew...@gmail.com wrote:

[matthew...@gmail.com]

On Tuesday, January 8, 2013 1:27:14 PM UTC-6, bdi...@gmail.com wrote:

2) How stable is the API?

In the past 3 months of use, I haven't run into any bugs.

It's not bugs that I was asking about, but rather how stable the API is with regards to future changes. If I implement a big app using $scope.$somemethod, how certain can I be that this won't be refactored in version 1.3, forcing me to either maintain my old version of Angular or update all of my code? I don't want to do either :)
 

3) What I'm lacking is the "Big Picture" Opinion from Angular.

Angular addresses many of the use cases you mentioned. AngularJS is a purely client side framework. It works best when you use RESTful services as your back end.

You can accomplish common navigation through the use of routing and ng-view. It has create support for CRUD (two way data binding, $http service, and resource classes). Dependency injection is used to resolve dependencies.

Yes, those are kind of all the buzzwords that I see on the welcome sign. I want to know about real implementation.
 

If you are using Angular to create a larger application, I would personally use a singe page application with routing. It makes things very fast.

What if you have 2,000 different url's to support? Do you have all your routes statically defined in one big js file that is on the page? Do you have all controllers in one big file? I mean, I could imagine many 100k of javascript being delivered just too bootstrap the app, then. Surely there is a more modular approach than this? What is the right design for a large app with many hundreds of pages (views) and many entities (models) with hundreds of attributes?

Thanks,

Matt

[Joshua Miller]

Hey Matthew!

You may find this video helpful: http://www.youtube.com/watch?v=oJoAnVRIVQo. It's from one of the meetups, describing rewriting a very large application at Google with Angular. For your other questions, I can only offer my proverbial two cents.

1) The angular community is still quite small - but we're fierce! If you look at the Google search trends (http://www.google.com/trends/explore#cat=0-5&q=angularjs%2C%20backbone&date=today%2012-m&cmpt=q), it's looking good for Angular in the long term. As for the question from clients "why", this is the best part - because it's _better_. It's more modern.

2) I can speak to this only to a limited degree, but it's 1.0, so best practices indicate a fairly stable API, but the team is working on an unnamed "2.0" that has more cool stuff that will surely break backward compatibility - but you could _choose_ to update or not.

3) I agree with Dave and Brian here. Angular is really built with SPAs in mind and this where it shines. As of right now, there is no good way to lazy-load dependencies, but it'es less of an issue than one might think (again, reference the video). Because of Angular's architecture (e.g. two-way data bindings), your javascript tends to be _significantly_ smaller than the equivalent jQuery or Backbone. I used Dojo on a project right before I came to Angular and my experience has been about a 75% reduction in code volume. As another example, I rewrote a jQuery plugin of around 350 LoC to an Angular directive of around 50; this is not atypical when you're coding to Angular's sweet spot. 

That said, the mountain will come to Mahomet - the team is working on lazy-loading and dependency management for the unnamed "2.0" release.

Hope this helps!

Josh

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en-US.
 
 

[Dave Merrill]

I'm with you Matt, excellent questions. 

The big app I work on has the > 450 client-only screens I mentioned, and is > 10k files, > 140 Megs, including front and back end, build, etc.. Loading the entire client side of that up front doesn't pass a basic sanity test IMO. I could see treating each dlg as a separate SPA. You may still be able to use routes and ng-view in some cases, to present several "screens" within one actual HTML file. I'm not aware of anyone doing this, but that doesn't mean it's not happening.

Big picture, these are really relevant questions for large apps. Those are the ones that need structure and code sanity the most.

Dave

[Pawel Kozlowski]

Hi Matt!

First of all, welcome to AngularJS :-)

On Tue, Jan 8, 2013 at 8:34 PM, <matthew...@gmail.com> wrote:
> On Tuesday, January 8, 2013 1:27:14 PM UTC-6, bdi...@gmail.com wrote:

> It's not bugs that I was asking about, but rather how stable the API is with
> regards to future changes. If I implement a big app using
> $scope.$somemethod, how certain can I be that this won't be refactored in
> version 1.3, forcing me to either maintain my old version of Angular or
> update all of my code? I don't want to do either :)

I would say that 1.x is reall, really stable in terms of API. You can
check the change-log here:
https://github.com/angular/angular.js/blob/master/CHANGELOG.md - it
has all breaking changes clearly marked.

Also, there are also 2 "life" versions:
1.0.x - which gets only bugfixes
1.x - that gets new features and bug fixes

So you can be either more conservative or use the latest version.

Cheers,
Pawel

--
Question? Send a fiddle
(http://jsfiddle.net/pkozlowski_opensource/Q2NpJ/) or a plunk
(http://plnkr.co/)
Need help with jsFiddle? Check this:
http://pkozlowskios.wordpress.com/2012/08/12/using-jsfiddle-with-angularjs/

Looking for UI widget library for AngularJS? Here you go:
http://angular-ui.github.com/

[bdi...@gmail.com]

Regarding the structuring of an Angular app, I have been using Grunt (gruntjs.com) as a build tool. It has a task that allows you to concatenate files together. I usually break it down to one controller, service or directive per file. You will end up with one large JS file but it my opinion that is the way to go. The initial load time may be slightly longer, but the user experience after that will be better.

In terms of the implementation of an Angular application - that is what the docs are there for :)

On Tuesday, January 8, 2013 2:34:01 PM UTC-5, matthew...@gmail.com wrote:

[matthew...@gmail.com]

Thanks for your response, Josh.

On Tuesday, January 8, 2013 1:42:31 PM UTC-6, Joshua Miller wrote:

3) I agree with Dave and Brian here. Angular is really built with SPAs in mind and this where it shines.

Perhaps this is part of my real hesitation, because I've not yet figured out how to do some things in a SPA.

For example, if you go to a url you may get back one of 10 different screens depending on your user role, security, time of day, the state of some data, etc.
I do not want to load all of those factors into a JS model and have a JS controller evaluate them to decide what view to show. That seems insane to me.
I want to keep real hard-core business and application logic on the server side, where it belongs. Not susceptible to quirks in users' browsers that may make the wrong thing appear, nor do I want my business logic exposed to users in their source.

What seems reasonable to me is to create mini-SPA's for sections of a larger app. When you leave a logical section, you round-trip. For operations within the section, or navigation within the section, you stay ajaxy and Angluarish. Then it becomes quite logical to deliver a single model and controller along with the painting of the section, and maintain it until you leave for somewhere else. At that point, a different model and controller are loaded when the round-trip returns.

Given the power and flexibility of real server-side controllers with config files, security rules, context, etc, I don't see any compelling reason to re-build all of that to run in the client. Especially when it seems like you can get a big benefit from Angular in "Mini-SPA" mode.

Is there a compelling reason to pass over the entire job of a big controller to Angular and force a SPA model?

Matt

[Joshua Miller]

Hi Matt!

You said "I want to keep real hard-core business and application logic on the server side, where it belongs". Why is the server where it belongs? There are some things a server has to do (security and final validation are obvious things), but what is the _real_ reason why other things, like presentation, cannot be passed on to the client?

Each year, more and more functionality is passed from server to browser; this is the direction of the field. While not (yet) suitable for every use case, desktops (and mobiles for that matter) are far more powerful than they used to be and javascript runs so significantly faster than it used to that many of these concerns are a bit antiquated. 

As far as this idea of "mini-SPAs" that some people have been advocating here and elsewhere, that may be a valid approach for some web _sites_, but it's probably not the best for most web _apps_. Apps _do_ something - and in theory do it well - but they don't do 400 somethings. An app can have a lot complex features and many routes and reach into 100k LoC, but it's still centered around one or a few fundamental goals.

You said you don't see "a compelling reason to pass over the entire job of a big controller to Angular". I say I don't see a compelling reason to have a big controller in the first place. SPAs (especially in angular) are not monolithic. Despite how it may seem at first glance, SPAs allow us to _simplify_ and maintain a nice, clean separation of concerns - just like we would with server-side MVC and per-action page reloading. But the compelling reasons why so many organizations are switching to SPAs are performance and user experience. And browsers these days can take the heat - even on mobile.

I've been developing web sites (and apps) since the late nineties. It's pretty insane how much has really changed in that time period. Every few years, developments come along that completely change our way of thinking about a problem space. This transition to SPAs is one of those. But we are in the _middle_ of that transition and it's not right for every use case - yet.

However, we should be careful not to base these kinds of decisions on an appeal to tradition. It may hurt our competitiveness.

Josh

[zdam]

Hi Matthew,

I'm about a year into serious AngularJS usage in a commercial application, which already 'existed', so the introduction of AngularJS absolutely had to be in a way that did not require all-or-nothing.  So some parts/pages of our app or partially Angular, with interop (which is easy) between existing (significant) raw jquery bits and angular, other parts of the system are pure Angular.

Our app is not an SPA, we successfully use AngularJS for 'parts' of our system, with full page round-trip refreshes to other various parts of the system, that they themselves may use Angular when arrived at.

- even in a new green-fields project, I think I would still go with this approach, rather than attempting a complete AngularJS SPA.

One thing that is interesting to reflect on, is that I had plenty of (quickly answered) questions to this list initially (there is a significant AngularJS learning curve), but I don't think I have asked a question in 6-8 months, yet continue to use Angular regularly..

Good luck!

[Dave Merrill]

I don't mean to be argumentative Josh, but I just don't think you're right that web _apps_ do only a few things. I work on a large commercial app, with approximately 1500 methods and growing in its server-side API, and as I've said before, over 450 pure-client-side-talking-ajax-to-the-server-api dialogs so far, along with many legacy round-trip dialogs we haven't converted yet. It has many admin, reporting, and data management functions, not a few. If every dialog has at least one model data structure (most have more; I'm modifying one with 19 formal datasets and a bunch of other vars right now, probably the upper end or near it) plus at least one controller, do you really think it's optimal, or even reasonable, to load all of that into the DOM on load?

Apps like this have some problems that SPAs with fewer areas of functionality just don't have.

Also, making major architectural changes to a large existing app is like replacing the engines while the plane's in the air -- you can't just stop and change everything all at once -- it has to be done incrementally. Zdam's team seems to have taken a reasonable approach, migrating various parts of the app one at a time, and probably building new functionality The New Way. In that case, you're not going to suddenly have everything in one SPA. You really _have_ to treat each dialog (or possibly related sets of them, like a wizard sequence) as a separate SPA. There a some limitations to that strategy, but there's no reason it can't be done, as Zdam's experience shows. It seems like the only real choice in this situation.

(Just to be clear, the app I work on's not in Angular at all now. While I'm learning and using Angular for some personal projects, I'm also thinking about whether I should propose it for the big app at work.)

Dave Merrill

[matthew...@gmail.com]

On Wednesday, January 9, 2013 12:57:11 AM UTC-6, Joshua Miller wrote:

You said "I want to keep real hard-core business and application logic on the server side, where it belongs". Why is the server where it belongs?

Several reasons:
1) It is reusable between server-side code that offers web services
2) It is hidden completely from curious users/hackers
3) It is considerably faster for very complex data crunching
4) It can be reused by other sibling applications that may not even be webapps
 

what is the _real_ reason why other things, like presentation, cannot be passed on to the client?

Presentation is fine. Handling the View is the biggest benefit of Angular, from my view.
 

Each year, more and more functionality is passed from server to browser; this is the direction of the field.

It is cyclical in computers. The power bounces from server to client and back again, in a continuous cycle :)
 

As far as this idea of "mini-SPAs" that some people have been advocating here and elsewhere, that may be a valid approach for some web _sites_, but it's probably not the best for most web _apps_. Apps _do_ something - and in theory do it well - but they don't do 400 somethings. An app can have a lot complex features and many routes and reach into 100k LoC, but it's still centered around one or a few fundamental goals.

You are underestimating the complexity of some webapps. One that I am touching has 500 database tables, 2,000 classes, 500+ screens, etc.
I cannot fathom putting the entire app logic and controller into the client. That would be insane.
 

You said you don't see "a compelling reason to pass over the entire job of a big controller to Angular". I say I don't see a compelling reason to have a big controller in the first place.

Perhaps you have not worked on significantly complex webapps :)
 
And don't get me wrong, I'm not objecting to the idea of SPAs at all, I think they are great. And I'm trying to move in that direction. I just think there is a need for a hybrid approach, where something like Angular does MV but leaves C on the server. I'm trying to figure out where that line is. Or at least where Angular *thinks* it is.

Matt

[ganaraj p r]

The C of the server is not the same as the C in the client.

In angular for example it assembles the connection between the model ( on the client ) with the view ( on the client ) . If these 2 are in the client how can the Controller be on the server?

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en-US.
 
 

--
Regards,
Ganaraj P R

[Joshua Miller]

Hello! 

Well, Matt - it seems you started quite the brouhaha. As you and Dave are making the same fundamental points, I will respond to you both inline. But first, Ganaraj is correct that the server and client controllers are different.

Dave said: "...along with many legacy round-trip dialogs we haven't converted yet..." Converting legacy applications to SPAs often take an incremental approach - and often rightfully so. But when starting from scratch, as Matt seems to imply he is doing, we wouldn't necessarily take the same approach, right? So I don't think this is an argument against SPAs per se.

Matt said: "It is cyclical in computers. The power bounces from server to client and back again, in a continuous cycle". Not so much, no. And even if that was true, what does that have to do with my point that browers can handle what we're asking of them?

Matt also answered my question about why he would keep logic on the server instead of the client in several bullets. I will now address each:

1) It is reusable between server-side code that offers web services. Yeah, but you're talking about _services_. Services are the backbone of any SPA. Of _course_ we should have reusability and our infrastructure should be service-oriented. Also, we should architect our SPAs to themselves have reusable components, which is a frequent topic in this group. I don't see what this has to do with what runs on the client versus what runs on the server.

2) It is hidden completely from curious users/hackers: A well-designed API should be able to be publicly distributed without fear of exploitation. If security and key validation are on the server (where they belong) what specifically are you afraid users will learn from your client-side code?

3) It is considerably faster for very complex data crunching: No one is suggesting that "complex data crunching", whatever that means, should be performed on the client. Usually in SPAs, that is left to the server, which is accessed through the service API. Here's a more fundamental question aimed at the premise of your question: why are you assuming offloading a complex calculation (or set of calculations, or even asynchronous job requests, etc.) would require a page reload on the client?

4) It can be reused by other sibling applications that may not even be webapps: This is the same as question one.

Now I want to spend a few minutes on a key point that it seems from both responses I was not clear enough in explaining. This is the most important point that I was making.

Dave said: "I just don't think you're right that web _apps_ do only a few things". If I had said that, I would be wrong. But what I said was actually that apps are "centered around one or a few fundamental goals". This is a key distinction. As a thought experiment, can you think of _any_ successful application (web or not) that does _not_ have one (or at most a few) fundamental goals? Right now I have Gimp open on another workspace; it contains many features and many dozens of dialogs and is scriptable through plugins, but it's goal is still one: manipulate raster images. LibreOffice is a suite of smaller applications, but even the entire suite has one goal: view and edit documents of a defined kind.

I worked as a project manager on a $20m marketing data warehousing (and accompanying web-based analytics application) initiative a few years ago; this was an organization-wide initiative supporting multiple lines of business, had dozens of customizable reports and special data tools, many dozens of incredibly varied and complex screens, all customizable based on the state of the application, etc. But it still had a fundamental goal: the presentation of a set of data (principally centered around KPIs) in a few key ways.

Complexity != many goals. As I said in my earlier response: "An app can have a lot of complex features and many routes and reach into 100k LoC, but it's still centered around one or a few fundamental goals." If your app is not, you are doomed to fail. Citations available upon request.

But all of this aside, I need to expose a logical fallacy underpinning your argument. If I was to boil your argument down its simplest form, I would summarize it as follows: This app I'm contemplating is just too big for SPAs. But when I press y'all for a reason, what I get are arguments from incredulity: Matt said "I cannot fathom" and "that would be insane." Dave said "do you really think it's optimal, or even reasonable". That you cannot imagine how it would work from your experience does not mean it doesn't work. You must prove _why_ it couldn't work (or at least wouldn't be optimal).

Finally, Matt said: "Perhaps you have not worked on significantly complex webapps" To which I must retort: perhaps you have not worked on sufficiently modern web apps. :-)

As I said, SPAs are emphatically _not_ right for every situation - yet. But I'll say again what I said before: we should be careful not to base our decision on what the Internet looked like a few years ago. It's just too different.

Hot damn that was long! But this is a great discussion. I hope you're having fun with it too. :-)

Josh

[matthew...@gmail.com]

On Wednesday, January 9, 2013 8:13:34 AM UTC-6, Dave Merrill wrote:

Also, making major architectural changes to a large existing app is like replacing the engines while the plane's in the air -- you can't just stop and change everything all at once -- it has to be done incrementally.

Indeed, it is quite a challenge.
 

Zdam's team seems to have taken a reasonable approach, migrating various parts of the app one at a time, and probably building new functionality The New Way. In that case, you're not going to suddenly have everything in one SPA. You really _have_ to treat each dialog (or possibly related sets of them, like a wizard sequence) as a separate SPA. There a some limitations to that strategy, but there's no reason it can't be done, as Zdam's experience shows. It seems like the only real choice in this situation.

Agreed. And in that scenario, don't you have to leave the Controller on the server? What do you think?
I think that mini-SPAs can have their own controller, but leave app-wide navigation to the server for round-tripping.

For example, my app has sections for different kinds of entities. One section may have 15 tabs in it, each to view or edit different variations of data about or connected to the entity. I can imagine this as a mini-SPA, with navigation between the tabs being all Controlled by Angular. But if you leave the entity section, it round-trips to go to the new area.

I also have some security/role-related concerns that I haven't figured out yet:

• If a user shouldn't see a section or portion of data at all, I don't even want to deliver that part of the template to the browser. I definitely do not want that section in the source, hidden by javascript logic
• If the user has different roles, they may see things rendered differently. I don't want to leave those rendering decisions up to javascript and Angular, so I guess I would need to deliver different partial HTML from the server based on security?
• Some information may be optional, or there may be different business rules applied based on roles and security, and I don't want to duplicate all of that logic in the client, so there would definitely be cases where I want my client-side model to be 'dumb' and pass off all real processing to the server.
  

Matt

[matthew...@gmail.com]

On Wednesday, January 9, 2013 9:17:38 AM UTC-6, ganaraj p r wrote:

The C of the server is not the same as the C in the client.

Okay, perhaps that is a misunderstanding on my part.
Is the C on the client more like the glue between model and view?
I see the C on the client being the routing and navigation, loading of partials, etc. Is that not part of the C?

Matt

[ganaraj p r]

Well, if you are doing all of it on the client then yes.. All of what you mentioned is part of the C in client ( routing and navigation are the parts that can sit anywhere! ).

But most notably, its the glue between the model and view ( which cannot sit on the server) .

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en-US.
 
 

[Ryan Zec]

On Wed, Jan 9, 2013 at 11:57 AM, <matthew...@gmail.com> wrote:

I also have some security/role-related concerns that I haven't figured out yet:

• If a user shouldn't see a section or portion of data at all, I don't even want to deliver that part of the template to the browser. I definitely do not want that section in the source, hidden by javascript logic

Data is not an issue if you properly authenticated on the server (you should never send data to the data that use user should not be able to access).  If you really don't want to even have sections of the template to show up (even though I don't see how harmful it would be if they can't access the data), the only way I know around this is by servering the templates from the server (so you would have to have some server side language generate the Angular templates).  Their might be a better option but I don't know of one with those requirements.

• If the user has different roles, they may see things rendered differently. I don't want to leave those rendering decisions up to javascript and Angular, so I guess I would need to deliver different partial HTML from the server based on security?

As far as I know. 

• Some information may be optional, or there may be different business rules applied based on roles and security, and I don't want to duplicate all of that logic in the client, so there would definitely be cases where I want my client-side model to be 'dumb' and pass off all real processing to the server.

I would say any type of data manipulation you need to do based on any type of authorization/permissioning needs to be done on the server side.

[matthew...@gmail.com]

On Wednesday, January 9, 2013 10:00:27 AM UTC-6, Joshua Miller wrote:

Well, Matt - it seems you started quite the brouhaha.

I'm glad, as it is helping me understand and clarify some key points :)
 

But when starting from scratch, as Matt seems to imply he is doing

Just to clarify, I'm looking to apply Angular to a big refactoring effort of a large existing app.
 
I think there are a number of points being made, but I'd like to focus on one, if I may:

But all of this aside, I need to expose a logical fallacy underpinning your argument. If I was to boil your argument down its simplest form, I would summarize it as follows: This app I'm contemplating is just too big for SPAs. But when I press y'all for a reason, what I get are arguments from incredulity: Matt said "I cannot fathom" and "that would be insane." Dave said "do you really think it's optimal, or even reasonable". That you cannot imagine how it would work from your experience does not mean it doesn't work. You must prove _why_ it couldn't work (or at least wouldn't be optimal).

Okay, here is what I cannot fathom:
If you are at location X in a large app, and you need to navigate to location Y without a round-trip, don't you need to have a controller in JS that knows which server-side resource to call to load the html and data? And doesn't your SPA need to know whether it needs to re-request the chrome around the body, in case you are navigating into a section that has a different layout, with different menus, etc? The brains for all of that deciding typically lives on the server, because it's complicated. If you want to be a SPA, how do you handle it?

I guess that is the fundamental question I have, and it probably has more to do with SPAs than it does Angular in particular. But because Angular handles routing and url-hashing, etc, I thought that it would have some opinion on how this should be done?
 

Hot damn that was long! But this is a great discussion. I hope you're having fun with it too. :-)

Yes, I greatly appreciate the sharing of ideas. I hope I can have my way of thinking challenged enough to come out of this with a better vision of how I can put Angular to use in the problems I want to solve!

Matt

[matthew...@gmail.com]

On Wednesday, January 9, 2013 11:01:31 AM UTC-6, ganaraj p r wrote:

Well, if you are doing all of it on the client then yes.. All of what you mentioned is part of the C in client ( routing and navigation are the parts that can sit anywhere! ).

This is the part I am trying to clarify. How this "C" works when done in the client, if it scales, etc.
It doesn't feel like it would scale to a large app, which makes me think that the mini-SPA approach would work best, so only small bits of routing and navigation are on the client.
But I'm not sure.
 

But most notably, its the glue between the model and view ( which cannot sit on the server) .

This I am very comfortable with, but I'm just not comfortable labeling  it a "Controller". If that's what Angular refers to as its C, though, that helps to clarify.

Thanks!

Matt

[Dave Merrill]

The client should never be that actually controls what users can do or see. Anyone can fiddle with your js and html using firebug etc, so it's not really under your control.

Ideally I think, the basic split is that data comes from the server, and data only gets modified there, by code that knows the applicable business rules. Not just security, anything -- can't delete the last user in the system etc. The server should never send data the user doesn't have rights to see, or modify data in ways the system doesn't allow.

The client side of this is just to provide a smooth user experience -- don't show menu items, buttons, links, etc, that when invoked, the server response will only tell them they don't have access. Typically you get data from the server about user rights, and use that to modify the UI. Again that's not to actually hide data or prevent user actions, just to make things clearer and nicer for users.

None of that is specific to Angular, or to SPAs, or multi-page ajax-y apps.

Dave

[Dave Merrill]

If you actually need to send the user who requested one specific url to different urls based on their rights, how about asking the server for the correct url, as data, then show that view on the client? 

Or, you could ask the server for rights infos, and have the knowledge of which view that implies for a given requested url on the client. Personally, that sounds like a business rule, and I want those on the server, among other reasons so they can apply to other clients besides this web app. You really want that if you expose your API publicly, and the ability to do that is a real business advantage.

In any case, anyone can navigate a browser or http-aware code to any url they want, from browser history on someone else's computer, something they read on the net about your app, guessing, whatever. You can't rely on what your client-side code does to secure anything. I know I keep saying this, but it's up to the server not to return any data or perform any actions not allowed by the system, for whatever reason.

Dave

[matthew...@gmail.com]

On Wednesday, January 9, 2013 11:40:59 AM UTC-6, Ryan Zec wrote:

Data is not an issue if you properly authenticated on the server (you should never send data to the data that use user should not be able to access).  If you really don't want to even have sections of the template to show up (even though I don't see how harmful it would be if they can't access the data), the only way I know around this is by servering the templates from the server

Yes, I understand about security. There are times when I do not want users to even be aware of the fact that there are additional sections of data that they are not seeing, nor do I want them to discover this by looking at the source.

This is a contrived example, but imagine an app that stores an "internal opinion" about customers. Security would dictate that customers would never see this data, of course, and it wouldn't exist in any service output or in the JSON model at all. But if a customer views the source and sees an "internal opinion" field in the template, which is hidden, they might question why the company is storing internal opinions. Especially in finance and other areas where privacy and security are very important, just knowing that data is being captured is a potential security risk.
 

(so you would have to have some server side language generate the Angular templates).

This is how I suspect it must go. Still generate templates using JSP using custom JSP tags and other tools to consider security and roles, such that what is sent to the client is a subset of what someone else might see. So Angular wouldn't be the only "view", and templates wouldn't always be static.

In fact, I can imagine a lot of cases where the template delivered to the client would vary greatly depending on business rules, roles, security, etc. So I still need a dynamic server-side component which is generating appropriate templates, which Angular then manipulates client-side in combination with the model.

Matt

[Joshua Miller]

Hello again!

If you are at location X in a large app, and you need to navigate to location Y without a round-trip, don't you need to have a controller in JS that knows which server-side resource to call to load the html and data? And doesn't your SPA need to know whether it needs to re-request the chrome around the body, in case you are navigating into a section that has a different layout, with different menus, etc? The brains for all of that deciding typically lives on the server, because it's complicated. If you want to be a SPA, how do you handle it?

Angular has routing built in. You define in advance the routes you want to handle (which are stored in the location hash) and specify what you want to do in each case. Each route can have a template (which can be composed of more partials, multiple controllers, etc.). So if you're at one part of the application and the user clicks a menu item to take them to another, the elements of the page that need to will change - but Angular does that for us. So that part's easy. 

As for your knowing which server-side resources to call, yes - your code does include that. In that case, we define Angular services (that are reusable components) that we can inject into any controller that needs it. So if we have a list of items, the controller of that will request the service, and call whatever methods are necessary. The service will connect to the server API and handle the response, basically.

You are right that this stuff _used_ to live on the server, but most new apps these days pass that on to the client. Javascript MVC frameworks (like Angular and Backbone) are built to do this because, as Dave said, it usually creates a better user experience.

I think I may have also found the source of some of the confusion. In a typical server-side app, each page we render has a single controller. In client-side apps, controller-to-view is not necessarily 1:1 and for complex apps almost never is. To create reusable components, each little piece of the page can have its own controller, if it needs one. And we can create directives to extend HTML. Etc. So controllers get nested. Your main route has a controller, but chances are it doesn't do a whole lot, because the view associated with it defines sections of the page pull in. For example, a menu section can be "included" as a partial with a reference to its own controller. Angular handles separation of concerns so that your higher-level, route-based controller and view don't need to know anything about the menu - other than it exists. This is what I meant a few posts ago when I said I didn't like big controllers.

Hope this helps!

Josh

--

[Joshua Miller]

Blast! You guys are replying to quickly! 

The current version of Angular does _not_ support dynamic server-side templates. If you search this group, you'll find some workarounds some people have done, but it's often not pretty.

That said, it's not that necessary in most cases. If you use angular properly, the user shouldn't be able to tell (even with a View->Source) the parts of the page they can't see. It is client-side, and it _may_ have been downloaded, but are we really worried that someone will dissect the browser cache and reverse-engineer your source code to try to hypothesize about what fields may not be shown? Since it's not a security issue (because it's a template and not the data), I don't really see a problem here. Perhaps someone has a better example, though.

Josh

[matthew...@gmail.com]

On Wednesday, January 9, 2013 12:38:09 PM UTC-6, Joshua Miller wrote:

Angular has routing built in. You define in advance the routes you want to handle (which are stored in the location hash) and specify what you want to do in each case. Each route can have a template (which can be composed of more partials, multiple controllers, etc.).

Okay, so if an existing app has 1,000 unique url's that are used to access it and view different pages, I need to define those 1,000 routes in javascript, along with mapping them to resources and templates, and deliver that big mess of routing logic to the client? Since a user may jump around to any of the 1,000 url's via links in the app, I have to be prepared for any url they click on, so I can handle it internally, right?

That's the part I don't get. Are you proposing that we deliver this big mess of routing logic to the client at the beginning? Or is there an alternative?

Matt

[matthew...@gmail.com]

On Wednesday, January 9, 2013 12:44:03 PM UTC-6, Joshua Miller wrote:

The current version of Angular does _not_ support dynamic server-side templates.

I'm not sure what this really means. How would it _not_ support them?
When it requests HTML from the server as a template, it has no idea if it's a static file or being generated dynamically.
If I tell Angular to load template "my_profile.html", I could generate that dynamically using any technology I want.
Is there some reason why Angular would refuse to load "my_profile.php" and handle the returned HTML?

That said, it's not that necessary in most cases. If you use angular properly, the user shouldn't be able to tell (even with a View->Source) the parts of the page they can't see. It is client-side, and it _may_ have been downloaded, but are we really worried that someone will dissect the browser cache and reverse-engineer your source code to try to hypothesize about what fields may not be shown?

Yes. In some cases, like financial applications, this is a concerns.
 
Matt

[Pawel Kozlowski]

Hi Matt,

On Wed, Jan 9, 2013 at 7:53 PM, <matthew...@gmail.com> wrote:
> Okay, so if an existing app has 1,000 unique url's that are used to access
> it and view different pages, I need to define those 1,000 routes in
> javascript,

Are those URLs following any pre-defined patterns? Sth like
/myapp/[category id]/[product id] ?
I'm asking since you can define variables in AngularJS routes.

But yeh, if each and every route is totally unique and they don't
share any common pattern you will have to define it "by hand".

[Pawel Kozlowski]

Hi!

On Wed, Jan 9, 2013 at 7:57 PM, <matthew...@gmail.com> wrote:
> I'm not sure what this really means. How would it _not_ support them?
> When it requests HTML from the server as a template, it has no idea if it's
> a static file or being generated dynamically.
> If I tell Angular to load template "my_profile.html", I could generate that
> dynamically using any technology I want.
> Is there some reason why Angular would refuse to load "my_profile.php" and
> handle the returned HTML?

Of course, AngularJS will download and use a template whatever is
exposed under a certain URL. I guess there are just 2 remarks here:

1) It means that you would have to load all the partials "on the fly".
For performance reasons it is a common practice to pre-load all the
partials in one of the first requests. So this is just something to
measure and take into account as a user will be waiting longer for
partials being downloaded and a browser will have to work harder
issuing multiple HTTP requests.

2) AngularJS is caching all the downloaded partials by default. So if
you will potentially need to clean up this cache if you need to allow
people to change a profile, sign-in as a different user etc. (without
refreshing the whole app in a browser).

[matthew...@gmail.com]

On Wednesday, January 9, 2013 1:08:04 PM UTC-6, Pawel Kozlowski wrote:

1) It means that you would have to load all the partials "on the fly".
For performance reasons it is a common practice to pre-load all the
partials in one of the first requests.

Ah, I didn't realize this. That would never work in a large app with hundreds of screens or more, obviously. There's no way you could pre-load templates for 500 complex screens in any efficient way.
So my assumption all along was to load partials "on the fly". Even with a slight request delay, the re-paint would be faster than a full round-trip.
 

2) AngularJS is caching all the downloaded partials by default.

I also hadn't learned that yet, good to know. In many cases, I would need to invalidate the cache, then.

Matt

[Ryan Zec]

On Wed, Jan 9, 2013 at 1:44 PM, Joshua Miller <jo...@joshdmiller.com> wrote:

That said, it's not that necessary in most cases. If you use angular properly, the user shouldn't be able to tell (even with a View->Source) the parts of the page they can't see. It is client-side, and it _may_ have been downloaded, but are we really worried that someone will dissect the browser cache and reverse-engineer your source code to try to hypothesize about what fields may not be shown? Since it's not a security issue (because it's a template and not the data), I don't really see a problem here. Perhaps someone has a better example, though.

Kind of.  One thing you can use it ng-switch as ng-switch will only render the element that matches and not render anything else (unlike ng-show/ng-hide which just hide the element using css).  I have also copied the if directive from the angular jquery mobile adapter for this purpose too (which to me just make for a cleaner way to either render something or nothing at all), https://github.com/tigbro/jquery-mobile-angular-adapter/blob/master/src/main/webapp/utils/if.js

The issue with both of those is that while it prevents users from seeing stuff they should not with View -> Source, it does not prevent it from Inspector -> Network.  Inspector -> Network will let you see the template raw which will include anything.  While I might agree I have never had a use case where showing the template without the data would be a major issue, I can see why some people or some use cases might have an issue with that.

[matthew...@gmail.com]

On Wednesday, January 9, 2013 1:01:41 PM UTC-6, Pawel Kozlowski wrote:

Are those URLs following any pre-defined patterns? Sth like
/myapp/[category id]/[product id] ?
I'm asking since you can define variables in AngularJS routes.
But yeh, if each and every route is totally unique and they don't
share any common pattern you will have to define it "by hand".

No, they don't follow such patterns. They are distinct screens with different content.
Since it seems unreasonable to me to have all of this routing in the client, I will explore alternate solutions.

The idea of mini-SPAs per section is sounding even better, because I can easily load all the routing needed for a given section and it's 10-20 sub-tabs. But when the user navigates away from that section, I can go back to the big beefy controller on the server to decide what to serve up next.

Matt

[Pawel Kozlowski]

Hi!

On Wed, Jan 9, 2013 at 8:16 PM, <matthew...@gmail.com> wrote:
> The idea of mini-SPAs per section is sounding even better, because I can
> easily load all the routing needed for a given section and it's 10-20
> sub-tabs. But when the user navigates away from that section, I can go back
> to the big beefy controller on the server to decide what to serve up next.

IMO this is a very reasonable approach. I've seen / worked on a huge
app (1000+ screens, mostly lists and forms of various complexity) that
was done as SPA. From the time perspective I would sub-dived this into
several (10-20) SPAs. But then again. each app is a bit different....

Cheers,
Pawel

[Joshua Miller]

Just out of curiosity, what application are you developing that requires 1000+ unique routes? And what kind of financial application is the same for both internal and external users?

[matthew...@gmail.com]

On Wednesday, January 9, 2013 1:32:29 PM UTC-6, Joshua Miller wrote:

Just out of curiosity, what application are you developing that requires 1000+ unique routes? And what kind of financial application is the same for both internal and external users?

Well, I can't go into any specifics, of course. :)
When a person has a huge amount of complex data, the webapp to manage, update, and report on that data becomes quite a monster.

Matt

[Joshua Miller]

Analytics and business intelligence applications are actually my specialty. What surprised me was the number of _unique_ routes. Using client-side visualization and a graph-centric backend, we're usually able to make this very manageable while still being very flexible and powerful - on the order of a few dozen routes as opposed to hundreds or thousands.

Josh

[Anders Hessellund Jensen]

1) What is the adoption of Angular like?

Regarding that, you might want to check out google trends:

 http://www.google.dk/trends/explore#q=angularjs%2C%20knockoutjs%2C%20backbonejs%2C%20emberjs&cmpt=q

[Peter Bacon Darwin]

Nice!

--

[Giuseppe]

Hello everyone. Very interesting discussion, this one going on... apart from the "I've done this. I've done that" parts ;) ;).
I'm in the process of starting a (hopefully modern) web app from scratch, and I'm considering AngularJS. Actually I've started considering some JS client framework, and now I'm almost certain it will be Angular.

I think I understand many good questions posted by Matt regarding a more complex app (whether fairly more or just more than a single-entity CRUD). I'll try to add my clarifications and a little bit of my thinking aloud, in the hope it helps the discussion.

For the sake of reasoning, I'm thinking of a web app to manage Customers, Orders, Offers, ... Say you think that each one of those functional areas should be kept separate from the others (i.e. not in the same single SPA) because they have a lot of code, lot of functionalties, whatever.

The app will have some Login-related functionalities, a NavBar on top within "the shell", some user information & settings also available from the shell.

At least, user info and NavBar will depend from user roles and security. There's more, that will come in the way later.

To reach one of those functional areas, the app will need a client-server round trip. The round trip will return a page with the needed Angular JS logic.

The page, generated server side by some language, contains the (Angular) shell controller/view/component/directive/partial/..., and its sub-controllers for NavBar and User info. Being server side generated, security and roles for them is sorted.

And if for some reason the NavBar is not generated server-side, but it is controlled client side, its Angular controller can still fill the bar asking the server which sections to put into.

Then the main content, say the customer list. The rendered page contains an Angular controller/view/... that handles the presentation of this data. Typically the rows available to the user and the columns will depend from roles, security, etc. Of course Angular controller can ask the rows to the server API. In order to keep up with roles & permissions, also the *columns* should come from the API.
I guess here on this last bit is where it gets tricky. Typically, the Angular view "template" would contain all columns, with their styles, HTML structures, etc ... and then based on Biz logic some of them should be hidden from user eyes. But still the column is present somewhere inside the view, at least before Angular hides or remove that.

To my understanding of what Matt says, instead, he does not even want those columns to be present at all in the view (I said "template" before, as that's very close to other JS templating frameworks). 

The first idea coming to mind is not to ask for data, but to ask for something that in the end is a "partial" view. In this case, a list with the pre-formatted HTML/CSS bits comprising the Customer list. But that sound very bad to me, very non-REST, very non-SPA, etc ...

The other way should be something like ask the server for view "template" on the fly, which I think someone else has already mentioned in the discussion, and if I'm not wrong is not supported by Angular (and probably nor from many other JS frameworks).

Ok. Does the road end here?

[Saurabh Nanda]

In fact, I can imagine a lot of cases where the template delivered to the client would vary greatly depending on business rules, roles, security, etc. So I still need a dynamic server-side component which is generating appropriate templates, which Angular then manipulates client-side in combination with the model.

Not only security, but also efficiency. If there are large portions of the app that the current user can't interact with, why would you want to send the view, controllers, & services related to those portions down to the user's browser?

Saurabh.

[Mark]

Great thread! I just wanted to add one thing on security we are currently working on. We are prototyping for an enterprise SPA supporting mainly forms, and our customers can choose to hide, or make read-only, every field in the app, against user-type down to individual user. 

So we are experimenting with sending self-describing data including field type and label, mandatory information, read-only flags, validation rules etc. This then gets transformed with nested directives into the resulting view. If a field is to be hidden it just doesn't get sent by the server. Performance seems good at the front-end, the challenge for this part of the app is at the back end - mark