|
1 | | -# abap2UI5 vs. Over-the-Wire Frameworks |
| 1 | +# Over-the-Wire: An Introduction for Business Applications |
2 | 2 |
|
3 | | -This page compares **abap2UI5** with modern "HTML Over the Wire" frameworks like **htmx**, **Phoenix LiveView**, and **Laravel Livewire**. |
| 3 | +## Background: Why is this relevant again? |
4 | 4 |
|
5 | | -The goal is to show how abap2UI5 combines Over-the-Wire simplicity with SAP-specific technologies, offering a lightweight alternative for UI5 development. |
| 5 | +In the early days of web development, **all websites were server-rendered**. |
| 6 | +Each user action, like clicking a link or submitting a form, triggered a full-page reload, with the server delivering the complete HTML response. |
6 | 7 |
|
7 | | -## Comparison: abap2UI5 vs htmx / LiveView / Livewire |
| 8 | +With the rise of **Single Page Applications (SPAs)**, this changed. SPAs moved UI rendering and application logic to the browser, using JavaScript frameworks like React, Angular, or Vue. This allowed for rich, interactive user experiences—but also introduced significant complexity in development, deployment, and maintenance. |
8 | 9 |
|
9 | | -| Concept | abap2UI5 | htmx / LiveView / Livewire | |
10 | | -|---------------------------|--------------------------------------------------------|-------------------------------------------------------------| |
11 | | -| **UI Rendering** | ABAP generates UI5 XML Views, rendered in browser | Server renders HTML, sends fragments to browser | |
12 | | -| **Frontend knowledge** | Frontend app only renders Views & Data, no app logic | Browser is "dumb", no application state or logic | |
13 | | -| **Interactivity** | UI events trigger AJAX calls to ABAP backend | Events trigger AJAX/WebSocket calls to backend | |
14 | | -| **State Management** | Backend holds full application state, Drafts simulate session | Backend maintains state (LiveView: WebSockets, Livewire: stateless diffs) | |
15 | | -| **Delta Rendering** | View & Data sent as JSON diff, only updated controls re-rendered | HTML diffs / fragments sent, partial DOM updates | |
16 | | -| **APIs required?** | Simple HTTP handler, no OData/CDS | No explicit API, server returns ready-to-render UI | |
17 | | -| **Frontend development effort** | No custom JS needed, pure ABAP | Minimal JS, declarative HTML attributes | |
18 | | -| **Deployment** | Pure ABAP code, no frontend build/deploy, via abapGit | Standard web app deployment, no frontend frameworks needed | |
| 10 | +Today, **Over-the-Wire approaches revisit the original idea of server-side rendering**, but with modern techniques. Instead of sending entire pages, only small HTML fragments or UI updates are transferred, combining simplicity with interactivity. |
19 | 11 |
|
| 12 | +## What is "Over the Wire"? |
| 13 | + |
| 14 | +**Over-the-Wire** refers to a development approach where the server generates and sends **ready-to-render HTML fragments** directly to the client (browser). |
| 15 | +Unlike modern Single Page Applications (SPAs), which rely on JSON data and complex client-side rendering, Over-the-Wire keeps the frontend logic minimal and leverages server-side rendering for both initial load and dynamic updates. |
| 16 | + |
| 17 | +In simple terms: |
| 18 | +- The **server prepares the user interface** (UI) and sends it as HTML. |
| 19 | +- The **browser displays what the server sends**, without building the UI from raw data. |
| 20 | + |
| 21 | +This approach reduces complexity and is especially suitable for applications where business logic resides on the server. |
| 22 | + |
| 23 | +## How does it differ from Single Page Applications (SPA)? |
| 24 | + |
| 25 | +In a typical SPA: |
| 26 | +- The client requests **raw data** (e.g., JSON) from the server. |
| 27 | +- The frontend JavaScript framework processes the data and builds the UI dynamically in the browser. |
| 28 | + |
| 29 | +In contrast, with Over-the-Wire: |
| 30 | +- The client requests **HTML fragments** directly from the server. |
| 31 | +- The server sends **fully rendered UI components**, which are inserted into the page. |
| 32 | + |
| 33 | +This shifts the responsibility for UI rendering back to the server, simplifying the frontend layer. |
| 34 | + |
| 35 | +## Benefits of Over-the-Wire for Business Applications |
| 36 | + |
| 37 | +- **Reduced Frontend Complexity**: No need for heavy JavaScript frameworks or complex build pipelines. |
| 38 | +- **Faster Time-to-Market**: Leveraging existing backend logic accelerates development. |
| 39 | +- **Better SEO & Accessibility**: Server-rendered HTML is immediately visible and indexable. |
| 40 | +- **Lower Maintenance Effort**: Fewer dependencies and simpler architecture. |
| 41 | +- **Efficient for CRUD Applications**: Ideal for forms, tables, dashboards, and admin tools. |
| 42 | + |
| 43 | +## Typical Use Cases |
| 44 | + |
| 45 | +- Internal business applications |
| 46 | +- ERP, CRM, and administrative tools |
| 47 | +- Data entry forms and report views |
| 48 | +- Applications with limited interactivity requirements |
| 49 | + |
| 50 | +## Limitations to Consider |
| 51 | + |
| 52 | +While Over-the-Wire offers significant advantages for backend-driven applications, it is less suitable for: |
| 53 | +- Highly interactive, real-time collaboration tools (e.g., design apps, chat platforms) |
| 54 | +- Applications requiring offline capabilities or rich client-side interactions |
| 55 | +- Scenarios where frontend and backend are developed by separate, independent teams |
| 56 | + |
| 57 | +## Popular Frameworks and Tools Following Over-the-Wire Principles |
| 58 | + |
| 59 | +| Framework | Primary Use | Technology Stack | |
| 60 | +|------------------------|-----------------------------------------------|---------------------------| |
| 61 | +| **htmx** | Enhances existing HTML pages with minimal JS | Technology-agnostic | |
| 62 | +| **Hotwire (Turbo)** | Full Over-the-Wire framework for modern web apps | Ruby on Rails | |
| 63 | +| **Phoenix LiveView** | Real-time UI updates via WebSockets | Elixir / Phoenix | |
| 64 | +| **Livewire** | Server-driven UI components for Laravel | PHP / Laravel | |
| 65 | +| **Unpoly** | Simplifies partial page updates without SPAs | Technology-agnostic | |
| 66 | +| **Blazor Server** | Server-side UI rendering with SignalR | .NET / C# | |
| 67 | +| **Inertia.js** | SPA-like experience without APIs | JavaScript + Laravel/Rails | |
20 | 68 |
|
21 | 69 | ## Conclusion |
22 | 70 |
|
23 | | -abap2UI5 takes the best of the "HTML Over the Wire" philosophy and applies it to SAP UI5 development. It reduces the overhead of typical SAP frontend architectures by: |
24 | | -- Keeping all logic and state in ABAP. |
25 | | -- Avoiding OData, CDS, and separate frontend deployments. |
26 | | -- Leveraging UI5 XML Views for rendering without losing UI5 flexibility. |
| 71 | +Over-the-Wire represents a pragmatic approach for building web applications where the **server remains in control of UI rendering**. |
| 72 | +It aligns well with business contexts that prioritize **simplicity, maintainability, and tight integration of backend and frontend logic**. |
| 73 | + |
| 74 | +For typical business applications—such as dashboards, forms, and administrative tools—Over-the-Wire offers a lean and efficient alternative to heavy SPA architectures. |
| 75 | + |
| 76 | +## Over-the-Wire and abap2UI5 |
| 77 | + |
| 78 | +The **abap2UI5** framework adopts the fundamental idea of Over-the-Wire, but with a specific focus on SAP development environments. |
| 79 | +Instead of sending raw data to a generic frontend application, abap2UI5 delivers a **view and corresponding view model** from the ABAP backend to the client. |
27 | 80 |
|
28 | | -For developers familiar with SAP GUI and ALV, abap2UI5 offers a modern yet minimalistic approach to build UI5 applications — fast, backend-driven, and efficient. |
| 81 | +Unlike traditional Over-the-Wire frameworks that send ready-made HTML fragments, abap2UI5 leverages the existing SAPUI5 runtime in the browser to render the final HTML dynamically. |
| 82 | +However, this rendering is based on **static UI5 code**, which is **never changed or generated dynamically on the frontend**. All business logic, UI definitions, and dynamic behavior are controlled exclusively from the backend. |
29 | 83 |
|
30 | | -## Further Reading |
| 84 | +In summary: |
| 85 | +- The **frontend code remains static and generic**. |
| 86 | +- The **backend defines what the UI should look like**, including the data and behavior. |
| 87 | +- This approach preserves the **Over-the-Wire principles of simplicity and backend-driven UI control**, while integrating seamlessly with SAPUI5 technology. |
31 | 88 |
|
32 | | -- [abap2UI5 GitHub Repository](https://github.com/abap2UI5/abap2UI5) |
33 | | -- [htmx Documentation](https://htmx.org/docs/) |
34 | | -- [Phoenix LiveView Documentation](https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html) |
35 | | -- [Laravel Livewire Documentation](https://laravel-livewire.com/docs) |
| 89 | +abap2UI5 thus bridges the gap between Over-the-Wire simplicity and the established SAPUI5 ecosystem, enabling efficient and maintainable web applications without introducing unnecessary frontend complexity. |
0 commit comments