A framework name can suggest a much smaller change than the one underneath it. Angular 2 is a good example to look back at: moving from AngularJS was not simply a matter of learning a few renamed methods.
The more interesting lesson for me is what happens when the underlying way of organising an application changes. I have to stop translating every unfamiliar feature back into the old system long enough to understand the new system on its own terms.
A change in structure, not just syntax
Angular 2 brought a component-based approach with templates, services and dependency injection into a different architecture from AngularJS. TypeScript became a central part of the normal development experience.
That asks more of someone than changing a few expressions in a template. It means understanding where data belongs, how behaviour is divided and which parts should be shared across the application.
I find those questions interesting because they overlap with design. A clear interface usually depends on a clear understanding of the records, relationships and permissions behind it. If those ideas are confused, a framework can organise the files without resolving the confusion.
Give a component a boundary
A small example from the Angular 2 style illustrates the separation:
import { Component, Input } from '@angular/core';
@Component({
selector: 'project-summary',
template: '<h2>{{ title }}</h2><p>{{ status }}</p>'
})
export class ProjectSummaryComponent {
@Input() title: string = '';
@Input() status: string = '';
}This is a component definition, not a complete runnable application. It needs the surrounding Angular module and bootstrap setup. Its job is to display two inputs. It does not also decide how every project in the system is fetched or saved.
The explicit inputs make the boundary visible. I can ask whether the component has the information it needs without beginning in the application's transport layer.
Keep shared work out of the template
A service gives shared behaviour a separate home. That can be useful for requesting records, handling a common operation or keeping a particular piece of application logic consistent.
I want the service boundary to represent a real responsibility. Putting miscellaneous functions in a file called service does not make the architecture clearer. The same problem exists with components: the useful part is deciding what belongs together, not merely increasing the number of files.
Dependency injection also changes how I think about testing. If a component receives a service through an explicit dependency, I have a clearer place to substitute controlled behaviour while checking an interaction.
Learn the path of one piece of data
When examining an unfamiliar framework, I prefer one small journey to a tour of every feature. Where does a record enter the application? What validates it? Which component presents it? What happens when someone changes it and the save fails?
That gives me a route through the architecture. It also exposes things a successful first render will not show, such as loading, errors, empty states and authority to perform an action.
I would keep that exercise separate from rewriting an existing website. Learning a tool and committing a client project to it are different decisions, with different costs if an assumption turns out to be wrong.
What stays useful after the release changes
Angular has continued beyond version 2. I would not treat this older release as a current recommendation for a new project. Its value here is the architectural shift it represents and the reminder that a familiar product name does not remove the need to learn carefully.
For me, the useful skill is being able to explain a framework's choices, then decide whether those choices fit the work. That is more durable than being quick at reproducing a setup without understanding what each part is responsible for.
Further reading
Angular's retained version 2 architecture guide explains the component, template and service boundaries. For a different approach to those questions, see my reflection on React components.