為什麼業內不流行基於移動端的Web APP去使用H5整站 canvas技術？
在html5中canvas的強大有目共睹。繪圖、布局、動畫甚至粒子特效皆可完成。flash時代基於flex技術的mxml來布局的整站flash大家還記得不？那也是可以基於flash內部虛擬dom進行布局的方式。當年基於flex技術的webAPP幾乎在那個時候成為的業界主流，但是隨著flash技術的沒落，為什麼H5中取代flash的canvas技術並沒有成為業界進行webAPP開發的主流呢？而大家依然使用DOM+CSS技術進行開發？眾所周知瀏覽器處理DOM是相對較慢的，而在canvas內部的繪圖布局的處理會快很多。如果考慮到SEO問題的話，如今的vue.js和reactjs等MV框架如果把數據在前端渲染依然SEO也是搜索不到的。曾今flipbroad的webAPP使用過react-canvas來製作網站，但是目前的主流依然是dom+css,撇開PC端要兼容低版本不支持canvas的瀏覽器， 那麼移動端webapp呢？據我所知egret白鷺曾今推廣過他們自己搞的exml在canvas中渲染然後利用mvvm的思路進行架構，但是這套思路一直沒法在前端開發的圈子中使用？不知道是什麼原因？僅僅因為各大網站的前端都是從切圖轉型的原因不適應canvas中的布局方式么？
呃，網頁後面本來就是一個大 canvas.
任何一個網頁, 任何一次繪製, 其實在瀏覽器里都是無數的 canvas 繪製操作.
任何人, 只要會一點 HTML/CSS , 就可以製作出精美的網頁. 最簡單的文本編寫, 對應著瀏覽器在背後默默的扛起繪製的繁重工作, 這是一個偉大的發明.
現在 Web 標準里提供 &
而用 &
人家發明 html 和 css 本來就是為了讓你盡量不要自繪，因為這事兒開發成本太高，為了解決特殊需求，人家又給你提供了 canvas。
能靠聲明實現的，不要靠編程，這是個大原則。現在你要摒棄 html/css，沒有特殊需求卻要在中 canvas 自繪整站。是不是回頭你覺得自繪開發效率低，又要在 canvas 里重新發明一套 html/css？
話說回來，如果非要完全自繪，幹嘛還要用 webview 呢？OpenGL ES 不是更方便嗎？
ps：其實按照題主的想法，canvas 少了一個重要功能，就是所謂的渲染代理。也就是說，通過 api 把原生 html 標籤渲染到 canvas 中去。有這個功能，整站渲染就不是啥問題了。
最終你會在canvas里把DOM再實現一遍。。。
對這個話題稍微有點感想。（ 曾經使用OpenGLES實現過安卓和iOS下的UI界面以及部分UI組件）
首先先說為什麼會有這個需求，主要還是在於性能。由於瀏覽器對canvas大部分都支持硬體加速。導致canvas繪製速度快，如果UI都用canvas來做的話，可以進一步增加畫面的流暢度。
但是這也伴隨著巨大的工作。如果使用的UI都是比較簡單而統一的，同時也沒有太多操作dom的要求，也不需要SEO等等，那麼這麼做是完全沒問題的。但是顯然，對於大多數傳統網站來說，還是有很多問題無法簡單解決。- SEO大部分還是需要的。就連react vue等框架，也都有嘗試服務端渲染解決這個問題。
- 操作DOM的輪子無法使用了。比如jquery或者雙向綁定，那麼在這個基於canvas的框架中，需要其他手段來代替他，這之間包含了很大的工作量，等同於新造框架。
- 現有的眾多組件庫都無法使用了。對於很多傳統頁面，需要一個好用的select，一個好用的表格，這些都無法找到合適的替代。
- 傳統的開發經驗無法在這裡得到延續，需要培養人去面對這種新型的模式。現有的人需要培訓，又找不到能一來就能用的人。會導致成本高。
總結：
對於傳統網頁：
優勢：頁面效率提高。
優勢削弱：手機不斷硬體升級，簡單頁面本身就不存在卡頓。vue，react等框架實用虛擬DOM也一定程度上緩解了部分DOM太多的複雜頁面。對於如今還卡頓的頁面，也許比起全canvas架構，更需要考慮下是否頁面本身複雜度的不合理。劣勢：
人力成本提高，需要更多錢招人培養人。開發周期提高，現成組件太少，做個效果都要花很多時間實現組件。SEO不支持，網站排名下降。對於遊戲：遊戲本身就是純canvas的，不然遊戲人物，骨骼動畫，粒子效果很多通過dom無法流暢實現。那麼遊戲所涉及到的UI，最好的方案就是依然採用全canvas方案，這樣保持了技術的統一性和邏輯的統一性。而且遊戲的UI也不會出現過於複雜的部分，也沒有SEO需求，遊戲開發者本身也都是熟悉canvas更多，所以有效避免了上面的問題。字體根本不受控制啊，畫出來的字根本不能看
部分手機上的canvas卡到讓你懷疑人生（比如三星的全系列機型）可能是有意閹割。另外canvas無法處理用戶輸入。
canvas雖然可以實現很多很炫的效果，但是網頁真的有處處需要這種特效的需求嗎？
HTML+CSS目前可以說非常成熟，幾乎沒有你做不出的效果，只有你想不到的設計。
再來說說canvas，canvas確實能實現一些複雜動畫，但是實現的同時也付出了代價：代碼無法做到標籤化，語義化。
可能你需要寫一堆數學公式來計算軌跡什麼的，想過沒有，維護這樣的代碼又是什麼樣的體驗？
既然是這樣，估計如果canvas整站真的火了，估計也會有人發明一套和html css差不多的東西來簡化編程。於是乎，又繞回來HTML CSS了。
不用整站canvas，有個很重要的理由就是無法SEO，目前展示類網站很大流量都來自搜索引擎，沒有搜索引擎的流量，估計這是站長不能承受的痛。
技術畢竟還是服務於實際需要，個人認為，拋開需求談技術的都是耍流氓。
現在的網頁90%以上內容都可以HTML CSS輕鬆實現，那為什麼還要發展全站canvas那？
剩下的很小部分可能才是canvas的著力點，你這時爽歪歪的用canvas來畫圖，又何樂不為那？
這正如企業管理中著名的話：把適合的人安排在適合的崗位上。
高射炮就是用來打飛機的，別用它來打蒼蠅；蒼蠅拍就是用來打蒼蠅的，你打個飛機試試？
----------------------------------2/7 21:00更新----------------------------------
吃完飯回來發現題主問題改了，現在vue angular2 react都有伺服器端渲染，SEO和首屏載入速度慢的問題都解決了。而canvas絲毫看不出來解決的希望。
至於RIA的問題，我覺得大可不必全站canvas，那些需要絢麗效果的地方使用canvas足矣
題主自答
在開了這題後，大家應該普遍注意到我的工作領域和傳統WebApp的不同，因此大家回答中提出了很多質疑，在質疑中有很多人提到了 webApp場景中Dom的便利性以及不同於遊戲領域的使用。我後來也另開了一貼，並在那一貼中把自己經歷和目前的困境講了一遍這裡不再贅述了，非常長的一篇回答寫我幾個小時。有興趣的朋友可以點擊到以下這個帖子里觀看。為什麼知乎前端圈普遍認為H5遊戲和H5展示的JSer（負責前端界面工作的程序員）不屬於前端工程師呢？ - 知乎用戶的回答 - 知乎
對於技術學習，我認為不外乎這幾個步驟：寫過hello world-&>做過demo-&>用在項目里過-&>踩過坑並想出解決方案-&>用這個技術燙平一切。
由於我自己是廣告領域，因此對於webApp領域的工作流我個人了解過vue.js，reactjs,angularjs,使用到的程度也就是demo程度吧，使用場景有限個人經歷有限等原因，因此我也不敢對於這些行業中的工作流叫板，只是想把自己行業（H5互動廣告行業）中我們團隊使用的canvas構建方法做一次更加細緻工作流以及經驗分享。我一直認為行業間的交流帶來的思考是能給彼此帶來新靈感從而適當優化工作流加快開發效率等優勢的。因此我才開這一貼在這裡討論，並非挑戰而是討論分享從而互相啟發拓寬思路。所以如果我有認知錯誤希望給我指出，感激不盡。
好了廢話不多，開始了。
————————————————————————————————————我先說說我們廣告行業里環境的情況吧
在廣告公司大家遵照的都是國際上4A公司的工作流程和做事方法來進行公司運營的。而正如大家所知廣告從一開始來說賣的就是一種創意給客戶從而把客戶的商品、品牌等推銷出去。在互聯網沒有出現之前傳統廣告公司有自己的一套標準模式。那就是客服（account）、創意（creative）包括文案和美術，最終的成品或許就是一張海報、一份宣傳折頁等等。這些東西被叫做物料。
在傳統廣告時代，物料的生成需要啟用印刷廠，所以不管account和creative想了多少東西最終交付給客戶的東西都是物料，因此他們對印刷廠的印刷技術以及所謂的後道技術提出了很多苛刻的要求，比如燙金、覆膜、凹凸、刀版、甚至要印在不同的材質上等等。
好了傳統講完了，這會兒時間到了互聯網時代，大量的信息可以通過網路去看了，因此整個廣告行業都認為紅利來了，可以把廣告創意搬到網上去實現，正值flash時代的出現，加上flash這種技術的便捷性，使得創意中美術的表現力大幅度的提升。因此在廣告公司中存在傳統創意和digtal創意一說，區別就在於傳統創意可能都不太理解做網頁需要用px作為單位而不應該使用厘米作為單位進行設計。當然好的digital創意還自己會做flash動畫等等。
所以我想大家應該看出來了，在廣告公司中創意最終怎麼工作才能提高業績，就看他怎麼和落地的技術表現結合。印刷時代玩弄印刷廠，到了網路時代就玩弄編程的工程師。因此作為廣告前端開發程序員說到底最值得讓社會敬佩的精神就是「耐操」，客戶虐你設計，你就虐我就行。但是最後的落地看誰呢，做的好不好純粹看技術能不能做，你天馬行空的想最後做不出來都是白搭。介紹完這些行業內職能關係，我想大家應該能看出來我們這行里最終誰說話最有分量了吧，應該也該看出來我們這行的前端工程師應該考慮什麼了吧。
對，酷炫才是王道，別人沒玩過的技術想法你拿出來溜過了就提給創意，創意做了5-6次一樣的東西了，客戶都不願買。
因此我歸納我們行業的前端具備如下幾個特點：
1、項目中得有一個核心技術亮點，至少別人沒做過的，而且每次都不一樣
比如fAR,VR，動作捕捉,人臉識別，口型識別，物理模擬，比如通過websocket實現多機互動，比如用svg實現讓用戶通過網頁如同秘密花園一樣填色最後列印出來，比如用webgl模擬水流等等，這些玩個幾次，就算是項目及中一次亮點。（以上說的這些我都做過：））2、項目都是短平快的。
雖說短平快，但體諒未必是小的，我曾今做過一個camping就有60多頁H5每頁都有不一樣的互動，因為minisite 配合活動來搞，所以項目周期一般就跟活動周期差不多時間。然後提前幾周進開發，並預留測試時間。所以往往加班是再說難免的。3、追求動畫效果
大家都經歷過flash，都清楚的，至少你的按鈕得有明確的動畫提示用來來點擊吧。當然為了營造氛圍就應該有場景中的一些其他動畫。轉場效果也要酷炫，最好再來個片頭引入，放完了再接到首頁。因此在喬布斯給flash判了死刑後，移動互聯網的到來，公司要求把廣告業務大量引流到手機端，通過微信，微博進行倒流的時候，作為技術的我們，離開了flash,還真不知道怎麼工作了。
最初我們做了幾種方案來達到這件事情的效果。
1、通過div+css布局，然後通過TweenMax.js 硬做。凡是經歷過flash時代的人都用過TweenMax。結果花的時間非常長，而且當動畫要求越來越多的時候，無數Tween疊加略卡，但在創意眼裡還是僵硬。
2、然後我們使用了當時還沒有被flash兼并進去的createjsTool，並開發成canvas,之前也搞過adobe的edge動畫工具，edge是基於dom+css的所以元素一多還是卡的厲害。也嘗試過蘋果下的hyper,跟edge差不多。
3、後來索性使用createjs，通過flash做完的動畫灌寫交互程序。這樣的方式持續了1年多。
4、在一次偶然的學習中，我們遇見了flash2x，在使用後發現了他可以導出到lufylengend以及當時流行的egret中，因為egret的名氣，以及對於導出後的運行效率的測試後，我們選擇了 flash+egret成為了我們主流的2D工作流。後來flash2x又支持cocos2dJS和layabox，以及淘寶的Hilo引擎。我一直勸說小可開發pixijs版本，也因為他太忙就沒有最終弄出來。
我們拿到flash文件後，導出出來的動畫和布局代碼基本上不用管，把交互寫在他的下方就好，這樣一來我們就有更多的時間來完成那些酷炫的交互代碼的工作了。這就是這件事的好處。
我們把canvas引擎歸納為2種，分別如下：
輕量級：
這種引擎只負責canvas自身，你可以把它用在網頁的任何局部，甚至可以在一個網頁里簡歷多個canvas項目。這種框架就是國外的幾個，比如createjs和pixi,但為了更好的兼容flash工作流，我們再輕量級選型上我們依然使用了createjs.
重量級：
因為canvas作為一個HTML5標籤而已，其實有很多事情是做不了的，比如聲音必須還得通過&，視頻還是得通過&對於選擇重量級還是輕量級我們一般根據項目結構的需要。我接下來就舉幾件事作為例子吧。
CSS3D:
我們公司css3d技術對社會影響最大的莫過於《淘寶造物節》的那個宣傳頁了吧。
但事實上老史（shrek）最早搞這個引擎的時候是在這個項目半年前，當時做了adidas的幾個站。就因為淘寶的知名度瞬間就引爆了。
使用這套技術整體上基於DIV+CSS技術。因此這個部分不怎麼需要整站canvas。有興趣的朋友，可以去sherk的github上下載使用。shrekshrek/css3d-engine
講到這裡，我問一下大家，如果基於css3d中的某個片面需要做動畫怎麼搞？傳統的做法上序列圖或者雪碧圖。如果是用canvas的話，這個部分可以讓動畫師做成flash導出createjs，當做canvas插入頁面再結合到這個css3d的環境中。這樣就妥妥的了。
微信朋友圈廣告：
我相信在廣告圈做前端的開發人員，沒人不碰微信那個定向投放的朋友圈廣告的。
首頁&<200k,20次請求以內，egret光引擎就300多k，creatjs 180k，顯然都是不行的。在這種情況下，創意不買賬就是啥效果都要，不能砍掉，那怎麼做？
如果是傳統的直接上css的animation,但依然僵硬怎麼辦？幸虧我們是flash出生，在flash里還存在一種語言可以專門用來開發工具，flash2x就是利用這個東西實現了用flash開發canvas的，這種語言也是js,但基於flash，所以叫做JSFL.
有興趣的看這裡：
http://help.adobe.com/zh_CN/flash/cs/extend/flash_cs5_extending.pdf這門語言可以控制到flash的任何部分，並導出場景內，時間線上的任何數據給你的其他代碼使用。既然不行，我們就自己造，然後打造了一個專門做css動畫的可視化工具。
關於布局：
布局這件事幾乎是到目前為止所有MV框架其實還是得人工去做的一件事。雖然有很多快捷工具，比如騰訊alloyTeam的alloyDesign等等。而且所有前端都經歷過最早在firefox的firbug中調試到了chrome中的開發者工具覺得格外的好用這個階段。然後就認為Dom+css的開發模型至少在布局上已經非常方便了。不過在我看來還是挺麻煩的。響應式布局大家應該都做過，在我們公司我們要求美術出至少3種斷點給我們，但事實上他們會死扣每一個像素是否對整齊，然後大家應該也都在css的hack中踩過坑吧。誒~不提了，想想都是一把淚。在移動端，最新的flex布局非常贊，對傳統的css盒模型又進行了一次改造，但事實上在webAPP中已經可以解決很多問題了。
前端布局中最煩的莫過於適配，這件事我想大家都很清楚。rem的發明，flex的發明都是好東西，但其實在我們的移動網頁中，我們發現其實最好用的其實是meta里的viewport。我們把頁面定寬固定住事實上可以解決移動設備的各種瀏覽器橫向適配。
然後在頁面里把postion:abosulte設置成絕對定位後，採用top和left進行數值設置，本質上就實現了跟canvas內一樣的坐標體系。css3d中也是這麼構建場景的。
所以我想你應該明白我想說什麼了么，我曾今把HTML比作在word中排版。因為最初對文檔流不熟悉所以往往很難控制，相反很多人覺得flash很好，那也是因為flash中的排版依據就是「圖形學」中的筆式繪圖儀的坐標規範，以坐標軸的第四象限來規範的。
以上就是我對於適配這件事的看法。
關於WebAPP布局的猜測
我最初接觸webApp的概念是從阮一峰翻譯的《黑客與畫家》一書中，看到paul graham用ruby on rail構建的一個工具。但事實上在Flash時代就有這樣的webAPP，當時在PC網頁里，我甚至還見過基於網頁的photoshop呢，不過都是基於flash架構的。當時我們管這種技術叫做RIA(富媒體應用)。在前端工程中我們同樣也接受了SPA（單頁應用）-即一個html，通過#錨點或者？加參數的方式實現路由分頁等前端工程。我們為什麼不能接受全站canvas呢？有人比喻說canvas封閉看不到dom樹，但是事實上canvas構建的數據層清晰明了，利用框架構建更是可以通過顯示列表看到跟開發者工具一樣的dom結構，如果你把這個理解成虛擬dom也是可以的吧，甚至跟chome開發者工具一樣參數雙向綁定你改了後，canvas中的布局相應調整。
也有人說這件事做了，就如同在一個瀏覽器里再造一個瀏覽器。這樣的觀點看待單頁網站的話不是一樣可以理解成把一個瀏覽器塞進一個html里么？
HTML這種標記語言最強大的地方莫過於「標記」二字，好的標記不僅僅是給機器看的，更重要的是給人看的。尤其類似於HTML，CSS 這種約定，說到底是給機器和人一起看的。語義化的重要性最終體現在 無障礙閱讀 領域 以及 搜索引擎優化（seo）這些領域。
這時候一定大家發現了canvas的弱勢，它就如同flash一樣，語義化的消失根本無法讓文本機讀到，也無法進行SEO.曾今flash時代雖然有flash content這個東西，但大多數時候我們還是通過html中meta的keyword進行關鍵詞錄入，canvas時代應該一樣這麼做。另外如果用react和vue生成的網頁說到底其實SEO也是一樣沒法完成的，他們唯一的好處是組件化了，可以更清晰的讓人看懂結構了。
這時候我就想到一件事，那就是對於WebAPP而言是不是所有的app都有語義化和SEO的必要性么？比如大眾點評做個H5，需要讓百度搜到他裡面的某某商鋪搞活動么？貌似其實意義不大，app裡面有自己的搜索，這個搜索訪問的是站內資料庫，這樣就足夠了。所以MV框架的好處就成為了前後端通用這一件事了。所以大肆宣傳全棧的同時確實把前端的很多工作簡化了。因為前端的雙向綁定和組件化完成後，你就有時間去搞後端的數據分析和數據處理了。這或許就是目前的現狀吧。
但是切圖誰都逃不掉吧。你即使用了react,用了vue，你還是得切圖，得寫css，得根據設計師給你的layout對位置吧。告訴你個秘密，我們已經擺脫切圖這件事了，原因就是flash可以支持ps完整導入並自動實現打包成movieclip，這樣一來用jsfl整理對應的數據結構就可以生成html或者某個json格式。這樣一來自動實現了切圖這件事了。
我不知道我的分享有沒有用，也不知道大家對此能有多大興趣。我暫時想到的就這麼多了。
不知不覺又寫了好幾個小時，之後再補充吧，晚安。相關鏈接為什麼知乎前端圈普遍認為H5遊戲和H5展示的JSer（負責前端界面工作的程序員）不屬於前端工程師呢？ - 知乎用戶的回答 - 知乎首先你得理解瀏覽器工作原理：
就是HTML+CSS最終會被瀏覽器經過一系列解析演算法轉換變成待渲染的圖形結構，然後paiting進視圖窗口中的，這就說明和Canvas最終的目的是相同的。打個比方，遊戲製作的過程，引擎設計-到引擎成熟是一個周期非常長，最終為了簡化遊戲開發的流程，不再為純圖形學買單來節約更多的開發周期成本。題目中提到的React-canvas，這只是一個為了想要做Write Once的產物，完美嗎？不完美，如果你有這個渲染框架完不成的功能再去擴充依然是一件很吃力的事情。Unity3d/虛幻等的誕生不就是為了解決開發者無休止的處理純計算機圖形的繁瑣又複雜的工作量，HTML/CSS作為Web中非常重要的發明，這就是為了給開發者快速構建應用的基石，複雜繁瑣的工作交給瀏覽器處理。當然，題主閑的蛋疼可以用牛刀殺雞，就是過程會無比的酸爽直到放棄，一拍大腿，還是他奶奶的HTML+CSS好用。還有SEO問題，我想說針對SEO有非常大需求的都是服務端渲染，最終仍然是HTML標籤可以做SEO優化，但是你canvas怎麼做服務端渲染？渲染之後頁面還是一個canvas標籤。
還有白鷺引擎的問題，知道白鷺引擎主要解決的問題是什麼嗎？是移動H5遊戲，你說可以提供HTML渲染的問題？那你用它拖拖UI看各平台打包之後的頁面是什麼，不還是HTML？
工具是用來解決特定問題的，canvas的出現也是解決問題的，而不是當萬金油用的，合適的工作需要合適的工具完成。
當然，追求60FPS也是所有前端希望實現的，把用戶體驗做到最好，不過未來技術發展誰說的好，這裡曾經試過用WebGl製作3D博客- -然後耐心+時間不足 放棄了。突然想到，如果我在canvas 中實現了webview,同時提供外部參數作為該webview的默認url，那如果我再通過他訪問自己，畫面太美.....
看到有朋友提到字體，確實也是一個坑
瀏覽器自己的dom中文本換行是很自然的行為，但是你用canvas去text就要自己定義虛擬游標和游標移動規則，遇到CSS 里text-align 尤其是多種對其方式，那更是非常繁瑣，在不說white-space文本溢出的表現形式，又或者是word-break等等你要自己分詞的屬性，想起來都麻煩。
其實不這麼做的理由很簡單，就是不值得。
也不是沒人這麼做，有人利用js還搞出了c++語法解釋器(非編譯器)但是這麼做給我的感覺就好像是在mac裡面裝了windows 然後又在上面跑個mac的虛擬機
感覺突然有了軟肋，同時還失去了鎧甲樓主可以去看看flipboard開源的react-canvas啊
然後題主實現了canvas布局引擎，然後發現自己還是需要一個dom樹
Flipboard 2年前就這樣做了，而且效果拔群
http://engineering.flipboard.com/2015/02/mobile-web/
但是商業公司不是技術驅動，用戶體驗和開發投入相比，不是所有的公司都需要像 Flipboard 一樣需要優化用戶體驗，畢竟 UC 標題黨帶來流量不知道高到哪去了。
不過伴隨虛擬 DOM 的出現和 React 的火熱， Flipboard 開源了 react-canvas，對 React 渲染層的封裝，簡化了 DOM樹 → 虛擬DOM → Canvas 的這一流程。但是畢竟是 JS 寫的渲染層， 所以和 react-native 在原生環境一樣，都有一定的局限。所以開發者在使用時還需進行一定的修改。
https://github.com/Flipboard/react-canvas/blob/master/README.md樓主提議非常好！贊一個！好了，現在開始說正經的吧！現實中你的設想已存在很久了，它就是 flash！在瀏覽器里隨意畫，不喜歡畫，也有現成的組件。比如，button，checkbox。什麼，flash性能差？憤怒的小鳥60幀每秒哦！還可以安卓，iOS通用。準確來說，應該叫Adobe air，說flash是怕你們不知道。
鋸齒邊你遇到過嗎 畫出來的文字數字模糊
這感覺就好像你在windows系統裡面裝了一個linux虛擬機，然後在這個linux虛擬機裡面你感覺還是windows系統好用，於是又在linux虛擬機裡面搞了一個windows虛擬機。。。
dom和canvas比起來
dom真心不慢dom的自由度也比canvas高canvas想要快，只有用webglCanvas 光一個適應各種手機的奇葩字體和合適斷行點，來做個文字渲染的正常從上往下流動的布局，題主你做一個試試看？
最常規的新聞站，做個後台可編輯的自由圖文混排，你試試看？
那SEO咋辦
題主這段話好熟悉
請問。既然有GDI/GDI+以及更底層的DirectX或者OpenGL，我們為什麼還需要UI控制項呢？理論上一切都可以自己繪製啊？
你說的是瀏覽器吧……
題主似乎搞反了一件事，mxml就是為了讓更多的開發者不用自己去繪製，而只是通過簡單的標籤就能把界面畫出來。如果按題主的邏輯，已經有as了，adobe幹嘛還弄個flex出來？
同理，明明可以用已有的html標籤的時候，幹嘛非要自己在canvas裡面畫？而且其他人也講到了，我都要自己繪製了，幹嘛還套webview？——————這個問題是UI工程師在知乎被黑得最慘的一次——————推薦閱讀：
※如何管理數量巨大前端組件？
※前端工程師的價值體現在哪裡？
※大型公司里外包員工和正式員工有什麼區別？
※hasOwnProperty 和 propertyIsEnumerable 的區別？
※為什麼初期的前端工程師工資都很高？