发布时间：2017年3月18日 - 7分钟阅读
在我的上一篇文章中，我展示了Polymer比Angular具有显著的性能优势。如果你正试图让你的应用程序快速发展（你应该这样做），你可能会想知道使用Polymer构建应用程序是否有意义。
使用Polymer构建应用程序的潜在问题是，Polymer最初并不是为构建应用程序而设计的。它是一个帮助开发者使用Web组件API的库（想想Web组件API的jQuery）。
幸运的是，Web Components提供的基于组件的开发模型足够灵活，你可以使用浏览器作为框架来构建复杂的应用程序。但是，虽然可以用Polymer创建复杂的应用程序，但它仍然缺少框架给你的结构和指导。
在这篇文章中，我将比较在Angular和Polymer中构建相同应用的开发经验。
工具和语言
Angular和Polymer都配备了命令行（CLI）工具，帮助开发者设置和构建项目。CLI工具隐藏了构建过程中的大部分复杂性：处理诸如转编译、优化和捆绑代码以用于生产的事情。Angular CLI另外（也可以选择）执行一个时间前（AOT）编译步骤，以减少浏览器中需要的JavaScript处理量。
Polymer
因为Polymer是基于Web标准的，所以组件是用HTML和JavaScript构建的。在Polymer 2及以后的版本中，默认的语言级别是ES6，它将被CLI移植到ES5，以支持旧的浏览器。
一个简单的Polymer组件。
当涉及到IDE支持时，Polymer仍然相当有限。Polymer团队正致力于通过Polymer IDE插件来改善这种情况，该插件可以与VS Code和Atom等编辑器一起使用。Polymer IDE插件可以帮助开发者避免常见错误，并提供一些自动完成帮助。因为Polymer使用的是纯ES6，所以没有类型检查。
Angular
Angular支持用TypeScript、JavaScript和Dart开发。网上的大部分文档和示例都是使用TypeScript，它是构建Angular应用的事实语言。TypeScript是JavaScript的超集，增加了类型检查功能。类型检查为开发人员提供了一个额外的代码检查层，对于确保正确使用API很有帮助，特别是在大型团队中工作或使用第三方库时。
一个简单的Angular组件。
在Angular中使用TypeScript也使得IDE更容易提供开发时间的帮助和检查。Visual Studio Code和WebStorm都对TypeScript有很好的支持，后者甚至可以帮助开发者包含导入，尽管有大量的模板，但在IDE中的Angular开发速度很快。
调试
调试Polymer应用程序是直接的。你可以使用浏览器开发者工具来设置断点，并检查正在运行的代码，就像你使用任何其他前端技术一样。
大多数情况下，调试Angular应用归结为一系列的console.log语句。
由于你的代码和浏览器中运行的代码之间的构建步骤，Angular的调试要复杂得多。Angular CLI构建创建的源映射应该允许你在浏览器中调试TypeScript代码。在实践中，这并不好用，因为源码图与运行的代码不匹配，断点也不起作用。还有一个用于调试Angular应用的Chrome插件叫做Augury，它可以让你检查组件的层次结构和状态。我并没有发现这个插件在定位问题方面非常有用。大多数情况下，调试Angular应用归结为一系列的console.log语句。浏览器控制台中的错误信息是神秘的，堆栈痕迹很少包括可识别的代码，只有Angular内部调用。
应用结构和路由
由于Angular和Polymer都是基于组件的，所以一般的应用结构是相似的。UI是由组件构成的，这些组件被组合成连续的更复杂的组件，这些组件被嵌套，直到出现一个应用程序。在Angular中，你可以另外将相关的组件捆绑成模块，用来限定依赖关系的范围，在需要的时候可以懒加载。
大型应用被组织成视图。视图通常与URL绑定，这样用户就可以链接到应用程序的不同部分，并使用浏览器导航按钮来回移动。视图组件和URL之间的这种映射由路由器处理。
Angular提供了一个有点复杂但功能丰富的路由器，支持任意深度嵌套的路由。它可以帮助开发者控制应用程序的JavaScript大小，懒惰地加载那些以后才需要的模块的代码。它还允许路由配备Guards，即在视图被激活之前或之后运行的代码，以有条件地防止导航。路由器是通过嵌套对象在TypeScript文件中配置的。
Polymer提供了一个可选的路由器，可以用于URL和组件之间的映射。使用路由器需要几个步骤和大量的重复性代码。你需要添加一个app-location 和 anapp-route 元素到你的应用程序中来监听URL的变化。利用这些信息，你可以决定显示哪些组件，并可以选择（手动）挂起这些组件的懒加载。
默认情况下，Polymer组件只被懒惰地加载到DOM中，但不会被移除。这导致DOM随着时间的推移在大型应用程序中不断增长，这可能会导致性能问题，特别是在内存有限的设备上。
有限的路由器是导致难以在Polymer中构建大型应用的最大因素。
Polymer路由器也支持嵌套路由。然而在实践中，使用嵌套路由会变得非常复杂，因为路由器不知道哪个视图是活动的，所以子路由会在所有视图上被触发，而不管它们是否可见。路由器也不挂接构建工具，所以你需要单独配置视图进行懒加载。
根据我的经验，我觉得缺乏一个稳固的路由器是导致在Polymer中难以构建大型应用的最大因素。
使用数据工作
数据绑定和数据流是构建应用程序的重要方面。Polymer在Web Components标准之上提供的功能之一是一个简单的数据绑定系统，支持数据的单向和双向绑定。相对于双向绑定，单向数据绑定更受青睐，以便于组件与其他框架的集成，并实现Redux等单向数据流模式。
Angular也自带了对单向和双向数据绑定的支持。除了数据绑定之外，它还带有依赖注入（DI）系统，使得挂接服务更加容易，尤其是在测试时。Angular在处理数据方面，尤其是异步HTTP通信方面，大量建立在RxJS和Observables上。如果你没有之前的经验，那么反应式编程模型需要一些时间来适应，但可以让你构建优雅的UI代码。
在表单中编辑数据在Polymer和Angular中有些不同。Polymer有一个表单元素，它扩展了HTML表单。所有的验证都是由表单元素本身来处理的，这有时有点局限性。在Angular中，验证是由框架处理的，这使得结合不同的组件更容易，但仍然有一致的验证。
让它看起来更漂亮
当涉及到定制您的应用程序的外观和感觉时，Angular比Polymer更容易使用。Angular可以与现有的CSS库（如Bootstrap或Semantic UI）一起工作，您可以轻松地编写全局CSS，使您的应用程序具有统一的外观。
Polymer在外观和感觉方面更难定制，因为Web Components的设计是为了封装它们的实现，这意味着您需要声明您在组件中导入的CSS变量和mixins。这意味着你不能轻易使用像Boostrap这样的东西，而且很难让第三方组件适合你的应用程序的外观和感觉。
Angular也让动态样式的工作比polymer更容易，因为模板语法中包含了一个根据条件设置样式名称的助手。在polymer中，你需要依靠基本的数据绑定和自定义方法，这增加了很多锅炉模板。
移动支持。渐进式Web应用，原生应用，还是两者兼而有之？
在移动支持方面，Angular和Polymer有不同的方法。Angular更专注于当今的需求，所以它包含了对构建Web应用和原生应用的支持（尽管原生支持需要你单独编写一个视图的实现）。他们最近还增加了对创建渐进式Web应用（PWA）的支持。
对于Polymer来说，PWA是唯一的移动策略。这与Polymer的目标一致，即基于Web标准来扩展你在Web上可以做的事情。
可维护性和稳定性
在API稳定性方面，Angular和Polymer都有一个不太好的记录。Polymer从0.5版本到1.0版本有一段非常艰难的过渡期。同样，Angular 2在开发过程中也经历了一段较长的API变更期，持续到整个候选版本。甚至在 "稳定 "的2.x版本中也有一些较小的突破性变化。
好消息是，两个团队都已经注意到了这一点，并计划在未来提供更顺畅的升级路径。目前处于候选版本的Polymer 2包含了对传统组件的支持，因此你可以逐个迁移应用。Angular团队还承诺，Angular 2+中的突破性变化将更容易迁移，并多次暗示将推出迁移工具来简化变化。
虽然很难预测未来，但我认为Polymer和它所建立的W3C标准将为需要长期维护的应用提供更稳定的基础。
选择开发舒适度而非性能
我们知道，Polymer可以让我们创建快速的Web应用。但事实证明，Polymer本身太低级，无法轻松构建大型应用。显然，开发者选择Angular这样的框架而不是Polymer还是有原因的。框架可以帮助开发者构建应用程序，并处理诸如路由、依赖注入、本地化以及其他你在构建大型应用程序时需要处理的事情。不幸的是，这种开发者的便利性是以终端用户的运行时性能为代价的。
使Web Components适合构建更大、更高性能的应用程序的第一步是改进路由器。它既有助于为应用程序提供结构，又能使创建具有数十或数百个视图的应用程序变得更加容易。
在本系列的最后一篇文章中，我将看看为什么谷歌正在开发两个基于组件的竞争性工具来构建Web应用，以及它对Web框架的未来可能意味着什么。
原文发表于vaadin.com。
