❶ 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