Where cap2UI5 Comes From

If you're a CAP developer, chances are you've never heard of abap2UI5 — it lives in the ABAP world. But cap2UI5 is a direct descendant of it, and knowing the family history explains many of its design decisions (and its unusual class names like z2ui5_cl_ui5_view_builder). Don't worry: you never need to read or write a single line of ABAP to use cap2UI5.

The abap2UI5 story

abap2UI5 is a popular open-source community project from the SAP/ABAP ecosystem. Its promise: write complete SAPUI5 apps purely in ABAP classes — no JavaScript, no XML views to deploy, no separate frontend artifacts, no BSP/UI5 repository uploads. One ABAP class = one app.

It works with the server-driven UI pattern, with an ABAP class in place of the JavaScript one: a generic UI5 frontend is served to the browser once, every interaction is one HTTP roundtrip, and the ABAP class builds the view as XML, binds data and handles events.

The project became successful because it removed an entire deployment and tooling layer for internal tools and utility apps — the same gap that exists on the CAP side. Over the years it grew a large sample collection (abap2UI5-samples), add-ons, and a community, all documented at abap2UI5.org. cap2UI5 is that concept ported to CAP/Node.js: instead of an ABAP class on NetWeaver, a JavaScript class in your CAP project's srv/ folder.

How the port actually works

This is the interesting part, and it's more than a one-time copy. cap2UI5 stays continuously in sync with abap2UI5 through automated pipelines in two build repositories — builder-abap2UI5-js (the framework build) and builder-cap2UI5 (the app build):

abap2UI5 (ABAP sources + UI5 frontend)          abap2UI5/samples
        │                                              │
        ▼                                              ▼
┌──────────── builder-abap2UI5-js sync pipelines ───────────────────────┐
│ update_backend   mirror → transpile ABAP → JS with abap2js            │
│                  (parser: @abaplint) → core/srv/z2ui5                 │
│ update_frontend  mirror → take the UI5 webapp 1:1, patch two          │
│                  config values → core/app/z2ui5/webapp                │
│ update_samples   mirror → transpile the demo apps                     │
│                  → core/srv/app/samples                               │
│ build_core       overlay the generated trees on the hand-written      │
│                  src/ → publish the core package into core/           │
│                  jest suite gates the commit — only green gets pushed │
└────────────────────────────────┬───────────────────────────────────────┘
                                 ▼
┌──────────── builder-cap2UI5 update_cap ────────────────────────────────┐
│ mirror the published core → assemble the CAP app (src/ + vendored     │
│ core) → test → publish 1:1 into the deployable cap2UI5/cap2UI5 repo   │
└─────────────────────────────────────────────────────────────────────────┘

Three different sync policies keep the pieces healthy:

Piece	Where it lands	Policy
Frontend (app/webapp from abap2UI5)	core/app/z2ui5/webapp → mirrored to the app's app/z2ui5/webapp	replaced 1:1 — only the UI5 bootstrap URL in index.html and the backend endpoint in manifest.json are patched
Framework core (transpiled ABAP classes)	core/srv/z2ui5/	fill-in only: the hand-maintained adaptation in builder-abap2UI5-js's src/ wins; transpiled classes are added but never overwrite the curated files
Samples (transpiled demo apps)	core/srv/app/samples/	fully machine-owned: overwritten on every sync

The transpiler (abap2js, built on the open-source ABAP parser @abaplint/core) converts ABAP classes into plain JavaScript. Anything outside its supported subset is emitted as a visible // TODO(abap2js): … comment instead of being silently dropped, and tracked in a transpile report.

What this means for you

• The frontend is battle-tested. You're running the exact UI5 app that thousands of abap2UI5 installations use — every upstream bugfix and new custom control (charts, camera, geolocation, …) flows in automatically.
• The wire format is identical. The frontend cannot tell whether ABAP or Node.js is answering. That's why the whole ecosystem of abap2UI5 knowledge, samples, and patterns applies 1:1.
• The naming is inherited. z2ui5_cl_ui5_view_builder, check_on_init, _bind_edit — these names come from ABAP conventions (z = customer namespace, cl = class, if = interface). They look unusual in JavaScript, but they keep the two worlds mappable line-by-line: any abap2UI5 sample can be ported (or auto-transpiled) to cap2UI5 mechanically.
• Not everything upstream ships comes along. The port carries one pinned framework release and deliberately leaves upstream's frozen legacy package behind — see cap2UI5 vs. abap2UI5 for what that means when you copy an older sample.
• Hundreds of ready samples. The core/srv/app/samples/ folder ships the transpiled abap2UI5 demo apps (z2ui5_cl_smp_app_*) — a huge, browsable cookbook. Try them in the browser playground without installing anything.
• You still write normal JavaScript. The sync pipeline is a maintainer concern. As an app developer you just require two classes and write a JS class — see the Quickstart.

→ Next: Try it in the browser — zero-install playground, or the Quickstart.