controllerAs in AngularJS 1.5: Is it Enough to Prevent Accidental Public Access?

Objective

The goal is to evaluate whether using the controllerAs syntax in AngularJS 1.5 sufficiently restricts template visibility of internal controller state, thereby preventing accidental public exposure of $scope internals.

Context & Constraints

AngularJS 1.x templates can read any property on the scope chain. When a controller assigns data directly to $scope, that data becomes implicitly public to all descendant scopes through prototypal inheritance. The documented controllerAs pattern exposes only properties explicitly attached to the controller instance (via this), which is intended to make the public surface explicit. However, the controller instance itself remains accessible, and any property on it is template-visible. Nested child scopes can still reference the controller instance through the alias, potentially revealing internal state if not carefully managed.

Unresolved Decision

While controllerAs offers a clearer public API, the community has not reached consensus on whether this pattern alone is a robust safeguard against accidental public access, or whether stricter encapsulation (e.g., the component() style with isolated bindings) should be the default approach before migrating to Angular (2+).

Key Questions

• Does controllerAs alone effectively limit template visibility of internal controller properties compared to direct $scope assignments?
• Can nested child scopes still access properties defined on the controller instance via the alias, and does this pose a risk of accidental exposure?
• Should teams adopt the component() style with isolated bindings as the default encapsulation mechanism in AngularJS 1.5, or is controllerAs sufficient for most use cases?