2018 년 10 월 업데이트
여전히 프론트 엔드 개발에 대해 잘 모를 경우 여기에서 훌륭한 리소스를 빠르게 살펴볼 수 있습니다.
https://github.com/kamranahmedse/developer-roadmap
2018 년 6 월 업데이트
처음부터 존재하지 않았다면 최신 JavaScript를 배우는 것은 어렵습니다. 새로 온 사람이라면 더 나은 개요를 위해이 훌륭한 글을 확인하십시오.
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70
2017 년 7 월 업데이트
최근에 Grab 팀에서 2017 년 프런트 엔드 개발에 접근하는 방법에 대한 포괄적 인 가이드를 찾았습니다. 아래에서 확인할 수 있습니다.
https://github.com/grab/front-end-guide
나는 또한 많은 도구가 있고 각 도구가 다른 측면에서 우리에게 이익이되기 때문에 꽤 오랫동안 이것을 찾고 있습니다. 커뮤니티는와 같은 도구로 나뉩니다 Browserify, Webpack, jspm, Grunt and Gulp. 에 대한 소식을들을 수도 있습니다 Yeoman or Slush. 그것은 실제로 문제가 아니며, 분명한 진전을 이해하려는 모든 사람들에게 혼란을줍니다.
어쨌든 뭔가 공헌하고 싶습니다.
1. 패키지 관리자
패키지 관리자는 다음과 같은 라이브러리 인 프로젝트 종속성의 설치 및 업데이트를 단순화합니다 jQuery, Bootstrap.-사이트에서 사용되며 사용자가 작성하지 않은 모든 것.
모든 라이브러리 웹 사이트 찾아보기, 아카이브 다운로드 및 압축 풀기, 파일을 프로젝트에 복사-이 모든 것이 터미널의 몇 가지 명령으로 대체됩니다.
NPM약자 : Node JS package manager소프트웨어가 의존하는 모든 라이브러리를 관리하는 데 도움이됩니다. 커맨드 라인에서 호출 package.json되고 실행 되는 파일에서 요구 사항을 정의한 npm install다음 BANG, 패키지가 다운로드되어 사용할 수 있습니다. front-end and back-end라이브러리 모두에 사용할 수 있습니다 .
Bower: 프런트 엔드 패키지 관리의 경우 NPM과 개념이 동일합니다. 모든 라이브러리라는 이름의 파일에 저장 bower.json한 다음 실행 bower install명령 줄에서.
가장 큰 차이점 Bower및 NPM정자 아래로 평면 종속성 트리를 요구하면서 NPM 중첩 된 종속성 트리를 않는다는 것입니다.
Bower와 npm의 차이점 은 무엇입니까?
NPM
project root
[node_modules] // default directory for dependencies
-> dependency A
-> dependency B
[node_modules]
-> dependency A
-> dependency C
[node_modules]
-> dependency B
[node_modules]
-> dependency A
-> dependency D
나무 그늘
project root
[bower_components] // default directory for dependencies
-> dependency A
-> dependency B // needs A
-> dependency C // needs B and D
-> dependency D
에 대한 일부 업데이트가 있습니다 npm 3 Duplication and Deduplication. 자세한 내용은 문서를여십시오.
Yarn:위한 새로운 패키지 관리자 JavaScript 출판 에 의해 Facebook에 비해 좀 더 장점으로 최근 NPM. 그리고 Yarn을 사용하면 여전히 NPM및 Bower레지스트리를 모두 사용 하여 패키지를 가져올 수 있습니다 . 이전에 패키지를 설치 한 경우을 yarn용이하게하는 캐시 된 사본을 만듭니다 offline package installs.
jspm: SystemJS동적 ES6모듈 로더 위에 빌드 된 범용 모듈 로더 의 패키지 관리자입니다 . 자체 규칙 세트가있는 완전히 새로운 패키지 관리자가 아니라 기존 패키지 소스에서 작동합니다. 기본적으로 GitHub및로 작동합니다 npm. 대부분의 Bower기본 패키지는를 기반으로 GitHub하므로 이러한 패키지를 사용하여 설치할 수도 jspm있습니다. 보다 쉬운 설치를 위해 일반적으로 사용되는 프런트 엔드 패키지를 대부분 나열하는 레지스트리가 있습니다.
다른 사이의 참조 Bower와 jspm:
패키지 관리자 : 니혼 전자 : JSPM 대 바우어를
2. 모듈 로더 / 번들링
규모에 관계없이 대부분의 프로젝트는 코드를 여러 파일로 분할합니다. 각 파일을 개별 <script>태그 와 함께 포함시킬 수 있지만 <script>새로운 http 연결을 설정하고 모듈화의 목표 인 작은 파일의 경우 연결 설정 시간이 데이터 전송보다 훨씬 오래 걸릴 수 있습니다. 스크립트를 다운로드하는 동안 페이지에서 내용을 변경할 수 없습니다.
- 간단한 모듈 그룹을 단일 파일로 연결하고 축소함으로써 다운로드 시간 문제를 크게 해결할 수 있습니다.
예 :
<head>
<title>Wagon</title>
<script src=“build/wagon-bundle.js”></script>
</head>
- 그러나 성능은 유연성을 희생시킵니다. 모듈에 상호 의존성이있는 경우, 이러한 유연성 부족이 가장 두드러 질 수 있습니다.
예 :
<head>
<title>Skateboard</title>
<script src=“connectors/axle.js”></script>
<script src=“frames/board.js”></script>
<!-- skateboard-wheel and ball-bearing both depend on abstract-rolling-thing -->
<script src=“rolling-things/abstract-rolling-thing.js”></script>
<script src=“rolling-things/wheels/skateboard-wheel.js”></script>
<!-- but if skateboard-wheel also depends on ball-bearing -->
<!-- then having this script tag here could cause a problem -->
<script src=“rolling-things/ball-bearing.js”></script>
<!-- connect wheels to axle and axle to frame -->
<script src=“vehicles/skateboard/our-sk8bd-init.js”></script>
</head>
컴퓨터는 당신이 할 수있는 것보다 더 잘할 수 있으므로 모든 것을 하나의 파일로 자동 묶는 도구를 사용해야합니다.
그리고 우리가 듣고 약 RequireJS, Browserify, Webpack및SystemJS
RequireJS:는 JavaScript파일 및 모듈 로더입니다. 브라우저 내 사용에 최적화되어 있지만와 같은 다른 JavaScript 환경에서 사용할 수 있습니다 Node.
예 : myModule.js
// package/lib is a dependency we require
define(["package/lib"], function (lib) {
// behavior for our module
function foo() {
lib.log( "hello world!" );
}
// export (expose) foo to other modules as foobar
return {
foobar: foo
}
});
에서 의존성으로 main.js가져 와서 myModule.js사용할 수 있습니다.
require(["package/myModule"], function(myModule) {
myModule.foobar();
});
그리고 우리 HTML에서와 함께 사용을 참조 할 수 있습니다 RequireJS.
<script src=“app/require.js” data-main=“main.js” ></script>
더에 대한 읽기 CommonJS및 AMD쉽게 이해를 얻을 수 있습니다.
CommonJS, AMD와 RequireJS의 관계는 무엇입니까?
Browserify: CommonJS브라우저에서 포맷 된 모듈을 사용할 수 있도록 설정 합니다. 결과적으로 Browserify모듈 번 들러만큼 많은 모듈 로더가 아닙니다. Browserify완전히 빌드 타임 도구이며, 클라이언트 측에로드 할 수있는 코드 번들을 생성합니다.
node & npm이 설치된 빌드 머신으로 시작하고 패키지를 가져 오십시오.
npm install -g –save-dev browserify
CommonJS형식으로 모듈 작성
//entry-point.js
var foo = require('../foo.js');
console.log(foo(4));
그리고 행복 할 때 번들로 명령을 발행하십시오.
browserify entry-point.js -o bundle-name.js
Browserify는 진입 점의 모든 종속성을 재귀 적으로 찾아서 단일 파일로 어셈블합니다.
<script src=”bundle-name.js”></script>
Webpack: JavaScript이미지, CSS 등을 포함한 모든 정적 자산을 단일 파일로 묶습니다 . 또한 다른 유형의 로더를 통해 파일을 처리 할 수 있습니다. JavaScriptwith CommonJS또는 AMD모듈 구문을 작성할 수 있습니다 . 기본적으로보다 통합적이고 의견이 많은 방식으로 빌드 문제를 공격합니다. 에서 Browserify사용 Gulp/Grunt하고 변환 및 플러그인의 긴 목록이 작업을 수행하세요. Webpack상자 밖으로 제공 충분한 전력은 일반적으로 필요가 없습니다 Grunt또는 Gulp전혀.
기본 사용법은 간단합니다. Browserify와 같은 Webpack을 설치하십시오.
npm install -g –save-dev webpack
그리고 명령에 진입 점과 출력 파일을 전달하십시오.
webpack ./entry-point.js bundle-name.js
SystemJS:는 오늘날 사용되는 일반적인 형식 ( CommonJS, UMD, AMD, ES6) 중 하나를 런타임에 모듈을 가져올 수 있는 모듈 로더입니다 . ES6모듈 로더 폴리 필 위에 구축되며 사용중인 형식을 감지하고 적절하게 처리 할 수있을 정도로 똑똑합니다. SystemJSES6 코드 ( Babel또는로 Traceur) 또는 플러그인 TypeScript과 같은 다른 언어를 변환 할 수도 CoffeeScript있습니다.
무엇이 무엇 node module이고 왜 브라우저에 잘 맞지 않는지 알고 싶습니다 .
더 유용한 기사 :
왜 jspm그리고 SystemJS?
의 주요 목표 중 하나 ES6모듈화 (정말 간단하게 설치하고 인터넷에 어느 곳에서 모든 자바 스크립트 라이브러리를 사용하는 것입니다 Github, npm등). 두 가지만 필요합니다.
- 라이브러리를 설치하는 단일 명령
- 라이브러리를 가져 와서 사용하기위한 한 줄의 코드
으로 jspm할 수 있습니다.
- 다음 명령으로 라이브러리를 설치하십시오.
jspm install jquery
- HTML 파일 내부에서 외부 참조 할 필요없이 한 줄의 코드로 라이브러리를 가져옵니다.
display.js
var $ = require('jquery');
$('body').append("I've imported jQuery!");
그런 다음 System.config({ ... })모듈을 가져 오기 전에 이러한 내용을 구성 하십시오. 일반적으로 run jspm init일 config.js때이 목적으로 이름 이 지정된 파일 이 있습니다.
이러한 스크립트를 실행하려면 HTML 페이지 를로드 system.js하고 로드해야 config.js합니다. 그런 display.js다음 SystemJS모듈 로더를 사용하여 파일을 로드합니다 .
index.html
<script src="jspm_packages/system.js"></script>
<script src="config.js"></script>
<script>
System.import("scripts/display.js");
</script>
참고 : Angular 2가 적용 npm한 Webpack것처럼 사용할 수도 있습니다 . 이후는 jspm통합하기 위해 개발되었다 SystemJS그것은 기존의 정상 작동 npm당신의 대답은 당신에게 달려 있으므로, 소스.
3. 작업 러너
작업 러너 및 빌드 도구는 주로 명령 줄 도구입니다. 우리가 그것들을 사용해야하는 이유 : 한마디로 : 자동화 . 축소, 컴파일, 단위 테스트, 린트 닝 과 같은 반복적 인 작업을 수행 할 때 수행해야하는 작업이 줄어 듭니다 .
Grunt: 개발 환경에서 자동화를 생성하여 코드를 사전 처리하거나 구성 파일을 사용하여 빌드 스크립트를 작성할 수 있으며 복잡한 작업을 처리하기가 매우 어려워 보입니다. 지난 몇 년 동안 인기가있었습니다.
모든 작업 Grunt은 서로 다른 플러그인 구성의 배열로, 엄격하게 독립적이며 순차적으로 순차적으로 실행됩니다.
grunt.initConfig({
clean: {
src: ['build/app.js', 'build/vendor.js']
},
copy: {
files: [{
src: 'build/app.js',
dest: 'build/dist/app.js'
}]
}
concat: {
'build/app.js': ['build/vendors.js', 'build/app.js']
}
// ... other task configurations ...
});
grunt.registerTask('build', ['clean', 'bower', 'browserify', 'concat', 'copy']);
Gulp: 자동화 Grunt는 구성 과 유사 하지만 JavaScript노드 애플리케이션과 같은 스트림으로 작성할 수 있습니다 . 요즘을 선호하십시오.
이것은 Gulp샘플 작업 선언입니다.
//import the necessary gulp plugins
var gulp = require('gulp');
var sass = require('gulp-sass');
var minifyCss = require('gulp-minify-css');
var rename = require('gulp-rename');
//declare the task
gulp.task('sass', function(done) {
gulp.src('./scss/ionic.app.scss')
.pipe(sass())
.pipe(gulp.dest('./www/css/'))
.pipe(minifyCss({
keepSpecialComments: 0
}))
.pipe(rename({ extname: '.min.css' }))
.pipe(gulp.dest('./www/css/'))
.on('end', done);
});
더보기 : https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.fte0nahri
4. 발판 도구
Slush and Yeoman: 그들과 함께 시작 프로젝트를 만들 수 있습니다. 예를 들어, HTML 및 SCSS를 사용하여 프로토 타입을 구축하려는 경우 scss, css, img, fonts와 같은 일부 폴더를 수동으로 생성하는 대신. yeoman간단한 스크립트를 설치 하고 실행할 수 있습니다 . 그런 다음 여기에 당신을 위해 모든 것이 있습니다.
자세한 내용은 여기를 참조 하십시오 .
npm install -g yo
npm install --global generator-h5bp
yo h5bp
더보기 : https://www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express
내 답변은 실제로 질문 내용과 일치하지 않지만 Google에서 이러한 지식을 검색 할 때 항상 맨 위에 질문이 표시되므로 요약하여 답변하기로 결정했습니다. 도움이 되셨기를 바랍니다.