Jerry加入SAP电商云Spartacus开发团队从零开始学习Angular，对这个知名前端开发框架的来龙去脉做了一些简单的了解。在这篇的一万多粉丝中，有很多朋友在日常工作中使用SAPUI5开发前端应用，但可能不是每个朋友都熟悉SAPUI5的前世今生，所以我想借用这篇文章了解SAP简单介绍一下UI5的发展历史。本文部分改编自SAPUI5开发人员AndreasKunz的SAP社区博客。可以点击文末“查看原文”访问英文原版博客。与国内外流行的前端开发框架三驾马车Angular、React、Vue一样，SAPUI5也是一个基于JavaScript的前端开发框架。与这三者相比，SAPUI5在面向企业用户的前端应用开发领域更具优势，主要体现在以下几个方面：长期兼容性和可维护性（long-termcompatibility&maintenance）开箱即用的企业级前端应用的开箱即用控件，国际化支持，应用健壮性和安全性支持，AccessibilitySAPUI5开箱即用，周边社区提供的众多开发和支持工具，SAPUI5也是SAPFiori设计理念和设计系统精心挑选的应用程序开发框架。SAPUI5起源——ProjectPhoenix（凤凰城）SAPUI5最早的起源可以追溯到2008年11月。来自SAP不同开发团队的几名员工，挤在一个只能容纳四个人的小会议室里，被赋予了一个秘密任务：创造一种新的UI开发技术。这个项目当时的代号是Phoneix。这个代号对应的凤凰图标一直沿用至今，成为了SAPUI5的Logo，如下图左上角所示：这种新的UI开发技术必须是灵活的、可扩展的、现代的和独立的Features比如后端实现技术。我们不妨回想一下，2008年在SAP生态的前端开发阶段活跃着哪些技术栈？当时，Jerry刚加入SAP成都研究院一年多，从事SAPBusinessByDesign的开发工作。2008年，SAP比亚迪还没有进入FeaturePack2.0的LeanStack（精简技术栈）时代。依然是基于ABAP和Java双栈（DualStack）架构，UI开发采用了VisualComposer+JavaWebdynpro的方式。同时，SAPCRMOn-Premises还处于新功能不断开发阶段。底层基于SAPBusinessServerPage(BSP)技术的WebClientUI框架。为了适应企业级应用程序从Client/Server架构向Browser/Server架构迁移的历史趋势，用于开发新的SAPCRM应用程序来替代原来在SAPGUI中运行的事务代码。WebClientUI的孪生兄弟ABAPWebdynpro，辅以FPM（FloorPlanManager），在SAPSRMUI开发领域丝毫不逊色于WebClientUI。如今，这对略显“老”的双子星依然在SAP产品UI开发大家庭中占据一席之地。Jerry目前正在使用的SAPCommerceCloud以前在2008年称为Hybris，UI使用较旧的JSP技术。分析这些前端技术，它们都有一个共同点：与后端系统有很强的耦合关系。SAPBSP、WebClientUI、ABAPWebdynpro开发的应用只能在ABAP系统上运行。JavaWebdynpro和JSP页面在没有JVM的情况下无法独立运行。与后台系统的强耦合给企业用户带来的一大挑战是UI技术的可升级性。例如，如果要升级WebClientUI和ABAPWebdynpro的版本，获得更多的特性支持，就得升级SoftwareComponent.SAPWebClientUI/Webdynpro对应ABAPNetweaver的编程范式，使用SAP提供的开发框架它为应用程序开发人员和浏览器提供支持。它在浏览器原生支持的API/CSS样式处理之间建立了一道屏障。这个壁垒是一把双刃剑：一方面，它让应用开发者可以专注于应用的业务逻辑开发，而不必花精力去考虑对企业发展至关重要的安全性、国际化和性能。-级前端应用程序如何实现产品标准，如和辅助功能；另一方面，也给一些真正需要扩展到UI框架的需求的实现带来一些挑战，以充分利用现代浏览器提供的最新特性。比如Jerry还在SAP成都研究院数字创新空间团队工作的时候，曾经做过一个原型开发，引入了一个基于WebGL（WebGraphicsLibrary）标准的第三方库Three.js。SAPCRMWebClientUI呈现不断旋转的3D足球效果。在WebClientUI应用程序中正确呈现此效果确实需要一些工作。SAP架构师团队睿智而有远见的架构师们早就意识到，2008年使用的SAPUI技术存在上述一系列的局限性。SAPUI5的诞生就是为了解决这些问题。SAPUI5正式为外界所熟知是2013年5月SAP在奥兰多的SAPPHIRENOW上发布了关于Fiori的公告。随着第一批共计25款基于SAPUI5的全新Fiori应用的发布，SAPUI5接过了2013年的开发大旗。SAP的前端区。处于起步阶段的UI5是由成熟的Scrum开发团队编码实现的。然后团队继续壮大并分裂成一个Core（核心）团队，另一个团队负责创建“sap.m”控件。起初sap.m命名空间下的控件只用于移动设备，m代表mobile，后来被重新定义为UI5的cross-devicemaincontrollibrary：Maincontrollibrariesacrossdevices。拥抱开源——OpenUI5的诞生在凤凰项目时期，SAPUI5的创始人都是忠实的开源项目爱好者。从立项之初就考虑开源，这样可以更方便的与前端社区协作，更早的得到用户反馈和bug报告，更有效的将UI5推广到SAP开发生态中.2013年12月11日，SAP宣布UI5将在Apache2.0开源许可下以OpenUI5的形式开源，也就是你今天在Github上看到的代码仓库：https://github.com/SAP/openui5中2014年10月，本代码仓库产出第一行代码提交。到2022年3月，代码提交数量增长到78657。OpenUI5包括SAPUI5框架的核心实现和大部分控件库。这些核心实现和控件库开发基本都是SAPUI5团队完成的。有少量SAPUI5控件库，由SAPUI5以外的其他产品开发团队实现。这些控件库有的只用于一些非常特殊的场景，有的包含特殊的知识产权。没有计划开源下提供的许可证，因此不包含在OpenUI5中。SAPUI5的快速发展和成熟作为SAP的旗舰产品S/4HANA选择SAPUI5作为其前端开发技术方案，通过大量SAPFiori应用的开发、交付和客户使用，SAPUI5进入时代随着快速发展，大量围绕SAPUI5的开发工具、访问模块和基础设施层应运而生，例如FioriLaunchpad、SAPWebIDE、Chrome开发者工具扩展UI5Inspector、端到端测试框架UIVeri5，以及UI5项目构建和启动命令行工具UI5Tooling等。这些新工具本身标志着SAPUI5及其社区的成熟。如今，Github上SAP主导的开源项目的代码存储库中有多达10%与SAPUI5相关。SAPUI5不仅增加了函数和控件库的数量，其核心也在不断进化，体现在核心更细粒度和更严格的模块化设计，更合适的依赖声明方式，以及更好的现代浏览性能。服务器异步请求执行能力的编程方法等方面。这些演化发生在UI5核心，不会影响现有SAPUI5应用的正常运行。推动SAPUI5演进的另一个源头是Fiori设计指南的不断发展。从最初的Fiori1.0到最新的3.0版本，Fiori一直在努力为用户提供更连贯、更简单、更愉悦的应用。Fiori设计指南本身正在开发中。SAPUI5作为贯彻指南的技术框架，也在不断调整自身以达到完美贯彻Fiori设计指南的目标。与原来只能通过离线压缩包进行分发的分发方式相比，OpenUI5现在支持多种分发和交互渠道供应用开发者选择：从部署在CDN（ContentDeliveryNetwork，ContentDeliveryNetwork）上的引导文件sap-ui)-core.js，到npm注册表上的openui5包。UI5WebComponents在前端开发生态系统评选的前9名WebComponents库中始终占据一席之地。UI5WebComponents是基于WebComponents标准开发的一组独立的UI元素。这些元素将样式和行为完全封装在自定义HTML标签中，因此可以独立使用，无需依赖SAPUI5框架。一些业务用户可能不需要SAPUI5框架提供的所有功能，或者已经有运行在Angular、React或Vue框架上的前端应用程序，但这些用户仍然希望在他们的应用程序中使用UI5控件。在这种情况下，UI5WebComponents是一个很好的补充解决方案。关于UI5WebComponents的详细介绍可以参考我的文章：FioriFundamentalsandSAPUI5WebComponents。SAPUI5的未来如果你继续关注SAP官方社区带有SAPUI5Tag标签的博客，你会发现以下两个方向是SAPUI5生态系统中讨论较多的主题：继续推动发展UI5WebComponents继续完善SAPUI5对TypeScript的支持其中，更详细的SAPUI5对TypeScript的支持可以参考我的文章：SAPUI5未来发展趋势之一：拥抱TypeScript.EvolutionNeverEnds。如果您对SAPUI5未来的发展方向感兴趣，可以登录SAP官方产品路线图网站，输入关键词SAPUI5，查看SAPUI5未来支持的新特性。谢谢阅读。https://roadmaps.sap.com/
