Angular js 1.x의 한계와 Angular 2로의 변화
Angular js 1.x의 한계
먼저 Angular js1.x의 한계는 아래와 같다.
간단하게 말해서, 구글팀이 Angular 1.x를 맡은 이후, 개발자들이 원하던 최신 기법을 Angular에 도입하려고 하면서 Angular 1.x를 재작성할 수 밖에 없었다. 일부를 살펴보자면,
- Angular 1.x는 서버렌더링을 할 수 없다.
- Angular 1.x 코드는 네이티브 코드로 변환할 수 없다.
- 어떤 환경에서는 잘 동작하지 않기도 한다.
Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.
Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.
-
- Angular js 1.x는 서버 렌더링을 할 수 없다.
- Angular js 1.x는 네이티브 코드를 변환할 수 없다.
- 어떤 환경에서는 잘 동작하지 않기도 한다.
Angular js 1.x는 DOM을 처리하는 과정에서 그 기능을 확장하는 방식이었는데, 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것 만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 따라서 Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.
Angular 2
Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.
Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.
Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.
Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.
Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.
Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.
Angular 2가 만들어진 것은 위에 있던 이유 외에 $scope 를 없애려는 것도 있었다. $digest 사이클을 통한 값 변경 체크 방식은 항상 성능의 약점으로 꼽혔기 때문에, 값 변경 체크 방식을 $digest 사이클 밖으로 빼내려고 했다. Angular 1.x의 코드 구조는 몇몇 중요한 이슈로 인해 그대로 사용하기 어려웠고 이후 버전을 위해 바뀌었다고 한다.
이러한 과정 때문에 Angular 2가 등장하게 된다. Angular2를 사용하면서 우리는 크로스 플랫폼의 렌더링 스케일 확장 문제, 속도, 성능 등 모든 것을 자유롭게 사용할 수 있다.
결론은 Angular js 1.x에서 Angular 2로 변하면서 코드를 재 작성했다고 할 정도로 크게 내용이 바뀐다. 새로운 개발 언어를 사용하거나 컴포넌트의 구성 방식이 바뀌고, 아키텍처, 사용하는 툴도 모두 다르다.
SemVer와 큰 변화(Breaking Changes)
Angular js 1.x
Angular 1.x는 몇 년 동안 수많은 버전들과 수많은 큰 변동 사항이 있었다. 1.x 변경 이력은 Angular js 1.x Github에서 찾아 볼 수 있다.
Angular 2와 Angular 3
이미 Angular 4가 나온지는 두 달이 다 되어간다.
나도 그랬지만 다른 분들도 처음엔 많이 혼란스러웠다고 한다.
먼저 Angular 2는 완전히 새로운 패러다임을 도입하기 위해 만들어졌다. 오프라인 컴파일이나 다른 렌더링 방식, 그 이외에 수많은 개선점들을 위해서 말이다.
Angular js 1.x는 기존의 DOM을 기반으로 하기 때문에 DOM이 로드될 때까지 기다리고, 거기에 뭔가를 붙이는 방식으로 동작했다. Angular 2는 반대로 프레임워크로서 템플릿에 대한 온전한 조정 권한을 갖고, 심지어 DOM을 만나지 않더라도 변화 자체를 처리한다.
(Angular js 1.x도 Angular 2도 써보지 않았지만 많은 변화가 있다는 것은 딱 봐도 알 것 같다.)
이 말이 무슨 뜻인지 설명하는 가장 간단한 예제는 컴포넌트가 DOM에 붙기 전에도 처리되는 클릭 이벤트가 있으며, 최종적으로 만들어진 DOM에서 (click)="fooFn()"과 같은 코드를 볼 수 없는 이유는 Angular 2는 자체적으로 이런 이벤트를 연결하고 처리하기 때문이다.
Angular 2 코드의 절반 정도는 내부 컴파일러가 차지하고 있다.(여기서 봐도 기존 DOM에 여러 기능들을 붙혀 사용하던 방식과 다르다는 것을 알 수 있다.)
초기 로드 시점의 성능 향상을 위해 지연 로딩 모듈을 사용하면서 "Ahead-of-Time"이라 불리는 컴파일 방식을 사용하는데, 이 때 사용하는 컴파일러다.
AoT 컴파일 방식을 사용하지 않고 'Just-in-Time" 컴파일 방식을 사용한다면 브라우저로 넘겨야 하고 이러면 전송되는 코드가 많아질 것이다. AoT 접근 방식은 React의 JSX와도 비슷한 점이 있는데, 결국 전처리의 문제다.
Angular 2의 코드 빌딩 방식은 Ahead-of-Time 방식으로 미리 전부 패키징하는 방식과 Just-in-Time 방식으로 필요할 때 필요한 모듈을 패키징하는 방식이 있다. 실제로는 같은 컴파일러를 사용하지만 타이밍과 활용 방식에 따라 구분한다. 클라이언트 입장에서 AoT 방식에서는 전체 코드를 다운 받아 오프라인에서 미리 렌더링하고 화면에 표시할 수 있고, JiT 방식에서는 필요한 라이브러리가 있을 때 해당 모듈을 컴파일해서 사용한다. (생각보다 복잡해보인다. 초보자로서는 대충 알듯 말듯하지만 직접 코딩을 해봐야 그 케이스를 알듯싶다.)
실제 버저닝
(Angular js 1.x에서 2로, 2에서 3, 4로 버전이 바뀐 진짜 이유)
일단. 구글의 버저닝 정책은 이렇다.
Angular 1.x에서는 버저닝 방식이 이랬다.
-
- Angular 1.0
- Angular 1.1 -1.2 지원을 위한 이전 버전
- Angular 1.2
- Angular 1.3 - IE8 지원 중단
- Angular 1.4
- Angular 1.5
Angular 2에서는 이렇다.
-
- Angular 2
- Angular 3
- Angular 4
- Angular 5
- Angular 6
- Angular 7
여기서 보면 알 수 있듯이 실제 코드나 구조의 변화와 관계 없이 Angular js 1.x와는 버저닝 전략 자체가 다르다. 구글 팀에서는 이 방싞이 좀 더 알아보기 쉽고, 명확하고, 코드 업데이트에 좀 더 나은 가이드를 줄 수 있다고 판단했기 때문에 이런 버저닝 전략으로 바꿨다고 한다.
Angular 2에서부터 SemVer를 따르면서 버전을 사용하는 철학이 달라지게 되는데, Major, Minor, Patch로 구분하는 SemVer에서 Angular가 2가 됐든 3, 4가 됐든 Major 버전이 바뀔 뿐 이라고 한다.
