The idea of a unified UI5 scaffolding tool

When we look at Open Source software, one of the most prominent ideas of the movement is that contributions get redistributed back to participants in order to “promote the production of high-quality programs as well as working cooperatively with other similarly-minded people” ¹ The SAP Open Source website even strengthens this with a punchline on “Co-Innovation”: “No single company can keep pace with the power and speed of communities that openly co-innovate. We believe that sharing creates value.” ²

With regards to this statement, a look at the current state of UI5 scaffolding tools is somewhat sobering. There are many different code generators, both within SAP and outside. The official UI5 tooling has no scaffolding support. Then there is @sap/generator-fiori for both freestyle UI5- and Fiori Elements apps. Then generator-easy-ui5 by developer advocate Marius Obert. And a plentitude of community generators (do an npm search ui5 generator and see for yourself).

All of them are geared toward the same purpose:

• bootstrapping (parts of) a UI5 application from scratch
• preconfigured for a particular use case (think Fiori Floorplans)
• with dev-, build- and deploy-time tooling included.

While some parts of one generator might be better than the others, and a combination of all of them might even get you where you want at some point, the fact stands:

it’s terribly inefficient.

And any effort of manually combining them becomes highly frustrating quickly, even for experienced UI5 devs.

What we’d need instead is a unified approach, following the initial thought at the beginning of this article:

a UI5 scaffolding approach everyone benefits from – the UI5 team, other SAP departments + -products, the UI5 community.

How could this be achieved?

Here’s an idea.

Let me walk you through this step by step.

1. community-based tooling is out there, manifold

On the one hand, the variety of community-based solutions for UI5 scaffolding might seem too diverse in numbers and quality.
But on the other hand: the solutions exist already, they are out there, some of them even advanced and presented in detail at UI5cons.

The challenge is to find a way to entice streamlining the existing community solutions into a single “engine”. Ideally also under a single roof, so finding and referencing them becomes more easy.

Also, that aggregation of solutions needs nuts and bolts for quality assurance (think auto-executing tests via Github Actions) so that bespoken engine can humm along smoothly.

Then this proverbial community engine would be ready for a proper chassis to put its horsepower onto the street. Or, in software development terms, have the community engine assembled for (re-)use.

2. bolt things together via easy-ui5

The easy-ui5 generator was recently featured in a UI5 NewsCast, and rightfully so. Marius has created a useful tool that has come a long way from a Friday evening pet project to a feature-laden UI5 source generator. Not the least being easy-ui5 ’s capability of bootstrapping application layouts for different deployment scenarios – a focus area where Marius has his ear on the tracks of other SAP teams, following up on changes on target infrastructure, bringing it back to the community via easy-ui5.

So what chassis other than easy-ui5 would be better suited for holding the afore mentioned community engine?

That’s right: none.

So all them streamlined UI5 scaffolding and templating solutions would find a natural fitting bond in easy-ui5.

3. re-use easy-ui5 in SAP generators

Now that a powerful engine and flexible chassis is in place, the groundwork is layed for bodywork and model variance. Namely that the generator-modules present in SAP products/solutions (e.g. WebIDE, Business Application Studio BAS) make re-use of the existing scaffolding capabilites in easy-ui5.

Note that this is not equivalent to a exact 1:1 re-use demand; on the contrary, it makes absolute sense to build enterprise features on top of easy-ui5 – such as multi-language capabilites, preconfigured BTP service bindings, integration stubs, and so on. There’s even no need to build onto all features of easy-ui5, as some might not hit home for SAP use cases.

The point is: don’t redo the functionalities that are already offered via easy-ui5, but make use of them to jump start an enterprise scale-up. No need to re-use all, but re-use at least.

To stay within the automotive analogy: build different car models on a shared chassis/engine base, but don’t build a dedicated engine and chassis for every model.

Return of Investments – for all

As laid out in the beginning of this article, the collaborative nature of Open Source software development benefits all participants, be it individuals or companies.

But in the sketched unified UI5 generator approach, there’s even more to it: by building up the re-use pyramid …

@sap/generators
↑ delivers core functionality
easy-ui5 as “framing” aggregator
↑  provides templates + generators
UI5 community organization

… a value-adding scenario is created that could be returned – via BAS/VS code extensions.

Obviously, the @sap/generators hold the combined functional benefit of the re-use pyramid. When distributed in BAS/VS Code extensions, the investment contained in them gets returned to both UI5 developers who use VS Code (and/or BAS) and paying BAS customers (they might even constitue the same target audience – developers paying for using BAS!).

Voilà. Return of Investment for parties involved.

Isn’t that a nice win-win scenario for all – SAP as a company, developers as a community and UI5 as a technology?

I’m game.