司徒正美
需要将这两个函娄倒过来
【新福利】前言
winter: 感慨一句，虽然现在看起来是如此落后还经常挨骂，IE6大概将会是浏览器历史甚至软件历史上的传奇了，鼎盛时高达98%的市场份额，能跟10年后的浏览器（包括它自己的升级版）竞争的功能，以及前所未有的标准化程度，它的一个版本给web带来的变革大概等于后面十几年加起来那么多。 民工精髓V:HTC，VML，XMLHTTP，那个时代企业B/S应用的三件宝，也有人用XSLT的 宝玉xp:当年真的大爱IE6啊，不用考虑浏览器兼容，只要IE6能跑就能兼容几乎所有浏览器。HTC搭配XML定制界面多方便。AJAX用起来很方便。CSS也简单，多用Table布局就好！
No setTimeout, No setInterval 如果你不得不使用setTimeout或者setInterval来实现动画，那么原因只能是你需要精确的控制动画。但我认为至少在现在这个时间点，高级浏览器、甚至手机浏览器的普及程度足够让你有理由有条件在实现动画时使用更高效的方式。 什么是高效 页面是每一帧变化都是系统绘制出来的(GPU或者CPU)。但这种绘制又和PC游戏的绘制不同，它的最高绘制频率受限于显示器的刷新频率(而非显卡)，所以大多数情况下最高的绘制频率只能是每秒60帧(frame per second，以下用fps简称)，对应于显示器的60Hz。60fps是一个最理想的状态，在日常对页面性能的测试中，60fps也是一个重要的指标，the closer the better。在Chrome的调试工具中，有不少工具都是用于衡量当前帧数： 接下来的工作中，我们将会用到这些工具，来实时查看我们页面的性能。 60fps是动力也是压力，因为它意味着我们只有16.7毫秒(1000 / 60)来绘制每一帧。如果使用setTimeout或者setInterval(以下统称为timer)来控制绘制，问题就来了。 首先，Timer计算延时的精确度不够。延时的计算依靠的是浏览器的内置时钟，而时钟的精确度又取决于时钟更新的频率(Timer resolution)。IE8及其之前的IE版本更新间隔为15.6毫秒。假设你设定的setTimeout延迟为16.7ms，那么它要更新两个15.6毫秒才会该触发延时。这也意味着无故延迟了 15.6 x 2 - 16.7 = 14.5毫秒。 ``` ``` 16.7ms DELAY: |------------|...
前端集成解决方案，英文翻译为 Front-end Integrated Solution，缩写fis，发音[fɪs] 前端集成解决方案并不是一个新词汇，将这个词拆开来看，我们能得到： 前端：指前端领域，即web研发中常用的浏览器客户端相关技术，比如html、js、css等 集成：将一些孤立的事物或元素通过某种方式改变原有的分散状态集中在一起，产生联系，从而构成一个有机整体的过程。[1] 解决方案：针对某些已经体现出的，或者可以预期的问题，不足，缺陷，需求等等，所提出的一个解决问题的方案，同时能够确保加以有效的执行。[2] 总结来说，前端集成解决方案就是： 将前端研发领域中各种分散的技术元素集中在一起，并对常见的前端开发问题、不足、缺陷和需求，所提出的一种解决问题的方案。 前端领域有哪些技术元素 前端行业经历了这么长时间的发展，技术元素非常丰富，这里列举出一般web团队需要用到的技术元素： 开发规范：包括开发、部署的目录规范，编码规范等。不要小瞧规范的威力，可以极大的提升开发效率，真正优秀的规范不会让使用者感到约束，而是能帮助他们快速定位问题，提升效率。 模块化开发：针对js、css，以功能或业务为单元组织代码。js方面解决独立作用域、依赖管理、api暴露、按需加载与执行、安全合并等问题，css方面解决依赖管理、组件内部样式管理等问题。是提升前端开发效率的重要基础。现在流行的模块化框架有requirejs、seajs等。 组件化开发：在模块化基础上，以页面小部件(component)为单位将页面小部件的js、css、html代码片段放在一起进行开发、维护，组件单元是资源独立的，组件在系统内可复用。比如头部(header)、尾部(footer)、搜索框(searchbar)、导航(menu)、对话框(dialog)等，甚至一些复杂的组件比如编辑器(editor)等。通常业务会针对组件化的js部分进行必要的封装，解决一些常见的组件渲染、交互问题。 组件仓库：有了组件化，我们希望将一些非常通用的组件放到一个公共的地方供团队共享，方便新项目复用，这个时候我们就需要引入一个组件仓库的东西，现在流行的组件库有bower、component等。团队发展到一定规模后，组件库的需求会变得非常强烈。 性能优化：这里的性能优化是指能够通过工程手段保证的性能优化点。由于其内容比较丰富，就不在这里展开了，感兴趣的同学可以阅读我的这两篇文章 [1] [2]。性能优化是前端项目发展到一定阶段必须经历的过程。这部分我想强调的一点是 性能优化一定是一个工程问题和统计问题，不能用工程手段保证的性能优化是不靠谱的，优化时只考虑一个页面的首次加载，不考虑全局在宏观统计上的优化提升也是片面的。 项目部署：部署按照现行业界的分工标准，虽然不是前端的工作范畴，但它对性能优化有直接的影响，包括静态资源缓存、cdn、非覆盖式发布等问题。合理的静态资源资源部署可以为前端性能带来较大的优化空间。 开发流程：完整的开发流程包括本地开发调试、视觉效果走查确认、前后端联调、提测、上线等环节。对开发流程的改善可以大幅降低开发的时间成本，工作这些年见过很多独立的系统（cms系统、静态资源推送系统）将开发流程割裂开，对前端开发的效率有严重的阻碍。 开发工具：这里说的工具不是指IDE，而是工程工具，包括构建与优化工具、开发-调试-部署等流程工具，以及组件库获取、提交等相关工具，甚至运营、文档、配置发布等平台工具。前端开发需要工具支持，这个问题的根本原因来自前端领域语言特性（未来我会单独写一篇文章介绍前端领域语言缺陷问题）。前端开发所使用的语言（js、css、html）以及前端工程资源的加载与定位策略决定了前端工程必须要工具支持。由于这些工具通常都是独立的系统，要想把它们串联起来，才有了yeoman这样的封装。前面提到的7项技术元素都直接或间接的对前端开发工具设计产生一定的影响，因此能否串联其他技术要素，使得前端开发形成一个连贯可持续优化的开发体系，工具的设计至关重要。 以上8项，1-3是技术和业务相关的开发需求，4是技术沉淀与共享需求，5-8是工程优化需求。 经过这些年的工程领域实践，个人觉得以上8项技术元素应该成为绝大多数具有一定规模的前端开发团队的标配。各位读者可以对照自己团队现状来思考一下团队开发体系还有哪些环节需要完善。 攒一套前端集成解决方案 不难发现，其实其他领域工程也基本需要解决上述这些问题。前端由于其领域语言的独特性，使得前端工程在解决这些问题上跟其他工程有很大区别，因此至今也没有形成一套比较好的理论体系指导团队实践前端工程。 仔细观察过一些团队的技术体系形成过程，大家都在努力拼凑上述8项技术元素的具体解决方案。单独观察每一项技术点，你或许会觉得都能各自找到已有的实现，但我要说，把所有8项技术点无缝的串联起来，是一项非常有挑战的工作，你信么？相信真正经历过这样事情的同学能明白我说的串联成本问题。 假设我们希望实践一套完整的前端集成解决方案，好了，如果我们单独去看每一项技术点，都可能会找来一两个现成的东西，假设我们东拼西凑的找全了所有8项技术要素对应的具体实现。接下来要用了，它们能很完整流程的跑起来么？ 正如前面的贴图展示的那样，所有的技术点都有一定的内在联系：...
分类名字说明默认值 1 数据value属性的当前值undefined 2 数据writabletrue 或 false。 为 true时，可以修改属性值。false 3访问器get返回属性值的函数。此函数没有参数。undefined 4 访问器set设置属性值的函数。它具有一个包含要分配的值的参数。undefined 5 数据/访问器enumerabletrue 或 false。 为 true时，可以由 for…in 语句枚举属性。false 6 数据/访问器configurabletrue 或 false。 为 true时，可以更改属性的特性且可以删除属性。false
 高清图在这里 
1. 每种资源应该只有两个基本URL，第一种是集合，第二种是具体元素，如要创建一个狗的API：`/dogs` 表示狗的集合， `/dogs/123` 表示某条狗；2. 不要在URL中使用动词；3. 借用http verbs来操作集合和元素。如 删除狗`delete /dog/123`, 新增狗`post /dogs`
Chrome Canary 正式登陆 Element.animate()Demo：http://jsbin.com/rotamufa/1，规范：http://www.w3.org/TR/web-animations/#extensions-to-the-element-interface
。把jQuery作为MVVM一个水下运作单元是个不错的选择。多亏了jQuery团队，许多生僻的浏览器特性与Bug都被发掘出来，给出侦测的手段与收复的办法。如果自己写，也只是实现了一个半成品的jQuery。 改成 ，把jQuery作为MVVM一个水下运作单元是个不错的选择。多亏了jQuery团队，发现了这么多生癖的DOM兼容性问题与侦测手段，及对应的修复方案，才让我们造轮子如此轻松。如果撇开jQuery，让我们自己处理，其实也只是实现一个功能折半的jQuery库而已。 MVVM把这两个都干掉了 改成 MVVM把这两个活儿自己揽了 最后一段的“出奇制胜”添加一脚注 我一向主张的开发框架的三大原则：1，复杂即错误，2，数据结构优于算法，3，出奇制胜。 http://www.cnblogs.com/rubylouvre/p/3513180.html