一个完整的前端是不是 这样的

Question

一个完整的前端是不是 这样的 HTML+CSS（less/sass/scss）+JS+JQ+Vue.js+node.js+json+jsx+webpack

有个朋友说:

完整的前端项目是
构建工具
前端框架
前端代码
但是 这些东西傻傻分不清楚

Answer 1

前端近些年发展迅速，尤其是模块化、工程化、自动化等概念的引入，以及MVC、Virtual DOM等框架层面的思想的引入，使得前端一下子变好多东西要学。老前端们各有自己的节奏，但对于在这个时间点新入行的前端而言，确实是一脸懵逼。

但是注意，并没有“完整”一说，不光前端如此，任何工程类的项目都是这样，可选的技术非常的多，每个特定的方向都有一套最适合的技术栈，并不是所有的项目都需要A、B、C、D……一大堆的东西，也没有哪一套技术栈能够通吃所有的场景，这需要开发人员对行业的现状和发展有一个清楚的认识，并且紧跟时代发展，为不同的项目选择最合适的技术组合。

其实前端不管是十年前还是现在，你就是说破个大天，最核心的都还是 HTML、CSS、JavaScript 三大件，其他都是顺应时代背景，围绕这三大件所展开的。

比如你提到的LESS、SCSS，就属于“CSS预处理器”，是对CSS功能的补充，但仅仅是语法上的区别，最终都需要转换成CSS才能被浏览器解析。同理，对于CoffeeScript、TypeScript等大抵也是如此，是对JavaScript的补充和扩展，功能更强大，但都需要转码为纯JS才能在浏览器中执行。

jQuery是前端们非常熟悉的名词了，百度上jQuery的解决方案甚至比纯JS的还多。确实jQuery对于解决DOM操作、跨浏览器兼容性等问题有着不可磨灭的贡献，但放到现在这已经成为非常基础的东西了，甚至有一点点过时，当下很多业务需求单纯使用jQuery已经无法很好的满足了。也正因为如此出现了大量令人懵逼的名词。

1. 大前端

曾几何时 JS 还只是个玩具，给网页做点 bling bling 的动效基本就是它的全部了。直到 Ajax 的出现一下子解放了生产力，异步刷新玩出了花。再之后我们迎来了当今前端界的大家长：Node.js。
Node 是一个运行环境，简单点理解就是把 Chrome 浏览器中的 JS 引擎给单独拿出来了，使得 JS 代码不光可以跑在浏览器中，还可以跑在许多其他环境中，由此引申出了各种可能性，比如 JS 可以跑在服务器上当后台服务、可以跑在桌面端模拟桌面应用（Node-Webkit、Electron）、可以跑在手机里模拟原生应用、可以扩展出大量的命令行工具造福开发者，当红辣子鸡“微信小程序”也选择了 JS 作为主力开发语言。一下子前端开发者们大翻身，打开了新世界的大门，仿佛什么都可以用 JS 搞定了（印证了老爷子当年的话：一些能用JS写的东西，终究都会用JS来写）。从此前端的生态范围一下子扩大了，区别于当年的概念，现在的前端被称为“大前端”。

2. 模块化

能做的事情多了，代码量自然也就上来了，如果还像当年那样全都写在一个文件里，一旦出问题那就要疯了，牵一发而动全身啊。所以要把系统拆分成不同的模块，每个模块负责一部分功能，一旦出了问题，只要修改相关的部分即可。曾经的 JS 不具备这一功能，Node 的出现为之创造了可能，ES2015 标准的推广更是将模块化落实到了语言层面，现如今前端也能像传统软件开发那样实现模块化了，并且已经成为了业界的标准做法。

ES6 自身就支持模块化，可以使用 class 更清晰的创建类，用 import/export 进行导入导出。但在此之前曾经有几个非常流行的模块化方法：CommonJS（NodeJS的规范）、AMD（RequireJS的规范)、CMD（SeaJS的规范）、UMD（分久必合的产物，试图用一份代码封装多种模块化规范）、SystemJS（同样是分久必合的产物，试图在工具层面上用统一的方式加载用不同规范封装的模块）

模块化把系统拆的粉碎，方便了开发调试，但对于生产环境却增加了大量的请求。因此在发布之前还需要进行打包，把多个JS文件合并成一个或较少的几个文件，红极一时的 browserify 就是干这个用的。当然现在我们有了更好的解决方案。

3. 工程化

随着项目规模的扩大，开发的方式就不能再按照小作坊的方式去做了，必须要从工程的角度去思考，模块化其实就是工程化的第一步。前面我们提到的CSS预处理器和CoffeeScript等都是为了解决工程化开发中遇到的问题而诞生的解决方案，例如不同浏览器的CSS属性的前缀、给CSS添加变量、函数、mixin等可编程的特性、为JS添加静态类型检测、早于标准实现一些更方便的高级语法等。但毕竟这些都不是标准，不能被浏览器直接解析，因此还需要相应的转换器，将用这些技术所写的代码转换成等价的标准的CSS和JS代码，以供执行。除此之外，工程化的开发还涉及代码压缩、混淆、哈希化等等大量的构建工作，这些东西不属于语言本身，但从工程的角度又不可或缺。

4. 框架

框架也是工程化的一部分，是针对某个特定领域问题所给出的一套相对完整的解决方案。目前最主流、讨论最多的几个前端框架莫过于Angular、React、Vue。（jQuery不是框架，也不是JS以外的另一种语言，jQuery是一个JS库。这个概念百度够了，这里不展开了）。

Angular 是 Google 推出的前端 MVC/MVVM 框架，将一些在后端开发中已经非常成熟的思想带入前端，例如MVC、双向数据绑定、依赖注入等，同时通过创建 Directive 在一定程度上实现了 Web Component 的需求，对 HTML 本身进行了一定的扩展。Angular 是一个重量级的框架，适合后台管理系统这种需要频繁对数据进行 CRUD 操作并体现到 DOM 的场景，配合 ng-route 还可以用于创建 SPA（Single Page Application）。

React 是 Facebook 推出的一个视图层框架，相比 Angular，它更加专注于解决视图层的组件化问题，它提出了 Vitual DOM 的思想，显著提升了界面绘制的性能；引入了 JSX 的语法，为组件化创造了新的可能。当然 React 并不孤独，配合 Redux 可以完成整个应用的数据流。同样配合 React Route 也可以实现路由。

Vue 是国内大神尤雨溪的作品，现在在国内应用也非常广泛。1.x 是个试水之作，相当于 Angular Lite，2.x 结合了 Angular 和 React 的优点，算是集大成者吧。现在微信小程序的框架基本就和 Vue 差不多。

前面提到的都是 Web 端的框架，还有两个相对小众但同样非常火的框架：React Native 和 Electron。

React Native 和 React 师出同门，将 React 的思想引入到移动终端，可以用 JS 代码编写性能接近原生的移动应用。

Electron 是 Github 的作品，它打包了一个 Chrome 浏览器，开发者可以用它编写运行在本地的离线应用，并且可以调用大量的本地操作，不经解释你甚至认不出来这其实是个 Web 应用。将 JS 搬到桌面应用端这件事，之前有个叫 node-webkit 的项目就已经干过，但它更多的是一个实验项目，Electron 则比较成熟，现在流行的 ATOM、VS Code 等都是基于 Electron 开发的。

5. 自动化

工程化带来了大量的工作量，其中很多都是重复性的劳动，例如转码、压缩、预处理/后处理、打包、重新加载页面等等，于是乎自动化的需求就越来越墙裂，在这方面最出名的当属 Grunt 和 Gulp，两者的定位叫做 Task Runner（任务执行器），你可以使用 JS 来定义一些列的任务，然后指定一些条件，一旦满足条件则执行相应的任务，最常见的就是监视源文件，一旦有改动则自动执行转码、压缩、打包等一系列操作，并自动刷新浏览器。从此开发人员只要一次性设定好这些任务，然后就可以专心于代码本身，而无需为这些琐事操心了。除了这两员大将，伴随着 React 的登场还有一门新的神器 Webpack，之所以把它单独拿出来说，是因为 Webpack 其实更加专注于打包，实战中配合 Grunt 和 Gulp 使用效果更佳。

6. 未来

JS能做的还有很多，尤其现在数据挖掘、人工智能、VR等其他领域的迅猛发展，JS 也在尝试着往这些方面插一脚。例如我们在朋友圈看到的一些炫酷的三维动画和游戏，以及一些带VR效果的H5宣传页，其中就用到了 three.js、D3.js、WebVR 等技术；一直很火的直播行业也在尝试 WebRTC；组件化的道路还很长，Web Component 的标准距离落地还有些许时日；Node OS 已经将魔爪伸向了操作系统，打算和Chrome OS一拼高下；IOT.js 更是布局物联网。“大前端”还在变大。

7. 来点实在的

面对这么多可选的技术，新入行的从业者难免会迷茫，到底该学什么最管用。这里我列举一些当前（2016年末）入行前端的新人在参加工作的头一年里必须要去了解的内容（如果你现在正大三，或在寻求跳槽的机会，最好也了解一下，否则面试过不了别哭）：

• 基础的基础：HTML5（重点 canvas 和 JS API）、CSS3（动效为主）、JavaScript（犀牛书3-9章、ES2015 语法可以看阮一峰的博客）

• CSS：LESS → SCSS（顺带看下 Autoprefixer 和 PostCSS 这两个小工具）

• JS：关注 ES2016 的进程、fetch、async/await 等新语法已经慢慢投入使用了。（这是个长期的过程）

• 构建工具：Gulp → Grunt → Webpack（Webpack上手门槛有点高，先把Gulp用起来）

• 模块化：seaJS → requireJS → UMD → SystemJS（主要在于几种方式的区别和特点）

• 框架：Angular、React、Vue（顺序随意，项目需求优先。其中 Angular 和 Vue 前阵子都更新到 2.x 版本，和第一版区别较大，如果没有历史项目拖后腿的话可以直接看最新版，老版本有精力再说）

• 依赖管理：npm、bower（npm一定要习惯）

• Node：常用API → Express → KOA

• 代码习惯：ESLint

• 版本控制：Git、SVN（工作必备技能，不仅限前端）

• 测试：Karma、Jasmine（是的，JS也可以测试）

• 微信：微信小程序（即将要火，趁早准备）

但愿对你有用。

Answer 2

不知道你看过没，随便看看吧.

• 原文How it feels to learn JavaScript in 2016

• 中文版2016年里做前端是怎样一种体验
  看完应该就大概知道怎么回事了，希望对你有帮助

Answer 3

从问题看你是个初学者
简单来说，建议你先学好 HTML+CSS+JS 打好基础，其他的东西可以慢慢去了解，这里简单介绍一下。
JQuery是库，对原生的js进行了扩展和优化；Vue.js是框架，提供了一种构建项目的模式；less/sass/scss+jsx+webpack 都是为了解决前端开发工程化的一些问题，属于高级一点的技术
项目接触的多了你才会遇到这些问题，用到相关的技术，基础打好了你才能理解这些技术，具体用的时候并不复杂。
初学者总是容易纠结一个标准的项目结构是什么样的，其实项目的结构根据具体的项目和用到的技术（框架等）需求确定，没有统一的标准，需要自己的经验同时借鉴别人的项目。作为初学者没必要对项目结构有太多要求，按照最简单的方式组合html+css+js就可以了。

Answer 4

没有真正的完整，只有一个好的标准

Answer 5

不考虑安全的项目就是不完整的，前端安全很重要，如何过滤用户输入这个就没有100%的好办法，哈哈

Answer 6

前端代码。。不用多说了
前端框架：bootstrap、vue.js、react..........省略一大堆,这些不是必须使用的，不用就不完整？没听说过
前端工具：webpack、gulp、grunt............省略一大堆，各种编译器、打包器、代码检查、补完等等都可以说是前端工具，不用就不完整？模块化开发的话，确实不用工具很麻烦。。有些老工具用了都很麻烦，但是这只是方便不方便的问题吧，我一个单页，只需要一整张图片，加几个<map>链接..这什么工具都不用吧。。这不完整？

完整不完整都是每个人看问题角度不同吧。。现在美国还有一些连js都没有用的大学网站，别人照样好好的

Answer 7

我的理解:首先是前端三板斧--HTML(以及HTML5)/CSS(以及CSS3)/JS,要能熟练,这是内功心法.然后其他的JQ,node.js等都是江湖流传的绝世神功,是建立在内功心法之上的.好吧,本人也仅处于磨炼内功的阶段,外家功夫涉猎不多,能完成开发需求就可以了(毕竟内功不到家啊),望能与各路豪侠在这条前端不归路上携程共勉..

Answer 8

转:开源弹出层Layer和UI框架LayUI作者贤心在介绍LayUI时开篇的感悟.
近几年，尤其是今年，常常会听到猿们吐槽“现在想简简单单的写个前端怎么就变得这么难呢？”。 的确，前端目前正处于一个超出常理，且疯狂造轮子的黄金时代， 标准化的逐步设想与浏览器本身的现状所形成的滞后感， 让一些尚未得到官方推广的方案开始引领着前端社区， 那仿佛是一场“五代十国”般的颠覆，这期间， 你看不到一个所谓的新鲜轮子可以维持超过三年的光环， 因为它很快就会被另一个新轮子所替代。 你必须保持对技术的高度狂热，透过未来的加锁去追逐那些层出不穷的，工具！ 是的，他们只是工具，准确地说是一种标准化最终形成的过度！ 透过那些高逼格工具的本质，最终仍然是 HTML、CSS、JavaScript 三驾马车的真实面貌。 与工具不同的是，它们是最终标准的归属者。 所以工具在发展，三驾马车本身同样也在高速发展， 那既然如此，我们为何不能跟随原生态的稳健脚步，安安静静地撸会码呢？ LayUI 定义为“经典模块化”，并非是自吹她自身有多优秀，而是绕开JS社区的喧嚣，以最简单的方式去诠释高效！ 她的所谓经典，是在于对返璞归真的执念，她以当前浏览器普通认可的方式去组织模块！ 我们认为，这恰是符合当下国内绝大多数程序员从旧时代过度到未来新标准的最佳指引。 所以 LayUI 本身也并不是完全遵循于AMD时代，准确地说，她试图建立自己的模式。 她具备AMD的影子，又并非受限于commonjs的那些条条框框， LayUI认为这种轻量的组织方式，比WebPack更符合绝大多数场景。 所以她坚持采用经典模块化，也正是能让人避开工具的复杂配置，回归简单， 安静高效地撸一会原生态的HTML、CSS、JavaScript。 但是 LayUI 又并非是Requirejs那样的模块加载器，而是一款UI解决方案， 她与Bootstrap最大的不同恰恰在于她糅合了自身对经典模块化的理解。