web前端需要哪些技术

所有知识框架，那肯定是一个结构型的展现，就是一棵树。web前端的知识点非常多，也非常散，需要好几层结构来组织这个体系，否则就会显得很乱。那么如何组织、把谁和谁放在一块儿？这是真正值得我们去思考的，你也可以自己来思考一下这个问题。

在我总结的这个知识框架中，首先第一层我划分为：理论知识，类库框架，编码开发，运行环境。如下图：

接下来给大家解释一下：

这个图要从下往上看，为何？——因为下面是上面的基础；

首先，我们需要一定的理论知识，不管是你听别人讲授、自己看书还是网上淘资料，你都需要一定的理论知识，每一种程序开发，都避免不了。

第二，有了这些理论知识我们就可以编码了——不错——but，没有人能抵挡住第三方框架和类库的诱惑，例如jquery；

第三，有了这些理论知识和协助我们的类库框架，我们就可真正的编码了。大家可能以为编码开发不就是写代码吗，还有啥？——这里面道道多着呢；

最后，开发程序的目的，最终是为了能高效、稳定的运行在相应的环境中，这其中又有哪些事情需要我们去做？请期待；

理论知识 包括“软知识”和“硬知识”

“软知识”和“硬知识”大家可能觉得词陌生，其实我一说大家就能明白。

所谓“软”的就是能在各个程序开发中都用到的，算是基本功、内功，例如数据结构、算法、设计模式、面向对象等等；

所谓“硬”的就是能直接用于本程序开发的。用C语言你就得学C语言语法，此时学java没用。我们web前端开发所需要的硬知识其实都包含在三个标准里面：http标准、W3C标准和ECMAScript标准；

聊一聊web前端开发中的“硬知识”

“软知识”的内容非常多，也是我们大学时代学习的重点（没学好是另回事儿，毕业再恶补）。我们本次主要讨论的是web前端这一个方向，因此就点到为止，让大家知道这些知识也在知识体系中扮演重要角色。

刚才说道，硬知识有三个标准：http标准、W3C标准和ECMAScript标准，那咱们就挨个聊聊这三个标准。

1. http标准

为什么做web前端要了解http标准？——因为浏览器要从服务端获取网页，网页也可能将信息再提交给服务器，这其中都有http的连接。web系统既然和http链接有瓜葛，你就必须去了解它。

我的意见是：你不必去非常了解http的详细内容，但是你要了解web前端开发常用的一些http的知识——就是上图中我列出来的那些。当然，我知识列了一个纲，详细内容还得靠你自己去查阅（本文章讲的是知识框架，不会涉及任何知识点的详细内容）

关于这方面的知识，建议去查阅《图解http》这本书，浅显易懂的讲述了这些内容，我曾经也看过。

2.W3C标准

如果说你只知道web前端的一个标准，估计肯定是W3C标准了（据我了解，貌似大部分人真的都只知道这一个标准）。它的内容非常多，看看www.w3.org/TR/这个页面。

写到这里让我想起了一句话：2/8原则——20%的功能满足80%的需求。我觉得这句话用到这里非常合适，我们在平时开发过程中根本用不到这么多东西。反而，你要把平时用的多的东西搞懂了。

下图的这些知识，我想不用再过多解释了，这就是我文章开发说的“三大块”（html、css、js）。现在你要知道，它们只不多是W3C标准的一部分，而W3C标准也只是web前端开发知识体系中的一部分而已。

（下图没有完全展开，想看权展开的图，可下载本文一开始提供的附件）

关于CSS的基础知识，毛遂自荐一下自己之前的一篇系列博客：《CSS知多少》

3. ECMAScript

简称ES，写全称太麻烦了。

有些人可能只知道javascript，而不知道ES——其实，js是在ES的基础上，为web浏览器做了一部分封装（增加了DOM操作、BOM操作等）。

如上图中的这些概念，大家可能平时都在javascript中看到，其实他们是ES的内容。只不过javascript继承了ES的这些特性，并且javascript用的比较广泛，因此才会在js中讨论的多一些。

还是那个“2/8原则”。其实ES中的内容也非常多，而且更新很快，现在都到ES6了。但是我上图中列出来的这些都是最重要的概念。如果你不懂原型、闭包和作用域，那就说明你还不完全了解ES，也就是不完全会用javascript。

在此毛遂自荐自己之前的一篇系列博客，大家可以去参考：《深入理解javascript原型和闭包系列》

5. 框架和类库

前面已经描述完了web前端开发所需要的理论知识。如何实践呢？——不能蛮干——还得绕世界去看看，有哪些大牛已经为我们做出了如此多的贡献。

用下面的这些类库或者框架，能大大提高你的开发效率。

首先，jquery一定是大部分web前端开发者不可或缺的工具。而我利用jquery不仅仅停留在只使用它的API和插件上，我还会自己去写jquery插件，我还会去读jquery的源码、了解jquery的设计思路。如果你也能那样做，请相信我，你会收获到意想不到的效果。如果有一个问题：怎样才能最最透彻的理解javascript的事件系统？最佳答案之一：读几遍（一遍可能读不懂）jquery关于事件处理部分的源码！

bootstrap不用再过多解释了吧，从github上的排名也能看出道道来。甚至连我们公司的UI设计师，都从bootstrap上截图作为素材。

fontAwesome是全世界最强大的图标系统。相比于css制作图标来说，这个要好很多倍，不管是开发、效率还是维护上。icomoon.io能让我自定义选择自己的图标文件。

requirejs和seajs这种模块定义系统，也一定是你系统中不可或缺的。我曾经看过一个教程，讲师就说：requirejs带来了既jquery之后的第二次前端技术变革。

其他的，backbone、angular、react这些也慢慢的开始发挥了他们的价值，此处精力有限就不再赘述了——但是，他们很重要——你至少要试着去了解它们。

6. 编码开发

要问编码IDE哪家强，当然要属微软的visual studio！但是即便是微软的VS最新版本，它也代替不了下面要说的这套开发环境。

如果你专门做web前端，就不要在用vs了，当然要选择sublime。写html语句还用手动一条一条写吗？你得需要zencoding的协助，否则效率太差了。

另外，针对html、css、js的压缩、合并、语法检查，文件的清除、复制这些操作，你还要手动去做吗？——你需要grunt或者gulp的帮助。

在此毛遂自荐自己的教程《用grunt搭建自动化web开发环境》，讲的比较详细，适合初学者学习。

如果你的系统中有比较多的js代码或者文件，请选择一个合适的模块定义规范——CMD / AMD

请用git来帮助你做文件版本管理，最简单的就是使用github。

调试、测试，也都有专门的工具，都是需要学的……

——我的天哪……这些字写到现在写的我的手都酸了，别说要学习这些知识了——再也别说我们web前端是“三大块”了！

7. 运行环境

当系统真正到了运行环境中，当你觉得终于完事儿的时候，其实还有好几个知识点需要你掌握。看下图：

首先，你要知道web系统虽然大部分是在浏览器下运行，但是js可能会被运行在node环境。

在浏览器环境下，最重要的两点是：web安全和性能优化。需要注意的纲要我都列出来了，如果想了解推荐两本书《白帽子将web安全》《高性能网站建设指南》

8. 其他

以上这些是全部的知识体系。如果你想成为一名合格的、让leader喜欢的程序猿，你除了知道这些知识之外，我觉得还需要以下几点：

要了解敏捷软件开发流程（如SCRUM）和项目管理知识（如考取PMP），这也属于一种“软”知识吧；

要学会在网上和别人交流（博客、qq群、开源项目），交流能让自己看到自己的不足；

要学会自我反省和自我学习。就像我现在一样，试着自己总结一下属于自己的东西，随时反省随时进步

什么是前端架构

说到架构，很容易拉出一系列的概念知识点，像系统架构、软件架构、框架等等，这些不是今天探讨的重点，大家可以下去百度来理解。架构的本质是什么？其实也是一种管理。通常我们所说的管理，都是指对于任务和人员的管理，而架构管的是机器和代码。比如说，机器的部署属于运维的物理架构，SOA属于服务架构，那么，前端的架构指什么呢？

长期以来，前端所处的位置是比较偏应用层，很薄的一层，而架构又要求深度和广度，所以之前在前端里面做架构，好比在小水塘里游泳，稍微扑腾两下就到处碰壁。但最近这几年来，随着一些列新的技术和概念的出现，前端的范围被大大拓展了，所以这一层逐渐变得大有可为。

单纯从语言的角度来说，html、js、css是最简单最容易上手的开发语言，不考虑模块化、工具、压缩优化，任何人都可以快速上手，完成一两个功能简单的页面。在规模很小的项目中，前端技术要素彼此不会直接产生影响，因此无需架构相关的思考。由于前端语言这种灵活松散的特点，使得前端项目规模在达到一定规模后，工程问题凸显，成为发展瓶颈，原来孤立的技术要素开始彼此产生影响，各种技术要素彼此之间开始出现关联，要用模块化开发，就必须对应某个模块化框架，用这个框架就必须对应某个构建工具，要用这个工具，就必须对应某个包管理工具……这个时候，需要有人从比较高的角度去梳理、寻找适合自己团队的集成解决方案。而这一系列解决问题的工具和手段就是所谓的前端架构。

架构的组成

组件框架

架构不等于框架这一点很好理解，相信大家都能够很深入的说明这里的差别，框架是架构的重要组成部分，架构决定框架的选型，框架决定架构的技术路线。架构围绕框架进行一系列的流程工具建设，从而形成完善自动的开发体系。

+框架不等于类库，这里就是很多人困惑的点，你用的什么框架？jquery、underscore、linq、seajs、requirejs等等，每个人都能够列举一大堆。但这个是不准确的，一套编码框架是有一系列的元素组成：

开发模式，我们如何来实现代码的职责分离。以前整个前端是mvc中v这一层，而现在前端内部也进行了mvc的逻辑细分，Javascript的MVC框架现在很多，有的强化m、有的强化c。每一个框架其实都有其特点的，并且有越来越多的创新改造，比如现在最流行的是mvvm。有angular、react等等。我们是为了引入mvvc才把他们纳入到我们的开发体系，而不是因为他是一个好用的类库。

通讯，模块化、组件化是前端在推进开发模式过程中的一个过程产物，为了有效的进行组件隔离和独立，现在有各种各样的通信模型出来，不过由于实现简单，代码少，他往往是合入到某个类库里面，但本质也是一个类库。比较成熟的比如：消息总线、事件模拟、缓存中转、flux模型等等。

模板，我们用什么样的方式来集中的处理数据往html的转换过程，这里就不用多展开，这种类库现在太多了，光我们公司就有很多套，大家在代码行、缓存管理、预编译、运算性能、强大的语法等等各个维度不段追求各种极致。

基础类库 最后才是传统类库，相信现在已经没有同学会在项目中去约束团队中的dom操作、常用函数、方法、异步化等等各种很基础东西，这个时候我们一般就是引入jq、zepto、underscor这些封装好的东西就行了。核心就是为了改善编码生产力。

对于框架的选型要从两面看，一是看该框架的本领，二是看你们团队的能耐。从经验上给几个点建议：

这里也可以顺便展开聊一下现在前端产品的形态分类：

从这些分类里面，我们这些年派生出了所谓全端和全栈的概念。但本质上怎么走还是要由所在产品的形态来决定。

内容型Web站点 侧重渲染方面的优化，前端逻辑比重小

操作型B/S系统 以数据和逻辑为中心，界面较规整

hybrid内置型，要处理缓存和一些本地接口，包括PC客户端和移动端。现在的本地应用，基于很多考虑，都变成了混合应用，也就是说，开发这个应用的技术，既包含原生的代码，也包含了嵌入的HTML5代码

Web游戏，前端的逻辑非常重，在代码结构上要求非常高的可管理性和更复杂的设计模式。

桌面应用型，现在有一些PC端的混合应用开发技术，比如node-webkit和hex，前者的典型应用是XDK，后者的典型应用是有道词典，此外，豌豆荚的PC客户端也是采用类似技术的，也有一些产品是用的qt-webkit。这类技术可以方便做跨平台，极大减少开发工作量。

大工程应该尽量避开谷歌产品，他的很多技术开源项目都是玩票性质的，GWT、Closure、Darty就是前车之鉴。曾今提出过很多的新技术，到现在还是独家的，变出太大。包括现在angular，喜欢做断崖式升级，做做运营后台系统问题不大，如果是线上系统的话，每次升级就是一次人月神话中的典型焦油坑。

关注应用场景，像刚才说到的boss后台是一种；另外我的平台是否有沉重的历史包袱，需要兼容ie6，还是可以轻装上阵；产品对于seo是什么样的态度？是否需要考虑自适应？或者我的团队足够大，能够各搞一套？；产品特征是强内容还是强交互或者是游戏性。这些都是选择不同框架的主要出发点。

没有最好，只有最适合自己的，基本上，针对每个平台，我们都可以列出一些主流框架，但不意味着你们都能驾驭得住。小马过马，老牛没过膝，松鼠淹个半死，就是这么回事。但无论我们选择什么框架或决定自己动手造轮子，都勿忘初心，技术必须让我们工作生活更为轻松愉快——我们只选择我们能驾驭住的框架，我们不能保证它在一年后是否会过时落后。

而且按照我个人这么多年的经验来看，任何框架都会过时，往往不是因为他不够好，而是因为一定有更好的出来。我们再选择一个框架或者一个类库的时候就要想好，未来我如何抛弃他。至少不能成为我们引入新的框架的绊脚石。现实的工作中很多的团队往往会陷入到年复一年的用今年的新框架去重构去年老框架代码的历史循环中去。对于引入框架如何尽量延长他的生命力，我个人的意见是选择框架时去追求概念，而不是潮流，当我的架构可以接受新的设计概念的时候才去考虑引入新的框架。用设计理念的选择代替框架的选择。之所以这么说是因为我观察到我们部门的后端架构的开发理念跟我进公司的时候是差不多的。更多你可以参考成都网站建设

---