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