Modernisierung von Legacy-Anwendungen

**Maliko**

Wir haben vorletztes Jahr unsere Software von Delphi 7 auf Delphi 10.3 geupdatet. Das war zwar ein ganz schöner Krampf, aber inzwischen läuft es einigermaßen rund. Wenn ihr das wirklich vor habt, stellt euch auf viel Ärger ein (zumindest wenn ihr ein so altes Projekt updatet). Mir fliegen immer noch 100te Deprecated-Meldungen beim Compilieren um die Ohren, weil wir einfach nicht dazu kommen alle Programmteile so zu updaten, dass aktuelle Componenten dafür genutzt werden. Einige Komponenten mussten wir sogar komplett ersetzen, da sie unter Delphi 10.3 nicht mehr lauffähig waren. Also nehmt euch gut Zeit wenn ihr ein so altes Projekt updaten wollt. Das wird dauern. Wir haben gut 3 Monate dafür gebraucht, bis alles wieder lief.

**TigerLilly**

Die Software läuft gut + wird aktiv vertrieben. Ich würde gern ca 2/3 binnen Jahresfrist erneuert haben, das lässt sich gut abgrenzen. Weil da stellenweise noch Code aus dem letzten Jahrtausend :- ) drin ist, würde ich alles, was allgemeiner Basiscode ist kübeln + neu machen. Ich würde auch alles, was mit Ausgabe etc zu tun hat, kübeln. Da gibt es viel zu viel neues und besseres (bzw gibt es manches jetzt eben auch nicht mehr). Ich würde wirklich nur den Kern der Businesslogik mitnehmen. Viele Anforderungen haben sich geändert und vieles weiß ich mittlerweile besser, bzw würde ich anders machen, weil ich weiß, wo in der Praxis Probleme auftauchen.

Aber vorher sind halt ein paar Grundsatzentscheidungen zu treffen:
- Als Web-Anwendung umsetzen? Native Anwendungen je Plattform? Saas?
- Welche Datenbank bei Stand-Alone bzw bei MultiUser
- Deployment und Installer bei Multiplatform
- Reporting und Ausgabe
- Import/Export/Replikation/Cloud
- Aktualisierung großer Datenmengen beim Kunden draußen

Und ja. Die Punkte waren als Ziele gedacht.

**Phoenix**

Zitat von TigerLilly:

Aber vorher sind halt ein paar Grundsatzentscheidungen zu treffen:
- Als Web-Anwendung umsetzen? Native Anwendungen je Plattform? Saas?
- Welche Datenbank bei Stand-Alone bzw bei MultiUser
- Deployment und Installer bei Multiplatform
- Reporting und Ausgabe
- Import/Export/Replikation/Cloud
- Aktualisierung großer Datenmengen beim Kunden draußen

Und ja. Die Punkte waren als Ziele gedacht.

Datenbank: Für standalone / Single-User reicht in aller Regel Sqlite. Andernfalls kommts drauf an was an Lizenzkosten bezahlt werden soll

Im Falle von OpenSource geht schon seit Jahren sehr vieles in Richtung PostgreSQL.

Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova.
Der Grund ist dass man mit einer einheitlichen Code-base wirklich alle Plattformen und vor allem auch alle Form-Faktoren (kleine hochkant Screens auf Smartphones über Tablet-Layouts bis hin zu Ultra-Wide Screens am Desktop) bedienen kann.
Schaut man sich z.B. Spotify an, Slack, MS Teams, Discord, Google Office, O365, Whatsapp, an (und viele viele andere Anwendungen), merkt man in den meisten Fällen noch nichtmal das das hintendran eigentlich alles nur Webseiten sind. Selbst 3D-Animationen mit 60FPS bekommt man damit problemlos hin.
Und wenn man ehrlich ist: Bei Geschäftsanwendungen ist es in aller Regel auch vollkommen egal wenn es Web-ig aussieht, hauptsache der Benutzer hat überall ein einheitliches Look & Feel und findet sich schnell zurecht.
Bei Consumer-Anwendungen sieht das allerdings ggf. anders aus, hier mag es unter Umständen sinnvoll sein, das man für eine möglichst breite Akzeptanz Plattform-Nativ aussehen will.

PWA's kann man bei Android auch einfach von der Webseite aus installieren. Will man das auf iOS in den Appstore bringen bleibt leider nichts anderes über als es zu Wrappen (z.B. Cordova), aber auch das ist in aller Regel kein Problem.

Die logische Schlussfolgerung daraus ist: Wenn man das Backend für das Web-Frontend sinnvoll ver-API-fiziert, ist es ein superkleiner Schritt das als SaaS bereitzustellen.

Sync-Thematiken mit lokalen Installationen sind meistens nur ein kleines technisches Detail (das haben wir auch schon etliche male gebaut).

**TigerLilly**

Zitat von Phoenix:

Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova.

Ja, das ist gut entschieden. Aber da reden wir nicht mehr von Delphi, oder was nutzt Ihr da für Front End und Back End/API?

**Phoenix**

Zitat von TigerLilly:

Zitat von Phoenix:

Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova.

Ja, das ist gut entschieden. Aber da reden wir nicht mehr von Delphi, oder was nutzt Ihr da für Front End und Back End/API?

Für die Frontend-Apps nehmen wir meistens Angular, aktuell wird aber auch viel nach Blazor nachgefragt.
Im Backend setzen wir auf .NET (Core) 5+, was seit der .NET Core-Reinkarnation deutlich schlanker, moderner und performanter unterwegs ist.

**TigerLilly**

Ja, Angular soll recht cool sein. Aber da hab ich kein projekttaugliches Know-How.

Am liebsten wär mir, wenn sich 2,3 finden, die vor derselben Hürde stehen wie ich. Dann einigt man sich auf einen technischen Unterbau, einer macht das reporting, einer das Benutzermanagement etc. Die Core-Logik macht wieder jeder selber + nutzt die Bausteine der anderen.

**Bernhard Geyer**

Zitat von TigerLilly:

Ja, Angular soll recht cool sein.

Eine wichtige/schwierige Entscheidung ist auf dem (für einem) RICHTIGEN Framework-Stack zu setzen.

Angular ist hier fast schon wieder "Schnee von Gestern" und die neuen Frameworks sind Vue und React (und noch ein 2-3 andere). Welche in 5 Jahren noch aktiv gepflegt wird oder "untergeht" ist offen.
Wir haben auch mal auf ein Framework von google gesetzt, welches aber mittlerweile als aussterbendes Framework gilt.

**taveuni**

Zitat von Phoenix:

Zitat von TigerLilly:

Zitat von Phoenix:

Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova.

Ja, das ist gut entschieden. Aber da reden wir nicht mehr von Delphi, oder was nutzt Ihr da für Front End und Back End/API?

Für die Frontend-Apps nehmen wir meistens Angular, aktuell wird aber auch viel nach Blazor nachgefragt.
Im Backend setzen wir auf .NET (Core) 5+, was seit der .NET Core-Reinkarnation deutlich schlanker, moderner und performanter unterwegs ist.

Hallo Sebastian, Sorry für das rauskramen dieses alten Beitrags. Eine Frage: Wir sind dran unsere Delphi Frontends abzulösen. Im Backend sind wir schon mehrheitlich mit .net Core unterwegs. Nun evaluieren wir Angular, React usw. Dabei sind wir auf Svelte gestossen und erste Tests sind begeisternd. Hast Du da Erfahrungen (auch im Vergleich zu React, Angular, Vue)?
Vielen Dank
Gruss Werner

Edit: Frage natürlich auch an TigerLilly

**Phoenix**

Zitat von taveuni:

Hallo Sebastian, Sorry für das rauskramen dieses alten Beitrags. Eine Frage: Wir sind dran unsere Delphi Frontends abzulösen. Im Backend sind wir schon mehrheitlich mit .net Core unterwegs. Nun evaluieren wir Angular, React usw. Dabei sind wir auf Svelte gestossen und erste Tests sind begeisternd. Hast Du da Erfahrungen (auch im Vergleich zu React, Angular, Vue)?

Svelte ist noch relativ Jung, und es ist eher leichtgewichtig. Das Entwicklungsmodell ist auch eher statisch, will heissen dort wird alles zur Übersetzungszeit gemacht und nicht zur Laufzeit.
Das mag auf den ersten Blick attraktiv wirken, allerdings kommt es dann darauf an, was man damit machen will.

Businessanwendungen tendieren dazu, irgendwann eine gewisse Komplexität zu erreichen.
Das bedeutet, man braucht zur Laufzeit irgendwann mehr Dynamik - das geht mit Svelte nicht wirklich, weil dort alles zur Build-Time erstellt wird - und zur Entwicklungszeit braucht man viel Übersicht und Kontrolle.
Auch hier hat Svelte massive Nachteile, weil hier sowohl die HTML-Struktur, der JS-Code als auch das Styling in einem File sind. Du hast hier also gar keine Chance, auch nur irgendwas in Richtung Separation of Concerns umzusetzen.

Will heissen, wenn es nur darum geht, eine einfache Master-Detail Ansicht umzusetzen, go for it, aber wenn Du komplexere Anwendungen bauen willst, wirst Du furchtbar schnell an die Grenzen stossen.
Vue hat da ähnliche Probleme.

Bleiben React und Angular über, wenn man wirklich sinnvoll an größeren Applikationen arbeiten will.
Und dann stellt sich die Frage, für was wurden die jeweiligen Frameworks entwickelt bzw. wo kommen sie her.

React kommt von Facebook bzw. Meta. Deren Webanwendungen sind Social Networks. Das bedeutet sehr oft die gleichen Elemente auf einer Seite, endloses Scrolling, und bei jedem Beitrag die gleichen Interaktionsmöglichkeiten, die aber jeweils sehr begrenzt sind (Kommentar hinterlassen, Liken, Teilen...). Das Backend von Facebook war im übrigen historisch mal PHP, dementsprechend fühlt sich das React Modell auch so an wie serverseitiges Rendering.
Wenn das die Hauptaufgaben Deiner Business-Anwendung sind, ja, dann ist React das richtige Tooling.

Angular kommt von Google. Die bauen damit so Sachen wie Gmail, die G Suite bzw. jetzt Google Workspace - also Calendar, Drive, Docs, Sheets, Slides, Forms etc.pp.
Also alles eher komplexe Anwendungen mit eher wenigen sich wiederholenden Elementen und dafür jedes deutlich Interaktionsfreudiger.

Angular setzt dabei auf ein sehr Komponentenorientieres Vorgehen, jede Komponente trennt Layout von Code und von Style, und Angular ist dabei sehr opionated was die richtige Anwendungsarchitektur im Web angeht. Es drängt sehr stark in Richtung reaktives Programmieren (weil der Code nunmal in der Eventloop der JS-Engine des Browsers lebt). Alles was rein kommt ist ein Event (Tastatureingaben, Clicks, Touch-Eingaben, die asynchrone Antwort einer HTTP-Anfrage an den Server, etc.pp.), und RxJS erlaubt es, ungeheuer elegant mit Eventstreams umzugehen. Auch das State-Management ist sehr opinionated mit dem Componentstore.

Wenn man sich also mit der Architektur und den Konzepten dahinter auseinangersetzt hat und versteht, warum das so ist, kannst Du mit Angular in kürzester Zeit die komplexesten Anwendungen umsetzen.
Die Lernkurve dahin ist allerdings zugegebenermassen ein wenig steiler.

**Bernhard Geyer**

Zitat von Maliko:

Mir fliegen immer noch 100te Deprecated-Meldungen beim Compilieren um die Ohren, weil wir einfach nicht dazu kommen alle Programmteile so zu updaten,

Die sollen auf jeden Fall weg.
Damit bemerkst du nicht mehr wenn neue Meldungen rein kommen da ob nun 400 oder 410 Meldungen kommen keinen Mehr interessiern.

Zitat von Maliko:

Einige Komponenten mussten wir sogar komplett ersetzen, da sie unter Delphi 10.3 nicht mehr lauffähig waren.

Wir haben vor dem update geschaut das nur gepflegte Komponenten drin sind.
Und nach Umstellung dann nicht mehr nötige Kompos (z.B. bsala webbrowser-Komponenten) dann auch entsorgt.

Zitat von Maliko:

Wir haben gut 3 Monate dafür gebraucht, bis alles wieder lief.

Bei uns lief das Jahrlang nebenbei, bis dann a, Druck zu groß wurde und b, Vorbereitungen soweit waren.
D6 -> XE6 -> 10.2 - 10.4 war der Weg und möchte nie mehr zu D6 zurück