❶ web2.0到底怎麼架構
分類: 電腦/網路 >> 互聯網
問題描述:
web2.0到底怎麼架構?
主要使用什麼技術?
現在還是個概念嗎?
如果要學web2.0,得先從哪下手?
謝謝!
解析:
Web 2.0是一個新生的術語，它的應用可以讓人了解目前萬維網正在進行的一種改變——從一系列網站到一個成熟的為最終用戶提供網路應用的服務平台。這種概念的支持者期望Web 2.0服務將在很多用途上最終取代桌面計算機應用。Web 2.0並不是一個技術標准，不過它包含了技術架構及應用軟體。它的特點是鼓勵作為資訊最終利用者透過分享，使到可供分享的資源變得更豐盛；相反的，過去的各種網上分享方式則顯得支離破碎。
概覽
Web（在這里，指代「Web 1.0」）最早的概念包括不常更新（甚至不更新）的靜態HTML頁面。而時代的成功則是依靠一個更加動態的Web（指代「Web 1.5」），其中CMS（內容管理系統）可以從不斷變化的內容資料庫中即時生成動態HTML頁面。從這兩種意義上來說，所謂的眼球效應則被緩或桐認為是固有的Web感受，也因此頁面點擊率和外觀成為了重要因素。
Web 2.0的支持者認為Web的使用正日漸以交互性和未來的社會性網路為導向，所提供的服務內容，通過或不通過創建一個可視的、交互的網頁來充分挖掘網路效應。某種觀點認為，和傳統網站相比，Web 2.0的網站更多表現為Point of presence或者是依賴用戶的門戶網站。
另一方面，其實早在1999年，著名的管理學者彼得·杜拉克 (Peter F. Drucker)就曾指出當時的資訊科技發展走錯了方向，因為真正推動社會進步的，是"Information Technology"里的"Information"，而不是"Technology"。若然單單著重技術層面而忽略了資訊的話，就只是一具空的軀殼，不能使社會增值。而Web 2.0很明顯是透過參與者的互動：不論是提供內容、為內容索引或評分，都能夠使他們所使用的平台增值。透過參與者的互動，好的產品或資訊本著它的口碑，從一小撮使用者擴展到一大班人，一但超過了臨界質量，就會「像病毒一樣廣泛留傳」(葛拉威爾，2002)。
該詞的來源
有不少人以為"Web 2.0"是一個技術的標准，其實這是個美麗的誤會，因為Web 2.0隻是一個用來闡述技術轉變的術語。這個術語是由O'Reilly Media的Dale Dougherty 和 MediaLive 的 Craig Cline 在共同合作的腦力激盪(brain storming)會議上提出來的。Dougherty提出了Web目前正處於復興時期，有著不斷改變的規則和不斷演化的商業模式。而Dougherty則是舉例說明——「DoubleClick是Web 1.0，Google AdSense 則是Web 2.0。 Ofoto是Web 1.0；Flickr 則是Web 2.0」，而不是給出確切的定義，和補充一個商業前景，同時O'Reilly Media、Battelle和MediaLive 在2004年10月啟動了第一個Web 2.0大會。第二次的年會已在2005年10月舉辦。
在他們的會議開場白上，O'Reilly和Battelle總結了他們認為的表現了Web 2.0應用特色的一些關鍵原則：
將Web作為平台；
駕馭群體智慧
資料將變成未來的「Intel Inside」；
軟體不斷發行與升級的循環將會終結（「永久的Beta版」）
輕量型程序設計模型；
通過內容和服務的聯合使輕量的業務模型可行；
軟體執行將跨越單一設備
豐富的使用者體驗
分享和參與的架構 所驅動的網路效應；
通過帶動分散的、獨立的開發者把各個系統和網站組合形成大匯集的改革；
拉動長尾的能力;
快速的反應與功能新增
雙向的互動
這種軟體發布中的版本號的使用從某一方面也暗示了整個Web已經被看作是一種有著重大增值意義的新產品，而且正在被重新編寫和發布。
同語義網的比較
對於Web 2.0這個詞的一個較早的出現是作為團戚語義網的同義詞。這兩個概念有點相似而擾坦且是互補的。結合了基於標簽的Folksonomy(分眾分類法)的社會性網路系統如FOAF和XFN，以及通過Blog和Wiki進行發表，已經創建了一個語義環境的天然基礎。
技術
Web 2.0技術基礎比較復雜而且還在演化中，但可以肯定的是包括伺服器端軟體、內容聯合組織、消息協議、基於標準的瀏覽器和各種不同的客戶端應用程序。（一般會避免使用非標准瀏覽器的一些增強功能和插件）這些不同但是互補的方法提供了Web2.0信息存儲、創建和分發的能力，這些能力遠遠超出了先前人們對網站的期望。
如果一個網站使用了以下一些技術作為特色的話，就說他是利用了Web 2.0技術：
技術方面：
CSS, 語義化有效的XHTML標記，和Microformats
不突出的豐富應用技術（例如Ajax）
數據的聯合，RSS/ATOM
RSS/ATOM數據的聚合
規則且有意義的URL
支持對網志發帖子
REST 或者是XML Web服務API
某些社會性網路方面
通用概念：
網站不能是封閉的——它必須可以很方便地被其他系統獲取或寫入數據。
用戶應該在網站上擁有他們自己的數據。
完全地基於Web —— 大多數成功的Web 2.0網站可以幾乎完全通過瀏覽器來使用
內容聯合組織
Web 2.0的首要的也是最重要的發展，包括了使用標准化協議的網站內容的聯合，這可以讓最終用戶在其他環境中使用網站的數據，包括另一個網站、瀏覽器插件、或者一個單獨的桌面應用程序。這些聯合協議包括RSS，資源描述框架（RDF），和Atom，這些都是基於XML的。特別的協議如FOAF和XFN（XHTML朋友網路）——這兩者都是為了社會性網路開發的——擴展了網站的功能或者可讓最終用戶不集中於網站就可以進行交互。參見microformats，以查詢更多的專門數據格式。
由於發展太快，很多這些協議都是事實上的標准而不是正式的標准。
Web服務
雙向的消息協議是Web 2.0架構的關鍵元素之一。兩個主要的類型是RESTful和SOAP方法。REST（Representational State Transfer）表示了一種Web服務 客戶端傳送所有的事務的狀態。SOAP（Simple Object Access Protocal）和類似的輕量方法都依賴伺服器來保存狀態信息。兩種情況下，服務是通過一個API調用的。這個API常常是根據網站的特殊需求定義的，但是標準的Web服務API（例如，給Blog發帖）的API依然被廣泛使用。一般來說Web服務的通用語言是XML，但並不一定，還存在大量不同的其他語言，如JSON，YAML等。
最近，出現了一個被稱之為Ajax的混合形式，用來增強基於瀏覽器的Web應用的用戶體驗。這可以用於一些特別的形式（如Google Maps、UrMap）或是一些開放的形式，可以直接利用Web服務API、數據聯合，甚至是繪畫。
寬泛得說，聯合是一種Web服務的形式，但是Web服務形式的使用卻不是很常見的。
參見 WSDL（Web服務描述語言）和Web服務規范表。
伺服器軟體
Web 2.0 的功能是在已有的Web伺服器架構上建立的，但是更加強調後台軟體。數據聯合不僅僅是名稱上和內容管理發布方法不同，而且Web服務要求更加強壯的資料庫和工作流的支持，並且變得與傳統的企業內部網的應用伺服器功能更加相似。供應商不管是用一個通用伺服器方法，可以把所有需要的功能都集中到一個伺服器平台上，或者是一個Web伺服器插件的方法，可以使用增強了API介面的標准發布工具和其他工具。不管選擇的是哪種途徑，Web 2.0的進化不會為這些選擇做出重大改變。
社會影響
Web 2.0中出現的數據聯合和消息傳送能力，提出了潛在的一種可能性——在完全不同的在線社區之間創建一個更加緊密的社會構造。同時還出現了一些新的術語來 *** 性地代表這些共同的社團，包括blogshpere：網志的世界，syndisphere：內容聯合發布，以及 wikisphere，然而其他的觀察者認為這些措辭和內在的含義太空泛了。
商業影響
可能的由Web 2.0帶來的指數級增長的業務的原因，可歸結為以人為本的消費和以計算機為本的消費的區別。
對於價值的鑒定和消費的過程中無需不同人為參與，由於Web 2.0的出現，也是完全可能的事情了。各個組織會不斷使用諸如RSS/Atom/RDF之類的聯合格式來聯合他們的價值提案。除了價值的聯合外，Web服務終點發布將簡化聯合的價值的消費過程。
事實上，至今沒有人能給Web2.0下一個明確的定義。每個人眼中的Web2.0都有不同的表述。 技術研究者眼中的Web2.0是SNS、BLOG等社會性軟體的興起； 博客們則認為Web2.0是人與人之間更為便捷的互動； 在風險投資商眼中，Web2.0又代表了新的商業機會和行業游戲規則。
而從行銷者的角度來看，Web2.0則至少意味著三個方面的內容： 一種創新的媒介形式、一個集中的社群環境，以及一種全新行銷理念。
目前逐漸盛行的BLOG行銷被認為是Web2.0行銷的典型形式之一。
早期的網路行銷不外乎是透過電子郵件發送、彈出式視窗、橫幅式廣告等幾種手法。 最常見的例子就是入口網站將其網頁上的廣告空間待價而沽，等到廣告商上門之後，入口網站再依點選率或是擺放時間的長短來收取費用。 這樣的缺點是，廣告商永遠無法知道你所擺放的廣告是不是真的接觸到你的目標客戶，還是只是在茫茫的網海中找尋一兩個真正有需求的消費者。 就像是Tim O'Reilly所說的一樣，如果Web 1.0的代表者是Netscape，那Web 2.0的代表就是Google。 Google一改以往廣告商尋找消費者的思考模式，而改以消費者自行查詢廣告的思維模式來經營。 Google將首頁保持干凈，但在關鍵字搜尋的時候提供你想要查找資訊的相關廣告，不但確保每一個點選進網站的瀏灠者都是對該資訊有興趣的潛在消費者，也一並解決了消費者對廣告視窗擾人的困擾。 而前一陣子Google推出的Google Page也有異曲同工之妙，利用免費提供部落格服務的形式，從中搜集更多消費者的習性，其中的用意就是要為消費者量身訂做一個個人化的Google。
❷ 現代Java Web開發架構分析
在本文中 我將集中討論現代的Java開發框架 分析它們的特徵和各自的使用優點 另外 我還想比較目前流行的生產質量框架 例如Struts Spring和Hibernate 並詳細討論其基本相似性及有關基本概念
我將簡短分析被用於支持這些框架的企業開發環境或工具箱 例如Borland JBuilder Eclipse以及BEA Workbench 請記住 市場上有許多有關這些開發框架的圖書;然而 在任何一篇文章中 要對它們進行深入描述是不可能的 不過 我將盡力討論最廣泛地使用的概念
共同點
幾乎所有現代的網路開發框架都遵循了模型 視圖 控制(MVC)設計模式 商業邏輯和描述被分開 由一個邏輯流控制器來協調來自客戶端的請求和伺服器上將採取的行動 這條途徑成為了網路開發的事實上的標准 每個框架的內在的機制當然是不同的 但是開發者們使用來設計和實現他們的Web應用軟體的API是很類似的 差別還存在於每個框架提供的擴展方面 例如標簽庫 JavaServer Faces或JavaBean包裝器等
所有的框架使用不同的技術來協調在Web應用程序之內的導航 例如XML配製文件 java屬性文件或定製屬性 所有的框架在控制器模塊實現的方法方面也存在明顯的不同 例如 EJB可能實例化在每個請求中需要的類或使用Java反射動態地調用一個適當的行動(Action)類 另外 不同框架在各自引入的概念上也有所不同 例如 一個框架可能定義用戶請求和反應(以及錯誤)場所 而另外一個框架可能僅僅定義一個完整的流 從一個請求到多個響答和隨後的再請求……
各種Java框架在它們組織數據流的方法方面是很類似的 在請求發出後 在應用程序伺服器上產生一些行動;而作為響應 一些可能包含對象集的數據總是被發送到JSP層 然後 從那些對象 可能是有setter和getter方法的簡單類 javabeans 值對象 或者一些集合對象 中提取數據 現代的Java框架還想方設法簡化開發者的開發任務 如通過使用簡易的API 資料庫連接池 甚至資料庫調用包等提供自動化的追蹤方式來實現 一些框架或者能夠鉤進(hooked into)另外的J EE技術中 例如JMS(Java消息服務)或JMX 或把這些技術集成到一起 伺服器數據持續性和日誌也有可能成為框架的一部分
企業開發環境
一些框架在Web開發者社區和企業發展領域變得相當流行 隨著這些框架的日漸成熟並開始發行穩定的版本 商業的IDE(集成發展環境)開始為這些框架提供支持並把他們納入到自己的產品中 一些IDE甚至基於框架的概念開發出整個的產品 例如 BEA WebLogic Workshop就是基於Struts框架建立起來的
Borland Jbuilder為Struts提供了內建的支持 也支持JSF和JSTL
Eclipse平台已成為一個很流行的開發工具 部分因為它是基於插件的 部分因為它對於Web框架的支持 現在 出現了眾多的Eclipse插件 甚至完整的基於Eclipse的IDE 許多插件被設計適合於Struts框架開發 例如MyEclipse()或M
大多數IDE都具有圖形化的流程和可視化對象(類代理) 例如 下面是一個JBuilder的行動(Action)設計器 用於規劃Web應用程序的頁面順序
WebLogic Workshop引入Java頁面流程技術 它擴展了Struts框架而提供了一個簡化的開發模型並增加了另外一些特性 Workshop使用頁面流(Page Flows) 實現輕易地把用戶介面與導航和商業邏輯分離開來 頁面流由JSP頁組成 這些頁麵包含用戶介面元素和一個控制器文件(JPF) 它包含由用戶提供的數據將怎樣被處理的指令以及下一步什麼頁面將被返回到用戶的信息 頁面流動提供給開發者一個可視化的Web應用程序總體輪廓 它讓開發者能夠看到直觀地分析不同的JSP頁彼此相關聯 並實現Web應用程序整體結構的快速建立
MyEclipse提供類似的特徵 並帶有更多吸引人的代價標簽
Apache Struts框架
Struts框架是一開源產品 基於模型 視圖 控制器(MVC)設計範例來開發Web應用軟體 它使用並且擴展了Java Servlet API 最初由Craig McClanahan創建 在 年 月 它被捐贈到Apache Foundation Struts框架展示了一個強有力的定製標簽庫 平鋪顯示 表單檢驗和I N(國際化) 另外 Struts支持許多描述層 包括JSP XML/XSLT JavaServerFaces(JSF)和Velocity;還支持一些模型層 包括JavaBeans和EJB
Spring框架
Spring框架是一個分層的Java/J EE應用程序框架 基於Expert One on One J EE設計和發行的代碼 Spring框架提供一種簡單的開發技術 用於自動化處理工程中大量的屬性文件和助理類
Spring框架包括的主要特色有:
強有力的基於JavaBeans的配置管理 使用Inversion of Control(IoC)原則 一個核心bean工廠 可用在任何環境 從applets到J EE容器程序 通用的抽象層適合於資料庫事務管理 允許可插入的事務管理器 並且不需要處理低層次的問題就可容易地劃分各事務的界限 一個很有意義的異常處理的JDBC抽象層 與Hibernate集成到一起 DAO實現支持以及事務策略
Hibernate框架
Hibernate是一適合於Java語言的對象 關系映射(ORM)解決方案 它也是開源軟體 類似Struts 並且在LGPL保護下發布 Hibernate被一群來自世界各地的Java軟體開發者所共同開發 它提供一個易用的框架來實現把一個面向對象的域模型映射到一傳統的關系資料庫 它不僅負責從Java類到資料庫表格(以及來自Java數據類型的SQL數據類型)的映射 而且還提供數據查詢和檢索能力 並能大大減少花在SQL和JDBC手工數據處理上的開發時間
Hibernate的目標是減輕開發者的與大量普通的數據持續性相聯系的編程任務 Hibernate還能夠適應開發進程 無論它是剛開始設計還是來自一現成的資料庫 Hibernate可以自動生成SQL 使開發者擺脫了手工處理結果集和進行對象轉化的繁瑣任務 並能使應用程序移植到所有的SQL資料庫 它還能提供透明的持續性 對持續性類的唯一的要求的是實現一個無參數的構造器
這個框架典型地使用在JavaSwing應用軟體 基於Servlet的Java應用軟體和使用EJBsession beans的J EE應用軟體中
結論
lishixin/Article/program/Java/hx/201311/26488
❸ web前端三大主流框架都是什麼
web前端的三大主流框架主要是React、Vue.js、Angular。
React
React框架是起源於Facebook的項目，可以輕易地解決跨瀏覽器兼容的問題，主要是通過對DOM的模擬減少與DOM的交互做到的。React的模塊化把組件進行了隔離，出現問題的時候更方便程序員對其進行修改，而且由於JavaScript，因此更有利於搜索引擎的優化。
優點：引入了一個叫作虛擬DOM的概念，運行速度快；提供了標准化的API，解決了跨瀏覽器問題、兼容性更好；代碼更加模塊化，重用代碼更容易，可維護性高。
缺點：React是目標是UI組件，通常可以和其它框架組合使用，並不適合單獨做一個完整的框架。
Vue
Vue是相對比較輕量級的框架，是通過進行雙向數據綁定來達到驅動頁面的效果，大多程序員在學習新框架的時候都會先從Vue開始。Vue比較簡單，官方文檔介紹的很清楚，可以非常快速的通過非同步批處理的方式對DOM進行更新，也能把可復用的、解耦的組件組合在一起使用，更能允許多種模塊的安裝，場景使用也更加靈活。
優點：漸進式構建能力是Vue.js最大的優勢，Vue有一個簡潔而且合理的架構，使得它易於理解和構建。Vue有一個強大的充滿激情人群的社區，這為Vue.js增加了巨大的價值，使得為一個空白項目創建一個綜合的解決方案變得十分容易。
缺點：在模型-視圖應用程序和狀態容器類型的應用程序之間的互相轉換可能會令人感到困惑；它類似於Web組件的模式，而不是真正的Web組件。
Angular
Angular擁有很好的應用程序，是一個以JavaSpript編寫的庫，模板功能也異常強大，本身就帶有豐富的Angular指令。一方面可以通過指令擴寬HTML，一方面可以通過表達式綁定數據到HTML。
優點：模板功能強大豐富並且是聲明式的，是一個比較完善的前端MVC框架，自帶了豐富的Angular指令；ng模塊化比較大膽的引入了Java的一些東西（依賴注入），能夠很容易地寫出可復用的代碼，對於敏捷開發的團隊來說非常有幫助。
缺點：驗證功能錯誤信息顯示比較薄弱，需要寫很多模板標簽；ngView只能有一個，不能嵌套多個視圖；比較笨重，沒有讓用戶選擇一個輕量級的版本。
❹ 求可視圖化編輯的web前端框架，可隨意自定義組態畫面
不得不推薦 HT for Web，滿足你這個要求可以說是非常容易的，而且我看他們官網上好像有一個你這個圖類似的，我找找圖
這幾個都跟你的圖類似吧 我覺得還是很強的一個框架，上手很容易倒是，是收費的
❺ 微服務架構圖
項目微服務架構圖
微服務架構根據目前產品存在的問題,針對快速開發、海量用戶、大量數據、低延遲等互聯網應用的實際需要,通過對業務架構、系統架構、基礎架構、技術架構進行設計，徹底解決系統解耦、性能低下等問題,而且支持雲計算部署,可以滿足高並發、高可用、高穩定。微服務並沒有一個官方的定義,可以理解為一種架構風格 。
大數據管理數據處理過程圖
大數據(big data),指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合,是需要新處理模式才能具有更強的決策力、洞察力。大數據處理的主要流程包括數據收集、數據存儲、數據處理、數據應用等主要環節。隨著業務的增長,大量和流程、規則相關的非結構化數據也爆發式增長。大數據處理,大...
產品開發流程圖
產品開發流程(Proct Development Process)產品開發流程是指企業用於想像、設計和商業化一種產品的步驟或活動的序列。產品開發流程涉及的人員從產品經理到設計師、前端、後端等等一系列人員,這篇文章主要關於產品開發的完整流程,希望對各個工作崗位上的人有借鑒意義。很多產品經理不...
阿里巴巴數據中台全景圖
阿里是數據中台概念的首先提出者，其案例更具分析意義。從阿里巴巴數據中台全景圖可以看出，阿里的數據中台包括了計算與存儲平台、數據資產管理、智能數據研發、統一數據中心中間件（OneService）四大模塊，最上層支撐著阿里數據、數據大屏、生意參謀等大數據應用。阿里數據中台架構。數據中台建設理論、方...
Web開發技術架構圖
大型web系統架構動態應用,是相對於網站靜態內容而言,是指以c/c++、php、Java、perl、.net等伺服器端語言開發的網路應用軟體,比如論壇、網路相冊。1、學習Web開發原理,包括MVC/MTV等Web框架; 2、學習Django Web框架,從技術原理到項目實踐; 3、學習Djan...
互聯網工作原理拓撲圖
互聯網工作原理拓撲圖模板，計算機網路是由很多台計算機組成的, 要實現網路之間傳輸數據, 必須要做兩件事, 數據傳輸目的地址和保證數據迅速可靠傳輸的措施。計算機網路是由許多計算機組成的,要實現網路的計算機之間傳輸數據,必須要作兩件事,數據傳輸目的地址和保證數據迅速可靠傳輸的措施。拓撲圖用於計算機...
管理業務流程圖
業務管理是網路管理中比較重要的部分，涉及的面也比較廣泛。在這一管理層，大多數的管理信息直接在GSM系統的各網路單元與GSM網路管理設施之間交換。這些管理信息還包括由AuC管理的安全性數據，由HLR管理的客戶數據，由MSC管理的費率和計費數據等。業務管理(Business Management)...
電商知識圖譜
知識圖譜(Knowledge Graph/Vault,以下簡稱KG)本質上是語義網路,是一種基於圖的數據結構,由節點(Point)和邊(Edge)組成。電商就是電子商務的簡稱，在互聯網上銷售產品而進行的商業活動,是把現實生活中的商業活動,搬到虛擬的世界當中電商這一特殊領域的知識圖譜構建過程中，...
樹狀網路拓撲圖
樹型拓撲（tree topology）：一種類似於匯流排拓撲的區域網拓撲。樹型網路可以包含分支，每個分支又可包含多個結點。樹狀拓撲結構是一種分級結構。在樹狀結構的網路中，任意兩個節點之間不產生迴路，每條通路都支持雙向傳輸、這種結構的特點是擴充方便、靈活，成本低，易推廣，適合於分主次或分等級的層級...
雲平台整體架構圖
雲計算的體系結構由5部分組成,分別為應用層,平台層,資源層,用戶訪問層和管理層,雲計算的本質是通過網路提供服務,所以其體系結構以服務為核心。公認的雲架構是劃分為基礎設施層、平台層和軟體服務層三個層次的，對應名稱為IaaS，PaaS和SaaS。
❻ 移動APP開發框架盤點2：Web移動前端框架大全
開源項目其實有一個成熟周期，這個周期大概是三年左右，自React框架在2013年發布並引爆了前端框架的大潮，這個屬於前端的周期就此開始了。
之後在2015年5月開源的React Native又開啟了屬於Web移動前端的周期，15-16年，18-19年，21-22年正好就是屬於移動前端的三個爆發點。
三年前，在第一個成熟收獲期，我盤點了移動開發框架。在這第二個成熟收獲期，理所當然要來盤點一波。
不過，當我點開github項目的code-frequency時，還是被這個准到嚇人的周期猜想驚呆了，先給你們看一波，剩下的自行驗證。
1、https://github.com/youzan/vant/graphs/code-frequency
2、https://github.com/quasarframework/quasar/graphs/code-frequency
再來說第二個比較有意思的發現，停止維護的項目絕大多數是Vue框架項目。
盤點開始的時候我還覺得React框架處於絕對劣勢，到完成時我發現React無論在選擇面還是成熟度上都超過了Vue。
原因我這里就不分析了，反正大家都有自己的看法。
網頁類框架就是前端組件框架，這一次雖然有大量項目停止維護，但是也有很多項目堅持了下來，而且還涌現出了一批新項目。
大廠佔了主導，因為這些年大廠在移動開發上的需求，遠高於其它方面。個人項目要堅持確實不易。
本來是想要做一個驗證項目，把所有框架都試用一遍並給出推薦度的。由於進度太慢，還是下一次再發吧。
這次的重點是漸進類框架，就是所謂多端同構框架（小程序框架）。這幾年國內的重點的各種小程序平台，所以多端框架的需求很是旺盛。
不過大多數先行者都沒挺過來還是讓我很意外，只有Taro成功了，想想還是有很多讓人唏噓的東西。
在這里還是先預測一波吧，因為這一類框架最變化最大，最終還是有很多框架要出局的。
漸進類框架是一個過渡性的產品，最終會變成橋接類框架的一部分，所以，與橋接類框架協同才是框架的出路。
這個賽道基本全是大廠了。
騰訊新一代跨端開發框架Hippy
Hippy一看就是淘寶Weex的對標項目，Kpi功能全面壓制。所以官方支持 React 和 Vue 兩種主流前端框架。在Weex2019年實質停更後發布，要不要這么卷？
Hippy 2.x 架構主要分成三層，UI(JS) 層 Hippy-React 和 Hippy-Vue 負責驅動 UI 指令生成；中間層 C++ HippyCore 負責抹平平台差異性和提供高性能模塊；渲染層 Android 和 iOS 負責提供終端底層模塊、組件，並與布局引擎通信。
對Weex慘遭遺棄，我上次就說過：「ReactNative提供工具，Weex提供框架，將平台差異化屏蔽（Write Once, Run Everywhere）。所以Weex則註定功能相對弱小，並且坑比較多。」Weex最終下馬也是必然的，淘寶又發布升級版北海，為了實現（Write Once, Run Everywhere），它採用自繪，而且是基於Flutter自繪。
所以Hippy3.x就一如既往的Kpi功能層層加碼，很有騰訊風格。在未來的 3.x 中業務與渲染層中的具體實現可根據用戶實際場景進行切換：業務層上不再局限於 JS 驅動，還可選擇（如：DSL/Dart/WASM 等）其它語言進行驅動；在渲染層中，渲染引擎除了支持現有原生（Native）渲染之外，還可以選擇其他渲染 Renderer，如 Flutter(Voltron) 渲染。
「Kraken 北海」是一款高性能Web渲染引擎。底層基於 Flutter 進行渲染。
Kraken 不限制上層開發者使用的框架，無論你是使用 Vue 、Rax 還是 React 都可以開發 Kraken 應用。
Kraken 的 runtime 通過 JS Engine Binding 的方式提供了一系列 Web 標準的 API 介面，調用相應 API 會執行相關邏輯並創建一系列需要發送給 Dart 層處理的指令。
Kraken 其實就是一個小程序平台，而且追求全平台完全一致。我雖然認為各平台不一致是很自然的事情，但是也表示理解，畢竟別人吹牛有當真的傳統（KFC表示認同）。
Kraken 現在也是一個小號瀏覽器，所以它的主要工作就是摳標准，畢竟它是一款基於 W3C 標準的高性能渲染引擎。
最後，我勸淘寶領導定Kpi要理智些，畢竟Hippy4我還蠻期待的。
滴滴出品的超輕量級動態化跨端開發框架，主打輕量和實用。
Hummer 以 JS 引擎為基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等業內知名 JS 引擎（這里本來還有個V8的，我刪除了，源碼裡面沒有，Kpi需要）。再配合經過調優的 Yoga 布局引擎，抹平了兩端視圖布局差異（性能更佳的自研布局引擎開發中）。順便提一下，Hippy採用V8（功能更強）自研布局引擎（性能更佳）。
Hummer 的特點是拋棄了業界其他動態化跨端框架普遍使用的DSL層和VDOM層，因此原生 Hummer 不具備前端開發常用的響應式編程的能力，但同時換來的是接近原生開發的體驗和性能。再以原生 Hummer 為基礎，在此之上開發了一套基於MVVM架構的開發框架 —— Tenon ，通過 Tenon，可以把使用 Vue/React 編寫的代碼，轉換成原生 Hummer 的代碼。
Hummer也是一個小程序平台，而且超輕量。如果想要無限提升自己APP的能力，可以考慮嵌入Hummer。
Web移動前端框架正在迎來第三個高速發展期，各類框架得到極大繁榮。
個人在具體項目的貢獻已經微乎其微了，創新、架構創新是唯一制勝的手段，這也是我看好React的根本原因。
最後，還是想做點微不足道的 探索 ，現在前端組件庫層出不窮，更換組件庫帶來的代價有點大。想創建一個框架，來實現上次說的組件公約數和公倍數，無縫切換組件庫。理論上支持所有組件庫 ，也能為後來者提供彎道超車的機會。我想大廠可能沒有需求，也不會願意發布這種框架，畢竟都是平台部門說了算。
這個庫就是useMobile，當然分為useMobileReact和useMobileVue。下次先發布useMobileReact。等我發布後，再來填上面表中缺的推薦度。
原文地址： https://www.cnblogs.com/windfic/p/16019457.html