jQuery在移动端
移动端dom操作库首推zepto，他实现了jQuery的大多数接口，被移动端成功扶正；弃用jQuery的主要原因是尺寸上的考虑
而jQuery经过几次发展，终于宣布不再理睬IE8，但是最新的版本尺寸依旧超过80K，而我移动端核心框架加起来还没一个DOM库大，很难不放弃他
究其原因，积重难返，要兼容老接口，又要照顾老用户，一些代码确实删不掉。
angularJS的更新
而与jQuery对应的是angularJS，框架的版本号改变却变成了框架的改变，2.X与1.X完全是两个东西，从模板到业务代码改变很大，不向下兼容，对此，我只能说：干得漂亮！同时也惹来骂声一片，程序员学习需要成本，一次学完了还得再学一次，而之前的业务代码要升级还得修改，这个确实很疼。
angularJS没有兼容老的写法，倒不是他不愿意兼容，是因为底层的机制发生变化，或者一些颠覆性的吸引，所以就改了，这个带来的好处可能是：框架性能提升50%，也可能是模板同时被服务器端解析，一套代码解决SEO问题。或者其它神马。权衡利弊，所以他就干了，不破不立，先破后立。
这里也引出了一个不可避免的问题：前端框架应该如何升级，如何迭代；全站样式应该怎样更新？
框架升级与样式升级对于一个大型站点来说都是一件令人头疼的事情，这两个问题刚好最近刚好就把我坑了进去
前端框架的升级
我们框架由1.X发展到了2.X，2.X的时候就有一次颠覆性的改动，会要求各个业务团队同步改动，其价值是：
① 一套业务代码同时解决H5站点、Hybrid、SEO三大需求
② 框架代码量减少30-40%，尺寸减少就是性能提升
③ 框架可维护性增加、结构清晰
那么其代价是：
① 不可避免的一些业务团队不买单，主要观点是：“框架升级应该透明”，倒是想透明，实现不了啊
② 业务团队需要重新学习框架用法，并且需要改老的业务代码，增加工作量，还有测试成本
③ app（apk）包多出了2.X的框架文件，尺寸反而上去了
总结一句便是：框架爽了，业务团队难受了。所以框架升级有几点需要注意：
① 接口统一
不到万不得已，不到无法实现，还是兼容老的接口吧。也许老接口命名不好，甚至接口拼写错误、也许老接口参数传递不合理，也许接口没有意义，但是该兼容的还是得兼容，因为别人已经用了，接口不兼容推动难，而且容易引发口水战
② 文档完善
文档完善包括说明文档与demo示例，js的文档可以通过规范的注释直接生成；但demo一定要高手来写，因为以后各个团队极有可能直接将你的demo copy过去，所以demo就是标准，要秉着精而全的态度去编码，而整个文档编写占用的时间可能超过框架编写。
很多团队不太注意文档的编写，其原因是框架使用者不足，或者时间、人力不够；现实的情况是每天接二连三的业务团队咨询重复的问题，多数时候开发者便不胜其烦了，所以框架文档与demo示例很重要
③ 站在业务角度思考
框架编写者最好是先做过业务，这样才会站在框架使用者的角度去思考问题，一个真实的情况却是：框架写完了而编写者却没有怎么使用过，所以写demo是个很好的消化过程
④ 态度友好
框架大版本升级，业务代码的更改是不可避免，一些团队接入框架也是不可避免；对老团队要照顾人家情绪，骂你两句得忍住，新团队人员技术良莠不齐，对技术差的要包容
框架升级总的来说文档充足，并且确实给各个业务团队带来好处，推动还算轻易。我厂由没有框架到第三方框架，到自主框架，再到更改底层dom操作库，更改AMD模块加载器，到UI分离......每一步的改变皆需要业务团队的包容与配合，但大家都为了更好的体验、美好的明天嘛！
框架更新还有一点要注意的是，每次大框架更新前一定要做一次框架的性能数据对比，这类数据一旦丢失便再也找不回来了
Html与Css的重构
框架更新，基本完全掌握在自己手里，但是全站的样式替换就完全让人摸不着头脑了。
移动站点经过两年的发展，一直使用的一套main.css文件，而这套main.css文件更是三易其手，最后无人想碰
这个时候便重构吧，重构便需要彻底，于是UED同事会配合对全站的Html标签使用，class命名做建议，最后出了一套main_v2.css与优化后的dom结构
从技术与维护来说，这个新的Html+Css确实比老的好，但是问题马上来了，新的main.css与老的main.css完全是两套东西，谁也不认识谁。
这类优化带来的利益并没有框架升级带来的好处多，于是推动本来就难，如果之前欠账多话，情况会更加复杂
老的main.css中有几个选择器是这样写的：
header { ...... }
h1 { ...... }
于是整个框架header标签算是废了，而新main_v2.css与新的结构又偏偏使用了这个结构
移动端业务快速扩展，业务线达数十个，各个业务线很难统一时间发布，偏偏main.css的业务还不在框架手里，操作更加复杂，而与main_v2配合的还有通用的UI组件的更新，整个事件想想就乱作一团。然后发现这里还涉及到Hybrid是将样式文件存在本地的，整个人直接就晕过去了。
上面的几点有点混乱总结下来是：
① 数十个业务线在使用main.css
② 业务线很难统一发布
③ main_v2.css不能保证老程序正常，事实上就是不保证
④ 新dom结构在main.css上不能运行
⑤ Hybrid与线上是一套main.css，但是是存在app的，并且发布时间不统一，H5站点与app就是两套东西，发布还得走增量
这种情况，我们这里的操作是：
① 释放标签
在header标签上加入class="old-header"之类的标识，并且禁止各个业务团队多css占用标签元素
等待一个大版本的迭代，确认所有header标签都具有old-header，便可以进行下一步操作
② 释放业务类标签样式
将main.css中的header标签选择器干掉，添加old-header的class，并且保证所有站点正常运行
③ 样式文件一增一减
在main.css中将新写的样式加入，新框架dom结构、样式更新，然后发布，这样可保证新老UI皆可运行，而使用新框架的使用新的结构
然后在新框架版本中（老版本就不管了）让业务团队将main.css改为main_v2.css，并且将里面多余的样式删掉
④ 最新版本框架对应新样式
以上几步过后，可以保证在最新框架版本中，框架最新，样式结构最新了
而整个这个简单的过程却需要耗时1、2个月，而且期间的main.css会变得比较大，最后换成main_v2.css就变小了
使用新框架的频道都切换结束后再将main.css中的多余css给删除，main.css也还原
以后使用新框架的团队统一将main.css改为main_v2.css即可
实际操作过程中可能会复杂点，会需要帮业务团队改代码，而老的dom结构与class可能与js业务逻辑产生关联也需要慢慢排查
结语
今天就自己经历的框架升级与全站样式替换提点简单的建议，如果您有更好的方法不妨留言。