Skip to content

Commit 29e0e61

Browse files
oblomov-devoblomov-dev
authored
Update comparison.md
1 parent dae6ed1 commit 29e0e61

File tree

1 file changed

+55
-33
lines changed

1 file changed

+55
-33
lines changed

‎docs/advanced/technical/comparison.md‎

Lines changed: 55 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -1,41 +1,63 @@
11
# abap2UI5 Compared to UI5, RAP & Over-the-Wire Frameworks
22

3-
This page compares **abap2UI5** with both:
4-
1. Modern "HTML Over the Wire" frameworks like **Phoenix LiveView**, **Laravel Livewire**, and **htmx**.
5-
2. Traditional SAP UI5 approaches: **Freestyle UI5** and **RAP (Fiori Elements)**.
3+
This page provides a structured comparison of **abap2UI5** with:
4+
1. Modern "HTML Over the Wire" frameworks like **htmx, LiveView, Livewire**
5+
2. Traditional **UI5 Freestyle** development
6+
3. SAP’s **RAP (Fiori Elements)** approach
67

78
The goal is to show how abap2UI5 combines Over-the-Wire simplicity with SAP-specific technologies, offering a lightweight alternative for UI5 development.
89

9-
## 1. abap2UI5 vs LiveView, Livewire & htmx
10-
11-
| Concept | LiveView / Livewire / htmx | abap2UI5 |
12-
|---------------------------|------------------------------------------------------|----------------------------------------------------------------|
13-
| **Server-rendered UI** | HTML is rendered on the server, sent as fragments | UI5 XML Views are generated in ABAP and rendered in browser |
14-
| **Frontend knowledge** | Browser is "dumb", no app state, only rendering HTML | UI5 app does not know app state or logic, renders Views + Data |
15-
| **Interactivity** | User events trigger AJAX/WebSocket requests to server | User events trigger AJAX roundtrips to ABAP backend |
16-
| **State Management** | Server maintains state (LiveView via WebSockets, Livewire via stateless diffs) | State and flow managed fully in ABAP (Drafts simulate statefulness) |
17-
| **Delta Rendering** | Only changed HTML parts are sent | View & Data sent as JSON diff, UI5 Controls are selectively updated |
18-
| **APIs required?** | No REST/OData needed, server returns UI directly | No OData/CDS needed, simple generic HTTP handler |
19-
| **Frontend development** | Minimal JS needed, declarative, markup-driven | No custom JS needed, all UI logic in ABAP |
20-
| **Deployment** | Part of backend app, simple web deployment | Pure ABAP code, no separate UI deployment, fully via abapGit |
21-
22-
> **Summary:** abap2UI5 applies the "HTML Over the Wire" principle to SAP UI5 applications. Like LiveView, Livewire, and htmx, it keeps state and logic on the server, simplifying frontend complexity. The difference: it leverages UI5 XML Views and integrates natively into ABAP workflows.
23-
24-
## 2. abap2UI5 vs SAP Freestyle UI5 & RAP
25-
26-
| Concept | abap2UI5 | UI5 Freestyle | RAP (Fiori Elements) |
27-
|---------------------------|--------------------------------------------------------|-----------------------------------------------------------|------------------------------------------------------------|
28-
| **UI Rendering** | UI5 XML Views generated in ABAP, rendered in browser | XML Views & JS Controllers render data in frontend | UI generated from annotations & templates |
29-
| **Frontend knowledge** | Frontend shows Views & Data from backend, no app logic | Application logic resides in frontend JS Controllers | Frontend driven by annotations, minimal logic |
30-
| **Interactivity** | Events sent via AJAX to ABAP backend | Event handling in frontend JS, calls backend via OData | OData calls on interaction, bound to annotations |
31-
| **State Management** | Managed in ABAP, Drafts emulate stateful flow | Frontend models handle state, backend only for persistence | RAP Draft handling via framework abstractions |
32-
| **APIs required?** | Simple generic HTTP handler, no OData/CDS necessary | Requires SEGW / OData / CAP service layers | Requires typed OData & CDS artifacts |
33-
| **Flexibility** | Full control in ABAP for Views, Models & Logic | Flexible, but high frontend development effort | Highly structured, less runtime flexibility |
34-
| **Frontend Artifacts** | No BSP / UI5 app deployment needed, index.html in ABAP | BSP App, UI5 repository deployment required | UI5 App generated from annotations, deployment required |
35-
| **Development Workflow** | Pure ABAP development, deploy via ABAP class activation | Frontend/backend developed & deployed separately | Backend annotations drive frontend generation |
36-
| **Versioning & Deployment**| Single ABAP code line, full abapGit integration | Separate transport of frontend & backend | CDS, OData, UI5 app artifacts transported separately |
37-
38-
> **Summary:** abap2UI5 avoids the complexity of OData, CDS, and separate frontend deployments. Unlike UI5 Freestyle (which requires full-stack JS development) and RAP (which follows strict structures), abap2UI5 allows for rapid, flexible UI5 development directly in ABAP — all in a single code line.
10+
## 1. abap2UI5 vs Over-the-Wire Frameworks
11+
12+
| Concept | abap2UI5 | htmx / LiveView / Livewire |
13+
|---------------------------|--------------------------------------------------------|-------------------------------------------------------------|
14+
| **UI Rendering** | ABAP generates UI5 XML Views, rendered in browser | Server renders HTML, sends fragments to browser |
15+
| **Frontend knowledge** | Frontend app only renders Views & Data, no app logic | Browser is "dumb", no application state or logic |
16+
| **Interactivity** | UI events trigger AJAX calls to ABAP backend | Events trigger AJAX/WebSocket calls to backend |
17+
| **State Management** | Backend holds full application state, Drafts simulate session | Backend maintains state (LiveView: WebSockets, Livewire: stateless diffs) |
18+
| **Delta Rendering** | View & Data sent as JSON diff, only updated controls re-rendered | HTML diffs / fragments sent, partial DOM updates |
19+
| **APIs required?** | Simple HTTP handler, no OData/CDS | No explicit API, server returns ready-to-render UI |
20+
| **Frontend development effort** | No custom JS needed, pure ABAP | Minimal JS, declarative HTML attributes |
21+
| **Deployment** | Pure ABAP code, no frontend build/deploy, via abapGit | Standard web app deployment, no frontend frameworks needed |
22+
23+
> **Summary:**
24+
abap2UI5 adopts the same backend-driven approach as htmx, LiveView, and Livewire, but uses UI5 XML Views and integrates natively into ABAP environments — combining Over-the-Wire simplicity with SAP UI technology.
25+
26+
27+
## 2. abap2UI5 vs UI5 Freestyle
28+
29+
| Concept | abap2UI5 | UI5 Freestyle |
30+
|---------------------------|--------------------------------------------------------|--------------------------------------------------------------|
31+
| **UI Rendering** | ABAP generates UI5 XML Views, browser renders UI | UI5 XML Views created & rendered in frontend (WebIDE/BAS) |
32+
| **Frontend knowledge** | Frontend does not know application state or flow | Full application logic in frontend JS Controllers |
33+
| **Interactivity** | Events sent to ABAP backend via AJAX | Events handled in frontend, backend provides data via OData |
34+
| **State Management** | Managed in ABAP, Drafts emulate frontend state | State managed in frontend models, backend only persists data |
35+
| **APIs required?** | Generic HTTP handler, no OData/CDS needed | Requires OData Service (SEGW / CAP) |
36+
| **Flexibility** | Full runtime control of Views, Models, Logic in ABAP | High flexibility in frontend, but complex coordination |
37+
| **Frontend Artifacts** | No BSP, index.html is stored in ABAP source code | BSP App or UI5 repository deployment required |
38+
| **Development Workflow** | Pure ABAP, deploy by class activation | Separate frontend & backend development & deployment |
39+
| **Versioning & Deployment**| Single abapGit project, backend-only transports | Frontend and backend transported separately |
40+
41+
> **Summary:**
42+
Compared to UI5 Freestyle, abap2UI5 eliminates the need for separate frontend apps, OData services, and JavaScript controllers — enabling faster development cycles with a pure ABAP approach while keeping UI5's capabilities.
43+
44+
## 3. abap2UI5 vs RAP (Fiori Elements)
45+
46+
| Concept | abap2UI5 | RAP (Fiori Elements) |
47+
|---------------------------|--------------------------------------------------------|--------------------------------------------------------------|
48+
| **UI Rendering** | UI5 XML Views generated dynamically in ABAP | UI generated from CDS annotations & templates |
49+
| **Frontend knowledge** | Frontend renders server-provided Views & Data, no logic | Frontend uses annotations, limited runtime flexibility |
50+
| **Interactivity** | Events trigger AJAX requests to backend | Interactions call OData services defined via CDS & RAP classes |
51+
| **State Management** | ABAP-driven state & drafts simulate statefulness | RAP framework handles drafts & state abstraction |
52+
| **APIs required?** | No OData/CDS needed, simple generic HTTP handler | Requires typed OData Services, CDS Views |
53+
| **Flexibility** | Full control of View, Model, Logic in ABAP, runtime changes possible | High structure, runtime changes limited by RAP framework |
54+
| **Frontend Artifacts** | No separate UI5 deployment, index.html in ABAP code | Generated UI5 app artifacts, deployment required |
55+
| **Development Workflow** | Pure ABAP, deploy via class activation | CDS, OData, UI5 artifacts developed & transported separately |
56+
| **Versioning & Deployment**| Single abapGit project, cloud & on-prem compatible | Separate transport of backend & frontend artifacts |
57+
58+
> **Summary:**
59+
While RAP enforces structured development through annotations, OData, and CDS artifacts, abap2UI5 offers more runtime flexibility and simpler development by avoiding these layers and keeping everything within ABAP.
60+
3961

4062
## Conclusion
4163

0 commit comments

Comments
 (0)