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業務邏輯產生關聯也需要慢慢排查
結語
今天就自己經歷的框架升級與全站樣式替換提點簡單的建議，如果您有更好的方法不妨留言。