作為一名IT行業的工作者，同時也是一名計算機專業的研究生導師，我來回答一下這個問題。
首先，前端開發的就業還是不錯的，而且隨著大數據、人工智能的發展，未來前端開發的發展前景將非常值得期待。
Web開發是前端開發的重要組成部分，但是隨著移動互聯網的發展，前端開發被賦予了更多的意義，目前前端開發不僅包括傳統的Web開發，也包括移動端開發（Android開發、iOS開發等），另外還包括各種大型互聯網平臺推出的眾多小程序開發。
另外，隨著大數據、物聯網的發展，前端開發目前也涉及到數據呈現端開發和嵌入式設備的開發領域，目前JavaScript在嵌入式領域也有一定的應用。相信隨著5G標準的落地應用，前端的開發場景將得到進一步的拓展，IT行業也會釋放出更多的前端開發崗位。
雖然前端開發的崗位比較多，但是由于前端開發已經經歷了多年的發展，而且前端開發的崗位門檻相對比較低，所以從業人員的數據也比較多，這在一定程度上提升了崗位競爭的難度。要想在當前的職場環境下提升自身的崗位競爭力，需要做好以下幾件事：
第一：掌握一定的移動端開發知識。除了傳統的Web開發技術之外，需要進一步掌握移動端開發知識，包括Android開發知識和iOS開發知識。
第二：掌握一定的后端開發知識。隨著Nodejs的應用，目前前端開發后端化也是一個比較明顯的發展趨勢，所以掌握一定的后端開發知識是有必要的。
第三：掌握一定的大數據知識。大數據正處在落地應用的初期，未來在大數據領域將釋放出大量的前端開發需求，所以掌握一定的大數據知識也會提升自身的崗位競爭力。
我從事互聯網行業多年，目前也在帶計算機專業的研究生，主要的研究方向集中在大數據和人工智能領域，我會陸續寫一些關于互聯網技術方面的文章，感興趣的朋友可以關注我，相信一定會有所收獲。
如果有互聯網方面的問題，或者考研方面的問題，都可以咨詢我，謝謝！
去年一篇《在 2016 年學 JavaScript 是一種什么樣的體驗？》嚇壞了很多想要入行新同學和入行很久的老司機，感覺一下子前端世界已經看不懂了，做個頁面要那么麻煩？當然如果你只是想要一個簡單的靜態頁面，這么玩兒就是殺雞用牛刀了。但如果你準備開發一個 Web App，之后會不斷的迭代，有一個舒適的開發環境是及其重要的，那么底怎么樣的環境才會是舒適愉悅的呢？
比如這樣的一個環境：資源依賴可以安裝并模塊化引用、可以使用很酷的 ES6 語法、可以使用 SASS 預處理器寫 CSS、代碼可實時更新而不用一遍遍的手動刷新頁面，這樣的開發環境你會不會覺得很爽！好，我們這就來配置一個這樣的環境！
基礎環境
首先，你需要一個 Node.js，然后 NPM 也會隨著 Node.js 一起裝上。
什么是 NPM ？簡單的說 NPM 是用來下載安裝 Node.js 的第三方工具包的一個管理器。當然，現在也可以安裝瀏覽器中使用的包。提到包管理器，就不得不說下 Bower，Bower 之前一直是前端庫管理工具，一開始 NPM 只能發布和安裝 Node.js 的包，所以 Bower 盛行一時，隨著 CommonJS 的普及，以及 UMD 規范的出現，讓 NPM 安裝前端瀏覽器 js 包成為了可能，隨著 NPM 生態的成熟，Bower 也就慢慢被人淡忘了～
Node.js 安裝完成后，可以執行以下命令驗證安裝是否成功：
$ node -v v6.11.0 $ npm -v 3.10.10
別急，Node.js 的部分還沒完，國內通過 NPM 的官方源安裝依賴好像很慢，動不動就要等上半天，如何解決？我們可以裝一個 nrm！nrm 是 npm registry 管理工具，可以自由切換 npm registry，然后命令行使用時依然是 npm ，國內有很多 npm 的鏡像，比如淘寶的 cnpm ，然而很多公司都架設了自己的私庫。什么是私庫？私庫就是只能在公司內網訪問，不能發布到 npm 共享平臺的 npm 包，比如我們大公司私庫的 registry 的名稱就是 hnpm。不細說了，我們先裝一個試試：
$ npm install -g nrm
然后根據官方教程我們先切一個國內的 registry，比如大淘寶的：
$ nrm use cnpm
然后用 NPM 隨便安裝個什么，看看速度如何？是不是很快^_^
等等，Node.js 還有。有的開發依賴包是有 Node.js 版本依賴的，我們知道 Node.js 不同大版本的功能還是差別很大的，但我們又不會一遍遍的卸載安裝吧？感覺好蠢！好吧，我們當然可以裝一個nvm，nvm？好像和 nrm 很像！nvm 是 Node.js 的版本管理工具，可以在多個終端切換和運行不同的 Node.js 版本，可以到這里參考具體的安裝教程。不過 nvm 在 windows 下不能使用，沒關系，這里還有幾個替代工具：nvm-window，gnvm 供你選擇。
同樣，我們執行下命令驗證安裝成果：
$ nvm --version 0.33.0
項目初始化
有了上面的工具我們就可以開始創建一個項目了，我們執行以下命令來開始一個項目：
mkdir my-app cd my-app npm init
執行 npm init 后你會看到你需要輸入項目的一些信息，完成后回車確認，然后npm會在根目錄下創建一個叫 package.json 的文件，你之后通過 --save 或者 --save-dev 安裝的依賴包都會出現在這個文件里。
先不管那么多，我們在根目錄下創建一個 src 目錄，然后在 src 下創建index.js、index.html……，好吧，你可以按照下面的結構新建文件：
. ├── package.json └── src ├── index.css ├── index.html └── index.js
在以下文件中輸入代碼：
index.js：
var el = document.createElement('div'), text = document.createTextNode('My App'); el.appendChild(text); document.body.appendChild(el);
index.html：
<!doctype html> <html> <head> <meta charset="utf-8" /> <title>My App</title> </head> <body> </body> </html>
我們要想辦法讓這個頁面跑起來，what??? 就這么簡單？，把js引入 index.html 不就完事兒了嘛？當然沒那么簡單，我們可是要搞高大上的東西的呢！
哈～跑題了，我們繼續。
首先我們要裝一個叫 webpack 的東西，它是一個模塊打包器，也就是我們俗稱的構建工具，之前的那些 Grunt，Gulp 也都是構建工具，但是這年頭流行 webpack 了！開個玩笑，webpack 的可擴展性和可插件化，以及把任何文件都視為模塊的概念得到了前端社區的一致推崇，而且在打包效率和按需分割文件上都是其他幾個構建工具無法相比較的，當然 webpack 的配置太靈活，官方文檔寫的太太太難看懂，也導致了很多初學者無從下手。
接下來我們就來配下這個神奇的工具吧。
自動構建
我們先安裝下 webpack：
npm install --save-dev webpack
然后在根目錄下新建一個 webpack.config.js 文件，輸入以下代碼：
let path = require('path'); module.exports = { entry: { app: path.resolve(__dirname, 'src', 'index.js') }, output: { filename: '[name].js', path: path.resolve(__dirname, 'dist') } };
但要想在瀏覽器中訪問還得有個本地服務器，好在 webpack 都幫我們想到了，我們可以裝一個webpack-dev-server：
npm install --save-dev webpack-dev-server
我們在 package.json 中增加個 npm scripts:
"scripts": { "start": "webpack-dev-server --port 3003" },
ok！我們執行下 npm start，在瀏覽器中訪問：http://localhost:3003。哎？好像哪里不對！是的，你得告訴 webpack，你的 bundle(打包后的 js)要插入到哪個 html 模板，前面說過，webpack 是插件化的，它把很多功能開放給了第三方來實現，他只是來負責拼裝的，好，現在我們需要安裝一個 html-webpack-plugin 插件：
npm install --save-dev html-webpack-plugin
修改下 webpack-config.js：
let HtmlWebpackPlugin = require('html-webpack-plugin'), path = require('path'); module.exports = { entry: { ... }, ... plugins: [ new HtmlWebpackPlugin({ template: path.resolve(__dirname, 'src', 'index.html') }) ] }
再次執行 npm start，頁面可以正常訪問了。
但是，這樣似乎有點 low，我們新增一個文件 utils.js，搞點es6語法：
. ├── package.json └── src ├── index.css ├── index.html ├── index.js + └── utils + └── utils.js
utils.js:
export function wordsToSentence(...words) { return words.join(' '); }
修改 index.js
+ import { wordsToSentence } from './utils/utils'; let el = document.createElement('div'), - text = document.createTextNode('My App'); + text = document.createTextNode( + wordsToSentence('Welcome', 'to', 'my', 'app!') + ); el.appendChild(text); document.body.appendChild(el);
刷新頁面后好像也沒什么異常（你肯定用了 chrome 吧！），仔細看控制臺的 source 的 app.js（你的 bundle）的代碼片段：
"use strict"; /* harmony export (immutable) */ __webpack_exports__["a"] = wordsToSentence; function wordsToSentence(...words) { return words.join(' '); }
值得注意的是，使用 ES6 時需要考慮那些沒有支持 ES6 的舊瀏覽器，雖然在 chrome 或者其他高級瀏覽器中沒有出現問題，但不能保證在其他瀏覽器中能正常運行。為了萬無一失，我們需要將 ES6 轉換為 ES5，也就是js代碼轉換器，這類工具當今世界就屬 Babel 最牛逼了：
npm install --save-dev babel-loader babel-core
稍等，裝了 Babel 還沒法用，還得搞個 presets：
npm install --save-dev babel-preset-env
在根目錄下新建個 .babelrc，輸入配置：
{ "presets": ["env"] }
修改 webpack.config.js，增加 babel 的支持：
... module.exports = { ... module: { rules: [ { test: /\.js$/, loader: 'babel-loader', include: path.resolve(__dirname, 'src') } ] }, ... };
執行 npm start，找到控制臺 source 下的 app.js 代碼片段：
"use strict"; Object.defineProperty(exports, "__esModule", { value: true }); exports.wordsToSentence = wordsToSentence; function wordsToSentence() { for (var _len = arguments.length, words = Array(_len), _key = 0; _key < _len; _key++) { words[_key] = arguments[_key]; } return words.join(' '); }
已經成功轉換成 ES5 代碼。但是，目前 ES6 Modules 是由 Babel 來轉的，你可以對比前后 2 次的代碼片段的模塊輸出部分。現在，webpack 2 已經內 4 置了 ES6 Modules 的轉換，據說效率和性能比 Babel 高！^_^沒驗證過哦，我們先試試，把 Babel 的模塊轉換關了先：
.babelrc
{ "presets": [ ["env", { "modules": false }] ] }
執行 npm start 再次查看輸出后的 app.js 的代碼片段：
-Object.defineProperty(exports, "__esModule", { - value: true -}); -exports.wordsToSentence = wordsToSentence; +/* harmony export (immutable) */ __webpack_exports__["a"] = wordsToSentence; function wordsToSentence() { ... }
模塊輸出方式又回到了使用 Babel 前的代碼。
js 的環境似乎已經準備就緒，但 css 還沒上場，我們來修改下 index.css：
#app { color: #57af09; }
同時將 css 導入 bundle 入口，并修改下 index.js：
import './index.css'; import { wordsToSentence } from './utils/utils'; let el = document.createElement('div'), ... el.id = 'app'; ...
有了樣式還不行，webpack 還需要相應的 loader 來處理 css 的模塊：
npm i --save-dev style-loader css-loader
修改下 webpack.config.js：
... module.exports = { ... module: { rules: [ ... { test: /\.css$/, loader: ['style-loader', 'css-loader'], include: path.resolve(__dirname, 'src') } ] }, ... };
執行 npm start，現在可以看到頁面已經有了樣式。但是，我們說過，我們希望使用先進的武器：SASS。我們修改下 index.css：
$app-color: #57af09; #app { color: $app-color; }
再修改下文件后綴：
. ├── package.json └── src - ├── index.css + ├── index.scss ...
修改 index.js 的入口：
-import './index.css'; +import './index.scss';
由于文件（模塊）類型變了，我們還需要一個 SASS 的 webpack loader:
npm install --save-dev sass-loader node-sass
再次修改 webpack.config.js：
... module.exports = { ... module: { rules: [ ... { - test: /\.css$/, + test: /\.scss$/, - loader: ['style-loader', 'css-loader'], + loader: ['style-loader', 'css-loader', 'sass-loader'], include: path.resolve(__dirname, 'src') } ] }, ... };
執行 npm start，webpack 編譯沒有報錯，頁面顯示一切正常！
代碼自動更新（熱更新）
如果你嘗試修改 index.scss 的樣式，你有沒注意到一個問題：頁面會自動刷新。但有時候我們在開發一個模塊，比如 dialog，刷新會導致你需要反復的在頁面上操作才能看到這個 dialog 的樣式更新。那我們有沒有辦法不刷新頁面又能看到代碼的更新呢？
其實很簡單，因為 webpack-dev-server 已經內置了這樣的功能，我們只要配置下 package.json的 npm scripts：
"scripts": { "start": "webpack-dev-server --hot --inline --port 3003" },
注意到上面的代碼，我們增加了 --hot --inline，讓開發環境有了熱更新的能力。我們重新執行 npm start，然后將你的瀏覽器和編輯器并排放置，然后反復修改 index.scss，你會看到頁面不會刷新，但樣式在自動的推送更新，這就是傳說中的熱更新。
結束語
到這里，簡單（簡陋）的、現代化的前端開發環境已經有了基本的雛形，但是，本篇文章不是webpack 的使用指南，也不是 ES6 的語法教程，盡管如此，還是希望你通過本篇文章感受到前端開發在工程化領域的發展帶來的驚喜。
從2010年1月底開始接觸前端，干到現在快8年前端了。跟你分享下我的經驗。
要說快的話肯定是使用一鍵建站、或者某些CMS提供的拖拽功能來做頁面。但是一鍵建站是外部產品，而支持拖拽功能的CMS報價不菲，印象中是幾萬起步。或者有些網絡公司結合自身系統開發出的快速專題功能。但是這些不太適合小公司使用。
在零存貨的情況下，肯定是技術、經驗越豐富，前端頁面做的越快。比如我開足馬力的情況下做完好幾個頁面，新同事可能一個頁面都沒做完，而且我做的比他還漂亮。一個效果圖掃幾眼，心里大概就有譜了。
但是批量操作的話，我覺得快的應該是直接用現成模板。需要什么模塊，直接從舊模板上copy過來就完事了，最多改改細節。根據我多年的經驗，一個公司里面，需要開發的頁面很多都是可以復用的。
不管效果圖多復雜，其實拆開了無非就那些個小模塊。可以在日常工作中將每一小塊整理出來以備到時候復制黏貼。
比如一些模塊是一行行的標題，有些是標題加圖片，有些是圖片加介紹，有登錄模塊，有查詢功能等等，經常用到的其實也就幾十種小塊而已，可能多的話上百種。拖拖拽拽就生成頁面的功能也是以此為基礎來做的。
有同學說用框架可能會更快。我認為這是片面的。我承認用框架絕對會快，我有些項目也是用框架做的，但是前提是你得懂框架。而學現在互聯網上的框架的時間成本絕對不低。你要是有基礎還好，沒基礎的話，光看說明文檔得煩死你。
不管用dw還是sublime還是其他種種軟件，都只是軟件而已，最終看的全是后面的人。
給我個文本文檔我都能寫出來前端頁面。
關于通用的CSS，我有話要說。
我在2012年左右的時候曾做過整站通用的CSS，后面發現坑了。原因如下：
我當年放的是一些通用樣式（我以為的通用樣式），包括頁面頭尾、各種fix等，后來發現頁面由于那時候的水平不高，代碼寫的并不好。而且因為數次改版，那個CSS變得很臃腫。但是由于用了很久，即使有注釋有些地方我也忘了到底是干什么用的……而且這個css覆蓋網站百萬以上網頁，我也怕改錯了造成不可彌補的錯誤。（感謝網站領導給我的試錯機會）
所以在某一個時間點之后，我慢慢拋棄了這種總的css。但是我現在也在做內部使用的小框架，準備再次將CSS搞成一個文件供公司通用，相信現在做的這個CSS應該會幾年前做的那個好一些了。經過培訓，在我這個框架基礎上，公司內部的前端頁面開發速度應該會有所提升。因為現在我們公司的前端基本都在公司呆了2年以上了。而我做的這個框架會盡可能貼近大家日常工作涉及到的工作，所以比較接地氣，比學那些網站巨型框架要容易入手的多。
個人淺見，不吝賜教。同時歡迎關注我的頭條號，我會不定時更新一些前端方面的東東。