2018年10月の更新
フロントエンド開発についてまだ不明な点がある場合は、ここで優れたリソースを簡単に確認できます。
https://github.com/kamranahmedse/developer-roadmap
2018年6月の更新
最初からJavaScriptを使用していなければ、最新のJavaScriptを学ぶのは大変です。あなたが新しい人なら、より良い概観を得るためにこの優れた文書をチェックすることを忘れないでください。
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70
2017年7月の更新
最近、2017年のフロントエンド開発への取り組み方について、Grabチームから非常に包括的なガイドを見つけました。以下のように確認できます。
https://github.com/grab/front-end-guide
世の中にはたくさんのツールがあり、それぞれが異なる面で私たちに利益をもたらすので、私はかなり長い間これも探していました。コミュニティはのようなツールに分かれていますBrowserify, Webpack, jspm, Grunt and Gulp
。についても聞こえるかもしれませんYeoman or Slush
。それは実際には問題ではなく、明確な道筋を理解しようとするすべての人を混乱させるだけです。
とにかく何か貢献したいです。
1.パッケージマネージャー
パッケージマネージャーは、次のようなライブラリであるプロジェクトの依存関係のインストールと更新を簡素化jQuery, Bootstrap
します。
すべてのライブラリWebサイトの閲覧、アーカイブのダウンロードと解凍、ファイルのプロジェクトへのコピー—これらはすべて、ターミナルのいくつかのコマンドで置き換えられます。
NPM
はNode JS package manager
、ソフトウェアが依存するすべてのライブラリを管理するのに役立ちます。呼び出すファイルでニーズを定義し、コマンドラインでpackage.json
実行npm install
します。その後、パッケージがダウンロードされ、使用できるようになります。front-end and back-end
ライブラリの両方に使用できます。
Bower
:フロントエンドパッケージ管理の場合、概念はNPMと同じです。すべてのライブラリはという名前のファイルに保存され、コマンドラインでbower.json
実行さbower install
れます。
最大の違いBower
とは、NPM
バウアーは、以下のようにフラットな依存関係ツリーを必要としながら、NPMは、ネストされた依存関係ツリーを行うということです。
引用バウアーと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
公開されたの新しいパッケージマネージャ。また、Yarnを使用すると、とレジストリの両方を使用してパッケージをフェッチできます。以前にパッケージをインストールしたことがある場合は、を容易にするキャッシュコピーを作成します。Facebook
NPM
NPM
Bower
yarn
offline package installs
jspm
:はSystemJS
、動的ES6
モジュールローダーの上に構築されたユニバーサルモジュールローダーのパッケージマネージャーです。独自のルールセットを備えた完全に新しいパッケージマネージャーではなく、既存のパッケージソースの上で動作します。そのままの状態でGitHub
、およびで動作しnpm
ます。Bower
ベースのパッケージのほとんどはに基づいGitHub
ているため、これらのパッケージもを使用しjspm
てインストールできます。簡単にインストールできるように、よく使用されるフロントエンドパッケージのほとんどをリストするレジストリがあります。
間で異なる参照してくださいBower
とjspm
:
パッケージマネージャを:JSPM対バウアー
2.モジュールローダー/バンドル
あらゆる規模のほとんどのプロジェクトでは、コードが複数のファイルに分割されます。各ファイルに個別の<script>
タグを含めるだけで<script>
、新しいhttp接続が確立されます。また、モジュール化の目標である小さなファイルの場合、接続のセットアップに、データの転送よりも大幅に時間がかかる場合があります。スクリプトのダウンロード中は、ページのコンテンツを変更できません。
- ダウンロード時間の問題は、単純なモジュールのグループを1つのファイルに連結し、それを縮小することでほぼ解決できます。
例えば
<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>
コンピューターはそれをあなたができるよりも上手に行うことができます。そのため、ツールを使用してすべてを1つのファイルに自動的にバンドルする必要があります。
その後、我々は話を聞いた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 などを含むすべての静的アセットを1つのファイルにバンドルします。また、さまざまなタイプのローダーを介してファイルを処理することもできます。JavaScript
with CommonJS
またはAMD
modules構文を記述できます。ビルドの問題を根本的により統合的かつ独断的に攻撃します。では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
モジュールローダーポリフィルの上に構築されており、使用されているフォーマットを検出して適切に処理するのに十分スマートです。SystemJS
ES6コード(Babel
またはTraceur
)や、TypeScript
およびなどの他の言語もトランスパイルできます。CoffeeScript
プラグインを使用。
node module
それが何であり、なぜそれがブラウザ内にうまく適合していないのか知りたいです。
より有用な記事:
なぜjspm
そしてSystemJS
?
主な目標の一つES6
モジュール性は、(インターネット上のどこからでも任意のJavaScriptライブラリをインストールして使用することが本当に簡単にすることですGithub
、npm
など、)。必要なものは2つだけです。
- ライブラリをインストールする単一のコマンド
- ライブラリをインポートして使用するための1行のコード
だから jspm
、あなたはそれを行うことができます。
- コマンドを使用してライブラリをインストールします。
jspm install jquery
- 1行のコードでライブラリをインポートします。HTMLファイル内で外部参照する必要はありません。
display.js
var $ = require('jquery');
$('body').append("I've imported jQuery!");
次にSystem.config({ ... })
、モジュールをインポートする前に、これらを構成します。通常、実行jspm init
すると、という名前のファイルがありますconfig.js
この目的のために。
これらのスクリプトを実行させるために、我々は負荷に必要system.js
とconfig.js
HTMLページに。その後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
with 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、フォントなどのフォルダーを作成することを計画しているとします。あなたはただインストールすることができます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でこれらの知識を検索しているときは常に質問が一番上に表示されるため、要約して回答することにしました。お役に立てば幸いです。