4

이제와서 jQuery를 쓰면 안되는 이유 part 2

[이제와서 jQuery를 쓰면 안되는 이유]가 이제와서 흥하고 있어서 2부를 써봅니다. 1부에서는 jQuery의 DOM 관리 문제에 대해 썼는데, 2부에서는 현재 jQuery에 어떤 이슈가 있는지 정리해보겠습니다.

jQuery의 이슈들

1. 사이즈가 크다.
jQuery 1.12.4 minified버전은 95K이고 압축하면 34K정도 됩니다. 크다면 크고 작다면 작은 사이즈입니다. 몇년전까지만해도 핸드폰의 사양이 낮아서 문제가 컸는데, 요즘은 그 정도는 아닙니다. 게다가 React나 Angular같은 라이브러리는 훨씬 더 크니 사이즈로 문제삼기는 좀 애매하죠. 필요없는 라이브러리를 제거한 slim버전은 27K인데, 예전 IE는 지원하지 않습니다.

2. Modular하지 않다.
한 프로젝트에서 jQuery의 모든 기능을 이용하는 경우는 없습니다. Javascript의 표준 모듈 방식인 것도 아니고, Tree Shaking도 지원하지 않기에 필연적으로 안쓰는 코드를 포함하게 되는데, 이게 옳은 일인지 고민이 필요합니다. 특히 Animation이나 AJAX는 너무 구식이라 더 좋은 대안을 쓰는게 낫습니다. slim 버전에서는 이와 같은 기능이 분리되었습니다.

3. 너무 쉽다.
document.getElementById(“some-id”)보다 $(“#some-id”)쪽이 훨씬 보기 편합니다. 그런데 너무 쉽다보니 $를 남발하게 됩니다. 생각보다 $를 쓰는게 메모리와 CPU를 잡아먹습니다. 그리고 jQuery.data같은 함수는 DOM에 직접 읽고 쓰는 기능을 제공하는데, 덕분에 속도면에서도 느리고 변수를 Global에 노출시키게 됩니다. 너무 편해서 잘못된 코딩을 하게 되는 것도 문제입니다만, 근본적으로 보자면 jQuery를 이해하지 못하고 쓰는게 문제겠죠.

4. jQuery는 javascript가 아니다.
기본적으로 jQuery는 Select한 element의 배열을 기준으로 작업합니다. $(“.some-class”) 이면 [el1, el2, el3]와 같은 Selector에 의해 선택된 배열을 내부에 가지고 있으면서 그 기준으로 작업을 합니다. 그런데 예를 들어 $(“div”).text()를 하면 div의 내용을 가져오는데, div가 두개가 있을 때는 두 div의 내용을 합쳐서 하나의 스트링을 반환합니다. < div >123< /div >< div >456</ div >이면 $(“div”).text()의 결과는 “123456”이 됩니다. 근데 과연 이런 동작이 맞을까요? 대부분 text()로 값을 가져오는 경우는 하나의 값이 필요해서 입니다. 두개의 text값이 필요하다면 각각의 값을 배열로 반환하는게 맞지 않을까 하네요. jQuery의 수많은 함수가 배열로 동작하는데, $(“.some-class”)가 배열처럼 보이지 않기에 문제를 일으킬 소지가 있습니다. 이와는 반대로 val()일때는 맨 처음 element의 값만 가져오도록 되어있는데 다른 함수들과 동작이 다릅니다.

jQuery의 hide, show는 element에 style을 적용합니다. < div style=”display:none” >처럼요. 그런데 element의 style은 우선도가 높기에 css에서 설정한게 안먹을 수도 있습니다. 그러므로 가급적 쓰면 안됩니다만 어디에고 그런 설명을 찾기는 어렵습니다.

jQuery만의 독특한 동작이 상당히 많습니다. 그게 틀린 방식은 아닙니다만 웹표준은 아닙니다. 그러므로 jQuery를 잘 쓰기 위해서는 jQuery 내부 동작을 잘 알아야 합니다. 근데 그럴꺼면 그냥 javascript로 작성하는게 더 편하지 않나 합니다.

5. 웹표준을 지키지 않는다.
지키지않는다는게 정확한 표현은 아니고, jQuery가 워낙 오래되서 웹표준이 정해지기 전에 나왔기 때문에 문제가 좀 있습니다. 예를 들어 jQuery Deferred는 하위호환때문에 Promise/A+ 표준을 지키지 않습니다. Ajax도 fetch라는 표준이 나와서 굳이 jQuery방식을 쓸 필요가 없구요. jQuery를 도입하게 되면 브라우저에서 지원하니 성능적으로 월등하고, 표준이라서 앞으로도 변함이 없는 기술을 놔두고 굳이 예전 방식을 써야 하는 상황이 됩니다. ES6로 들어서면서 Javascript의 기능도 많이 늘었기에 polyfill이나 transpiler로 처리하는게 장래를 생각하면 더 나은 방식입니다.

6. 업데이트의 문제
1.x버전과 2.x버전은 공식적으로 소프트웨어로서의 수명을 다했습니다. IE6~8을 지원하려면 1.x를 써야 하는데 그렇게 되면 차후의 서포트를 받지 못하게 됩니다. IE9부터는 jQuery 3.x에서 지원하므로 당분간은 문제가 없을 예정입니다만 IE9, 10지원을 포기하면 수많은 대안이 존재합니다.

7. Virtual DOM과 상성이 안좋다.
Virtual DOM뿐만이 아니라 요즘 나오는 라이브러리들은 DOM을 직접 다루지 않고 template에서 자동으로 생성하기 때문에 jQuery와 함께 쓰기가 매우 애매합니다. 둘 중의 하나를 골라야한다면 Vue, React, Angular같은 새로운 라이브러리를 선택하는게 맞겠죠.

이 외에도 문제는 많이 찾을수 있을테지만, jQuery같이 규모가 크고 수많은 사람들이 쓰고 있는 라이브러리에 치명적인 문제는 그리 많지 않습니다. 작은 사이트를 만들고 돌리는데는 아직도 jQuery만으로 충분합니다. 그러나 점점 트렌드가 바뀌고 있으니 준비하고 다음 단계로 넘어가야 하지 않을까 하네요. 특히나 Javascript 업계는 전례가 없을 정도로 빨리 변하고 있으니까요.

0

웹개발시 유용한 폰트에 관한 상식들

회사 로고를 만들기위해 폰트에 관해 공부 했는데 그때 알게된 정보를 기록으로 남겨본다. 디자인은 포토샵으로 크롭하고 용량줄이는 정도만 할 줄 알고, 폰트 쪽은 완전 초보라 디자인 전문가가 보면 별거 아닌 내용이다.

 

1. 폰트 종류는 크게 나눠서 Serif와 Sans Serif가 있다. 장식적이고 가독성이 높은 폰트가 Serif, 모던하고 심플한 폰트가 Sans Serif이다. Serif는 글자의 장식적인 부분을 의미하고 Sans는 without을 의미한다. 전통적으로 출판업에는 사람이 읽기 쉬운 Serif 폰트가 주로 쓰여지고 있었기 때문에 Sans Serif는 역사가 오래 되지 않았다.

 

2. 예전엔 로고나 헤드라인에는 Sans Serif를, 본문엔 가독성이 좋은 Serif를 썼는데, 요즘엔 본문에 Sans Serif를 써도 뭐라고 하는 사람이 없다. 디자이너들이 Helvetica 이후로 모던한 폰트를 적극적으로 쓰기도 했고, 해상도가 낮은 PC 모니터에서는 장식이 많은 Serif를 읽기가 힘들기에 Sans Serif만 써서 그렇기도 하다. 이유야 어찌되었든 Sans Serif가 인기를 얻은지 몇십년이 지나서 사람들 눈에 폰트 형태가 익숙해지니 굳이 본문에 Serif를 쓸 필요가 없는 것이다. 그런데 모니터가 다 레티나로 바뀌면서 본문용으로 Serif체가 쓰이는 경우가 늘어나고 있다. 트렌드는 돌고 돈다. (모니터에서는 산세리프가 더 가독성이 높다는 주장도 있다.)

 

3. 한글의 구조가 사각형이라서인지 한글 Serif는 영문 Serif와 느낌이 많이 다르다. 영문 디자인을 그대로 따라할 수 없는 이유이다.

 

4. 웨이트가 많고, 글자 간격이 일정하고, 디자인에 일관성이 있는 폰트가 사용성이 좋다. 그런 폰트는 어떤 알파벳 조합이나 미디어(책, 문서, 웹사이트 등등)상에서도 아름답게 보인다. 당연한 이야기지만 유명한 유료 폰트는 이런 조건을 대부분 만족한다. 최근에는 무료 폰트 중에서도 이런 폰트들이 많이 나와서 웹폰트나 로고로 자주 쓰이고 있다. Lato, Roboto, Linux Libertine 등등.. 잘 알아두면 웹개발에 많은 도움이 된다. 그런데 이렇게 잘 알려진 무료 폰트는 너무 많은 사이트에서 웹폰트로 쓰고 있기 때문에 이제는 좀 식상한 감이 있다. 특히 Lato..

 

5. 로고에 쓰이는 폰트는 굳이 유료일 필요는 없지만 디자인 작업을 하는 입장에서 보면 범용성있는 유료 폰트로 단기간에 퀄리티있는 로고를 만드는게 남는 장사다. 무료 폰트를 검색해서 일일이 자간과 형태를 조절하는건 귀찮은 일이니까.. 어차피 조절해야한다고? 그러면 디자이너 쓰는 비용이 폰트 비용보다 더 든다.

 

6. 유료 폰트는 웨이트와 라이센스 종류에 따라 과금이 천차만별이다. 원하는 웨이트 하나만 사서 데스크탑 용도로만 쓰면 몇 만원 선에서 지출이 끝나는데, 풀셋으로 갖추려면 돈이 몇백단위로 나간다. 특히 PDF, E-Book, 앱, 서버 등에 폰트를 포함해서 배포하는 라이센스가 무진장 비싸다(최소 10배). 임베디드 용도로 써야 한다면 그에 따른 라이센스 비용도 체크해야 한다. BI를 위해서 전부 사는 것도 괜찮은 방법이지만 그만큼 돈을 벌어야겠지..

 

7. Helvetica, Univers, Futura, DIN, Baskerville, Avenir, Bodoni, Gill Sans 등등등.. 유명한 유료 폰트는 알아두는게 좋다. 길거리나 웹에서 볼 수 있는 대부분의 타이포그래피가 이런 유명한 폰트를 기반으로 만들어지고 있다. 무료 폰트 중에는 이런 유명한 폰트를 흉내낸 폰트가 꽤 있는데, 완성도는 살짝 떨어져도 잘만 이용하면 쓸 만하다.

 

8. 영문 웹폰트를 잘 쓰면 개성있는 사이트를 만들 수 있지만, 한글이나 일본어는 쓸 만한 웹폰트가 많지 않다보니 그에 맞춰서 쓸 수 있는 영문 웹 폰트를 찾는 일이 쉽지 않다. 디자이너가 열심히 찾아다녀야한다. 그리고 한글 웹폰트는 무거워서 잘 안쓰게 된다.

 

8. 광고/브랜딩에 신경쓰는 화장품, 의류 브랜드는 로고의 폰트와 브랜드 이미지가 완벽하고 일치하고 어색한 부분이 없다. 고급 디자인 에이전시에 맡겼겠지.. 그 외의 일반적인 간판은 대충 만든게 눈에 보인다.

 

9. 헬베티카는 폰트 자체에 개성이 없고, 이탤릭체가 어설프다는 이유로 디자이너 사이에서 호불호가 갈린다. 길거리를 다니면 헬베티카 쓰는 간판이 많은데, 무성의해 보인다.

 

10. 무료 폰트를 찾는다면 다음의 두 사이트를 추천한다. 특히 구글은 완전 짱임.. http://www.dafont.com/ https://www.google.com/fonts 유료 폰트사이트는 검색해보면 많이 나온다.

 

풀스택 개발엔 디자인도 포함된다. 사이트 하나를 만드는데 필요한 전문 지식이 이렇게 많다.

0

컵라면을 맛있게 먹는 방법

IT 프로젝트에서 마감날이 다가오면 개발자들이 제일 바빠집니다. 기획과 디자인이 늦게 끝난 프로젝트라면 더더욱 그렇죠. 아무리 개발 경력을 쌓아도 마감에 대한 압박은 어쩔 수 없지만, 초반에 열심히 체력을 비축해 두었으면 어떻게든 버틸 수 있습니다. (프로젝트 중간에 긴급 투입되었다면…)

아무튼 마감에 치이면 밥 먹을 시간도 부족해서, 저녁을 컵라면으로 때우는 일이 생깁니다. 일본의 컵라면이야 맛있으니 큰 불만은 없지만, 자주 먹다보니 항상 맛있는 컵라면을 먹는게 쉬운일이 아니라는 사실을 알게 되었습니다.

컵라면을 끓이는 방법은 아주 간단합니다. 1. 뚜껑을 열어 스프를 꺼내고, 2. 따뜻한 물을 선에 맞춰 붓고, 3. 정해진 시간을 기다린 후 먹으면 됩니다.

그런데 직접해보니 2, 3단계가 쉽지가 않습니다. 밝은 곳이 아니면 물을 붓는 선이 잘 안보이는데다, 컵을 기울여서 쥐게되면 적당히 부었다고 생각했는데 오버하는 경우가 생깁니다.  정해진 시간을 맞추는 것도 어려운게 물을 부은 다음에 바로 시작 시간을 체크해야 하는데 빼먹는다거나, 기다리는 중간에 메신저등등의 인터럽트가 걸릴 때도 있습니다.

그렇다면 항상 완벽한 컵라면을 먹고 싶다면 어떻게 해야할까요? 1. 물따르는 곳의 조명이 밝아야 합니다. 2. 정확히 수평을 유지하려면 테이블 위에 올려놓고 주전자나 포트를 이용해 따르는 방식이어야 합니다. 3. 다 따르자마자 스톱워치를 돌리고 중간의 인터럽트는 무시합니다.

그런데 이게 쉬운 일은 아니죠. 포트 대신에 정수기만 있다거나 탕비실 조명이 원래 어두운 상황에서, 단지 컵라면을 완벽하게 끓이기 위해 조명을 바꾸거나 포트를 사기는 애매하니까요. 중간에 중요한 연락이 왔는데 무시하기도 그렇죠.

그리고 더욱 근본적인 문제가 있는데, 맛있게 보여서 사온 컵라면이 맛이 없으면 모든 과정을 제대로 해내도 원하는 결과를 얻지 못합니다.

결국은 가끔 실패한  컵라면을 먹는 것으로 타협을 보게 됩니다. 하지만 어떻게해야 최선의 컵라면을 먹을수 있는지 고민해보았다면, 그리고 더 나은 방법을 제시할 수 있다면, 누군가 컵라면에 대해 고민하고 있을때 조언해줄 수 있습니다. 그런게 개발자의 일이 아닐까 하네요.

P.S. 참고로 제가 먹고 성공한 컵라면을 소개해 드리겠습니다.

일본 컵라면 추천 2016년

3

웹개발의 다섯가지 특징

요즘들어 젊은 개발자들과 대화할 기회가 많이 생기면서 제가 생각하는 웹개발에 대해 한 번 정리할 필요를 느꼈습니다. 제가 웹개발을 잘 아는 것은 아니지만 정리해가면서 배우는 것도 있으니까요. 일단은 특징에 대해 정리하고 차차 웹개발 프로세스에 대해서도 정리할 생각입니다.

제가 생각하는 웹 개발의 특징은 다음과 같습니다. 스테이트가 없는 것도 특징이지만, 너무 당연한 듯해서 제외했습니다.

  1. 데이터 처리가 중심이다.
  2. 비동기로 움직인다.
  3. 다양한 사용자층이 있다.
  4. 다양한 개발자/회사들이 참여하고 있다.
  5. 계속 발전한다.

 

데이터 처리가 중심이다

웹에는 이미 fancy한 것들이 넘치기때문에 컨텐츠가 없는 사이트는 매력이 없습니다. 많은 초보 개발자 분들이 언어나 프레임웍을 공부를 하느라 데이터 관리에는 소홀하신 모습을 보이시는데, ORM으로 가든, NoSQL로 가든, Machine Learning으로 가든 데이터의 본질적인 특성을 이해해야 좋은 서비스를 만들 수 있다는 사실엔 변함이 없습니다. 자주 변경되는 필드를 정규화한다던가, 자주 검색되는 필드에 인덱싱을 건다던가 캐싱을 한다던가 하는 DB 관리도 중요하지만, 정말 필요한 데이터를 수집하고 있는지,  어떤 식으로 보여주어야 하는지에 대한 고민도 해야합니다. MySQL의 스펙을 빠삭하게 아는 것만으로는 현장에서 필요한 개발자가 될 수 없습니다. 물론 MySQL의 스펙을 열심히 공부하는 개발자는 데이터의 특성에 대해서도 이해하려고 노력하는 경우가 대부분이죠.

비동기로 움직인다

모던 웹브라우저는 이미 비동기 방식으로 동작하고 있습니다. 개발하기엔 동기방식이 편하지만 사용자 경험(UX)을 높히기 위해서는 비동기를 도입할 필요가 있습니다. 즉시 즉시 처리해야 사용자들의 만족도가 올라가니까요. 요즘은 서버쪽도 비동기 방식이 각광을 받고 있습니다. NGINX + PHP-FPM이 인기인데는 다 이유가 있습니다. 비동기 동작을 모르고 웹개발 하기는 점점 더 어려워 질테니 지금 당장 뭔가 배우는 것을 추천합니다. 예를 들자면 RxJS.

다양한 사용자층이 있다.

웹의 오픈성은 세상 모든 계층의 유저를 불러모읍니다. 유저마다 요구하는 것이 다르고, 다양한 요구를 반영하기 위해 설계가 복잡해질 가능성이 높은데다, 실제로 써보지 않으면 필요한지 아닌지 알 수 없는 부분도 많습니다. 그러므로 일단 빨리 올리고 유저의 피드백을 모아 기민하게 반응할 필요가 있습니다. 심지어 클라이언트가 원하는 소프트웨어를 구현하는 SI라 하더라도 초기 기획서 대로 개발되는 일은 많지 않습니다. 그러므로 웹개발자라면 사양 변경에 따른 수정은 당연한 것으로 생각하고 미리 대비가 되어있어야 합니다. 또 하나 주의해야할 점은 웹서비스는 어떠한 접근도 가능하기 때문에 해킹이나 잘못된 입력에 대한 체크는 기본 중의 기본이라는 것입니다. e-commerce나 유저의 개인정보를 취급하는 사이트라면 더더욱 주의가 필요합니다.

다양한 개발자/회사들이 참여하고 있다.

페이스북, 구글, 아마존같은 실리콘밸리 대기업이 웹업계를 대표하고 있긴 하지만, 전 세계적으로 다양한 회사와 개발자들이 존재하고 그 시장 규모도 어마어마합니다. 예를 들어 도쿄브랜치는 현재 일본 시장에서 소규모 개발 프로젝트를 다수 진행하고 있는 중인데, 아직 안망하고 있습니다. 한국에서 IT개발하면 자바로 하는 SI가 전부인 것같지만 다양한 개발 커뮤니티가 존재합니다. 이런 상황에서 어떤 식으로 개발하는 것이 좋을지, 혹은 어떻게 개발 경력을 쌓아야 할지 결정하는 일은 쉽지 않습니다. 회사가 정해준다면 그걸 따르기만 하면 되지만, 개발 경력을 쌓다보면 자기가 스택을 선택해야할 상황이 옵니다. 지금 새로운 웹서비스를 개발할때 Angular vs React vs Vue.js vs jQuery, Ruby on Rails vs PHP vs Go vs Java Spring이라면 어떤 선택이 최선일까요?  단가가 중요한 경우라면 빠르고 안정적으로 개발할수 있는 기술을 선택하는 것이 베스트겠지만, 거대 IT회사가 개발했거나, 시장에서 주로 쓰이는 기술을 선택하는 것이 더 유리할 수도 있습니다.

계속 발전한다.

웹업계란 마치 끊임없이 레이즈를 해야하는 포커판과 같습니다. 지금도 계속 새로운 서비스가 나오고 있고, 온라인 상에서는 어떻게 하면 유저에게 더 좋은 서비스를 제공할수 있을지 활발한 토론이 계속 되고 있습니다. 프론트엔드로 치면 처음엔 jQuery면 되었는데 Backbone이 나오고 Angular가 나오고 React가 나오는 식입니다. 기능이 추가되면서 한번에 구현해야할 요구사항도 늘어나고 있기 때문에 개발은 점점 더 복잡해지고 있고 앞으로도 이 추세는 계속 될 것입니다. 이런 상황에서 웹개발자가 할 일은 프로젝트의 복잡성을 낮추는 기법을 연구하고 기술 자체보다는 UX를 우선으로 생각하는 일일 것입니다.

 

 

간단하게 제가 매일 겪고있는 웹개발의 이슈들을 정리해봤습니다. 업계에 종사하는 분들이 보면 별것 아닌 뻔한 이야기지만 웹개발을 시작하시는 분들에게 조금이라도 도움이 되었으면 합니다.

1

레거시 jQuery 프로젝트를 es6기반으로 변경하기

프론트엔드 개발을 오래하다보니 예전 프로젝트를 관리할 일이 종종 생기고 있습니다. 그런데 워낙 프론트엔드의 기술 발전이 빠르다보니 이미 아무도 쓰지 않는 예전의 기술로 프로젝트를 관리하는 것이 무척 난이도 높은 작업이 되버렸습니다. 시대의 흐름에 맞게 es6와 npm기반으로 바꾸고 싶어서 다양한 방법을 리뷰하다가 rollup.jsbuble를 알게 되었습니다.

rollup.js는 es6의 표준 모듈 시스템을 지원하는 bundler이고, buble는 es6코드를 es5로 바꿔주는 transpiler입니다. 더 복잡하고 유명한 프로그램도 있지만 제 목적엔 rollup.js이 최적이더군요. 특히나 최종 결과가 너무 깔끔하게 나와서 감동했습니다.

rollup.js의 환경 설정에 시간이 걸리는데, 한번에 처리하기 위해서 boilerplate를 github에 올려놨습니다. node.js와 git가 설치되어있다면 5분도 안걸립니다.

build명령을 실행시키면 es6로 작성된 src/main.js 파일을 바탕으로 dist폴더에 es5형식의 파일이 생성됩니다.

그런데 파일을 수정할 때마다 빌드명령을 입력하기는 귀찮은 일이죠. 그럴 때를 위해  watch모드가 존재합니다.

built-in서버 기능은 안넣었는데 html 파일에 dist/app.js를 넣어서 제대로 동작하는지 확인해보시기 바랍니다. 혹은 직접 만들어진 코드를 보셔도 됩니다.

browser-sync를 이용하여 built-in서버기능을 넣었습니다.

index.html 파일과 src폴더내의 js파일을 수정하면 바뀐 결과가 바로 브라우저에 반영되는 것을 보실수 있습니다.

 

아래처럼 es6 형식으로 작성한 코드가

es5로 깔끔하게 변환됩니다.

이렇게 개발환경을 설정하니 es5로 작업하는 것과 속도 면에서 별 차이가 없고, es6의 깔끔한 문법덕분에 개발 효율은 몇배로 증가했습니다. 예전 코드를 main.js에 통채로 카피해서 하나씩 es6화 하는 것도 가능하고, 최종결과가 IE8같은 레거시 브라우저에서도 문제 없이 돌아가니, 지금 당장 프로젝트에 적용할 수 있는 것도 무척 매력적입니다.

이번에 rollup.js를 써서 개발하면서 느낀 것은 Javascript의 미래가 생각보다 멀리 있지 않다는 것입니다. es5는 이제 잊으시고 지금 당장 es6개발에 도전해보시기 바랍니다.

0

10분만에 Angular 2.0 RC2 시작하기

이번에 Angular 1 기반 프로젝트를 Angular 2로 이전하는 작업을 하게 되었습니다. node기반 프로젝트들이 설정 난이도가 높기로 유명해서 걱정했는데 angular-cli덕분에 금방 끝낼수 있었습니다. 그 과정이 감동적으로 심플해서 간단하게 정리해봤습니다.

 

개발 환경은 제 맥북기준으로 설명하겠습니다. 일단 npm이 있어야 하는데 저는 nvm을 이용해서 v6.2.1을 깔았습니다. nvm은 brew를 통해서 깔면 됩니다. 참고로 nvm과 npm 설정은 10분에 포함이 안됩니다.

npm 설정이 끝났다면 글로벌 라이브러리를 설치합니다.

 

그리고 angular-cli를 이용해서 프로젝트 폴더에 신규 프로젝트를 만듭니다.

프로젝트 폴더와 필요한 모든 파일이 생성됩니다. 원래라면 더 이상의 작업은 필요없는데, RC2를 적용하려면 수정이 필요합니다.  라이브러리를 버전업하고 angular-forms를 추가해야 하는데 forms에 관해서는 이 문서를 확인해보시기바랍니다.

 

수정을 위해서, 그리고 작업을 위해서 IDE로 VS Code를 쓰고 있는데 아래는 제가 쓰는 플러그인의 리스트입니다. vi나 에디터플러스로 편집하셔도 아무 문제 없습니다만 intellisense가 지원되는 IDE가 편하긴 편하더군요. VS Code를 설정하는 시간도 10분에 안들어갑니다.

 

프로젝트 폴더로 들어가셔서 package.json을 수정합니다.

rc.1을 rc2로 바꾸고 router의 버전을 alpha.3에서 alpha.7로 올려줍니다. @angular/forms의 추가도 잊지 마시길.

 

src/main.ts에서 http와 forms를 쓰도록 변경해줍니다.

disableDeprecatedForms는 RC2전용으로 RC1 이전의 forms를 쓰지 못하게 막는 코드인데 RC3이후로는 쓰이지 않을 예정입니다.

 

src/system-config.ts에 forms를 한 줄 추가해줍니다.

 

이제 라이브러리를 설치하고 서버를 실행시킵니다.

http://localhost:4200/ 으로 접속해서 app works! 메세지가 보이면 성공입니다. src/app/app.component.ts에서 title을 변경하면 자동으로 브라우저에 반영되는지 확인해보시기 바랍니다. 만약 built-in 서버가 필요가 없다면 build –watch를 하시면 됩니다.

어때요? 10분이면 충분하죠?

 

저의 경우 built-in서버 대신 nginx위에서 작업했는데 dist/index.html 을 참조해서 페이지를 하나 만들고, System.js의 base URL을 설정하니 문제없이 동작했습니다. 아래와 같은 코드를 System.import 위에 넣어주시면 됩니다.

 

angular-cli를 만져보니 요즘 구글이 정말 일을 잘하고 있구나 라는 생각이 들었습니다. ng 명령어를 이용하면 테스트를 비롯한 다양한 기능이 지원되는데 직접 확인해보시기 바랍니다.

환경설정이 간단하게 끝났으니 그 다음엔 웹어플리케이션을 제작하는 일이 남았습니다. typescript를 익히시고 angular2 quickstart angular2 seed 같은 예제를 참조하신 후에 자신만의 멋진 프론트엔드 작업을 하시기 바랍니다. 아차차, 테스트를 위해서 jasmin, karma를, ajax를 위해선 rxjs도 알아둬야 하는 걸 빼먹을 뻔 했네요.

Angular2를 조금 써봤는데 내부적으로는 많이 바뀌었지만 실제 작업을 해보면 Angular 1과 거의 비슷한 감각으로 사용할 수 있도록 설계되어 있었습니다. 능력자 구글의 서포트가 있으니 정식버전이 나오면 프론트엔드 분야에 큰 영향을 미치지 않을까 예상해봅니다. 마치 초창기 스프링처럼요. 성공적으로 환경 설정하시고 잘 활용해보시기 바랍니다.

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text.

Start typing and press Enter to search