官方推荐使用模块化单文件引入，我不知道模块化，所以采用了标签式单文件引入。
[html] view plain copy print?
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>echarts测试</title>
</head>
<body>
<!-- 第二步：为ECharts准备一个具备大小（宽高）的Dom -->
<div id="main"
style="height: 400pxwidth: 800pxborder: 1px dotted black"></div>
<!-- 第一步：标签式单文件引入。引入之后可以直接使用echarts对象。 -->
<script src="../js/echarts-plain-original.js"></script>
<!-- 注意顺序，使用echarts对象要在引入echarts文件之后 -->
<script type="text/javascript">
// 初始化一个图表实例
var myChart = echarts.init(document.getElementById('main'))
// echarts把复杂的图表结构化，图表的基本结构包括以下部分：标题，x轴，y轴，数值序列。
var option = {
// 标题
title : {
text : '销量和进货量'
},
// x轴
xAxis : [ {
type : 'category',
data : [ "衬衫", "羊毛衫", "雪纺衫", "裤子", "高跟鞋", "袜子" ]
} ],
// y轴
yAxis : [ {
type : 'value',
axisLabel : {
formatter : '{value}件'
}
} ],
// 数值序列
series : [ {
name : '销量',
type : 'line',
data : [ 5, 20, 40, 10, 10, 20 ],
} ]
}
// 为图表实例加载数据
myChart.setOption(option)
</script>
</body>
</html>
ReactReact和Vue有许多相似之处，它们都有：使用VirtualDOM提供了响应式（Reactive）和组件化（Composable）的视图组件。保持注意力集中在核心库，伴随于此，有配套的路由和负责处理全局状态管理的库。相似的作用域，我们会用的时间来讲这一块的比较。不仅我们要保持技术的准确性，同时兼顾平衡。我们指出React比Vue更好的地方，例如，他们的生态系统和丰富的自定义渲染器。React社区在这里非常积极地帮助我们实现这一平衡，特别感谢来自React团队的DanAbramov。他非常慷慨的花费时间来贡献专业知识，来帮我们完善这个文件，直到我们都满意。这么说，就是希望你能对这两个库的比较的公平性感到放心。性能简介到目前为止，在现实的测试中，Vue是优于React的（通常至少快20%-50%，尽管在某些情况下还要更快）。我们可以提供一个到这个参照项目的链接，但是坦率的说，所有的参照在某些方面是有缺陷的，很少有像你所写的一个真实应用。那么，让我们详细了解下吧。渲染性能在渲染用户界面的时候，DOM的 *** 作是最昂贵，不幸的是没有库可以让这些原始 *** 作变得更快。我们能做的最好的就是：尽量减少DOM *** 作。Vue和React都使用虚拟DOM来实现，并且两者工作一样好。尽量减少除DOM *** 作以外的其他 *** 作。这是Vue和React的一个不同的地方。假如说，在React中，渲染一个元素的额外开销是1，而平均渲染一个组件的开销是2。在Vue中，一个元素的开销更像0/vue/dist/vue.js">然后就可编写Vue代码并应用到生产中，而不用担心性能问题。由于起步阶段不需学JSX，ES2015或构建系统，所以建立应用花的时间会更少。本地渲染ReactNative能使你用相同的组件模型编写有本地渲染能力的APP（IOS或Android）。能同时跨多平台开发，对开发者是非常棒的。相应地，Vue和Weex会进行官方合作，Weex是阿里的跨平台用户界面开发框架，Weex的JavaScript框架运行时用的就是Vue。这以为着不仅在浏览器，在IOS和Android上面也可以用Vue来进行开发。在现在，Weex还在积极发展，成熟度也不能和ReactNative相抗衡。但是，Weex的发展是由世界上最大的电子商务企业的需求在驱动，Vue团队也会和Weex团队积极合作确保为开发者带来良好的开发体验。MobXMobx在React社区很流行，实际上在Vue也采用了几乎相同的反应系统。在有限程度上，React+Mobx也可以被认为是更繁琐的Vue，所以如果你习惯组合使用它们，那么选择Vue会更合理。Angular1Due的一些语法和Angular的很相似（例如v-ifvsng-if）。因为Angular是Vue早期开发的灵感来源。然而，Augular中存在许多问题，在Vue中已经得到解决。复杂性在API与设计两方面上Vue.js都比Angular1简单得多，因此你可以快速地掌握它的全部特性并投入开发。灵活性和模块化Vue.js是一个更加灵活开放的解决方案。它允许你以希望的方式组织应用程序，而不是在任何时候都必须遵循Angular1制定的规则，这使让Vue能适用于各种项目。我们知道把决定权交给你，是非常必要的，就是是为什么提供Webpacktemplate，让你用几分钟，去选择是否用高级特性，比如热模块加载、linting、Cssextraction等等。数据绑定Angular1使用双向绑定，Vue在不同组件间强制适用单向数据流。这使应用中的数据流清晰易懂。指令与组件在Vue中指令和组件分得更清晰。指令只封装DOM *** 作，而组件代表一个自给自足的独立单元——有自己的视图和数据逻辑。在Angular中两者有不少相混的地方。性能Vue.js有更好的性能，并且非常非常容易优化，因为它不使用脏检查。在Angular1中，当watcher越来越多时会变得越来越慢，因为作用域内的每一次变化，所有watcher都要重新计算。并且，如果一些watcher触发另一个更新，脏检查循环（digestcycle）可能要运行多次。Angular用户常常要使用深奥的技术，以解决脏检查循环的问题。有时没有简单的法来优化有大量watcher的作用域。Vue.js则根本没有这个问题，因为它使用基于依赖追踪的观察系统并且异步列队更新，所有的数据变化都是独立地触发，除非它们之间有明确的依赖关系。有意思的是，Angular2和Vue用相似的设计解决了一些Angular1中存在的问题。Angular2Augluar2完全是一个全新的框架。例如,它具有优秀的组件系统，并且许多实现已经完全重写，API也完全改变了。TypeScriptAngular1面向的较小的应用程序，Angular2已转移焦点，面向的是大型企业应用。TypeScript被引用，这对那些喜欢用Java或者C#等类型安全的语言的人是非常有用的。Vue也适合企业应用，也可以使用TypeScript来支持官方类型和用户贡献的类型，尽管这是可选的。尺寸和性能在性能方面，这两个框架都是非常快。但是如果你查看第三方参照，就可以得出Vue2比Angular2要快的。在尺寸方面，虽然Angular2使用tree-shaking技术和编译技术能使代码尺寸减小。即便包含编译器和全部功能Vue2(23kb)比起Angular2(50kb)还是小的多。但是要注意，用Angular的App的尺寸缩减是用tree-shaking移除了那些框架中没有用到的功能，当随着引入功能的增多，尺寸会越来越大。灵活性Vue官方提供了构建工具，但没限制你如何构建。有人喜欢用统一的方式构建，也有很多开发者喜欢这种灵活自由的方式。学习曲线开始使用Vue，你使用的是熟悉的HTML、符合ES5规则的JavaScript（也就是纯JavaScript）。有了这些基本的技能，你可以快速地掌握它(指南)并投入开发。Angular2的学习曲线是非常陡峭的。即使不包括TypeScript，它们开始指南中所用的就有ES2015标准的JavaScript，18个NPM依赖包，4个文件和超过3千多字介绍，这一切都是为了完成个HelloWorld。而Vue'sHelloWorld就非常简单。EmberEmber是一个全能框架。它提供大量的约定，一旦你熟悉了它们，开发会很高效。不过，这也意味着学习曲线较高，而且不灵活。在框架和库（加上一系列松散耦合的工具）之间权衡选择。后者更自由，但是也要求你做的架构决定。也就是说，最好比较Vue.js内核和Ember的模板与数据模型层：Vue在普通JavaScript对象上建立响应，提供自动化的计算属性。在Ember中需要将所有东西放在Ember对象内，并且手工为计算属性声明依赖。Vue的模板语法可以用全功能的JavaScript表达式，而Handlebars的语法和帮助函数语法相比之下非常受限。在性能上，Vue甩开Ember几条街，即使是Ember2.0的最新Glimmer引擎。Vue自动批量更新，Ember当性能关键处需要手动管理。KnockoutKnockout是MVVM领域内的先驱，并且追踪依赖。它的响应系统和Vue相似。它对浏览器支持以及所有的表现也是让人印象深刻的。它能最低支持到IE6，而Vue最低只能支持到IE9。随着时间的推移，Knockout的发展已有所放缓，并且略显有点老旧了。比如，它的组件系统缺少完备的生命周期事件方法，尽管这些在现在是非常常见。以及相比Vue调用子组件的接口显得有点笨重。如果你有兴趣研究，会发现它们在接口设计的构思理念上是不同的。这些通过各自创建的simpleTodoList可以体现出来。或许有点主观，但是很多人认为Vue的API接口更简单结构更优雅。PolymerPolymer是另一个由谷歌赞助的项目，事实上也是Vue的一个灵感来源。Vue的组件可以粗略的类比于Polymer的自定义元素，并且两者具有相似的开发风格。最大的不同之处在于，Polymer是构建于最新版的WebComponents标准之上的，并且需要非凡的polyfills来工作（性能下降），浏览器本身不支持这些功能。相比而言，Vue不需要依赖polyfills来工作，最低到IE9。在Polymer1.0版本中，为了弥补性能，团队非常有限的使用数据绑定系统。例如，在Ploymer中支持的唯一表达式只有布尔值否定和单一的方法的调用，它的computed方法的实现也不是很灵活。Polymer自定义的元素是用HTML文件来创建的，这回限制你的普通的JavaScript/CSS（和被现代浏览器普遍支持的语言特性）。相比之下，Vue的单文件允许你非常容易的使用ES2015和你想用的Css的预编译处理器。当部署到生产环境的时候，Polymer建议使用HTMLImports加载所有资源。而这要求服务器和客户端都支持Http2.0协议，且浏览器实现了标准。这是否可行就取决于你的目标用户和部署环境了。如果状况不佳，你必须用Vulcanizer工具来来打包Polymer元素。在这方面，Vue可以结合异步组件的特性和Webpack的代码分割特性来实现懒加载（lazy-loaded）。这同时确保了对旧浏览器的兼容且又能更快加载。对Vue和WebComponent标准之间进行深层次的整合，也是完全可行的，比如CustomElements、ShadowDOM的样式封装。然而现在在我们做出严肃的承诺之前，我们仍在等待标准成熟，进而广泛应用于主流的浏览器中。RiotRiot2.0提供了一个类似于基于组件的开发模型（在Riot中称之为”Tag”），提供小巧精美的API。Riot和Vue可能共享一些设计理念。即使相比Roit重一点，Vue还是有很多显著优势的：根据真实条件来渲染，Roit根据是否有分支简单显示或隐藏所有内容。功能更加强大的路由机制，Roit的路由功能的API是极少的。成熟工具的支持。Vue提供官方支持Webpack、Browserify和SystemJS，而Roit是依靠社区来建立集成系统。过渡效果系统。Riot现在没有提供。更好的性能。Roit尽管广告称用虚拟DOM，实际上用的还是脏检查机制，因此和Angular1患有相同的性能问题。以上所述是小编给大家介绍的Vue.js2.0和React、Augular等其他前端框架大比拼，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对脚本之家网站的支持！欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）