#ecma5 | Explore Tumblr posts and blogs

pignose-barn · 8 years ago

Text

Angular 2 그리고 웹 프론트엔드 (1/2)

한동안 마무리 지어야 하는 일때문에 정신이 없다가 이제서야 정리를 할 시간이 오게 되었다..

이 포스트에서는 Angular가 무엇인지 모르는 분들을 위해 Angular를 설명하는 내용을 채울까 한다.

Angular 2 그리고 웹 프론트엔드 (1/2) - 현재 글

Angular 2 그리고 웹 프론트엔드 (2/2)

Angular는 구글에서 만든 자바스크립트 프레임워크이다.

프레임워크이기 때문에 일반적으로 여러분이 아시는 jQuery, underscore, lodash 보다 규모가 큰 프로젝트다. (지원되는 기능의 폭도 넓으며 채택한 의존 라이브러리들도 많다.)

한글 발음으로 “앵귤러 제이에스"라고 발음하면 되며 여기서 Angular는 “앙상한" 이라는 단어를 가지고 있는데,

아무래도 뼈대를 갖춰주는 프레임워크라는 의미로 사용했을 것이라고 생각된다.

Angular 공식페이지에 기재된 워딩이 “One framework” (하나의 프레임워크)인데, 이는 Mobile까지 대응하겠다는 Angular의 목표가 깃들어있다.

Angular에 대해서 대체 무슨 프레임워크인가, 어떤 목적과 장점을 가지고 있는가에 대해서 궁금증이 많으실 것이라 생각된다.

사실 이 물음을 풀어드리기 위해서는 앞서 웹 프론트엔드 개발 동향을 먼저 설명해야 할 것 같다.

웹 프론트엔드의 변화

현재 웹 프론트엔드 개발에서 사용되는 툴이 많다! 너무 많다! (그리고 많아지고 있다!!)

(필자는 이 사진에 보여지는 앱보다 많은 앱을 사용했음에도 전체에 비해서는 절반도 채 되지 않는다.)

일부 개발자는 전통적인 프론트엔드 개발 방식대로 html과 javascript 그리고 css를 개발하고,

javascript 엘리먼트를 쉽게 찾을 수 있는 jQuery와 jQueryUI를 연동하여 서비스를 완성 했을 것이다 그리고 그렇게 개발하는 방법에 큰 불편함이 없었을 것이다.

결과적으로 오늘에서 이렇게 개발을 도와주는 앱이 많아진 것은 ECMA 5에서 ECMA 6로 자바스크립트 표준이 변경되고 있는 상황과,

Node.js 보급으로 인해 백엔드 서버 개발자가 점점 javascript를 사용하게 되면서 백엔드 기술 프론트엔드와의 경계가 허물어지고 있는 점.

그리고 거대한 웹 서비스 벤더사(구글, 페이스북)에서 프론트엔드 프로젝트에 기여를 하고 있는 점 이것들이 뭉치면서 아래와 같은 결과를 내었다.

웹 프론트엔드 개발에 백엔드 개발에서 요구되던 기능이 추가되고 있다.

ECMA6의 지원을 위한 서브 툴이 생겨나고 있다.

많은 모바일기기 지원으로 보다 빠른 웹을 시장이 원하고 있다.

많은 기존 자바스크립트 라이브러리들이 최신 기술을 수용하고 있다.

(웹 프론트엔드 개발자들은 공부할 것이 엄청나게 늘어나 버렸다.)

또한 이러한 변화가 프론트엔드의 러닝커브를 늘렸으며,

기존 개발 환경에 익숙하여 최신 동향을 살펴보지 않는 개발자들은

자리를 위협받는 상황이 오지않았나 조심스럽게 추측해본다.

웹 프론트엔드 도구들

그러면 아까 사진에 보여드린 수많은 앱 들이 도대체 무슨역할을 하나?

그리고 그것이 반드시 필요한가에 대해서도 설명을 드릴까 한다.

상당히 지루하고 딱딱한 내용이 될 것 같아 많은 링크와 사진을 첨부했다.

1. npm, bower, yoman, yarn

이 4가지 서비스는 Pakcage Manager(패키지 매니저)라고 부르는 서비스다.

(yoman은 정확히 말하면 스캐폴딩(Scaffolding - 실제 작업을 하기 전 철골을 덧대듯이 작업에 필요한 최소한에 구조를 만들어주는 단계)만 해주는 서비스.)

쉽게 풀어보자면 프로젝트에 사용할 라이브러리를 직접 찾아 해당 파일을 원격지에서 다운받아 로컬 파일에 옮기지 않아도, 간단한 명령어로 추가/수정/삭제를 지원하고 의존성(Dependency)을 관리해주는 서비스들을 의미한다.

또한 라이브러리 배포와 호스팅/빌드/테스트 스크립트 정의도 가능하다.

2. Typescript, Flow

타입스크립트는 자바스크립트에서 발생할 수 있는 문제(타입 검증)를 해결해주는 동시에 ECMA6의 스펙을 포함하여 지원하고 있으며 Microsoft와 Google이 협력하여 개발하고 있는 언어이다. Typescript를 통해 개발을 진행하게되면 런타임 단계에서 발생할 수 있는 오류를 미연에 방지할 수 있고 OOP 지향한 개발과 Dependency Injection(DI)등의 패턴을 구현할 수 있게 된다. React 프로젝트의 Flow또한 타입 검증을 지원해준다.

3. Reactive Programming

과거에는 웹 페이지 이동 (빈 화면에서 로딩이 걸리고 새로운 페이지가 보여지는) 없이 데이터를 업데이트 하는 사이트는 드물었지만 지금은 웬만한 서비스에서 이 기술을 적용하고 있다. 이러한 비동기 통신은 콜백함수를 통해 전달이 되어야 했으며 이 때문에 콜백지옥이 발생하기도 했다. RX(ReactiveX) 프로젝트는 이러한 문제를 해결해주며, 옵저버 패턴을 제공하여 서로다른 컨텍스트에 데이터를 동시적으로 제공해줄 수 있다. Redux, Flux 서비스는 이러한 데이터를 효율적으로 대상에게 전달할 수 있다. 참고로 AngularJS 2는 RxJS를 포함 할 수 있다.

4. grunt, gulp, webpack

여러분이 만약 반복되는 작업을 조금이라도 재활용하여 효율적인 프로그래밍을 원했다면 CSS의 작성이 굉장히 피곤하게 느껴졌을 수 있다, LESS와 SASS, Stylus와 같은 기술은 이러한 반복되는 작업을 없애주고 더불어 색상 코드를 특정 % (밝게, 어둡게)와 같은 편의 함수를 제공한다. 다만 결국 브라우저는 CSS 문서만을 인식하기 때문에 .less .sass와 같은 확장자는 빌드단계에서 변경이 이루어져야 한다, 그 밖에도 빌드 단계에서 진행되야 하는 작업들 (ECMA6 파일을 ECMA5 파일로 변경, 문서 최적화, 코드 테스트, 카피라이팅 삽입, 문서 문법 검증, 번들링 등)을 도와주는 도구가 grunt, gulp, webpack과 같은 도구이며 이는 다시 npm등의 패키지 매니저 도구와 연동하여 사용하거나 IDE(통합 개발환경)에서 연동하여 빌드과정을 일관화 시킬 수 있다. 이렇게 되면 파편화 되있는 JS, CSS, HTML 문서를 하나로 합쳐주며 표준코딩을 지향하게 되며 하위 호환 여부 검토가 수월하고 예기치 못한 버그와 사이드이펙트를 미연에 방지 할 수 있게 된다.

5. RequireJS 그리고 CommonJS와 AMD(Asynchronous Module Definition)

Node.js의 영향 중 하나라고 필자는 생각한다.

네이버 D2에서 작성한 글이 보기 좋아 링크를 공유한다.

웹 페이지에서 서비스를 개발할 때 여러 Javascript 라이브러리를 합쳐 하나의 완성된 서비스를 만든다. 이때 이 라이브러리를 하나의 모듈로 볼 때 그 모듈에 대한 표준이 없다는 것이다. 따라서 각각의 라이브러리들은 서로다른 라이브러리 제공방식을 사용하고 있고 이를 이용하는 개발자는 각각의 라이브러리마다 다른 방식의 사용법 (같은 라이브러리라도 버전마다 달라지기도 한다.)을 이용해야하고 또 이러한 부분은 굉장히 비효율적으로 이용된다. (케익 한조각을 먹기위해 케익 전체를 사야하는 상황)

이를 해결하기 위해 나온 모듈 제공 방식이 CommonJS와 AMD이다.

각각의 사용형태가 다른 모듈들을 제공하는 하나의 표준을 만들어 그것을 지향하면 라이브러리 추가와 확장이 훨씬 쉬워지며 이는 큰 프로젝트에서도 모듈의 관리가 용이하며 효율적이다. 하지만 이 방식을 사용해도 마찬가지로 브라우저에서는 지원하지 않기 때문에 (다만 ECMA6는 import 키워드를 제공한다.) 이를 번들링 하기 위한 systemjs, Jspm, Rollup.js, Webpack등의 서비스가 존재한다

6. jasmin, chai, mocha

규모가 큰 프로젝트 일수록 소스관리가 중요하여 자칫 하나의 수정사항이 사이드이펙트(다른 비즈니스 로직에 직/간접적으로 영향이 가는 것)가 발생 할 수 있다.

이는 라이브서비스에 커다란 이슈이며 이를 해결하기 위해 QA와 테스트케이스가 존재한다. 다만 규모가 크고 지원하는 플랫폼이 넓으며 수많은 페이지와 버그가 발생하는 환경을 시연하기 어려운 요소가 발생되면 이러한 테스트는 사람이 직접하기 어렵고 특히 애자일 방법론을 사용하는 개발 환경에서는 이러한 과정이 거의 불가능에 가깝다. 결국 이를 해결하기 위해서는 자동화된 개발 테스트 환경이 필요하다.

프론트엔드 개발도 마찬가지로 유닛 테스트를 지원하는 서비스가 있다. 가상의 DOM Mock에 라이브러리의 모든 케이스를 테스트해보고 결과적으로 테스트의 결과를 확인할 수 있게 제공하여 서비스 배포이전에 모든 기능에 안전성을 검토 할 수 있다.

7. istanbul, blanket, JSCoverage

이전에 말한 유닛테스트는 서비스 되고있는 소스코드의 얼마나 많은 부분을 테스트 해주는지에 대한 부분이 상당히 중요하다. (많은 부분이 자동화 테스트를 지원할 수록 서비스는 안정적이고 신뢰를 보장하기 때문) 하지만 얼마나 많은 부분의 소스코드에 테스트를 지원하는지 사람이 알기에는 어렵다고 볼 수 있다. 이 때문에 얼마나 많은 부분이 테스트가 되었는지, 다시말해 얼마나 코드가 커버(Cover)되었느냐는 커버리지(Coverage)라는 용어를 사용하여 지표를 결정한다. 유닛 테스트 도구와 연동하여 커버리지 도구를 사용하게 되면 커버리지 지표를 리포트로 제공받게 된다.

8. JSDoc

JSDoc은 javascript 모듈에서 사용되는 각각의 클래스, 함수들에 대한 정의를 JSDoc에서 정의한 표준 주석양식에 맞춰 작성하게 되면 그에따른 자동화된 개발 래퍼런스 문서가 만들어지게 된다. 마크다운 문서로 래퍼런스 문서를 제공하여 gitbook 같은 호스팅 서비스에 등재하게 되면 하나의 인쇄물로서 출력도 가능하다. 이러한 방법은 개발자가 일일히 래퍼런스 문서를 만들지 않아도 래퍼런스 문서를 만들 수 있는 이점이 있으며 표준화된 주석 사용으로 협업 및 인수인계가 원할하게 된다. 사실 다른 Doc 툴도 있지만 해당 서비스가 가장 유력하다.

AngularJS 2에 대한 설명을 위한 포스팅이었으나, 최근들어 웹 프론트엔드 개발 동향이 많이 변하고 있어 그 부분을 중점적으로 정리해보았다.

다음시간에는 Angular 2와 Angular 1 그리고 ReactJS를 주제로 중점적으로 다뤄보는 시간을 가져보도록 하자. 아디오스!

5 notes · View notes

jobrealtime · 7 years ago

Text

[Full time] React Js developer at Jobisite

Title: React Js developer- Angular 2.0 experience Company Name: UST Global Location : Thousand Oaks, CA Mode: 12months+ Rate: 60/hr max IT Experience should be minimum 9 Years Job Description: React Js developer- Angular 2.0 experience · Experience in developing commercial grade, responsive, cross-platform applications for multiple devices · Hands on experience in developing single page applications · Good understanding in principles of accessibility · Expert level skills in JavaScript , HTML5 and CSS3 · Good understanding of latest JavaScript framework standards such as ECMA5 and 6 · Hand on experience in a variety of JavaScript libraries and frameworks - React & Redux or/and AngularJS (or equivalent), Node js, Bootstrap, jQuery · Working knowledge of RESTful API, DOM API, AJAX Programming, JSON, and XML Knowledge in modern version control systems such as GIT · Experience in Agile, BDD, TDD, and Scrum methodologies · Experience in JavaScript testing frameworks such as Jasmine, QUnit, Karma etc · Experience in designing UI as independent, reusable UI components or widgets · Good understanding of Web Analytics and Dynamic tag manager tools · Genuinely excited about technology, have a strong interest in learning and playing with the latest technologies Reference : React Js developer jobs Apply from JobRealtime.com http://jobrealtime.com/job/2283/react-js-developer-at-jobisite/

0 notes

qoholic · 7 years ago

Text

[Full time] React Js developer at Jobisite

Title: React Js developer- Angular 2.0 experience Company Name: UST Global Location : Thousand Oaks, CA Mode: 12months+ Rate: 60/hr max IT Experience should be minimum 9 Years Job Description: React Js developer- Angular 2.0 experience · Experience in developing commercial grade, responsive, cross-platform applications for multiple devices · Hands on experience in developing single page applications · Good understanding in principles of accessibility · Expert level skills in JavaScript , HTML5 and CSS3 · Good understanding of latest JavaScript framework standards such as ECMA5 and 6 · Hand on experience in a variety of JavaScript libraries and frameworks - React & Redux or/and AngularJS (or equivalent), Node js, Bootstrap, jQuery · Working knowledge of RESTful API, DOM API, AJAX Programming, JSON, and XML Knowledge in modern version control systems such as GIT · Experience in Agile, BDD, TDD, and Scrum methodologies · Experience in JavaScript testing frameworks such as Jasmine, QUnit, Karma etc · Experience in designing UI as independent, reusable UI components or widgets · Good understanding of Web Analytics and Dynamic tag manager tools · Genuinely excited about technology, have a strong interest in learning and playing with the latest technologies Reference : React Js developer jobs Apply from qoholic.com http://qoholic.com/job/2297/react-js-developer-at-jobisite/

0 notes

jobsaggregation · 7 years ago

Text

[Full time] React Js developer at Jobisite

Title: React Js developer- Angular 2.0 experience Company Name: UST Global Location : Thousand Oaks, CA Mode: 12months+ Rate: 60/hr max IT Experience should be minimum 9 Years Job Description: React Js developer- Angular 2.0 experience · Experience in developing commercial grade, responsive, cross-platform applications for multiple devices · Hands on experience in developing single page applications · Good understanding in principles of accessibility · Expert level skills in JavaScript , HTML5 and CSS3 · Good understanding of latest JavaScript framework standards such as ECMA5 and 6 · Hand on experience in a variety of JavaScript libraries and frameworks - React & Redux or/and AngularJS (or equivalent), Node js, Bootstrap, jQuery · Working knowledge of RESTful API, DOM API, AJAX Programming, JSON, and XML Knowledge in modern version control systems such as GIT · Experience in Agile, BDD, TDD, and Scrum methodologies · Experience in JavaScript testing frameworks such as Jasmine, QUnit, Karma etc · Experience in designing UI as independent, reusable UI components or widgets · Good understanding of Web Analytics and Dynamic tag manager tools · Genuinely excited about technology, have a strong interest in learning and playing with the latest technologies Reference : React Js developer jobs Apply from jobsaggregation.com http://jobsaggregation.com/job/2283/react-js-developer-at-jobisite/

0 notes

qoholicusa · 7 years ago

Text

[Full time] React Js developer at Jobisite

Title: React Js developer- Angular 2.0 experience Company Name: UST Global Location : Thousand Oaks, CA Mode: 12months+ Rate: 60/hr max IT Experience should be minimum 9 Years Job Description: React Js developer- Angular 2.0 experience · Experience in developing commercial grade, responsive, cross-platform applications for multiple devices · Hands on experience in developing single page applications · Good understanding in principles of accessibility · Expert level skills in JavaScript , HTML5 and CSS3 · Good understanding of latest JavaScript framework standards such as ECMA5 and 6 · Hand on experience in a variety of JavaScript libraries and frameworks - React & Redux or/and AngularJS (or equivalent), Node js, Bootstrap, jQuery · Working knowledge of RESTful API, DOM API, AJAX Programming, JSON, and XML Knowledge in modern version control systems such as GIT · Experience in Agile, BDD, TDD, and Scrum methodologies · Experience in JavaScript testing frameworks such as Jasmine, QUnit, Karma etc · Experience in designing UI as independent, reusable UI components or widgets · Good understanding of Web Analytics and Dynamic tag manager tools · Genuinely excited about technology, have a strong interest in learning and playing with the latest technologies Reference : React Js developer jobs Apply from qoholic.com http://qoholic.com/job/2297/react-js-developer-at-jobisite/

0 notes

fmcaldas · 7 years ago

Text

[Full time] React Js developer at Jobisite

Title: React Js developer- Angular 2.0 experience Company Name: UST Global Location : Thousand Oaks, CA Mode: 12months+ Rate: 60/hr max IT Experience should be minimum 9 Years Job Description: React Js developer- Angular 2.0 experience · Experience in developing commercial grade, responsive, cross-platform applications for multiple devices · Hands on experience in developing single page applications · Good understanding in principles of accessibility · Expert level skills in JavaScript , HTML5 and CSS3 · Good understanding of latest JavaScript framework standards such as ECMA5 and 6 · Hand on experience in a variety of JavaScript libraries and frameworks - React & Redux or/and AngularJS (or equivalent), Node js, Bootstrap, jQuery · Working knowledge of RESTful API, DOM API, AJAX Programming, JSON, and XML Knowledge in modern version control systems such as GIT · Experience in Agile, BDD, TDD, and Scrum methodologies · Experience in JavaScript testing frameworks such as Jasmine, QUnit, Karma etc · Experience in designing UI as independent, reusable UI components or widgets · Good understanding of Web Analytics and Dynamic tag manager tools · Genuinely excited about technology, have a strong interest in learning and playing with the latest technologies Reference : React Js developer jobs Apply Source: http://qoholic.com/job/2297/react-js-developer-at-jobisite/

0 notes

jobsaggregation1 · 7 years ago

Text

[Full time] React Js developer at Jobisite

Title: React Js developer- Angular 2.0 experience Company Name: UST Global Location : Thousand Oaks, CA Mode: 12months+ Rate: 60/hr max IT Experience should be minimum 9 Years Job Description: React Js developer- Angular 2.0 experience · Experience in developing commercial grade, responsive, cross-platform applications for multiple devices · Hands on experience in developing single page applications · Good understanding in principles of accessibility · Expert level skills in JavaScript , HTML5 and CSS3 · Good understanding of latest JavaScript framework standards such as ECMA5 and 6 · Hand on experience in a variety of JavaScript libraries and frameworks - React & Redux or/and AngularJS (or equivalent), Node js, Bootstrap, jQuery · Working knowledge of RESTful API, DOM API, AJAX Programming, JSON, and XML Knowledge in modern version control systems such as GIT · Experience in Agile, BDD, TDD, and Scrum methodologies · Experience in JavaScript testing frameworks such as Jasmine, QUnit, Karma etc · Experience in designing UI as independent, reusable UI components or widgets · Good understanding of Web Analytics and Dynamic tag manager tools · Genuinely excited about technology, have a strong interest in learning and playing with the latest technologies Reference : React Js developer jobs Apply from http://jobsaggregation.com/job/2283/react-js-developer-at-jobisite/

0 notes

jobrealtimecom · 7 years ago

Text

[Full time] React Js developer at Jobisite

0 notes

obscurejavascript · 10 years ago

Text

JavaScript Inheritance Strategy #3: Prototypal

In terms of syntax this is the simplest strategy. Like functional inheritance an object is inherited from directly. But instead of modifying the object directly Object.create extends it. Here is the parent:

var shape = { type: 'shape', announceType: function() { console.log(this.type); } }; shape.announceType(); //shape

The child is based directly on the parent:

var circle = Object.create(shape, { type: {value: 'circle'} }); circle.announceType();// circle

Keep in mind Object.create is ECMA 5 so it will only work in IE 9+. So for older browsers a polyfill will need to be used. This strategy is simple, but the syntax covers up the implementation making it seem somewhat magical (see the polyfill for what it does). So I prefer the functional inheritance style.

Github Location: https://github.com/Jacob-Friesen/obscurejs/blob/master/2014/prototypalInheritance.js

#javascript #inheritance #object orientation #object.create #ecma5 #programming #coding #web development #cheese #obscure

2 notes · View notes

kazu69 · 12 years ago

Link

#javascript #array #ecma5

1 note · View note

pignose-barn · 8 years ago

Text

자바스크립트 모듈 제공을 위한 AMD, CommonJS 그리고 RequireJS 소개

자바스크립트는 편리한 언어이다.

필자는 자바스크립트의 유연함과 고차함수, 익명함수 사용의 편리함과 직관적은

정말이지 엄청난 매력을 가지고 있다고 생각한다.

이번 포스팅에는 자바스크립트가 모듈을 제공하기 위해서

AMD, CommonJS를 알아보고 RequireJS에 대해서도 소개하고자 한다.

서론

필자는 오픈소스를 자주 사용한다.

그리고 오픈소스 기여도 자주 하는편이라고 생각된다.

오픈소스 참여를 할 때, 깃허브를 많이 사용하는데

여러분도 이 고양문어(옥토캣)을 많이 보셨을 거라 생각한다.

필자가 기여하는 프로젝트 중에

달력 컴포넌트를 만들어주는 자바스크립트 프로젝트가 있다.

이 곳에서 해당 프로젝트를 확인 할 수 있다.

이 코딱지 만한 프로젝트도 점점 사용자들이 이용해주면서

기능을 확장하고 있는데

최근에 AMD, CommonJS 지원 작업을 한 적이 있는데

작업을 진행하면서 발생한 크고작은 이슈에서 얻은 경험을 공유하고자 한다.

시작하기 앞서 이 글을 읽어보면 좋을 것 같다. (4년도 더 된 글이다..)

배경

자바스크립트는 파이썬, 루비, 다른 스크립트 언어 계열과 차이점이 존재한다.

바로 모듈 사용의 표준이 존재하지 않다는 것이다. (ECMA5 기준)

https://gist.github.com/KennethanCeyer/6d6ba68b76354398f770b1e0adc0b8e2

파이썬 모듈 사용

https://gist.github.com/KennethanCeyer/7d02f92ba85c16533668bfe6cdd6e4a5

루비 모듈 사용

Node.js를 사용하고 있는 개발자들은 module.exports를 통해 모듈을 정의하고

require() 함수를 통해 정의한 모듈을 불러와 사용하고 있다.

이곳을 통해 Node.js에서 모듈을 어떤식으로 사용하는 지 알 수 있다.

이러한 방식을 CommonJS로 불린다.

https://gist.github.com/KennethanCeyer/d4848af11711a3ab3f65653449b32c43

Node.js 모듈 형태를 보면 다른언어에 비해 모듈제공이 조금 차이가 있다.

module.exports와 exports 두개를 사용하는데

이런 제공방식은 혼동을 초래하기도 한다.

필자는 그래도 Node.js의 모듈 형식에 대해서 크게 불만을 가지고 있지 않다.

문제는 프론트엔드에서는 이런 모듈 제공방식이 없었다는 것이다!!

https://gist.github.com/KennethanCeyer/609879cb173368093316eb7de667f54b

그나마 비슷하게 모듈 제공방식을 따라해봤다.

프론트엔드에서 사용하는 자바스크립트는 DOM 오브젝트를 사용하고 있다.

전역 오브젝트인 window를 사용하면 다른 자바스크립트 파일에 리소스를 전달 할 수 있다.

하지만 이것도 사용하는 HTML에서 불러오는 모듈 파일을 먼저 로드해야

문제가 없이 작동된다.

즉 대상 모듈이 존재 할 수도, 존재하지 않을 수도 있는 상태가 벌어진다. (으아아악!)

하지만 프론트엔드에서 사용하는 프로젝트도 규모 커지면 커질수록

모듈의 필요성은 커져갔고

그렇게 AMD 방식과 CommonJS 방식 두개의 모듈 정의 규칙이 생기게 되었다.

사실 두개 말고도 ES2016, ES6, System.register 등등의 모듈제공 방식도 있지만

여러분의 정신건강을 위해 비밀로한다... (이미 비밀이 아니잖아!!)

AMD

AMD는 Asynchronous Module Definition (비동기 모듈 정의) 규칙이다.

https://github.com/amdjs/amdjs-api/wiki/AMD에서 자세한 내용을 확인 할 수 있다.

https://gist.github.com/KennethanCeyer/3c78f7c18c3519355509e2174103d633

AMD의 규칙을 이용해서 정의해봤다.

브라우저에서 모듈을 정의하고 불러오는 기능을 사용하기 위해서는

AMD의 규칙을 따르는 도구를 사용해야 하는데,

위의 코드에서는 RequireJS를 사용했다.

(RequireJS에 대한 설명은 http://requirejs.org/에서 확인 할 수 있다.)

위 사진에서 math.js는 main.js의 require 함수에 의해 동적으로 로딩되었다.

AMD 관련한 글 중에

AMD is Not the Answer(AMD는 해답이 아니다.)라는 글이 있다.

여기서는 AMD의 정의구조와 HTTP 동적 로딩을 비판하고 있는데 관심있는 분들은

한번 읽어보시길 바란다.

필자는 이렇게 생각한다.

AMD와 CommonJS 둘 모두 프론트엔드 브라우저에서 동적 로딩을 할 경우

페이지가 열리기 전까지 수많은 JS를 사용자가 페이지를 열어볼 때 불러오므로

부하가 발생하게 된다. (캐시를 해도 느린건 마찬가지)

여러분이 생각하는 1~20개의 자바스크립트 파일 로딩이 아니다.

몇 백개의 자바스크립트를 매 사용자가 페이지를 전환할 때마다 불러 온다고 생각해보자...

AMD, CommonJS 모두 비동기 통신을 통해 파일을 동적으로 불러오는 경우

성능의 이슈가 있기 때문에

보통 프로덕션 서버로 배포 할 때 번들링(Bundling) 작업을 진행하게 된다.

번들링은 이후 섹션에서 자세히 설명하도록 하겠다.

아까전에 얘기했던 오픈소스 프로젝트 PIGNOSE Calendar는

AMD 스타일로 모듈을 정의한다.

소스코드를 통해 확인이 가능하다.

그렇다고 RequireJS를 사용하지 않는 프로젝트에서

해당 프로젝트 소스를 불러와도 (이를테면 <script> 태그를 통해 로딩 시)

소스는 문제없이 작동해야한다.

AMD는 define 함수와 require 함수를 통해 모듈 정의와 로딩을 진행하는데

이 두가지 함수 모두 브라우저에서 인식 할 수 있는 함수가 아니다.

따라서 아까 우리는 require.js 스크립트를 추가적으로 불러와

브라우저에서도 모듈 정의와 로딩이 동작하도록 했다.

하지만 라이브러리에서 require.js 파일을 의존하여

같이 빌트-인 하기에는 require.js 소스코드 용량이 크다.. (18KB)

RequireJS 측에서는 이렇게 AMD를 사용하지만 라이브러리 형태로 제공해야하는

프로젝트를 위하여 RequireJS의 ��니마이즈 버전인 Almond(아몬드)를 제공한다.

아몬드의 설명에 따르면 gzip과 클로저 컴파일러를 이용할 때 약 1킬로바이트의 용량이 된다고 한다.

필자는 RequireJS를 번들링 하기 위해 Grunt Task(그런트 테스크)를 사용하는데

그런트 RequireJS 테스트 설명을 보면

almond 빌트 인이 명시되어있다.

여러가지 유명 자바스크립트 라이브러리를 살펴봐도

대부분 아몬드를 빌트인 하여 제공하고 있다.

CommonJS

아까 설명한 것과 같이 Node.js 진영에서는 CommonJS를 기본으로 사용하고 있다.

그 외에도 tsconfig에서 commonjs로 모듈을 정의해도 CommonJS로 정의가 된다.

CommonJS 제공이 중요한 이유가

당연하게도 Node.js에서 모듈을 불러오는 기본 ��타일이 CommonJS이기 때문에

프론트엔드 라이브러리일지라도 Node.js 코드를 통해 유닛 테스팅을 하는 경우

혹은 moment, underscore처럼 Node.js에서도 사용 가능해야하는 라이브러리 일 경우

CommonJS 모듈 형태도 제공해야 한다. (맙소사, 저 울어도 되요?)

번들링

번들링을 쉽게 설명하자면

여태까지 여러분이 모듈들을 싸질러놓은 똥을 하나의 단일 파일로 취합하는 과정이다.

앞서 말씀드린 모듈 타입(AMD, CommonJS, ES2015, ES6 etc)을

분석하고 거기서 불러오는 파일을 파악하여

하나로 모아주는 번들러(Bundler)가 필요한데.

많이 사용하는 번들러 종류는 아래와 같다.

Webpack

Rollup.js

Jspm

Browserify

Grunt와 Gulp와 같은 빌드테스크 도구에서도 플러그인을 연결하여

번들링을 진행 할 수 있다.

PIGNOSE Calendar는 앞서 말했듯 Grunt를 사용하여

RequireJS를 번들링하고 Almond를 묶어서

번들러의 선택은 여러분의 자유지만

여러분의 정신건강 상 웹팩(Webpack) 번들러를 사용하시기를 권장드린다.

필자는 AngularJS 2 AOT 를 사용할 때 그곳에 명시된 롤업JS(Rollup.js)를 사용했으나

무수한 경고(Warning)이 표시되었고

AngularJS2에서는 무슨일에선지 그것을 무시하는 코드를 넣어 공식페이지에 공개했다.

그 때문에 필자는 웹팩(Webpack) 버전 2로 교체하고 잘 쓰고 있다.

참고로 Webpack 1에서는 AngularJS AOT를 번들링 할 때 Uglify에서 에러가 발생한다.

아무도 해결방법을 공유안해서 필자가 직접 했다고 한다.

혹시 같은 문제를 겪는 분은 이 링크를 살펴보시길 바란다.

AngularJS 2 AOT를 적용하시고자 하신다면 Webpack 2를 사용하시는 게 정신건강에 좋다.

배포

좀 전에 얘기드린바와같이

우리의 아름다운 자바스크립트 프론트엔드 환경에서는

제공하는 라이브러리를 어떤식으로 호출 할지 모른다.

require([``], function(module) {})로 사용 할 수도 있고. (AMD)

var module = require(``)로 사용 할 수도 있다. (CommonJS)

심지어 import { module } from ``; 형태로 사용 할 수도 있다. (ES6)

우리는 이런 모듈 방식을 모두 제공하는 팩토리 형태를 만들어야 한다.

심지어 이 팩토리 표현에 대해서는 마땅한 표준도 없다.

(세상에 마상에)

표준은 아니지만 UMD라는 친구가 있는데

Universal Module Definition의 약자이다.

여기서 제공하는 템플릿이 그래도 많이 사용되고 있는 듯 보인다.

힘내세요 프론트엔드 라이브러리/프레임워크 개발자 여러분..

피토하셔도 이해합니다..

이 글을 읽어보자

글의 제목은

It's Not Hard: Making Your Library Support AMD and CommonJS

(여러분의 라이브러리가 AMD와 CommonJS를 지원하는 것은 결코 어렵지 않습니다.)

인데 이 글의 분량이 어느정도인지 파악이 되는가?

여러분은 고작 다른언어에서는 기본적으로 제공하는 모듈 지원을 위해

이 정도의 글을 더 읽어야한다.

(모듈 지원도아니다, 지원하고 있는 모듈 외에 모듈 정의 호환 지원이다.)

본론으로 돌아와서,

앞서 말했던 PIGNOSE Calendar 플러그인은 AMD 모듈을 사용하고 있지만

CommonJS, Plaintype(<script>를 통해서 불러오는 경우)를 지원해야 했다.

이를 위해 하나의 Factory를 정의하게 되는데

기초 원리는 간단하다.

우선 아래 코드를 먼저 살펴보자.

https://gist.github.com/KennethanCeyer/19402abf4901a833052319ece54119d4

자바스크립트를 조금 공부하신분은 IIFE에 대해서 들어보셨을 것이다.

IIFE는 Immediate Invoked Function Expression의 약자로 즉시 함수 호출 표현식이다.

이걸 왜 사용하는지는 이곳에서 자세히 살펴보실 수 있다.

이것을 사용하는 주요 이유는 전역 함수와 지역 함수 구분을 위한 클로저 정의를 위해 사용한다.

아까 보여드린 Factory에서도 IIFE 형태의 호출 표현식을 사용하는데

root, factory 매개변수를 IIFE 형태로 전달한다.

root는 this가 전달되며 factory는 모듈로 제공될 함수가 전달된다.

IIFE에서는 각 모듈을 사용하는지 검사 한후 factory를 호출하게 된다.

PIGNOSE Calendar는 module.export (CommonJS) 형태에서

Mocha를 통한 Unit Test를 제공해야 하기 때문에

각종 의존라이브러리를 추가하여 부르게 된다.

그리고 Node.js 환경에서는 window, document가 존재하지 않기 때문에

window와 document를 jsdom을 통해 Mocking 하고있다.

결론

결론적으로 아직 자바스크립트의 모듈링 표준은 걸음마 단계이다.

아직 ECMA 6가 모든 브라우저에서 채택되지 않았기 때문에 (채택상태 보기)

과도기적인 면모를 보인다.

ECMA 6가 AMD와 CommonJS 스타일을 사용하지 않기 때문에

나중에는 AMD와 CommonJS 모두가 버려지는 아름다운 현상이 일어나진 않을지..

이곳에서 RequireJS를 지원하는 Grunt 설정을 볼 수 있다.

PIGNOSE Calendar는 모듈 호환을 제공하고 브라우저에서도 정상 동작한다.

이곳에서 확인해보자

여러분도 자바스크립트 모듈을 사용하고

빈틈 없는 멋진 개발자가 되보자.

(모듈 모르는 뇌 삽니다.)

#개발 #commonjs #requirejs #amd #es2015 #es6 #import #exports #module #almond #factory #webpack #rollupjs #angularjs #angularjs2 #ahead of time #aot #bundler #frontend

2 notes · View notes

9treeblog-blog · 12 years ago

Text

Javascript code performance review

Within the scope of my latest projects, I had to review a lot of performance details on JavaScript to determine best possible solutions for core functionalities and architecture.

If you follow the classic "by the book" rules, you should avoid, when possible:

loops

closures

object spawning

DOM access, specially DOM writes

DOM queries (find DOM objects)

Ok, but how bad is it? How do they compare to each other? What options do I have? Which are the best ways to get the same result?

This study focuses on answering these questions as best as possible in order to achieve an approximate scale on comparative performance results in JavaScript.

1. Loops

It's easy to intuitively understand unrolled loops are faster than having the loop itself. However for ease of development, we sometimes tend to use unnecessary loops for common tasks;

Take a look at http://jsperf.com/unrolling-loops

You can see the difference between running direct code vs doing the same in a loop is massive, really massive. Of course the unrolling above is way too much work unless you have a system where performance is hugely more important than anything else - including a huge file size...

But the overall point is, if it takes you only 3 or 4 more lines to do it and it doesn't involve extra functions call, etc, it's probably better just to unroll the loop.

2. Closures

Look at this example: http://jsperf.com/closure-vs-no-closure

Free code is, as expected, faster, followed by the function call and finally the closure. However the gap between each use case performance varies between implementations, we can see Chrome running free code much, much faster than having a closure, while other browsers can have a very close match between all use cases.

So what does it mean?

in average : - closure - slowest! - function call - 2x faster than closure; - free code - 4x faster faster than closure;

Finally I've confirmed this performance test in a practical case testing loops against "forEach" callbacks in http://jsperf.com/loops-vs-each-callbacks

You can see regular loops perform twice as fast, as expected. To put it in perspective this means running the function call alone, takes about the same time to run as this example's entire loop.

3. Object Spawning

Take a look at http://jsperf.com/instance-vs-object-create/4

We can see the new ECMA5 Object.create is, in average, as fast as instancing a new object from a function, with the exception of Chrome where instancing a function is clearly very, very optimised, along with creating direct object and arrays - actually, this is one of the reasons why JavaScript "is" so fast in Chrome.

As you can see, instancing is still faster than using a closure, about 2x faster more or less the same as a function call (by our previous example; But it will probably be much slower if you have a big prototype.

However be aware that creating an object or array directly actually takes longer than instancing, even if you use an interim functional call to get rid of the "new" keyword (eg. jQuery's $()).

To conclude I would say it is ok to use instances and objects altogether, however if there is something which can be easily done through simple function calls instead, use them.

4. DOM Access - read and write

Ok, this is a big one.

Let us start with an overview of the most common tasks: http://jsperf.com/dom-read-vs-dom-write/2

You can immediately identify that using single style reads and writes is much slower than using CSS classes, and, as one would expect, using computedStyle is always slower than regular reads and style writes are the absolute slowest - in fact, changing the same property via class is about 4x faster then a style.property write.

But wait a second! setAttribute and getAttribute are incredibly fast! Let's play around with them a little bit more and check out what is better/worse

4.1 Data API : attribute vs .dataset

You can see by the previous test results that using attributes is way faster. Clearly dataset.data hasn't been optimised yet.

However it is very likely as its use becomes more and more common, .dataset will very likely be optimised too.

4.2 attribute class vs .className :

http://jsperf.com/classname-vs-setattriubute-getattribute

Fairly close, but .className is still a faster solution, attributes loose in this case;

4.2.1 Extra: classList vs .className:

http://jsperf.com/classname-vs-classlist-showdown/2

Serves to show if your browser supports ECMA5 standards, classList is highly optimised; Use it.

4.3 style.property vs setAttribute style :

http://jsperf.com/style-property-vs-setattribute-style

Ok, style is clearly optimised vs setAttribute use as expected, except... Wait... What?! What the hell is up with firefox?? Why is it so fast?

I double checked and it actually changes the style as expected, it really works! And it appears to be 4x faster than using style.property on all other browsers... A setAttribute("style") + computedStyle read in Firefox is still faster than a style.property read in chrome! There is something really strange going on here... - if anyone can explain why this is happening please let me know in the comments.

So overall writes are indeed slower than DOM reads, but not that slower. Actually getting the computedStyle takes much longer that a write.

So: avoid computedStyle reads, and if you do it, try doing it only once until you actually change it again.

DOM queries and selectors

Lastly, the DOM query selectors, here are the results: http://jsperf.com/dom-queries

When can clearly see the advantage of always using document.getElementById as it is twice as fast as any other option.

If you cannot rely on a specific id but are still just looking for one item, use querySelector as it is, for the most part, the second fastest option.

If you really require more than one items returned, consider first if you can use document.getElementsByClassName, and only use querySelectorAll as a last resource.

Remember that having up to 5 or 6 getElementById calls is still faster than a single querySelectorAll call. Use it wisely.

Comparing them all together

For the sake of fully grasping the concept, I have combined a jsperf with a mix of a few results above and put them all against each other.

Here it is: http://jsperf.com/mother-of-comparisons

The results table:

So, as you can see, messing with CSS things always cost you the most, no matter what. All code you can do is fairly insignificant comparing to it, but if you want to go into performance details, here you have it:

Results: (best to worst)

Simple code & functions

Closures

getElementById

instance new Object

messing with DOM objects without reflows* - most attributes, etc

querySelectorAll

messing with DOM objects that triggers reflows* - CSS, classes, etc

1-5 everything is pretty fast

6-7 avoid when possible (at least 20x slower than 1-4)

* Note: reflows is, in a simplistic view, when the browser has to redraw all or part of the page - more on this later ;)

#javascript #ecma5 #performance #html5

2 notes · View notes