整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
今出现了大量的CSS前端框架，但真正优秀的框架只有少数几个。
本文将会比较其中五个最佳的框架。每个框架都有自己的优点和缺点，以及具体的应用领域，你可以根据自己的具体项目需求进行选择。此外，许多选项都是模块化的，允许你仅使用所需的组件，甚至可以混合使用来自不同框架的组件。
本文依据各个框架的GitHub流行度来顺序介绍。
Foundation
Foundation是排在第二名的框架。ZURB这样坚实的公司一直支持着Foundation，所以这个框架有强大的基础。Foundation现已用于许多大型网站，包括Facebook，Mozilla，Ebay，Yahoo！和国家地理等。
Foundation说明
Foundation是一个真正的专业框架，提供业务支持、培训和咨询。它还提供了许多资源来帮助你更快更轻松地学习和使用该框架。
Semantic UI
Semantic UI是一个语义化设计的前端开源框架。它利用自然语言原理，从而使代码更加可读和可理解。
Semantic UI说明
Semantic是这里所讨论的所有框架中，最具创新性和全功能的框架。其框架的总体结构、类中清晰逻辑的命名约定方式和语义方面也超过了其它框架。
Bootstrap
Bootstrap是目前可用框架中无可争议的领导者。其人气日益增长，你可以放心的选择这个框架，而不必担心项目会失败，因为具有广泛使用基础的框架，不太可能被抛弃。
Bootstrap说明
Bootstrap的广泛流行是它的优势所在。在技术上，它不一定比列表中的其它框架更好，但它提供了比其它四个框架更多的资源（文章和教程、第三方插件和扩展、主题构建器等）。简而言之，Bootstrap 无处不在，这是人们继续选择的主要原因。
Pure
Pure是一种轻量级的模块化框架，采用纯CSS编写，具有可根据需要一起使用或单独使用的组件。
Pure说明
Pure为你的项目提供了一个干净的开始，只提供基本框架。对于不需要全功能框架但仅包含在其工作中的特定组件的人来说，pures是一个理想的选择。
UIkit
UIkit是一个易于使用和自定义的组件的简洁集合。虽然它不像其它框架那样受欢迎，但它提供了相同的功能和质量。
UIkit说明
UIkit成功应用在许多WordPress主题中。它提供了灵活和强大的手动定制机制（以前版本的框架还提供了高级GUI定制程序）。
什么是最适合你的框架？
在选择框架时，可以从以下几个方面考虑：
如果你还不确定使用哪个框架，那么可以采用混合搭配的方式。当某个特定的框架不能满足你的需求时，可以混合使用两个或多个项目的组件。
最后值得一提的是，现在Flexbox和Grid Layout在主流浏览器的最新版本中得到很好的支持，比以往任何时候都更容易构建复杂的布局。这可能会鼓励更多的开发人员放弃前端框架，从头开始编写他们自己想要的布局。
原文地址：https://zhuanlan.zhihu.com/p/39837067
近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？
作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。
那么，当我们在讨论多端框架时，我们在谈论什么：
多端
笔者以为，现在流行的多端框架可以大致分为三类：
1. 全包型
这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。
这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。
2. Web 技术型
这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有：
缺点有：
1. 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 JS 和 Native 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。
2. 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。
3. JavaScript 编译型
这类框架就是我们这篇文章的主角们：Taro、WePY 、uni-app 、 mpvue 、 chameleon，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架，以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。
这类框架最大优点和创造的最大原因就是小程序，因为第一第二种框架其实除了可以跨系统平台之外，也都能编译运行在浏览器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 react-native-web, Weex 原生支持)
另外一个优点是在移动端一般会编译到 React Native/Weex，所以它们也都拥有 Web 技术型框架的优点。这看起来很美好，但实际上 React Native/Weex 的缺点编译型框架也无法避免。除此之外，编译型框架的抽象也不是免费的：当 bug 出现时，问题的根源可能出在运行时、编译时、组件库以及三者依赖的库等等各个方面。在 Taro 开源的过程中，我们就遇到过 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，当然也少不了 Taro 本身的 bug。相信其它原理相同的框架也无法避免这一问题。
但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。
那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。
如果不管什么 DSL 都能接受，那就可以进入下一个环节。
生态
以下内容均以各框架现在（2019 年 3 月 11 日）已发布稳定版为标准进行讨论。
开发工具
就开发工具而言 uni-app 应该是一骑绝尘，它的文档内容最为翔实丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。
其它的框架都是使用 CLI 命令行工具，但值得注意的是 chameleon 有独立的语法检查工具，Taro 则单独写了 ESLint 规则和规则集。
在语法支持方面，mpvue、uni-app、Taro 、WePY 均支持 TypeScript，四者也都能通过 typing 实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对于 JSX 的良好支持，Taro 也能对组件进行自动补全。
CSS 方面，所有框架均支持 SASS、LESS、Stylus，Taro 则多一个 CSS Modules 的支持。
所以这一轮比拼的结果应该是：
uni-app > Taro > chameleon > WePY、mpvue
多端支持度
只从支持端的数量来看，Taro 和 uni-app 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），chameleon 少了头条小程序紧随其后。
但值得一提的是 chameleon 有一套自研多态协议，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能。uni-app 则有一套独立的条件编译语法，这套语法能同时作用于 js、样式和模板文件。Taro 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似 React Native 的方式）。
在移动端方面，uni-app 基于 weex 定制了一套 nvue 方案 弥补 weex API 的不足；Taro 则是暂时基于 expo 达到同样的效果；chameleon 在移动端则有一套 SDK 配合多端协议与原生语言通信。
H5 方面，chameleon 同样是由多态协议实现支持，uni-app 和 Taro 则是都在 H5 实现了一套兼容的组件库和 API。
mpvue 和 WePY 都提供了转换各端小程序的功能，但都没有 h5 和移动端的支持。
所以最后一轮对比的结果是：
chameleon > Taro、uni-app > mpvue > WePY
组件库 / 工具库 /demo
作为开源时间最长的框架，WePY 不管从 Demo，组件库数量 ，工具库来看都占有一定优势。
uni-app 则有自己的插件市场和 UI 库，如果算上收费的框架和插件比起 WePy 也是完全不遑多让的。
Taro 也有官方维护的跨端 UI 库 taro-ui ，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 demo 的数量不如前两个。但 Taro 有一个转换微信小程序代码为 Taro 代码的工具，可以弥补这一问题。
而 mpvue 没有官方维护的 UI 库，chameleon 第三方的 demo 和工具库也还基本没有。
所以这轮的排序是：
WePY > uni-app 、taro > mpvue > chameleon
接入成本
接入成本有两个方面：
第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 wxparse、echart、zan-ui 等）多是基于原生微信小程序框架语法写成的。目前看来 uni-app 、Taro、mpvue 均有文档或 demo 在框架中直接使用原生小程序组件 / 库，WePY 由于运行机制的问题，很多情况需要小改一下目标库的源码，chameleon 则是提供了一个按步骤大改目标库源码的迁移方式。
第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。
而对于两种接入方式 Taro 都提供了 taro convert 功能，既可以将原有微信小程序项目转换为 Taro 多端代码，也可以将微信小程序生态的组件转换为 Taro 组件。
所以这轮的排序是：
Taro > mpvue 、 uni-app > WePY > chameleon
流行度
从 GitHub 的 star 来看，mpvue 、Taro、WePY 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。
uni-app 则号称有上万案例，但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是 uni-app 领先，它拥有 20+ 个 QQ 交流群（最大人数 2000）。
所以从流行程度来看应该是：
uni-app > Taro、WePY、mpvue > chameleon
开源建设
一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架 / 库生命力的非常重要的标准。
从第三方贡献者数量来看，Taro 在这一方面领先，并且 Taro 的一些核心包 / 功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的 omi 框架小程序部分也是基于 Taro 完成的。
WePY 在腾讯开源计划的加持下在这一方面也有不错的表现；mpvue 由于停滞开发了很久就比较落后了；可能是产品策略的原因，uni-app 在开源建设上并不热心，甚至有些部分代码都没有开源；chameleon 刚刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现。
那么这一轮的对比结果是：
Taro > WePY > mpvue > chameleon > uni-app
最后补一个总的生态对比图表：
未来
从各框架已经公布的规划来看：
WePY 已经发布了 v2.0.alpha 版本，虽然没有公开的文档可以查阅到 2.0 版本有什么新功能 / 特性，但据其作者介绍，WePY 2.0 会放大招，是一个「对得起开发者」的版本。笔者也非常期待 2.0 正式发布后 WePY 的表现。
mpvue 已经发布了 2.0 的版本，主要是更新了其它端小程序的支持。但从代码提交， issue 的回复 / 解决率来看，mpvue 要想在未来有作为首先要打消社区对于 mpvue 不管不顾不更新的质疑。
uni-app 已经在生态上建设得很好了，应该会在此基础之上继续稳步发展。如果 uni-app 能加强开源开放，再加强与大厂的合作，相信未来还能更上一层楼。
chameleon 的规划比较宏大，虽然是最后发的框架，但已经在规划或正在实现的功能有：
如果 chameleon 把这些功能都做出来的话，再继续完善生态，争取更多第三方开发者，那么在未来 chameleon 将大有可为。
Taro 的未来也一样值得憧憬。Taro 即将要发布的 1.3 版本就会支持以下功能：
同时 Taro 也正在对移动端进行大规模重构；开发图形化开发工具；开发组件 / 物料平台以及图形化页面搭建工具。
结语
那说了那么多，到底用哪个呢？
如果不介意尝鲜和学习 DSL 的话，完全可以尝试 WePY 2.0 和 chameleon ，一个是酝酿了很久的 2.0 全新升级，一个有专门针对多端开发的多态协议。
uni-app 和 Taro 相比起来就更像是「水桶型」框架，从工具、UI 库，开发体验、多端支持等各方面来看都没有明显的短板。而 mpvue 由于开发一度停滞，现在看来各个方面都不如在小程序端基于它的 uni-app 。
(本文章转载自infoq, 如有侵权, 请联系作者删除)
于web前端三大框架，一直以来是广大前端开发者口水战必争话题。那么阿多比设计学院的小编也来趟一趟这浑水，仅仅是小编的个人一点小的看法，轻喷哦~
之所以web前端框架这个话题热度那么高，很大程度上是因为受众众多。这一点我要解释给前端小白听一下，虽然你在刚开始学习的时候往往是从HTML，CSS，JS学起的，但是一个完整的课程最后肯定是少不了web框架的。因为最后在实际工作的时候，一般都是在框架上搭建网站的，是不会真的从底层开始写代码的。
因此框架作为项目接近100%利用率的好工具，也是网站的基础，他的好坏也就显得尤为重要了。说到这里大家应该能够明白，大家嘴里的三大框架，肯定是平分秋色，各有优劣的。不然这样激烈的市场，一无是处的框架一早就被淘汰了。
下面给大家具体分析一下这三个前端框架：
1. Angular
大家眼里比较“叼”的框架，甚至有人说三大框架中只有她能称的上一个完整的框架，因为他包含的东西比较完善，包含模板，数据双向绑定，路由，模块化，服务，过滤器，依赖注入等所有功能。对于刚开始学习使用框架的小伙伴们，可以推荐这个框架，学会之后简直能颠覆之前你对前端开发的认知。使用 TypeScript能够提高代码可维护性，有利于后期重构。双向数据流很方便，但是等业务复杂之后，你可能就搞不清楚数据流了。还有令人不开心的脏值检查，以及directive的封装并没有解决视图与数据关系完全分离，有时候还要用$digist强制触发检测。
2.React
这个框架本身比较容易理解，他的结构很清晰，就是由十几个API组成，然后异步渲染，我们只需要处理好接口和维护就好了，但是很多人反映上手还是有一定的的难度的。React是单向数据流，代码写起来会较双向数据流的多一些，但是同样的排查问题时思路清晰很多。
3.Vue
号称是最简单，最容易上手的框架，同时也是行内的大趋势，还可以用来开发最火的小程序。毕竟用这神器，代码码的飞快，项目也能快速上线。同时他也是双向数据流。有些人认为Vue是Angular和React的结合，既有Angular的模板语法也有React的组件化体系。
当你学会其中某个框架之后，你再转用其他框架的时候，学会是很容易的，因为方法都是大同小异的。具体的使用还是得看公司的项目适合或者要求哪个框架。之前阿多比设计学院的小编再网上暗访了一下，看看有没有人这三个框架都十分精通的，但是很遗憾的发现，都用过的人不少，但是真正敢说精通的还是没有。这些框架学会使用还比较容易，但是里面的“水太深”，精通还需长久的时间，望大家共勉，一起学习进步呀!
*请认真填写需求信息，我们会在24小时内与您取得联系。
