Modernisierung von Legacy-Anwendungen

[TigerLilly]

Gibt es hier noch jemanden, dem eine Modernisierung einer Legacy-App ins Haus steht?
- Datenbank Single User/Multi User
- Multi Platform (jedenfalls Windows/Mac)
- Teilbereiche Mobile

Ich würde mich gern zu den Themen austauschen, vielleicht können wir einander da ja unterstützen + von unterschiedlichen Blickwinkeln profitieren?

Hat jemand Interesse?

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1503314)

Gibt es hier noch jemanden, dem eine Modernisierung einer Legacy-App ins Haus steht?

Nicht, dass mir das selbst ins Haus steht, aber daraus besteht der weitaus größte Teil meiner Aufträge.

[freimatz]

Mobile - da gibt es schon Legacy? :shock:

Ansonsten habe ich es jeden Tag mit Legacy-Anwendungen zu tun. Sie sind 15-30 Jahre alt.

Empfehle dazu auch Discord.

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1503320)

Mobile - da gibt es schon Legacy? :shock:

Ich hatte das so verstanden, dass die drei Punkte das Ziel darstellen. :)

[freimatz]

Scheint mir plausibel. Der Istzustand wäre auch interssant.

[Bernhard Geyer]

Zitat:

Zitat von freimatz (Beitrag 1503320)

Mobile - da gibt es schon Legacy? :shock:

Unsere erste Mobile Anwendung/Lösung hatten wir Unverkauft in die Rundablage entsorgt...
Also ja. Auch beim Mobil dürfte sich sehr viel getan haben (und nicht nur auf HW-Ebene mit den Erstgeräte auf Windows CE-Basis).

[Phoenix]

Zitat:

Zitat von TigerLilly (Beitrag 1503314)

Gibt es hier noch jemanden, dem eine Modernisierung einer Legacy-App ins Haus steht?
Ich würde mich gern zu den Themen austauschen, vielleicht können wir einander da ja unterstützen + von unterschiedlichen Blickwinkeln profitieren?
Hat jemand Interesse?

Also nicht, das es bei uns ins Haus stehen würde, aber wir begleiten seit etlichen Jahren viele Kunden in der DACH-Region bei der Modernisierung von Altlasten und auch bei der Neu-Entwicklung von Software im Bereich "Modern Business Applications".

In den allermeisten Fällen geht das in die Richtung von Ver-Service-fizierung von Businesslogik und Datenzugriff, so daß ein weiterer On-Premise Betrieb möglich ist, sich das ganze Gebilde aber in aller Regel deutlich besser in Richtung Cloud bewegt sowie von Plattformübergreifenden und teilweise auch Offlinefähigen Client-Anwendungen.

Die Ver-Service-fizierung ist dabei allerdings in aller Regel der Knackpunkt, denn sobald die Kunden sinnvolle APIs anbieten können, tun sich auf einmal neue Welten an Integrationsszenarien und damit auch neuen Geschäftsmöglichkeiten auf.

Allerdings ist bei uns der Technologiestack ein anderer als Delphi.

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

[Bernhard Geyer]

Zitat:

Zitat von Maliko (Beitrag 1503380)

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:

Zitat von Maliko (Beitrag 1503380)

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:

Zitat von Maliko (Beitrag 1503380)

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

[Phoenix]

Zitat:

Zitat von TigerLilly (Beitrag 1503393)

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

[Maliko]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1503397)

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.

Wem sagst du dass? Leider sind der großteil der Meldungen vom Datenbanksystem (genauer gesagt den Transactions). Die komplette Datenbankanbindung läuft über ein System des ursprünglichen Entwicklers (wir haben das System damals übernommen) und ein umbau bei diesem betrifft ca 600 Units. Daher ignorieren wir diese momentan und sind stattdessen derzeit dabei eine komplett neue Datenbankanbindung via Aurelius zu schreiben und die Units nach und nach umzustellen. Das dauert halt leider, vor allem da wir ja auch noch neue Features entwickeln müssen.

[TigerLilly]

Zitat:

Zitat von Phoenix (Beitrag 1503403)

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?

[Bernhard Geyer]

Zitat:

Zitat von Maliko (Beitrag 1503405)

Wem sagst du dass? Leider sind der großteil der Meldungen vom Datenbanksystem (genauer gesagt den Transactions). Die komplette Datenbankanbindung läuft über ein System des ursprünglichen Entwicklers (wir haben das System damals übernommen) und ein umbau bei diesem betrifft ca 600 Units. Daher ignorieren wir diese momentan und sind stattdessen derzeit dabei eine komplett neue Datenbankanbindung via Aurelius zu schreiben und die Units nach und nach umzustellen. Das dauert halt leider, vor allem da wir ja auch noch neue Features entwickeln müssen.

OK. Also nicht ignoriert sondern es wird schon was gemacht.

[Phoenix]

Zitat:

Zitat von TigerLilly (Beitrag 1503406)

Zitat:

Zitat von Phoenix (Beitrag 1503403)

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:

Zitat von TigerLilly (Beitrag 1503457)

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. :cheer: Das geht nicht unter. :zwinker:

[ConstantGardener]

Ja das ist eine schwere Entscheidung mit den JavaScript/CSS Frameworks. Wir haben mittlerweile 3 WebApps mit verschiedenen Bootstrap Varianten am Start, der Rest ist halt Javascript/Typescript. Aber schon das ist nervig.

Ich fand die Aussage von Herrn Suer (deutscher Entwickler/SymCom glaube ich) beim TMS WebCore Seminar vorgestern bei TMS interessant: Sie setzen WebCore (also Pascal --> Javascript Transpiler mit entsprechender Pascal RTL) ein um nicht bei einem falschen Javascript Framework zu landen. Werde da jetzt auch mal intensiver reinschauen, lizensiert haben wir es schon länger aber nur kleinere Sachen probiert.

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1503459)

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.

[sh17]

Busfaktor :lol: :lol: den muss ich mir merken

[Phoenix]

Zitat:

Zitat von sh17 (Beitrag 1503486)

Busfaktor :lol: :lol: den muss ich mir merken

Kennst Du nicht? Ist ziemlich geläufig: https://en.wikipedia.org/wiki/Bus_factor

[DeddyH]

Zum Thema "Delphi geht nicht unter" möchte ich mal Kylix, Delphi.NET und Delphi4PHP in den Raum werfen. Und zumindest meiner Meinung nach ist FMX auch nicht gerade der große Wurf.

[Maliko]

Delphi4PHP? WTF? Das klingt ja schon nach Frankensteins Monster. Ist es allen erstes das was ich denke? Ist das allen ernstes Delphi welches von PHP Interpretiert werden kann? Davon höre ich grad das erste mal. Das konnte doch nur in die Hose gehen.

[TigerLilly]

Strange. Ich frage nach Kolleg*innen, die Legacy-Apps modernisieren wollen + wir landen bei Frameworks aus anderen Welten. Hmm. Da haben doch einige mal die Entscheidung getroffen, weg von Delphi zu gehen. Würde ich zum jetzigen Zeitpunkt nicht machen - mit TMS Web Core - wurde ja schon genannt - gibt es ein echt spannendes Tool auch für Web Anwendungen.

[freimatz]

Zitat:

Zitat von Maliko (Beitrag 1503492)

Delphi4PHP? WTF? Das klingt ja schon nach Frankensteins Monster. Ist es allen erstes das was ich denke? Ist das allen ernstes Delphi welches von PHP Interpretiert werden kann? Davon höre ich grad das erste mal. Das konnte doch nur in die Hose gehen.

Nein es ist m.E. nicht das was Du denkst. Da gab es diese Woche ein Webinar von Mathias Eissing, sollte auch bei Youtube zu finden sein.

[freimatz]

Zitat:

Zitat von TigerLilly (Beitrag 1503494)

Strange. Ich frage nach Kolleg*innen, die Legacy-Apps modernisieren wollen + wir landen bei Frameworks aus anderen Welten. Hmm. Da haben doch einige mal die Entscheidung getroffen, weg von Delphi zu gehen. Würde ich zum jetzigen Zeitpunkt nicht machen - mit TMS Web Core - wurde ja schon genannt - gibt es ein echt spannendes Tool auch für Web Anwendungen.

Ja nun, das hängt weitgehend davon ab, was man unter "modernisieren" versteht. Wenn man nur eine alte Delphi-Anwendung modernisieren will so dass sie wie eine neuen Delphi-Anwendung aussieht, dann kann man auch ein neues Delphi nehmen. Und "Multi Platform" sowie "Teilbereiche Mobile" bekommt man mit Delphi auch noch hin.

Hierfür scheint mir der Zustand der alten App wichtig. Noch wichtiger ist für mich die Frage: sind die Anforderung klar? Wenn die nicht eindeutig sind und es nur heißt "soll funktionieren wie bisher", dann kann man die Neuentwicklung gleich aufgeben.

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1503512)

Noch wichtiger ist für mich die Frage: sind die Anforderung klar? Wenn die nicht eindeutig sind und es nur heißt "soll funktionieren wie bisher", dann kann man die Neuentwicklung gleich aufgeben.

Das ist auch meine Erfahrung. Die einzig vollständige Spezifikation steckt im vorhandenen Sourcecode (das gilt allerdings auch für die Liste der Bugs). Solange es also keine externe Spezifikation gibt, die eine ähnlich breite Abdeckung hat, kann eine Neuentwicklung nur dann erfolgreich sein, wenn das jemand macht der den alten Code versteht. In dem Fall wäre aber eine Weiterentwicklung in Delphi mit adäquater Modernisierung die deutlich billigere Lösung. Ich kann das aus diversen Kundenprojekten nur unterstreichen. Andererseits würden diejenigen, bei denen es auch so geklappt hat vermutlich auch nicht bei mir anklingeln :)

[MEissing]

Zitat:

Zitat von DeddyH (Beitrag 1503490)

Zum Thema "Delphi geht nicht unter" möchte ich mal Kylix, Delphi.NET und Delphi4PHP in den Raum werfen. Und zumindest meiner Meinung nach ist FMX auch nicht gerade der große Wurf.

Silverlight
Windows Forms
Skype for Business
Windows Phone
Windows 10 IoT Core
Microsoft Edge (original)
Kinect
Codeplex
XNA
Visual Basic
SourceSafe
MS Java VM
Bob
....

[Stevie]

@MEissing Tja, wenn man nicht jahrelang braucht, um ausm Quark zu kommen, dann kann man auch schneller Frameworks und Produkte bauen und wieder deprecaten :stupid:

[DeddyH]

[OT] Und mit whataboutism kommt man ja überall durch :stupid: [/OT]

[MEissing]

Hier ging's doch um React, Vue, Blazer... "Moderne" Frameworks und deren Langlebigkeit (oder auch nicht). Und du kommst mit Kylix, Delphi.Net und Delphi4PHP (ist "OK" als Einwurf) und schwadronierst dann von Whataboutism...

Lächerlich. Sorry.

[venice2]

Zitat:

Lächerlich. Sorry.

Habt ihr eigentlich keine anderen Sorgen?
Schaut euch in der Welt mal um und macht euch hier nicht gegenseitig runter.
Von Erwachsenen intelligenten Menschen sollte man eigentlich etwas anderes erwarten.

[arnold mueller]

Zitat:

Zitat von TigerLilly (Beitrag 1503494)

Strange. Ich frage nach Kolleg*innen, die Legacy-Apps modernisieren wollen + wir landen bei Frameworks aus anderen Welten. Hmm. Da haben doch einige mal die Entscheidung getroffen, weg von Delphi zu gehen. Würde ich zum jetzigen Zeitpunkt nicht machen - mit TMS Web Core - wurde ja schon genannt - gibt es ein echt spannendes Tool auch für Web Anwendungen.

Was erwartest du? Delphi war und ist super für die (Windows) GUI Entwicklung. Alles was jetzt so nach und nach gekommen ist funktioniert mit jeder Version auch immer besser, der Rest der Welt bleibt aber nicht stehen. Embarcadero läuft den Trends hinterher.

Ich würde heute für eine grundlegende Modernisierung nicht mehr Delphi verwenden. An die modernen Sprachen und Technologien sollte man sich ruhig mal rantrauen. Swift, Kotlin und go sind kein Hexenwerk.

[Bernhard Geyer]

Zitat:

Zitat von arnold mueller (Beitrag 1503635)

Was erwartest du? Delphi war und ist super für die (Windows) GUI Entwicklung. Alles was jetzt so nach und nach gekommen ist funktioniert mit jeder Version auch immer besser, der Rest der Welt bleibt aber nicht stehen. Embarcadero läuft den Trends hinterher.

Ab und zu war es mal gut "hinten dran" gewesen zu sein.
Wie oft man die Kollegen aus dem MS VS-Umfeld gesehen hatte das sie in dem einen Jahr auf DIE Zukunftstechnologie umgestiegen sind und 1-2 Versionen von VS war das schon wieder out und man sollte auf die nächste Technik umsteigen. Paradebeispiel sind hier die DB-Zugriffstechniken wie (zwischenzeitlich) schneller Wechselten als die Modetrends.

Zitat:

Zitat von arnold mueller (Beitrag 1503635)

Ich würde heute für eine grundlegende Modernisierung nicht mehr Delphi verwenden. An die modernen Sprachen und Technologien sollte man sich ruhig mal rantrauen. Swift, Kotlin und go sind kein Hexenwerk.

Für ein Neustart "auf der Grünen Wiese" muss sich Delphi mit den ganzen neuen Ansätzen vergleichen die ohne 20 Jahre "altlast" daher kommen.
Und im Umfeld der Javascript-Frameworks sind schon einige sehr schöne Techniken dabei, gegen die ein Delphi-Anwendung nicht ankommt wenn es heißt "Lauf im Browser, Smartphone, ...)
"Lauf unter Windows" wird hier teilweise gar nicht mehr benötigt, da diese Geräteklasse über "Browser" abgedeckt wird.

[arnold mueller]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1503636)

Für ein Neustart "auf der Grünen Wiese" muss sich Delphi mit den ganzen neuen Ansätzen vergleichen die ohne 20 Jahre "altlast" daher kommen.

Es muss nicht immer der Neustart auf der grünen Wiese sein. Die Umstellung einer klassischen Client-Server Anwendung auf eine Microservice Architektur kann man mit wenig Risiko nach und nach durchführen. Ich würde REST Api's aber nie mehr mit Delphi bauen seitdem ich weiß um wie viel einfacher das mit go geht.

Meiner Meinung nach ist Delphi unschlagbar im Bereich Windows GUI. Der Bereich Mobile und Backends ist grundsätzlich möglich, andere Technologien sind aber sinnvoller.

[venice2]

Zitat:

Meiner Meinung nach ist Delphi unschlagbar im Bereich Windows GUI.

Och! Zeig mir wo und in welchen Zusammenhang.
Ich behaupte das meine GUI's die von Delphi bei weitem Übertrumpfen ohne VCL soweit es geht
ohne Hunderte von Komponenten auf der Form und reine Win32API.
Soviel dazu.

Zudem unabhängig von irgendwelchen Styles. Einfach ein paar png's deren Ästhetik abhängig vom jeweiligen Designer sind.
Müssen nicht allen gefallen daher hat man die Möglichkeit diese als Skins darzustellen. Für jeden etwas also.
Mitunter reicht ein einfaches ändern des Hintergrund schon aus wie du am Beispiel sehen kannst.

Edit:
Zudem hat es immer schon Styles in irgendeiner Form gegeben (nichts anderes als Skins) die zuerst mit Winamp sowie ich weiß eingeführt wurden.
Auch gab es nachher einige Anwender Komponenten bsp. "DynamicSkinForm" für Delphi wo man die form entsprechend Design konnte.
Das hat aber nichts mit Delphi Ansicht zu tun!
Delphi hat keine besseren Gui's als andere Programmiersprachen nur weil man die Möglichkeit hat Styles(Skins) zu verwenden.
Das kann ich wie du siehst ohne Verwendung der vcl.Forms + Hunderte von Komponenten + Styles

[arnold mueller]

Zitat:

Zitat von venice2 (Beitrag 1503642)

Zitat:

Meiner Meinung nach ist Delphi unschlagbar im Bereich Windows GUI.

Och! Zeig mir wo und in welchen Zusammenhang.
Ich behaupte das meine GUI's die von Delphi bei weitem Übertrumpfen ohne VCL soweit es geht
ohne Hunderte von Komponenten auf der Form und reine Win32API.
Soviel dazu.

Ich hatte damit nicht gemeint, dass Delphi GUIs im Vergleich zu anderen Tools besonders toll aussehen. Sie sehen halt so aus, wie man es auf der Windows Plattform üblicherweise erwartet. Mein Punkt war, dass mit Delphi diese Art von Anwenungen besonders gut gebaut werden können - im Sinne von einfach und schnell und deshalb unschlagbar.

[venice2]

Zitat:

Mein Punkt war, dass mit Delphi diese Art von Anwenungen besonders gut gebaut werden können - im Sinne von einfach und schnell und deshalb unschlagbar

Dann hast du nicht gelesen oder es noch nicht versucht mit mehreren Monitoren und High Dpi zu arbeiten.
So wie ich hier lese ist das alles nicht sehr ausgereift. Komponente verschieben sich wie von Geisterhand auf dem Formular und.. und.. und
Kann nur besser werden die Frage die da wäre? Wann.

Irgendwie widerspricht sich deine Aussage mit der Realität!

Zitat:

im Vergleich zu anderen Tools besonders toll aussehen

Es geht hier nicht um Tools sondern um die Form (Fenster) an sich. Bei mir verschieben sich keine Komponente (gibt halt keine)

[sh17]

Zitat:

Zitat von venice2 (Beitrag 1503667)

Es geht hier nicht um Tools sondern um die Form (Fenster) an sich. Bei mir verschieben sich keine Komponente (gibt halt keine)

Das mag mit einer Anwendung mit wenigen Fenstern ganz witzig sein, aber nicht für eine "normale" Businessanwendung