目录
web标准
Web标准是由一系列标准组合而成。
一个网页主要由三部分组成：结构层，表现层，行为层。对应的标准也分三方面：结构化标准语言主要包括XHTML和HTML以及XML，表现层标准语言主要包括CSS，行为标准主要包括对象模型，DOM、ECMAScript等。
结构层标准，就是W3C规定的那样：
1.标签的书写，需要开始和结束。单便签除外；
2.块级元素不能放在p标签里面。li内可以包含div标签；
3.块元素里面可以放在块和内联，特殊的 p和 h1—h6里面不要放块元素，li和div可以放很多。因为这两个标签，本身就有容器的属性；
4.内联里面要放内联，不要放块；
5.结构与表现分离；
6.命名一定要规范；
表现层标准：
css的书写，首先要尽可能使用外部引入的方式，因为结构层尽可能的减少表现层的代码过多出现。达到分离的目的。css的选择器有哪些，那些属性可以继承，那些不可以继承。他们之间的优先级是怎么样的。怎么用最简洁的css代码表达设计者的想法，而不只是实现设计者的想法就没事了。我们要的是代码简洁，代码过多，反而让浏览器解析很多，浪费时间。
行为层标准：
主要是javascript中的知识。比如DOM、ECMAScript。使用javascript中的标准，即可。一般对于用户的行为，或者说页面上的动态效果的一些特殊实现，我们可以会考虑到使用javascript来进行书写，但是代码的可复用性，模块化。变量，作用域。
表现与数据分离：
表现：顾名思义，就是表达出来的现象，在前端来看，就是html+css，就是平常所看到的的网页的架子；
数据：一般是从后端数据库或从哪爬过来的数据，然后在前台显示出来，即是网页中各个结构上的内容；
说到这，你会有疑问了，其实就是MVC。0.0
实现表现与数据分离的好处与代价是什么？
好处：模块化 –> 容易测试 –> 降低bug频率；
坏处：程序结构复杂，比较耗时，上手有学习曲线；
什么样的情况下需要用到这种思想？
需要：项目具有明显的数据需求，比如要与很多Service交互，业务流程复杂，表单很多；
不需要：项目是典型的静态信息展示型页面，或是微型的内部app，或是产品idea验证时期的MVP；
如何有效的实践这种思想？
学习开发 –> 学习测试 –> 学习“测试驱动开发” –> 学习真正的开发；
不会测试而夸夸其谈表现与数据分离的人，你离他们要远一点，哪天项目搞砸了，别连累到你；
web语义化
什么是语义化？其实简单说来就是让机器可以读懂内容。
在广义方面
对于当前的 Web 而言，HTML 是联系大多数 Web 资源的纽带，也是内容的载体。在 Web 被刚刚设计出来的时候，Tim Berners-Lee 可能不会想到它现在会达到的规模以及深入到我们生活的那么多方面。也许起初的想法很简单：用来发布 Web 内容和资源的索引，方便人们查看。
但是随着 Web 规模的不断扩大，信息量之大已经不在人肉处理的范围之内了。这个时候人们开始用机器来处理 Web 上发布的各种内容，搜索引擎就诞生了。再后来，人们又设计了各种智能程序来对索引好的内容作各种处理和挖掘。所以让机器能够更好地读懂 Web 上发布的各种内容就变得越来越重要。
其实 HTML 在刚开始设计出来的时候就是带有一定的「语义」的，包括段落、表格、图片、标题等等，但这些更多地只是方便浏览器等 UA 对它们作合适的处理。但逐渐地，机器也要借助 HTML 提供的语义以及自然语言处理的手段来「读懂」它们从网上获取的 HTML 文档，但它们无法读懂例如「红色的文字」或者是深度嵌套的表格布局中内容的含义，因为太多已有的内容都是专门为了可视化的浏览器设计的。面对这种情况，出现了两种观点：
1.我们可以让机器的理解能力越来越接近人类，人能看懂、听懂的东西，机器也能理解；
2.我们应该在发布内容的时候，就用机器可读的、被广泛认可的语义信息来描述内容，来降低机器处理 Web 内容的难度（HTML 本身就已经是朝这个方向迈出的一小步了）。
在代码编译方面
最初的HTML中如h1~h6、thead、ul、ol等标签，通过标签的语义，最初设计的想法，来达到语义化的要求。如标题、表头、无序、有序列表，搜索引擎很好的利用了这些语义化标签抓取内容
后来，最初定义的HTML语义化标签，不足以实现对Web页面各个部分的功能或位置描述，所以Web前端人员利用HTML标签的id和class属性，进一步对HTML标签进行描述，如对页脚HTML标签添加如id=”footer”或者class=”footer”的属性（值），以“无声”的方式在不同的前端程序员或者前后端程序员间实现交流。
制定HTML5的W3C组织采用了诸如header、footer、section等语义化标签，来进行页面布局的设计想法，弥补了采用id=”header”或者class=”section”等。
更深层次的语义化，是自己在团队合作的过程中，对于需要声明的变量和class，id。尽可能使用彼此能理解的英文。这样减少合作的成本，加快合作的效率。
页面布局和架构
布局
分为两种：
代码上的：代码就是最典型的DIV+CSS布局，表格布局（table），iframe框架(特殊地方使用)布局，具体的使用。可以对应的看一下。目前最流行的是，div+css布局的方式。当然布局的概念比较广泛，因为在css中也存在很多布局的方法，比如float和position。具体理解的程度，需要自己去详细的阐述。
视觉上的：比如单页面的，九宫格的，瀑布流布局，tab切换布局，手风琴布局等。
架构
在谈前端架构之前，需要先探讨一下不同人群对前端产生的困惑。前端这个职业最近几年才逐渐被认可，之前一直是低端的代名词，所以多数高手很不屑搞这个。之前的很多项目，人们对前端这块的要求也只是能用就行，所以很少会在上面去细致、深入地建立一套完善体系。而多数产品的技术经理也会是后端出身的，往往对前端的认识还停留在Java Struts那个原始的MVC模型上，或者首先想到的就是GWT和JSF，这是从后端角度出发的一种视角。用这类思维方式做出来的产品，一般用户体验都不会很好。
另一方面，从界面层上手的人群，他对用户体验这方面会把控得比较好，但通常缺架构意识，或者说是软件工程的意识。在界面层比较复杂的情况下，很可能会有失控的趋势。对整个系统结构的认知程度通常不够深入，也缺乏设计模式等方面的知识。
开发人员会有一些困惑：
- 创建项目的时候，一般没有人作前端的技术选型
- 拿到项目之后，没有直接可复制的基础版本
- 习惯于引用第三方组件
- 赶功能，需要某个组件或者特效
- 上网搜到一个合适的，加进来
- 它还依赖一些别的库
- 文件大还是次要的
- 可能会产生冲突，样式也不一致
开发经理也会有一些困惑：
- 协作过程感觉有问题
- 前端人员写原始界面，包含静态界面和特效
- 开发人员接着改，加逻辑
- 发现有问题要返工了
- 在谁的代码基础上继续改？如何合并？
- 能自动单元测试吗？
- 能自动发布打包吗？
用户会对这些事情感到烦恼：
- 长得丑
- 界面老土
- 风格不一致
- 速度慢
- 加载慢
- 渲染慢
- 执行慢
- 出错
架构的本质是什么？其实也是一种管理。
通常我们所说的管理，都是指对于任务和人员的管理，而架构管的是机器和代码。比如说，机器的部署属于运维的物理架构，SOA属于服务架构，那么，前端的架构指什么呢？
长期以来，前端所处的位置是比较偏应用层，而且是很薄的一层，而架构又要求深度和广度，所以之前在前端里面做架构，好比在小水塘里游泳，稍微扑腾两下就到处碰壁。但最近这几年来，前端的范围被大大拓展了，所以这一层逐渐变得大有可为。
怎样去理解架构呢？在早期的文字MUD游戏里，有这么一句话：“你感觉哪里不对，但是又说不上来。”在我们开发和使用软件系统的过程中，或多或少会遇到这样的感觉，有这种感觉就说明架构方面可能有些问题。
在狭义的前端领域，架构要处理的很重要的事情是组件的集成。由于JavaScript本身缺乏命名空间这样的机制，多数框架都倾向于自己搞一套，所以这方面的碎片化是很严重的。如果一个公司的实力不足以自研所有用到的组件，就会一直面临这方面的问题。
比如说，在做某个功能的过程中，发现需要一个组件，时间来不及做，就到网上搜了个，加到代码里面，先运行起来再说。一不小心，等功能做完的时候，已经引入了无数种组件了，有很多代码是重叠的，可能有的还有冲突，外观也不一致。
环顾四周的大型互联网公司，基本上都有自己的前端框架，比如阿里的Kissy和Arale，腾讯的JX，百度的Tangram，360的QWrap等，为什么？因为要整合别的框架，并且在此基础上发展适合自己的组件库，代价非常大，初期没办法的时候只能凑合，长期来说，所有代码都可控的意义非常重要。
那么，是不是一套框架可以包打天下呢，这个真的很难。对于不同的产品形态，如果想要用一套框架去适应，有的会偏轻，有的又偏重，有的要兼容低端浏览器，有的又不要，很难取舍。
常见的前端产品形态包括：
- 内容型Web站点 侧重渲染方面的优化，前端逻辑比重小
- 操作型B/S系统 以数据和逻辑为中心，界面较规整
- 内嵌Web的本地应用 要处理缓存和一些本地接口，包括PC客户端和移动端
这三种产品的前端框架要处理的事情显然是不太一样的，所以可以细分成2-3种项目模板，整理出对应的种子项目，供同类产品初始化用。
最近我们经常在前端领域听说两个词：全端、全栈。
全端的意思是，原来的只做在浏览器中运行的Web程序不够，还要做各种终端，包括iOS，Android等本地应用，甚至PC桌面应用。
为什么广义的前端应当包含本地应用呢？因为现在的本地应用，基于很多考虑，都变成了混合应用，也就是说，开发这个应用的技术，既包含原生的代码，也包含了嵌入的HTML5代码。这么一来，就造成了开发本地应用的人技能要求较广，能够根据产品的场景，合理选择每个功能应当使用的技术。
现在有一些PC端的混合应用开发技术，比如node-webkit和hex，前者的典型应用是Intel® XDK，后者的典型应用是有道词典，此外，豌豆荚的PC客户端也是采用类似技术的，也有一些产品是用的qt-webkit。这类技术可以方便做跨平台，极大减少开发工作量。
所以，我们可以看到，在很多公司，开发安卓、iOS应用的人员跟Web前端的处于同一个团队中，这很大程度上就是考虑到这种情况。
全栈的意思是，除了只做在浏览器中运行的代码，还写一些服务端的代码，这个需求又是从哪里来的呢？
这个需求其实来自优化。我们要优化一个系统的前端部分，有这么一些事情可以做：
- HTML结构的优化，减少DOM树的层次等等
- CSS渲染性能的优化，批量写入DOM变更之类
- 资源文件的优化，比如小图片的合并，图像格式的处理，图标字体的使用等
- JavaScript逻辑的优化，模块化，异步加载，性能优化
- 加载字节量的优化，主要是分摊的策略
- HTTP请求的优化
这里面，除了前三条，其他都可能跟后端有些关系，尤其是最后一条。但是前端的人没法去优化后端的东西，这是不同的协作环节，所以就很麻烦。
那么，如果有了全栈，这个问题可以怎么解决呢？
比如说，我们要做最原始的小文件合并，可以在服务器做一些配置，把多个合并成一个请求，比如某个url：.cn/kissy/k/1.4.1/??dom/base-min.js,event-min.js,event/dom/base-min.js,event/base-min.js,event/dom/touch-min.js,event/dom/shake-min.js,event/dom/focusin-min.js,event/custom-min.js,cookie-min.js?t=1.js
这个就很明显是多个文件合并而成的，9个小文件的请求，合并成了一个64k的文件请求。
这种简单的事情可以在静态代理服务器上配置出来，更复杂的就比较难了，需要一定的服务端逻辑。比如说，我们有多个ajax请求，请求不同的服务，每个请求的数据量都非常少，但因为请求数很多，可能会影响加载性能，如果能把它们在服务端就合并成一个就好了。但这个优化是前端发起的，传统模式下，他的职责范围有限，优化不到服务端去，而这多个服务很可能是跨产品模块的，想要合并，放在哪个后端团队都很怪异。
这可真难办，就像老虎追猴子，猴子上了树，老虎只能在下面干瞪眼。但是如果我们能让老虎上树，这就不是个问题了。如果有这么一层NodeJS，这一层完全由前端程序员控制，他就可以在这个地方做这种合并，非常的合理。
除此之外，我们常常会用到HTML模板，但使用它的最佳位置是随着产品的场景而不同的，可能某个地方在前端更好，可能某个地方在后端好些。到底放在哪合适，只有前端开发人员才会知道，如果前端开发人员不能参与一部分后端代码的开发，优化工作也还是做不彻底。有NodeJS之后会怎样呢，因为不管前端模板还是后端模板，都是JavaScript的，可以使用同一套库，这样在做调整的时候不会有代码迁移的烦恼，直接把模板换地方即可。
现在，也有很多业务场景有实时通信的需求，目前来说最合适的方案是Socket.io，它默认使用NodeJS来当服务端，这也是NodeJS的一个重要使用场景。
这样，前端开发人员也部分参与了运行在服务端的代码，他的工作范围从原先客户端浏览器，向后拓展了一个薄层，所以就有了全栈的称呼。至于说这个称呼还继续扩展，一个前端开发人员从视觉到交互到静态HTML到JavaScript包办的情况，这个就有些过头了。
以上这些，主要解决的都是代码层面的事情。另外有一个方面，也是需要关注，但却常常不能引起重视的，那就是前端的工程化问题。
早期为什么没有这些问题？因为那时候前端很简单，复杂度不高，现在整个很复杂了，就带来了很多管理问题。比如说整个系统的前端都组件化了之后，HTML会拆分成各种模板，JavaScript会拆分成各种模块，而CSS也通过LESS或者SASS这种方式，变成了一种编译式的语言。
这时候，我们考虑一个所谓的组件，它就比较麻烦了。它可能是一个或者多个HTML模板，加上一个或者多个JavaScript模块，再包含CSS中的一部分构成的，而前两者都可能有依赖项，三个部分也都要避免与其他组件的冲突。
这些东西都需要管理，并且提供一种比较好的方案去维护。在JavaScript被模块化之后，也可以通过单元测试来控制它们的质量，并且把这个过程自动化，每次版本有变更之前，保证它们最基本的正确性。最终，需要有一种自动化的发布机制，把这几类代码提取，打包合并，压缩，发布。
目前这方面研究最深入的是之前百度FIS团队的张云龙，他的几篇文章在https://github.com/fouber/blog强烈推荐阅读。
END
本文引自：http://blog.csdn.net/zhanghuiqi205/article/details/56011688
https://kb.cnblogs.com/page/210101/
507
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
