Firemonkey vs VCL

[Headbucket]

Hallo,

seit der Threaderstellung sind nun fast 2 Jahre vergangen. Mich würde mal interessieren, ob und wie sich eure Meinung inzwischen zu FireMonkey verändert hat.

Wir stehen im Moment auch vor der Entscheidung "VCL vs FireMonkey" für ein Projekt, welches viele Jahre im Einsatz sein soll.
Multiplatform ist eigentlich kein Thema für uns.
Gibt es inzwischen trotzdem Gründe, weshalb man lieber FireMonkey anstatt VCL wählen sollte?

Bietet die VCL heute noch immer Vorteile? Läuft FireMonkey inzwischen stabiler und man stößt nicht ständig an irgendwelche Grenzen?
Wir haben etwas Angst, dass die VCL nicht mehr groß weiterentwickelt wird. Bereits in den letzten Updates gab es nur noch wenige Neuerungen für die VCL. Vllt ist sie aber auch einfach ausgereift?

Grüße
Headbucket

[jaenicke]

Wir haben VCL und Firemonkey austauschbar als Oberfläche. Beide haben Vorteile, die Firemonkey GUI hat schöne Effekte, die VCL Oberfläche ist eher im Windows 10 Stil schlicht und elegant. Von der Funktionalität her unterscheiden sich die Oberflächen bei uns nicht.

Für Firemonkey bekommst du weniger kostenlose Komponenten, wenn das eine Rolle spielt. Wenn du zum Beispiel eine erweiterte Baum- oder Listenkomponente benötigst, musst du sie für Firemonkey vermutlich kaufen während es für die VCL z.B. die VirtualTrees kostenlos gibt.

Probleme hatte ich ansonsten mit Firemonkey mittlerweile keine mehr.

[Mavarik]

Für ein neues Projekt solltest Du nicht Fragen "Firemonkey oder VCL", sondern eher Programm von GUI trennen so das der unterschied lediglich ein Paar "dumme" Formulare sind.

Da Frage muss also lauten: "Klick mich zusammen RAD oder MVVM"!

Mit Delphi 10 läuft es übrigens alles sehr stabil.

[stahli]

@jaenicke+Mavarik

Die Trennung GUI + BL ist immer sinnvoll.
Die Frage ist dann nur, wie man die Kommunikation der Ebenen löst.

Die LiveBindings lösen (falls sie zwischenzeitlich stabil laufen sollten) ja auch nur einen Teilbereich.
Mavarik, kann man inzwischen mal etwas von Deinem MVVM-Framework sehen? (Mich persönlich würde lediglich ein Video interessieren, weil ich mir FMX nicht mehr arbeite.)


@Headbucket
Wie stabil und performant FMX inzwischen läuft kann ich nicht beurteilen.
Wenn Du aber noch XE8 nutzt würde ich keine Experimente eingehen.
Wenn FMX dann nur mit aktiver Subscription.

[Mavarik]

Zitat von stahli:

Mavarik, kann man inzwischen mal etwas von Deinem MVVM-Framework sehen? (Mich persönlich würde lediglich ein Video interessieren, weil ich mir FMX nicht mehr arbeite.)

Sowie ich/wir das FDK fertig haben, kommt das alles... Tutorials & Videos stehen jedoch auf letzter Position meiner #Todo-Liste.

Zitat von stahli:

Wenn Du aber noch XE8 nutzt würde ich keine Experimente eingehen.
Wenn FMX dann nur mit aktiver Subscription.

+1

[Bambini]

Zitat von Headbucket:

Multiplatform ist eigentlich kein Thema für uns.
Gibt es inzwischen trotzdem Gründe, weshalb man lieber FireMonkey anstatt VCL wählen sollte?

Wenn es nur für Windows und Multiplatform kein Thema ist, dann ist VCL immer noch die beste Wahl.

[jaenicke]

Zitat von Bambini:

Wenn es nur für Windows und Multiplatform kein Thema ist, dann ist VCL immer noch die beste Wahl.

So allgemein kann man das nicht sagen. Hast du schon einmal mit der VCL versucht Alpha-Transparenzen oder gedrehte Texte und Controls usw. umzusetzen? Ich schon, habe am Ende alles selbst gezeichnet, da ist Firemonkey der deutlich bessere Weg...

[Rollo62]

Ich sehe es mal ganz pragmatisch:

GESTERN:
VCL ==> Windows als ==> alles wunderbar, kann ich mit etwas Glück noch 2-3 Jahre weiterbetreiben
C/S ==> TDataset

HEUTE :
FMX statt VCL ==> Windows alt /OSX/iOS/Android, wenn man es braucht (so wie ich)
C/S, Cloud ==> TDataset, Livebindings sind möglich

MORGEN :
FMX ==> Windows neu + CrossPlatform ==> Crossplatform wird sich mehr angleichen, Win neu wird man bald nicht mehr wiedererkennen
C/S, Cloud, Linux Server, interne Berechnungen ==> LiveBindings


Windows Universal App wird sicher einiges von Android/iOS übernehmen, Desktop wird weniger Wichtig.
Auch Windows Motto ist Cloud first, Mobile first ...


Ich würde jedem empfehlen sich schon heute mit FMX zu beschäftigen, läuft unter Rx10 Subscription bereits ziemlich stabil wenn man nicht
alle Exotenkomponenten anpacken muss.
Fmx ist der beste Weg für Delphianer ins neue Jahrtausend.

Jedenfalls finde ich das Konzept von FMX und sogar von LiveBindings genau richtig, auch wenn es heute noch hakelt und Emba hier
und da mal was ausprobiert.
Emba hat sich die richtigen Konzepte abgeschaut und ist meiner Meinug nach auf einem guten Weg.
Aber wer sich zu spät damit befasst dem wird u.U. der Zug wegfahren.

Das Framework ist jetzt schon sehr mächtig, und immer mehr Code wandert ins System.xxx wo es von Fmx und Vcl genutzt werden kann,
so das ich viele hingewurstelte ZusatzKomponenten wie Jedi konsequent rauswerfe und lieber ein aufgeräumtes Fmx benutze.
Immer mehr BasicCode wird da mit den richtigen Patterns umgesetzt (ExpressionParser, Tasks, Parallel, SystemInfo, PlatformServices, etc. etc.),
so dass man eigentlich kaum noch 3rd Party für den täglichen Bedarf braucht.
Da tut die Lernkurve nur einmal etwas weh, aber ich denke sehr bald in der Zukunft wird sich das wieder auszahlen:

Zitat:

Ein Code auf allen Plattformen

funktioniert wirklich, soweit ich das Bestätigen kann.
Ich fände es super wenn möglichst viele sich schon damit auseinander setzen würden statt zu resignieren,
umso schneller kann es noch besser wereden.

Denn mir ist eines völlig klar: VCL wird FMX langfristig nicht verdrängen, eher umgekehrt.
Und bald wird hier jeder nur noch mit Phones, Tablets und Smartwatches rumlaufen, da frage ich mich welche VCL App da laufen wird

Rollo

[warschonweg]

Was zu der Frage führt, wieso es noch kein Qt5 für Delphi gibt.

[Sherlock]

Zitat von warschonweg:

Was zu der Frage führt, wieso es noch kein Qt5 für Delphi gibt.

Weil Delphi auf halbwegs native Controls zugreifen kann, und nicht auf systemfremde Dinger angewiesen ist, die unbedarfte Anwender in die Irre führen. Weshalb ich auch weiterhin (für Windows) die VCL favorisiere.

Sherlock