Angular 로드맵 - Angular의 과거와 현재, 그리고 미래 > 시티즌 인사이트

본문 바로가기

시티즌 커뮤니티

시티즌 인사이트

IT&개발 정보 Angular 로드맵 - Angular의 과거와 현재, 그리고 미래

페이지 정보

작성자 GrapeCity 작성일 20-09-22 09:28 조회 144회 댓글 0건

본문

Angular 로드맵 - Angular의 과거와 현재, 그리고 미래


구석기 시대의 JavaScript - SproutCore

태초에 SproutCore가 있었습니다. SproutCore는 데스크톱 수준의 단일 페이지 웹 앱을 쉽게 빌드하기 위한 최초의 종합적인 JavaScript 프레임워크였습니다. 그 이전에도 이런 작업을 할 수는 있었습니다. Google은 Gmail을 출시함으로써 웹 앱이 복잡한 데스크톱 응용 프로그램을 대체할 수 있다는 사실을 만천하에 보여 주었습니다. 심지어 Google은 Gmail을 구축하는 데 사용했던 라이브러리 집합과 최적화 컴파일러를 담은 Closure Tools도 오픈소스로 만들었습니다. 

문제는 Google의 Closure Tools가 개발자에게는 그다지 편하지 않았다는 점입니다. Closure Tools는 Java에 대한 의존성이 너무 높았기 때문에 JavaScript, PHP, Ruby, Python으로 작업하던 웹 개발자들은 고립 상태에 처하게 되었습니다. Gmail은 가능성을 보여 준 훌륭한 사례였으나, 그와 유사한 응용 프로그램을 개발하는 것은 불가능하다고 생각하는 사람들이 많았습니다.

몇몇 용감한 개발자들이 jQuery를 겹겹이 이어 붙여 놀라운 단일 페이지 응용 프로그램을 가까스로 엮어낸 적은 있습니다. 이러한 앱은 최종 사용자의 눈에는 훌륭해 보였지만, 이를 관리하는 개발자 입장에서는 기술적인 문제가 급격하게 누적되었기 때문에 개발 팀이 아침에 출근하기를 두려워하는 지경이 되었습니다.

이에 따라 추진력 있는 개발자들이 전 세계 웹 개발자가 쉽게 사용할 수 있고 Gmail과 비슷한 응용 프로그램을 만들 수 있는 프레임워크를 구축하기 시작했습니다. 이러한 프레임워크 중 처음 등장한 제품이 바로 SproutCore였습니다. SproutCore는 완벽한 위젯 모음을 제공했기 때문에 HTML 또는 CSS를 전혀 사용하지 않고도 복잡한 웹 응용 프로그램을 빌드할 수 있었습니다.

웹에서 힘겹게 작업을 하던 이전의 데스크톱 개발자들에게는 굉장한 이점이었습니다. 한편 비슷한 목표로 제작된 프레임워크가 몇 개 더 등장했는데, 그중에서 GWTCappuccino가 가장 유명했습니다. 이러한 프레임워크에서는 JavaScript 대신 다른 언어를 JS로 변환하여 사용할 수도 있었습니다. 다시 한번 말하지만, 데스크톱 개발자에게는 매우 유용한 프레임워크였습니다. 하지만 이 프레임워크로 인해 열정적인 웹 개발자들은 겉도는 기분이 들었고 어렵게 익힌 HTML, CSS, JavaScript 기술은 쓸모없는 것처럼 느껴지곤 했습니다.

결국 웹에 덧칠해서 마치 다른 물건인 것처럼 만드는 대신 진정한 웹 개념이 적용된 프레임워크가 태동하게 되었습니다. 당시 선보인 몇 가지 초기 프레임워크(Backbone 및 Knockout)는 어느 정도 성공적이었습니다. Ember도 이 시기쯤 나타났습니다. Ember는 SproutCore를 낱낱이 분해한 뒤 정말로 웹 친화적인 프레임워크로 다시 만들어 내려 했습니다. Ember는 더 강력하고 빠르게 재구성된 JavaScript 세계의 아이언 맨이 되고자 했습니다.

하지만 이들 중 어떤 프레임워크도 인기를 얻지 못했습니다. 세상은 더 좋은 프레임워크를 기다리고 있었습니다. 그리고 2010년, 마침내 더 향상된 프레임워크인 Angular가 등장했습니다.


Angular의 전성기

Angular는 버전 1.0이 출시되기 전부터 프런트 엔드 개발 분야를 완전히 사로잡았습니다. 마침내 HTML을 가장 중시하는 사용하기 쉬운 JavaScript 프레임워크가 등장한 것입니다. 개발자와 설계자는 협업을 통해 멋진 단일 페이지 응용 프로그램을 빌드할 수 있게 되었습니다. HTML과 CSS를 문명 세계의 개발자라면 손도 대서는 안 되는 미개한 도구처럼 취급하던 기존의 프레임워크에 짜증과 불쾌감을 느끼던 설계자들은 안도의 한숨을 내쉬었습니다.

Angular를 처음 접한 개발자들에게 가장 먼저 마법처럼 다가온 기능은 양방향 데이터 바인딩이었습니다. 그 이전에는 대부분의 개발자가 WPF 및 Windows Forms 같은 데스크톱 프레임워크에서만 이런 종류의 데이터 바인딩을 구경할 수 있었습니다. 양식과 기타 UI 요소를 JavaScript 모델 개체에 바인딩할 수 있는 훌륭한 기능이었습니다. 양방향 데이터 바인딩은 과도하게 사용할 경우 성능 문제를 일으킬 수 있지만, 이를 분별력 있게 사용한 팀은 Angular로 복잡한 프런트 엔드 응용 프로그램을 훨씬 더 빨리 만들 수 있다는 사실을 알게 되었습니다.

Angular는 데이터를 HTML 요소에 쉽게 바인딩할 수 있다는 것 외에도 많은 장점에 힘입어 인기를 끌기 시작했습니다. 특히 재사용 가능한 HTML + CSS 구성 요소를 Angular 명령문으로 쉽게 만들 수 있었습니다. Angular 이전의 다른 JavaScript 프레임워크에도 이런 기능이 있었지만 이렇게 큰 인기를 끈 제품은 Angular가 처음이었습니다. 서버 측 프레임워크에서는 재사용 가능한 구성 요소를 오랫동안 사용해 왔습니다. 예를 들면 Rails와 Django의 ASP.NET 사용자 컨트롤과 부분 템플릿이 여기에 해당됩니다.

마지막으로, Angular는 프런트 엔드 개발 환경에서 종속성 삽입을 보편화했습니다. 종속성 삽입은 엔터프라이즈 응용 프로그램에서 오랫동안 널리 사용되었는데, 이것이 아마 JavaScript 환경에서는 인기를 얻지 못한 이유이지 않을까 싶습니다. 프런트 엔드 개발자들은 쓸데없이 복잡한 엔터프라이즈 소프트웨어 설계 패턴 같다면서 이를 오랫동안 배척했습니다. 이런 우려가 타당하지 않다는 뜻은 아닙니다. 응용 프로그램을 작성하다가 "지금 SimpleBeanFactoryAwareAspectInstanceFactory가 정말로 필요한 걸까?"라고 자문해 본 적이 있으십니까?

하지만 종속성 삽입은 그 가치가 검증된 기능입니다. 그리고 과거에는 종속성 삽입을 많이 사용하지 않던 사람들도 Angular 덕분에 이 기능을 쉽게 사용할 수 있게 되었습니다. HTTP 클라이언트가 필요하거나 애니메이션을 사용하고 싶을 때도 문제없습니다. Angular에는 이를 위한 기본 제공 서비스가 있고, 요청만 하면 Angular가 해당 구성 요소에 삽입해 줍니다. 아무것도 사용자가 직접 인스턴스화할 필요가 없습니다.

아니면 브라우저 밖에서 구성 요소를 계속 단위 테스트하면서 브라우저의 또는 위치 개체를 사용하고 싶을 수도 있습니다. Angular의 $window 및 $location 기본 제공 서비스는 바로 이런 기능을 지원합니다. 사용자가 원하는 브라우저 개체가 런타임 시 제공됩니다. 그리고 Node.js에서 서버 측 단위 테스트를 실행할 때 모의 서비스를 구성 요소로 전달하여 이러한 서비스가 다양한 시나리오에서 예상대로 동작하는지 확인할 수 있습니다.

이 모든 기능에 더하여, Angular에서는 사용자의 자체 서비스를 간단하게 등록하고 삽입할 수 있었습니다. 모든 데이터를 DOM에 바인딩하고 최상의 결과가 나오기만을 기도하던 개발자들에게는 정말 훌륭한 기능이었습니다. API를 호출하는 프런트 엔드 응용 프로그램을 새로 작성하는 경우, API 호출이 너무 잦으면 지출 비용이 늘어나므로 개발자라면 응용 프로그램이 Twilio API를 8억 번씩 호출하는 종류의 불상사를 미연에 방지하기 위해 미리 테스트를 준비하려 할 것입니다.

이에 따라 개발자는 런타임 시 삽입할 Twilio 서비스를 만들게 됩니다. 그리고 테스트 시간이 되면 개발자는 응용 프로그램이 시도하는 모든 API 호출의 비용을 기록하는 모의 서비스를 만듭니다. 그런 다음에는 일반적인 사용 시나리오에서 어마어마한 요금이 청구되는 일이 없도록 일반 사용 시나리오에 대한 테스트를 작성합니다. 결국 대부분의 개발자는 Angular 명령문과 종속성 삽입을 함께 사용하면 신뢰할 수 있는 소프트웨어 엔지니어링 기법으로 모듈식 프런트 엔드 응용 프로그램을 작성하고 테스트할 수 있다는 사실을 깨닫게 되었습니다. 많은 개발 팀에서는 이렇게 하면 만족스러운 결과를 얻을 수 있다고 판단하고 모든 작업을 Angular에서 해결하기로 했습니다.


Angular의 하락과 React의 부상

React의 부상

Angular 환경에서는 대부분의 기능이 만족스러웠지만 모든 것이 장밋빛은 아니었습니다. 개발자가 너무 많은 모델 개체를 너무 많은 DOM 요소에 바인딩하려고 하면 심각한 성능 문제가 발생하기 시작했습니다. 일부 응용 프로그램은 속도가 엄청나게 느려졌습니다. 적당한 수준의 성능을 얻으려면 $digest를 직접 호출하는 한편 다른 묘책도 사용해야 했습니다. 그즈음에 새로운 도전자가 나타났습니다. 바로 React였습니다. 처음에 React는 Angular를 크게 위협할 것 같지는 않았습니다. 그러나 React의 괴짜 개발자들은 코드에 마크업을 혼합하는 것 같은 방식으로 굳이 JSX를 발명해 내고야 말았습니다. 우리가 지금껏 템플릿 언어를 만드느라 고생한 것이 마크업과 코드를 혼합하지 않겠다는 바로 그 이유 때문이었는데 말입니다.

결과적으로 React의 접근 방식은 프런트 엔드 개발 커뮤니티에서 꽤 유명세를 떨치기는 했지만 대중적인 인기를 얻지는 못했습니다. 대세는 여전히 Angular였고, 상황은 그대로 계속될 것처럼 보였습니다. 갑작스러운 원인으로 인한 큰 실망감으로 Angular의 인기가 식어버리기 전까지는 말입니다. 원인 제공자는 바로 Angular 팀 본인들이었습니다.


Angular 2 출시

Angular 2는 2014년 ng-europe 컨퍼런스에서 처음 공개되었습니다. Angular 팀의 계획은 좋게 말해 Angular 커뮤니티에 충격을 선사했습니다. Angular 개발자들이 즉각적으로 부정적인 반응을 보인 데는 그만한 이유가 있었습니다. Angular 2에서는 Angular 1의 여러 가지 친숙한 개념을 배제하고 호환되지 않는 새로운 템플릿 언어를 도입한 데다가 완전히 새로운 언어로 프로그래밍해야 했습니다.


AngularJS

Angular 1과 Angular 2 모두 이름은 'Angular'였지만 이 둘은 몇 가지 공통점을 제외하면 사실상 크게 다른 프레임워크였습니다. 혼동을 피하고자 Angular 팀은 구 버전 Angular를 'AngularJS'로, 새 버전을 간단히 'Angular'로 부르기 시작했습니다. 그러나 AngularJS는 JavaScript로 작성되었기 때문에 이름이 직관적으로 와닿았지만 Angular는 그렇지 못했습니다. 두 프레임워크 간의 차이점을 뚜렷이 보여주기 위해 지금부터는 Angular 1을 AngularJS라고 부르겠습니다.

이 모든 사태의 장본인인 AngularJS 개발자들은 이 프레임워크의 미래에 대한 신뢰를 잃었습니다. 이들은 앞으로는 새 프레임워크로 전환해야 한다며 사용자들을 위협했고, 그에 따라 많은 사람이 정말로 새 프레임워크로 떠나 버렸습니다. AngularJS 이용자가 대거 이탈하자 React가 가장 큰 반사 이익을 누렸습니다.

React는 AngularJS만큼의 기능은 없었지만 어떻게 보면 이 점이 긍정적으로 작용했습니다. 개발자가 사용하는 보기 라이브러리에 꼭 필요한 기능만 담겨 있다면, 그 라이브러리의 개발자들 때문에 사용자의 계획이 어그러질 가능성은 굉장히 낮아지기 마련입니다. 처음에는 AngularJS에 비해 React를 사용하기가 꽤 불편했습니다. AngularJS에서는 기본 제공되던 기능을 사용하려면 라이브러리를 조각조각 이어 붙여야 했습니다.

하지만 많은 개발자는 이것이 위험을 줄일 수 있는 좋은 방법이라고 생각했습니다. 이렇게 하면 라이브러리를 만드는 개발자가 대대적인 변화라며 역호환도 되지 않도록 제품을 변경할 가능성이 낮아지기 때문입니다. 바로 Angular가 그랬던 것처럼 말입니다.


Vue의 출현

Angular 2를 둘러싼 사건이 한창 벌어지고 있을 때 Vue라는 프레임워크가 등장하면서 AngularJS의 비극적인 사태를 한층 더 악화시켰습니다. Vue는 AngularJS에서 영감을 받아 탄생했으나 Vue 개발자들은 이를 더 간소화하고 쓸데없이 복잡하다고 생각되는 요소를 제거했습니다. 따라서 기존의 AngularJS 개발자들에게 매우 친숙하게 다가왔습니다. Vue는 React로 바꾸고 싶지 않던 많은 AngularJS 개발자들에게 피난처가 되어 주었습니다.

물론 AngularJS 개발자들은 인내심을 가지고 Angular 2가 나오기를 기다렸습니다. 하지만 Angular 2 계획이 불투명해지자 AngularJS 사용자들이 React 및 Vue로 대거 이탈한 것만은 분명했습니다.


Angular 2로 부활

마침내 Angular 2가 출시되었습니다. 예상대로 Angular 2에는 AngularJS의 여러 가지 친숙한 개념이 빠져 있었지만, 서비스 및 종속성 삽입 같은 가장 좋은 몇 가지 기능은 그대로 남아 있었습니다. Angular가 원래 계획했던 분기 방식이 아니라 일반 TypeScript를 사용한다는 점은 개발자들에게 다행이었습니다.

하지만 Angular 팀에서 TypeScript 대신 Dart 프로그래밍 언어를 사용하는 새 프레임워크 분기를 그대로 유지하는 바람에 혼란이 가중되었습니다. 처음에는 단일 코드 기반에서 TypeScript 버전과 Dart 버전을 동시에 개발했지만 결과적으로 Angular TS 버전과 Dart 버전을 분리하기로 했고, Angular Dart는 현재 별도의 프레임워크입니다.

이러한 혼란에도 불구하고 Angular 2 출시 이후 Angular의 인기가 서서히 다시 높아지기 시작했습니다. 소프트웨어 개발 과정이 늘 그렇듯이, 트렌드는 변하기 마련입니다. 개발자들은 부가 기능이 포함된 대규모 프레임워크가 유용할 수도 있다는 사실을 깨달았습니다. 응용 프로그램의 규모가 확실히 커지면 결국 이런 부분이 실제로 필요해지게 됩니다.

특히 엔터프라이즈 개발자들이 Angular로 돌아가기 시작했습니다. 이것은 당연한 현상입니다. 일반적으로 엔터프라이즈 웹 앱을 시작하는 개발자는 일이 복잡해질 수밖에 없다는 것을 알게 됩니다. 응용 프로그램에 필요한 87가지 기능을 처음부터 다 알고 있는데 조그마한 MVP로 시작할 이유가 없습니다.


Angular 3의 현재 상황

Angular 2는 완벽하지는 않았지만, 복잡한 웹 응용 프로그램을 만드는 많은 개발자는 새롭게 개선된 Angular가 필요에 꼭 맞는 프레임워크임을 깨닫기 시작했습니다. 다행히 출시된 Angular에는 몇 가지 흥미로운 개선 기능이 포함되어 있었습니다. 무엇보다 Angular 팀은 버전 간에 큰 변화를 주지 않고도 새 버전의 프레임워크를 지속적으로 발표할 수 있다는 것을 보여 주었습니다.

당시에는 이상하게 보였지만, Angular 팀은 버전 3을 완전히 건너뛰고 버전 4로 넘어가기로 했습니다. 여기에는 그럴 만한 이유가 있었습니다. Angular 라우터 패키지가 이미 진행되어 버전 3이 출시된 반면, Angular의 나머지 부분은 아직 버전 2.3이었기 때문입니다. Angular 팀은 모든 Angular 패키지 버전을 한꺼번에 다음 버전으로 높이고, 다음 릴리스에서 모든 기능을 버전 4로 상향하는 것이 가장 쉬운 방법이라고 판단했습니다.


Angular 4

Angular 4에는 시간 컴파일 사전 추가를 비롯하여 몇 가지 중대한 변경 사항이 반영되었으며, 이로 인해 프로덕션 JavaScript 번들 규모가 작아졌고 응용 프로그램 로드 시간이 단축되었습니다. 그리고 서버 측 렌더링 지원이 추가되어 응용 프로그램을 미리 렌더링하고자 하는 경우 초기 로드 성능을 향상하는 데 큰 도움이 되었습니다. 이 밖에도 프레임워크 전반에 걸쳐 많은 개선 기능이 추가되었음에도 불구하고 Angular 2에서 4로 업그레이드하는 과정은 대부분 쉽고 원활하게 진행되었습니다.


Angular 4.3 및 Angular 5

Angular 4.3에는 기존의 HTTP 서비스보다 더 사용하기 쉬운 새로운 HTTP 클라이언트가 추가되었습니다. Angular 5에서는 기존의 HTTP 서비스가 사용 중지되었고 다음 릴리스에서는 삭제될 예정입니다. 이러한 불편에도 대부분의 경우 업그레이드가 간단히 완료되었기 때문에 불만은 거의 없었습니다. 또한 Angular 5에는 개선된 국제화 지원 및 더 많은 빌드 최적화 기능도 추가되었습니다.


Angular 6 및 7

Angular 6

Angular 6 및 7은 일부 개발자들에게 실망을 안겼습니다. 큰 변화는 없었지만 특히 Angular CLI 도구 등 삶의 질을 향상하는 소소한 변경 사항이 많았습니다. 눈에 띄는 변화가 줄었다고 해서 Angular 팀이 혁신을 멈춘 것은 아닙니다. 그 대신, 프레임워크의 성숙도가 무르익었으므로 개발 팀은 이제 보이지 않는 부분에 더 집중하면서 버그를 수정하고 성능을 개선하고 있습니다.

이 프레임워크가 안정된 것은 Angular 2 출시 이후로 기존의 AngularJS 개발자들이 다시 Angular로 돌아왔기 때문입니다. 그리고 엔터프라이즈 개발 팀에서도 이 프레임워크를 주목하고 있습니다. 수십 년간 가동할 엔터프라이즈 응용 프로그램을 빌드할 때는 예측 가능한 일정에 따라 새 릴리스를 출시하되 너무 빨리 변경되지 않는 프레임워크를 사용하는 것이 바람직합니다. Angular 2만 사용하던 개발자도 몇 분이면 Angular 7 응용 프로그램을 가동하고 개발 작업에 참여할 수 있습니다.


Angular 8 및 Angular Ivy

이 프레임워크는 이렇게 해서 오늘날에 이르렀습니다. 지금까지 살펴보았듯이, Angular는 많은 발전을 거쳤습니다. Angular는 웹 개발자들의 사랑을 받다가 질타를 받았고, 비록 초창기의 인기를 아직 완전히 회복하지는 못했지만 다시 신뢰를 회복했습니다.

이제 곧 Angular 8이 출시됩니다. Angular 8에서는 Bazel 빌드 시스템을 쉽게 사용할 수 있도록 대대적인 변화가 이루어졌으며, 이는 Google 외부에서 이 시스템을 사용하는 3곳의 개발사 모두에게 희소식이 아닐 수 없습니다. Angular 8 변경 사항을 읽어 보시기 바랍니다.

그러나 더욱 반가운 소식은 Angular 팀이 Angular Ivy라는 새로운 렌더러 개발에 박차를 가하고 있다는 것입니다. 이 제품은 현재의 렌더러를 바로 대체할 수 있도록 고안되었습니다. 대부분의 경우 현재의 응용 프로그램을 변경하지 않고도 Angular Ivy를 사용할 수 있습니다.

변경 없이 바로 교체 가능한 Angular Ivy 프레임워크를 개발자들이 주목해야 하는 이유는 무엇일까요? 속도와 번들 크기라는 두 가지 중요한 이유 때문입니다. 웹 개발자들은 이 문제로 수년간 골머리를 앓아 왔습니다. 개발 팀에서는 5MB, 10MB 또는 그 이상의 JavaScript 번들을 제공했고 그 정도면 충분하다고 생각했습니다. 그런데 과연 개발자의 i7 기반 MacBook Pro에서 완벽하게 작동하던 응용 프로그램이 모든 사용자의 환경에서도 똑같이 작동할까요?

안타깝게도 현실에서는 최고 사양의 최신 하드웨어를 사용하지 않는 사람들이 많습니다. 수백만 명의 인터넷 사용자들은 모뎀보다 약간 더 빠른 정도의 인터넷 연결 회선에 처리 용량이 감자보다 조금 더 큰 구형 Android 휴대폰에 의존하고 있습니다. 이들에게 거대한 JavaScript 번들은 로드 시간이 너무 오래 걸리고, 장치를 구문 분석하고 실행하는 데는 그보다 더 긴 시간이 필요합니다. 이보다 평범한 사례를 보더라도 최고 사양의 최신 하드웨어를 사용하지 않는 사용자는 전 세계에 수없이 많습니다. 이러한 사용자에게 대용량 JavaScript 앱은 무용지물이고 불편하기까지 합니다.


Angular Ivy

Angular Ivy 렌더러는 여러모로 유용합니다.

  1. 효율성에 중점을 두고 작성된 이 렌더러는 훨씬 더 적은 수의 CPU 명령으로 동일한 작업을 해냅니다. 따라서 배터리 수명이 증가하고, 성능이 떨어지는 장치를 사용하는 사용자의 스트레스도 줄어듭니다.

  2. 이 렌더러는 기존 렌더러보다 훨씬 더 모듈에 가까운 방식으로 작성됩니다. 따라서 트리 쉐이킹 및 구형 코드 제거 작업이 훨씬 더 쉽습니다. 결과적으로 현재의 렌더러가 종종 그렇듯이 온갖 기능을 번들에 담는 대신 응용 프로그램을 실행하는 데 필요한 코드만 개발자의 프로덕션 JavaScript 번들에 포함됩니다.

  3. Angular Ivy에는 작아진 번들 크기와 빠른 렌더링 속도 외에도 Angular 개발자를 위해 삶의 질을 높여주는 또 다른 개선 기능이 있습니다. 다시 빌드하는 시간도 대폭 단축됩니다. 개발 모드에서 응용 프로그램을 실행하고 변경 사항이 나타날 때까지 기다리는 시간이 훨씬 더 짧아졌습니다.

  4. 템플릿 유형 확인 기능이 개선되어 런타임이 아니라 컴파일할 때 더 많은 오류를 포착할 수 있습니다. 런타임 템플릿 버그는 매우 거슬리는 문제입니다. 테스트 중인 개발자에게도, 응용 프로그램을 사용하는 사용자에게도 문제가 되기 때문입니다.

  5. 현재의 보기 엔진 컴파일러와 달리 Angular Ivy 템플릿 컴파일러는 사람이 판독 가능한 코드를 생성합니다. 이 기능은 까다로운 템플릿 버그를 추적할 때 매우 편리합니다.

간단히 말해 응용 프로그램의 크기가 작아지고, 속도가 빨라지고, 개발자의 만족도가 높아지며, 사용자는 더 행복해집니다.

Angular 9

다음은 Angular 9 개요입니다.

주요 내용은 다음과 같습니다.

  • 기본 제공되는 Angular 기능

  • Angular로 정교한 개발

  • Angular 보기 엔진 이해

  • Angular Ivy로 고질적인 문제 해결

  • Angular Ivy와 모바일

  • 선택하지 않아도 되는 명령문

  • 개선된 Angular 진단 기능

  • Angular Ivy의 국제화

  • Angular 9의 DI 및 형식 안전성

  • Angular Core의 종속성 삽입 변경 사항

  • Angular 벤치마크(Angular 8.2.7 vs. 9.0.0-next.5)


Angular 10

Angular 10의 새로운 기능

2020년 6월 말에 Angular 버전 10.0.0이 출시되었습니다. 주요 릴리스인 Angular 10에는 Angular Material의 새로운 날짜 범위 선택기, TypeScript 버전 업그레이드, 라이브러리 버전 업데이트 등의 변경 사항이 포함되어 있습니다.

새로운 기능은 다음과 같습니다.

  • Ngtsc 컴파일러 인터페이스

  • 비동기 타임아웃 구성

  • 부실한 잠금 파일 보고

  • basePaths의 지연 계산

  • 번역 파일 병합

  • 명시적 매핑


Angular의 과거와 현재, 그리고 미래

초창기부터 지금까지 Angular를 사용해 왔다면 함께 축하해 주십시오. 그동안 불완전한 패치도 많았지만, 마침내 빠르고 현대적인 프레임워크를 재미있게 사용할 수 있게 되었습니다.

React, Vue, 아니면 다른 프레임워크로 바꾸셨던 AngularJS 개발자라면 Angular를 한 번만 더 바라봐 주시기 바랍니다. 현재의 프레임워크를 그대로 사용하기로 한다 해도, 시간을 들여 살펴볼 가치가 있을 것입니다.

Angular를 한 번도 사용한 적이 없다면 이번 기회에 도전해 보십시오.

지금까지 Angular의 과거와 현재, 그리고 미래를 훑어보았습니다. 이 제품은 상당한 격변을 거쳐 왔습니다. Angular를 사용하는지 여부와 관계없이 재미있게 읽으셨기를 바랍니다.

현재 어떤 프레임워크를 사용하고 있으며 그 이유는 무엇입니까? 질문이나 의견이 있는 경우 아래에 입력해 주시기 바랍니다.


프레임워크를 가리지 않는 UI 구성 요소를 찾고 계십니까?

GrapeCity는 데이터 그리드, 차트, 게이지, 입력 컨트롤을 비롯하여 완벽한 JavaScript UI 구성 요소를 보유하고 있습니다. 이와 함께 매우 효과적인 스프레드시트 구성 요소 제공합니다. 당사는 Angular(React 및 Vue도 포함)에 대한 심층적인 지원을 제공하며, 최신 JavaScript 프레임워크에서 사용할 수 있도록 구성 요소를 확장하고자 최선을 다합니다.


  • 페이스북으로 공유
  • 트위터로  공유
  • 구글플러스로 공유
  • 카카오톡으로 보내기

댓글목록

등록된 댓글이 없습니다.

그레이프시티 홈페이지를 통해 제품에 대해서 더 자세히 알아 보세요!
홈페이지 바로가기

인기글

더보기
  • 인기 게시물이 없습니다.
그레이프시티 홈페이지를 통해 제품에 대해서 더 자세히 알아 보세요!
홈페이지 바로가기
이메일 : sales-kor@grapecity.com | 전화 : 1670-0583 | 경기도 안양시 동안구 시민대로 230, B-703(관양동, 아크로타워) 그레이프시티(주) 대표자 : 허경명 | 사업자등록번호 : 123-84-00981 | 통신판매업신고번호 : 2013-경기안양-00331 Copyright ⓒ 2020 GrapeCity inc.