Progressive Web App (PWA) oder doch klassische Software-Entwicklung?

Nein, natürlich nicht. Die Anforderung des Themenerstellers war eine plattformunabhängige Anwendung.

Ich habe das letzte mal mit Delphi 6 gearbeitet. Eine Windows Anwendung. deshalb ist mir aktuell nicht klar wie das Ganze konkret aussehen soll. Sprich Oberfläche z.b. Für alle Plattformen (Desktop/Mobile/Web)
 
Ich habe das letzte mal mit Delphi 6 gearbeitet.

Tja.

Delphi hat inzwischen seit ein paar Jahren neben der Windowsbibliothek „VCL“ ein plattformunabhängiges Framework namens „FireMonkey“ (FMX) an Bord. Damit kann man ein paar schöne Dinge basteln - zum Beispiel mobile Anwendungen. Sogar mit der kostenlosen „Community“-Version.

https://www.embarcadero.com/products/delphi

Öfter mal ein Update machen! ;)
 
Ja, das sieht schon nice aus.
Ich habe definitiv zu wenig Zeit :D
 
Wir arbeiten schon sehr lange mit Vaadin. Ist ein Java-Framework und für uns bei PWAs das Mittel der Wahl.
 
Ich verstehe diese Verbortheit gegenüber PWAs nicht. Sicherlich sind diese nicht nativ, aber das erinnert mich immer an dogmatisch getriebene Diskussionen, die sich nur um die Technische Umsetzung selber drehen, die Fachlichkeit und den benötigten Aufwand für mehrere Plattformen nativ zu programmieren aber einfach ignorieren.

Für den Einstieg und eine schnelle Time-To-Market (um zu erfahren, ob die User überhaupt bereit sind für die Idee Geld auszugeben) ist eine PWA auf Basis eines X beliebigen Web-Mobile-UI Framework optimal. Dazu dann noch ein App-Wrapper wenn man erste native Funktionen braucht und hinterher kann man immer noch die Diskussion Aufwand<->Wartung<->Mehrwert von PWAs ggüb. nativer Entwicklungen führen. Meine Empfehlung ist es immer, einfach zu starten, die Tools nutzen die man kennt, die Tools zu nutzen wo es eine große Community für Q&As gibt, sich schnell Nutzer-Feedback einzuholen und danach erst zu überlegen, wie und ob man technisch migrieren möchte.

Grad im B2B-Bereich kenne ich duzende von aktuell neu entstehenden Applikationen, die alle den Browser als reine Deployment-Shelf nutzen. Eine der beliebtesten "Lightweight-IDEs" wie Visual Studio Code ist nichts anderes als ne WebApp im Electron Bundle verpackt und dann gibt es auch noch WebAssembly, wenn man bei den nativ gängigen Programmiersprachen bleiben möchte.
 
  • Gefällt mir
Reaktionen: VALBITZ57 und WirbelFCM
den benötigten Aufwand für mehrere Plattformen nativ zu programmieren

Welcher wäre das in Delphi so ungefähr?

Eine der beliebtesten "Lightweight-IDEs" wie Visual Studio Code ist nichts anderes als ne WebApp im Electron Bundle verpackt

Was sicherheitstechnisch ein Albtraum ist und auch von der Performance her ein schlechter Witz, gerade, wenn man da „Lightweight“ dranschreiben will. Auf so was zu verzichten fällt mir echt leicht.
Manche nennen es verbohrt, ich nenne es qualitätsbewusst.
 
Welcher wäre das in Delphi so ungefähr?

Die Lernkurve sich in Delphi / FireMonkey und dem Framework-Umfeld, gegenüber den jahrelang anhaltenden Marktbestrebungen, einzuarbeiten. Weiterhin der Aufwand sich bei spezifischen Fragen und auftauchenden Problemen Antworten abseits der recht speziellen Nische zu finden. Das heißt nicht, dass die Lösung schlecht sein mag, aber auf JavaScript aufsetzende UI-Frameworks sind nunmal der Marktdurchdringende Standard für die aktuelle Web Entwicklung - gleichwohl man diesen nicht mögen muss. Diese Nische mag durchaus ihre Berechtigung haben, einem Anfänger aber hierzu zu raten halte ich für sehr gewagt.

Als Beispiel seien ~3000 StackOverflow-Fragen für FireMonkey in Bezug zu jeweils ca. 220k Fragen für React und Angular oder auch 2 Millionen JavaScript Fragen zu nennen.
Hinzu kommt noch die normale restliche Informationslandschaft rund um die Standard Web-Technologien.

Was sicherheitstechnisch ein Albtraum ist und auch von der Performance her ein schlechter Witz, gerade, wenn man da „Lightweight“ dranschreiben will. Auf so was zu verzichten fällt mir echt leicht.
Manche nennen es verbohrt, ich nenne es qualitätsbewusst.

Das kann man alles verteufeln, aber trotzdem ist und bleibt es der effizienteste Weg wenn man im Zielkonflikt "Time-To-Market"<->"Informations- und Personalangebot"<->"Technische Umsetzung" bestehen möchte. Ich möchte aber nochmal erwähnen, dass dies nicht heißt, dass die Delphi-Lösung keine Berechtigung hat. Sie bleibt aber eine Nische, deren Wahl wohl überlegt sein sollte. Nicht ohne Grund wird von den großen Playern am Markt, wie Google oder Facebook, Unsummen an Geld in die Weiterentwicklung des eigentlichen Web-Umfelds gesteckt. Electron soll nur als Beispiel verstanden werden - gemeint ist der Trend zu immer weniger Desktop-Entwicklung und hin zu immer mehr Web-Entwicklung + PWAs oder alternativ / da wo es sinnvoll und ressourcentechnisch möglich ist, native App-Implementierung zu präferieren. Auch hier sieht man z. B. bei Apple die Bestrebungen, die App-Entwicklung zu stärken und die Migration von iPad Apps auf den Mac immer einfacher zu gestalten.
 
  • Gefällt mir
Reaktionen: MoNchHiChii und wegus
Als Beispiel seien ~3000 StackOverflow-Fragen für FireMonkey in Bezug zu jeweils ca. 220k Fragen für React und Angular oder auch 2 Millionen JavaScript Fragen zu nennen.

Dir ist klar, dass das eigentlich nur bedeutet, dass React und Angular wesentlich mehr Probleme bereiten, für die man eine Lösung braucht?
Nicht alles ist eine Website und das, was der hier Fragende vorhat, ist mit einer Website auch am zweitschlechtesten abgebildet. Delphi ist scheiße für Websites, aber es ist großartig für native Entwicklung.
 
Dir ist klar, dass das eigentlich nur bedeutet, dass React und Angular wesentlich mehr Probleme bereiten, für die man eine Lösung braucht?
Nicht alles ist eine Website und das, was der hier Fragende vorhat, ist mit einer Website auch am zweitschlechtesten abgebildet. Delphi ist scheiße für Websites, aber es ist großartig für native Entwicklung.

Nein, das bedeutet schlichtweg das sich mehr Leute mit diesen Themen beschäftigen und man als Programmierer für eine hohe Anzahl verschiedenster Frage und Umfeldkonstellationen eine Antwort finden kann. Auch hier ist StackOverflow einfach die Standard-Anlaufstelle für zahlreiche technologische Plattformen. Ein Blick auf verschiedenste Indexe, Buch und Seminarangebote, Stellenausschreibungen, Entwicklungen der Großen Player und co zeigen schon ein deutliches Bild, was in der Fläche eingesetzt wird und wo eine (aus guten Gründen existierende) Nische ist.

Die Frage die du stellst ist berechtigt. Die Herangehensweise an die Technologie sollte heutzutage aber im Ausschlussprinzip ausgehend von der Technologie erfolgen, welche die meisten Nutzer einfacher erreichen kann (Ausnahmen gibt es im B2B-Umfeld wenn technische und organisatorische Rahmenbedingungen hinzukommen). Hierbei erzeugen Webseiten und native Apps aus dem Store einfach die wenigsten Hemmnisse auf Nutzer-Seiten und sind der einfachste Distributionsweg.

Der TE hat es aber doch selber schon vermutet, dass seine Idee keinen großartigen nativen Zugriff benötigt. Webcam und Micro sind im Web überhaupt kein Problem (z. B. gut ersichtlich bei allen Telco-Lösungen wie Microsoft Teams, Slack, WebEx und co. Auch so etwas wie Screen-Sharing ist damit sehr einfach möglich).

Vielleicht kann er uns noch 1, 2 weitere Stichworte zur Funktionalität und den zu erreichenden Plattformen nennen. Bisher sehe ich aber keine Gründe, welche gegen eine Web-Lösung sprechen würde, die vieles einfacher macht.
 
Webcam und Micro sind im Web überhaupt kein Problem (z. B. gut ersichtlich bei allen Telco-Lösungen wie Microsoft Teams, Slack, WebEx und co.

Aus gutem Grund haben „alle Telko-Lösungen“ auch eine eigene Zugangssoftware... :)
Das Web wird niemals die Qualität und vor allem Kompatibilität der nativen Systemschnittstellen erreichen.

Bisher sehe ich aber keine Gründe, welche gegen eine Web-Lösung sprechen würde, die vieles einfacher macht.

Performance, Kompatibilität, Datenschutz.
 
Aus gutem Grund haben „alle Telko-Lösungen“ auch eine eigene Zugangssoftware... :)
Das Web wird niemals die Qualität und vor allem Kompatibilität der nativen Systemschnittstellen erreichen.

Wo wir wieder bei dem oben aufgeführten Zielkonflikt wären. Das Thema Web, PWA und zusätzlich WebAssembly (was eine native Ausführung erlaubt) wird zunehmend durch die großen Player gepusht. Wie gesagt, diese Entwicklung muss man nicht mögen und sie ist auch nicht überall sinnvoll - aber da wo es um Standardanwendungen geht ist allein der vereinfachte Distributionsweg einer PWA / Smartphone-App in einem absoluten Gegengewicht zu jeglichen Vorteilen einer Desktoplösung. Wobei wir vom TE zum Thema Desktoplösung vs Smartphone-App noch paar Worte brauchen (ich vermute aktuell, dass es ihm eher um eine breite Verbreitung geht, wo dann wiederum Smartphone-Apps die Alternative zur PWA wären - siehe auch Hinweis zu Phonegap im Ausgangspost. Hier würde meine Empfehlung in die Richtung gehen, entweder sich bewusst erstmal für eine Plattform zu entscheiden - iOS weniger Nutzer aber kauffreudiger oder aber eine [gewrappte] PWA mit dem UI-Framework seiner Wahl zu erstellen)

Performance, Kompatibilität, Datenschutz

Dies ist leider sehr generisch und ohne konkrete Punkte nur schwierig zu diskutieren, trotzdem ein Versuch.

Performance hängt von der Art der Anwendung ab. Bitcoin-Mining oder Spiele macht man lieber nativ (wobei berechnungshungrige Apps mit WebAssembly auch kein Problem mehr sind, 3D tut noch weh), bei 90% der Apps die der durchschnittliche Benutzter aber einsetzt ist dies absolut zu vernachlässigen (Facebook, YouTube, X beliebige Plattform-PWA oder im Geschäftsbereich als die bekannten Apps wie Teams, Slack und co).

Kompatibilität ist die Frage zu was? Ich würde behaupten eine Webseite / PWA ist zu einer höheren Anzahl an Endgeräten kompatibel, als jegliche andere Technologie, welche auf Endnutzer abziehlt. Kompatibilität zu Schnittstellen ist auch eine nähere Spezifikation wert. Die Standard audiovisuellen Schnittstellen eines normalen Benutzers wie Kamera, Mikro oder auch Screensharing und Dateiupload stehen alle im Web zur Verfügung.

Datenschutz ist eine Grundsatzdiskussion, welche selbst für Sicherheitskritische Bereiche wie Online-Banking im Web erfolgreich gelöst werden konnte.
 
ich vermute aktuell, dass es ihm eher um eine breite Verbreitung geht, wo dann wiederum Smartphone-Apps die Alternative zur PWA wären

Womit Delphi, bei dem das Portieren auf eine weitere Plattform ohne jeden Codeaufwand vonstatten geht, weiterhin im Rennen bliebe.
Aber ja, etwas Rückmeldung von @kenduo wäre willkommen.

bei 90% der Apps die der durchschnittliche Benutzter aber einsetzt ist dies absolut zu vernachlässigen (Facebook, YouTube, X beliebige Plattform-PWA oder im Geschäftsbereich als die bekannten Apps wie Teams, Slack und co).

Gerade interaktionslastige Anwendungen wie „Teams, Slack und Co.“ verschenken viel Potenzial dadurch, dass sie unbedingt Webtechniken nutzen wollen. Man stelle sich vor, Slack würde stattdessen - wie zum Beispiel mIRC - vorrangig per System-API kommunizieren: Wie performant das sein könnte! (Der Vergleich ist bewusst gewählt. Ich nenne Slack gerne „IRC mit Bildchen“, viel mehr ist es ja auch nicht; da ist die Rechtfertigung für das Geschwindigkeitsgefälle meiner Meinung nach einfach nicht gegeben.)

Ich würde behaupten eine Webseite / PWA ist zu einer höheren Anzahl an Endgeräten kompatibel, als jegliche andere Technologie

Klar, wenn sich alle Browser auf sämtlichen Systemen endlich mal auf dieselben Standards einigen könnten, alle Menschen nur noch den neuesten Webfasel auf den neuesten Systemen auf dem neuesten Mainstreamcomputer statt z.B. NetSurf unter RISC OS nutzten (das wird übrigens schon daran scheitern, dass es keine Upgradepflicht gibt) und Dinge wie NoScript und uBlock nicht existierten...
Letztere sind übrigens aus gutem Grund weit verbreitet. Das Web ist Feindesland, also das Land der Werber und sonstigen Kleinkriminellen. Da ist Vorsicht geboten, wenn es darum geht, wer aus der Ferne Code auf dem eigenen Rechner ausführen darf und wer nicht.

Eine Menge Fallstricke und Unsicherheiten, die eine native Anwendung allesamt umgeht.

Datenschutz ist eine Grundsatzdiskussion, welche selbst für Sicherheitskritische Bereiche wie Online-Banking im Web erfolgreich gelöst werden konnte.

Im Sinne von: Es passiert nur noch ganz selten was. Nur ist das „Offline-Banking“ da halt immer noch statistisch voraus. Du verstehst, worauf ich hinaus will?
„Fast sicher“ ist wie „ein bisschen schwanger“.
 
  • Gefällt mir
Reaktionen: kenduo
Multi Plattform Apps sind tatsächlich ein Problem. Java als GUI ist meist furchtbar. Dart/Flutter ist für Android/IOS gut, aber eben nicht für den Desktop.

MS mit seinem Net Core kommt dem am nächsten. Aber Net Core 3 erfüllt es noch nicht und Net Core 5 wird erst im Herbst fertig. Bis jetzt hat MS lediglich für LINUX noch keine GUI. Aber eine Quelle und läuft unter Android/IOS,macOS und Windows soll mit Net Core 5 gehen.

Der Delphi Ansatz ist interessant, kenne das Tool nur aus den 1990ern. Ich mag aber Pascal nicht und würde dad RAD Studio von Embarcado vorziehen.

Man mag zu „neueren“ Entwicklungen stehen wie man will, aber Dart/Flutter ist eine Lösung, sowie PWA in Typescript oder Javascript auch.

Ich selbst habe mir NetCore 5 ins Lernheft geschrieben. Mir fehlt aber die Zeit bisher.


Ich sehe gerade: von den Embarcado Tools (Delphi/Builder/Rad Studio) braucht man die Enterprise Version für 3500€, wenn man eine DB wie MySQL oder Postgres nutzen will :crack:

Die einfache Version bleibt also eine reine WebAnwendung oder eben NetCore 5. Wenn IOS/Android das Ziel sind, dann Dart/Flutter.
 
  • Gefällt mir
Reaktionen: warnochfrei
PWA für kleinkram der nur sporadisch und kurz genutzt wird.
Nativ für alles was man länger und häufiger nutzen muss, und für alles wo es zu abbrüchen während der nutzung kommen kann.


NICHTS ist Ärgerlicher als wenn man einen text geschrieben hat und dann beim klick auf Senden ein Fehlermeldung vom Browser kommt, dass man einen verbindungsfehler hat oder einen Timeout.
 
  • Gefällt mir
Reaktionen: kenduo und warnochfrei
Verstanden :)

Was ich noch überlegt habe. Ich kann Wordpress als Grundlagen nehmen, die DB um meine "Sache" erweitern (das bekomme ich hin :D) und das über statische Seiten in Wordpress einbauen.
Kann man das einfach umsetzen? Akzeptiert WP solche "Fremdkörper"?

Das natürlich nur als erster Schritt, Um zu sehen, wie das ganze läuft, bevor es ernst wird.

Wenn du wordpress als Grundlage nutzt, kannst du dir das auch sparen. Wp ist ein fruchtbares, hochinefdizientes datensammel-Wirrwarr, das den ganzen sinn einer spwa ad absurdum führt. Ich kann dir gerne mal die email oder telnr. Von meinem Spezi zukommen lassen, damit du mal aus erster Hand etwas Input bekommst. Aber danach werden dir die Ohren bluten :D
 
Wenn IOS/Android das Ziel sind, dann Dart/Flutter.

Wir verwenden die Kombination Typescript, Ionic(Angular) und Capacitor.

Funktioniert einwandfrei.

Flutter ist halt sehr Google-lastig und die ganze Entwicklung ist sehr "Android"-like (Layout bspw. - ich arbeite da lieber mit HTML/SCSS, als mich mit Layout-Constraints rumzuschlagen).
Und auch die Entwicklung "native"-Erweiterungen ist in Flutter meiner Erfahrung nach eher spröde. Das ist bei Capacitor mittlerweile recht geschmeidig gelöst.
 
  • Gefällt mir
Reaktionen: wegus
PWA für kleinkram der nur sporadisch und kurz genutzt wird.
Nativ für alles was man länger und häufiger nutzen muss, und für alles wo es zu abbrüchen während der nutzung kommen kann.

Ich würde sagen: hauptsächlich kommt es auf die Kompetenz der Entwickler an.
Wenn Du ein Team hast, das nur aus exzellenten Web-Entwicklern besteht, die aber noch keine Zeile Kotlin programmiert haben, dann kommt man mit anderen Tools evtl. besser zum Ziel.

NICHTS ist Ärgerlicher als wenn man einen text geschrieben hat und dann beim klick auf Senden ein Fehlermeldung vom Browser kommt, dass man einen verbindungsfehler hat oder einen Timeout.

Das Verhalten hängt auch nur von der Kompetenz der Entwickler ab. Offline-Webanwendungen funktionieren seit Jahren. Webworker & Co. sind deine Freunde.
Gerüchteweise gibt es komplette Office-Anwendungen als PWAs.
 
  • Gefällt mir
Reaktionen: warnochfrei
Was sicherheitstechnisch ein Albtraum ist und auch von der Performance her ein schlechter Witz, gerade, wenn man da „Lightweight“ dranschreiben will. Auf so was zu verzichten fällt mir echt leicht.
Manche nennen es verbohrt, ich nenne es qualitätsbewusst.


wenn ich natürlich eine besch...eide entwicklerumgebung nutze, um eine (web)app zu entwickeln, wird auch das ergebnis bescheiden sein.
das hat aber absolut NICHTS mit der qualität von spwa's an sich zu tun.

aber ich habe auch leicht reden, ich habe echte spwa's schon in aktion gesehen und konnte mich von der qualität überzeugen und weiß daher, daß die nativen apps in nichts nachstehen, aber eben zusätzlich einige vorteile bieten, die native apps nicht bieten.

hier habe ich mal noch ein "fragment" so einer halbfertigen spwa gefunden, da findet man ein paar rudimentäre infos zur technik und auch einen beispielshop der v.a. durch seine (quasi) echtzeit-performance auffällt.

der clou ist allerdings, wenn man das fenster danach schließt, die internetverbindung trennt und die seite nochmal aufruft. die funktioneirt noch genau so wie vorher (caching sei dank) :cool:
 
Zurück
Oben Unten