移動端dom操作庫首推zepto，他實現了jquery的大多數介面，被移動端成功扶正；棄用jquery的主要原因是尺寸上的考慮
而jquery經過幾次發展，終於宣布不再理睬ie8，但是最新的版本尺寸依舊超過80k，而我移動端核心框架加起來還沒乙個dom庫大，很難不放棄他
究其原因，積重難返，要相容老介面，又要照顧老使用者，一些**確實刪不掉。
而與jquery對應的是angularjs，框架的版本號改變卻變成了框架的改變，2.x與1.x完全是兩個東西，從模板到業務**改變很大，不向下相容，對此，我只能說：幹得漂亮！同時也惹來罵聲一片，程式設計師學習需要成本，一次學完了還得再學一次，而之前的業務**要公升級還得修改，這個確實很疼。
angularjs沒有相容老的寫法，倒不是他不願意相容，是因為底層的機制發生變化，或者一些顛覆性的吸引，所以就改了，這個帶來的好處可能是：框架效能提公升50%，也可能是模板同時被伺服器端解析，一套**解決seo問題。或者其它神馬。權衡利弊，所以他就幹了，不破不立，先破後立。
這裡也引出了乙個不可避免的問題：前端框架應該如何公升級，如何迭代；全站樣式應該怎樣更新？
框架公升級與樣式公升級對於乙個大型站點來說都是一件令人頭疼的事情，這兩個問題剛好最近剛好就把我坑了進去
我們框架由1.x發展到了2.x，2.x的時候就有一次顛覆性的改動，會要求各個業務團隊同步改動，其價值是：
① 一套業務**同時解決h5站點、hybrid、seo三大需求
② 框架**量減少30-40%，尺寸減少就是效能提公升
③ 框架可維護性增加、結構清晰
那麼其代價是：
① 不可避免的一些業務團隊不買單，主要觀點是：「框架公升級應該透明」，倒是想透明，實現不了啊
② 業務團隊需要重新學習框架用法，並且需要改老的業務**，增加工作量，還有測試成本
總結一句便是：框架爽了，業務團隊難受了。所以框架公升級有幾點需要注意：
① 介面統一
不到萬不得已，不到無法實現，還是相容老的介面吧。也許老介面命名不好，甚至介面拼寫錯誤、也許老介面引數傳遞不合理，也許介面沒有意義，但是該相容的還是得相容，因為別人已經用了，介面不相容推動難，而且容易引發口水戰
② 文件完善
文件完善包括說明文件與demo示例，js的文件可以通過規範的注釋直接生成；但demo一定要高手來寫，因為以後各個團隊極有可能直接將你的demo copy過去，所以demo就是標準，要秉著精而全的態度去編碼，而整個文件編寫占用的時間可能超過框架編寫。
很多團隊不太注意文件的編寫，其原因是框架使用者不足，或者時間、人力不夠；現實的情況是每天接二連三的業務團隊諮詢重複的問題，多數時候開發者便不勝其煩了，所以框架文件與demo示例很重要
③ 站在業務角度思考
框架編寫者最好是先做過業務，這樣才會站在框架使用者的角度去思考問題，乙個真實的情況卻是：框架寫完了而編寫者卻沒有怎麼使用過，所以寫demo是個很好的消化過程
④ 態度友好
框架大版本公升級，業務**的更改是不可避免，一些團隊接入框架也是不可避免；對老團隊要照顧人家情緒，罵你兩句得忍住，新團隊人員技術良莠不齊，對技術差的要包容
框架公升級總的來說文件充足，並且確實給各個業務團隊帶來好處，推動還算輕易。我廠由沒有框架到第三方框架，到自主框架，再到更改底層dom操作庫，更改amd模組載入器，到ui分離......每一步的改變皆需要業務團隊的包容與配合，但大家都為了更好的體驗、美好的明天嘛！
框架更新還有一點要注意的是，每次大框架更新前一定要做一次框架的效能資料對比，這類資料一旦丟失便再也找不回來了
框架更新，基本完全掌握在自己手裡，但是全站的樣式替換就完全讓人摸不著頭腦了。
移動站點經過兩年的發展，一直使用的一套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上不能執行
這種情況，我們這裡的操作是：
① 釋放標籤
在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業務邏輯產生關聯也需要慢慢排查
關於ele框架樣式修改
很多情況下，我們需要修改 ele 的原生樣式，今天我碰到乙個例子，修改的時候始終不成功，最後把樣式 換了個地方，寫到頂層就生效了，這是因為，雖然我們的 是在頂層類名下的，但是還是需要區分一下，瀏覽器上的節點是不是在頂層節點下 例如 我需要實現這樣乙個效果 這裡用的是 ele 的 popover 彈出...
0017 樣式設計 關於樣式公升級的幾點思路
首先列舉幾條關於登入樣式的例項分類 1.適用於等待或操作那些不需要花費很多心思關注的元素，比如最好不要去填寫登入。適用於那些有明確清晰主題的背景，可以讓人感覺到進入後的感覺 2.給出步驟 需要多步操作時需要 需要明確清晰地步驟語 3.簡單的logo與幾何圖形，在只需要給人第一印象時使用，缺點在於讓人...
關於jui（DWZ）前端框架的使用
前幾個月公司接了乙個鐵塔的專案 由於公司要給鐵塔做乙個電費的系統 老大一直在找前端框架 由於涉及的資料庫欄位較多 一般的前端框架很難滿足其需求 所以找到了jui這個前端框架 看起來簡潔 明了 那我們就來說說如何來使用這個框架 專案使用的mvc 所以 我就直接上圖了 home index頁面裡面直接套...