Modernisierung von Legacy-Anwendungen

[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.

[haentschman]

Zitat:

Welche in 5 Jahren noch aktiv gepflegt wird oder "untergeht" ist offen....welches aber mittlerweile als aussterbendes Framework gilt.

...siehste, deshalb Delphi. Das geht nicht unter.

[Phoenix]

Zitat von Bernhard Geyer:

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).

React ist älter als Angular

Und es gibt tatsächlich relativ einfache, fachliche Gründe die einem bei der Entscheidung helfen, wann man welches Framework nehmen sollte.
React kommt von Facebook, und ist primär für Anwendungen gedacht, die viel anzeigen und viele, aber dafür immer die gleichen Eingabemöglichkeiten haben. Also eine Ellenlange Timeline von Posts und unter jedem das immer gleiche Kommentar-Eingabefeld und Reaktionsmöglichkeiten (daher der Name: React), auf die Posts.

Baust Du also das neue Facebook: React it is. React ist ausserdem mehr eine Sammlung von Bibliotheken als wirklich ein Framework.

Angular wurde von Google als der neue Unterbau von deren Geschäftsanwendungen wie die GSuite gebaut. Komplexe und schnelle Interaktionen, und dabei den Entwicklern eben nicht nur Tools an die Hand geben, sondern auch Guidelines WIE etwas zu machen ist. Angular setzt dabei stark auf Komponenten (wie Delphi und z.B. Winforms / WPF auch) und lenkt den Entwickler sehr stark in die Richtung das ganze State-Handling über RX (reactive Extensions) zu machen, weil es hiermit sehr effizient wird genau herauszufinden, welche Teile des UIs neu gerendert werden müssen und welche eben nicht (Change detection), was zu einer deutlich besseren UI-Performance führt wenn man eben nicht in einer endlosen Timeline nur virtualisiert scrollen muss.

Schreibst Du also Business-Anwendungen mit einer gewissen Komplexität wirst Du mit React früher oder später an die technischen Grenzen der Bibliotheksammlung kommen.

Vue ist so ein zwischending und kann beides, aber weder das eine noch das andere so richtig gut. Dafür ist es leichtgewichtiger. Wenn Du also eine kleine Anwendung mit einer kleinen Handvoll Ansichten und nur begrenzten Interaktionsmöglichkeiten brauchst kann das funktionieren. Aber wehe die Anwendung wird dann irgendwann deutlich komplexer.

Und ob ein Projekt morgen noch existiert kann Dir sowieso keiner verläßlich sagen. Da müssen nur die zwei, drei Hauptentwickler abends einen Trinken gehen und auf dem Weg dahin vom Bus überfahren werden....

Bei den Web-Frameworks und dem neuen .NET 5+ hat man den Vorteil, das das alles Open Source ist und jeweils sehr viele Firmen da ihre Anwendungen drauf aufbauen. Wenn Google morgen sagt, Angular wird nicht mehr weitergemacht (unwahrscheinlich, die schmeissen ihre neue GSuite eher nicht weg also Busfaktor..., dann haben alleine wir in unserer Firma 3 Kollegen die Angular so im Detail kennen, dass sie in der Lage wären das weiter zu pflegen. Und viele unserer Kunden würden uns dann wahrscheinlich sogar dafür bezahlen wollen, weil deren Invest hoch genug ist um das nicht im Sande verlaufen lassen zu wollen.

[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.