最近的工作中，笔者受邀给一个团队讲述了SAP开发技术的演进史。我的讲课是按照以下主题来介绍的：其中，SAP的技术回顾和演进，我的想法是从前到后介绍。我画了一张很简单的图：根据作者在社区发布的信息，我个人总结Fiori的两个发展方向为：（1）兼容性，即通过FioriFundamentals，使用非UI5开发框架前端-端开发者也可以用自己喜欢的技术开发符合FioriUX的应用。(2)轻装上阵，即通过SAPUI5WebComponents，不仅可以像之前的UI5控件库一样继续提供很多开箱即用的UI控件，还可以避免前端应用对UI5框架。我们来看看上面提到的两个新概念。FioriFundamentals看看SAP官网的权威定义：上面定义的一些要点：(1)FioriFundamentals在前端应用中起到轻量级表现层的作用，可以和Angular等前端框架一起使用、反应和Vue。(2)FioriFundamentals不是一项新的UI技术，也不会取代UI5，而是CSS和HTML标签的集合，使开发者能够使用他们喜欢的UI框架来开发具有FioriUX风格的应用程序。FioriFundamentals是CSS和HTML标签页的合集，我们来看一个具体的例子。这是FioriFundamentals部署在CDN上的CSS：这是SAPFioriFundamentals帮助文档中提到的绘制表格的标签：如何在Vue应用中使用这些标签：至于为绘制的表格添加事件处理机制这个标签，它的方法和纯Vue应用完全一样，所以一个传统的Vue开发者，在FioriFundamentals的帮助下，几乎不需要额外学习就可以开发SAPFiori应用的前端界面。SAPUI5WebComponents最近在SAP社区有一篇关于WebComponents的博客：UI5WebComponents-theBetaisthere：正如博客文章的标题所说，SAP最近发布了UI5WebComponents的Beta版本，并邀请了大多数SAP开发人员生态系统试用并提供反馈。SAPUI5WebComponents是SAP根据WebComponents标准规范，将之前SAPUI5控件库中的控件重新实现的产物。相信了解SAPUI5的朋友，看完我上面的描述，脑海中会浮现出这些问题：什么是WebComponents标准？为什么SAP要做这个重新实现？重新实施的产品是什么？关于第一个问题，直接访问WebComponents官网即可找到答案。程序员都知道以org结尾的网站喜欢用几百页甚至几千页来定义各种技术规范，WebComponents也不例外：https://www.webcomponents.org...前端组件化一直是一种前端生态中最热门的话题，Angular、React、Vue，前端三驾马车，都有自己的组件实现，而webcomponents.org上定义的规范其实提供了一个标准，只有符合这个标准的才行只有其中的实现才算是通用的组件化实现，现代所有浏览器都可以支持。该规范的内容也托管在github上：它包含四大标准：ShadowDOM、CustomElements、HTMLTemplates和CSSchanges。SAPUI5WebComponents的实施当然符合这些标准。第二个问题是SAP开发UI5WebComponents的动机。作者个人观点：为客户和合作伙伴提供更灵活的UI5控件使用方式，避免对UI5框架的依赖。比如我们要使用UI5控件库中提供的按钮控件，即使我们只在XML视图中写一行简单的定义，借助SAPUI5WebComponents，开发者也可以使用UI5直接不用在控件中导入UI5框架。SAPUI5WebComponents可以在任何前端框架中使用，也就是下图中突出显示的最后一句话。此时，当然需要回答第三个问题。SAPUI5Web组件到底是什么？上图传达的关键点：SAPUI5WebComponents并不是基于UI5框架。也就是说，它与UI5框架没有任何依赖关系，可以独立使用。SAPUI5WebComponents不是SAPUI5框架的继承者，而应该被看作是后者的补充。将UI5控件库提供的控件在HTML层面暴露给消费者，而不是传统方式的API层面暴露。这样UI5WebComponents就可以直接在其他前端框架中使用，而不需要依赖于UI5框架。我们来看一个具体的例子：在浏览器中打开如下HTML页面，你会看到一个UI5按钮。单击时弹出的按钮实例的innerHTML属性值。这是SAPUI5Web组件的最简单的HelloWorld示例。在示例中，我们使用了SAPUI5WebComponents的自定义标记
