Wenn man Delphi ohne native
GUI denkt, dann bleibt da kaum was über das man nicht mit anderen Frameworks wesentlich schneller erledigen könnte. [...]
Ich seh es genau umgekehrt wie du: Es ist (vielleicht zusammen mit Visual Studio) ein Alleinstellungsmerkmal von Delphi, native GUIs in kurzer Zeit erstellen zu können. Dort wo Delphi heut noch zum Einsatz kommt, dass sind i.d.R. Profi-Anwendungen mit extrem langfristiger Verfügbarkeit. Also
IMHO das krasse Gegenteil von dem was heutzutage bei Webfrontends gemacht wird. Ich würde also das Alleinstellungsmerkmal kultivieren anstatt absägen. Aber da red ich ja mit der Hand wenn ich seit Jahren trommle dass sie die
VCL X-Plattform machen und alle Compiler mit allen Editionen ausliefern sollen.
Ich sehe das tatsächlich ähnlich wie Du, hast in vielen Punkten Recht, deswegen muss ich meinen
VCL-Vorschlag erklären. Plattformunabhängiges
GUI ist sicher mindestens so aufwändig wie alle möglichen DBs zu unterstützen. Man käme aber in vielen Fällen schon sehr weit mit einem webbasierten
GUI, ohne weitere libs. Da geht mit HTML5 und CSS3 schon eine ganze Menge. Will/muss man das
GUI komplexer datengesteuert aufbauen/ zur Laufzeit verändern, kann man sowas wie d3.js (data driven documents, ein modulares Microframework) ins Spiel bringen. Ich hab d3 bewusst erwähnt in Abgrenzung zu den buzzword-frameworks, dann a) ist es standardkonform - Arbeit, die man dort investiert, ist nicht für Tonne und b) ist es von einer Codequalität, die man suchen gehen kann. Oder ich lasse mir die Seite oder Teile davon, weil alles textbasiert ist, direkt aus der Datenbank erzeugen, da hat Delphi ja auch allerhand zu bieten. Dann brauche ich nur Ahnung von
SQL und komme sehr weit. Auch bei
SQL hat sich einiges getan, window functions bspw sind ein mächtiges Konstrukt.
Angenommen, Du willst eine Fabriksteuerung schematisch visualisieren und darüber auf einem Screen überwachen und steuern, oder das Dashboard eines Reporting-Systems - mach das mal mit der
VCL. Aus Delphi-Sicht wäre dafür "nur" nötig, eine ordentliche Rendering engine zu integrieren, man würde sich vermutlich einig mit Mozilla. Und wenn Du dann eine Stelle asynchron haben willst, packst Du eine kleine selbergeschriebene js-
unit oder .pas-
unit dazu. Der Ansatz würde auch die Abhängigkeit von TeeChart relativieren.
Re Frameworks: Immer so wenig wie möglich, für Packages gilt das gleiche.
VCL X-Plattform machen: Ja klar, aber der jetzige Delphi-
GUI-Gemischtwarenladen - das kann sich ziehen. Das Problem ist nicht neu, ich weiß nicht, woran es hängt, ist aber irgendwann auch egal. Es gibt andererseits da draußen viele, die sich mit Web gut auskennen, denen kann man sagen, ihr könnt die Oberfläche einer Delphi-Anwendung umsetzen, wie ihr es kennt, und dann schauen wir uns die Datenanbindung und Steuerung an. Das könnte für Emba den Druck etwas rausnehmen, sie könnten sich in Ruhe um die
GUI-Integration kümmern, aber derweil kämen etliche neue und jüngere Leute, die ihr bisheriges Knowhow zu Delphi mitbringen können. Denn bspw App-Entwicklung ist/war lange sehr frickelig. Das könnte auch für Firmen mit großen Delphi-Anwendungen Entlastung und Perspektive bringen. Also mindestens längerfristige Perspektive, oder die Möglichkeit, einfach zu wechseln. Am besten beides, und zwar für Firmen und für den Nachwuchs.
Es geht auch darum, dass man mehr als eine Option hat, etwas umzusetzen, Hauptsache, die Basis dafür ist von guter Qualität. Delphi kann diese verschiedenen Welten zusammenbringen, und das Deployment zusammen mit dem direkten Draht zum Betriebssystem, der Webanwendungen normalerweise versperrt ist - das ist, wo Delphi wirklich wieder punkten könnte.