Browserbasierte Programme

[avalon74]

Hallo zusammen,

meine Kenntnisse über IT haben nie den Stand von PC-Eigenbau und der Installation von Windows und seinen Programmen überschritten. Deshalb frage ich mal hier in die Runde ...

Die Lagerverwaltungssoftware meines Arbeitgebers in der neuesten Version läuft jetzt im Browser. Vorher als eigenständige Anwendung (Enterprise Client Java). Begründung ist wohl die Sicherheit!?
Soll das die Zukunft sein im Browser zu arbeiten oder ist das eine Notlösung? Habe fast täglich Abstürze während der Arbeit, was vorher nicht der Fall war.

Danke für die "Erleuchtung"

 

[whats4]

das problem offiziell an die IT melden.
abstürze kosten geld, vermindern die produktivität, und selbst kannst null machen, mangels rechten und mangels befugnis.

und warenwirtschaftssysteme sind teuer, kommt der hersteller seinen pflichten ned nach, kann sowas ein fall für die juristen werden.

 

[Shark1705]

Aber unter Strich wird das die Zukunft wahrscheinlich werden. Nur noch cloudbasierte Lösungen, obwohl on-Premise früher viel besser lief. Ich kann es auch manchmal nachvollziehen, da man als Softwarehersteller dann nicht mehr sich auf zig verschiedene Konfigurationen einstellen muss. Du "mietest" die Cloudlösung von mir und gut ist.

Trotzdem solltest du dem Rat von @whats4 befolgen und das Ganze melden. Abstürze sollen nicht sein, unabhängig ob im Browser oder als Client oder als standalone. Wir verwenden eine "Hybridlösung" (Microsoft Dynamics + mehrere Websevices für die Scanner im Lager) und das läuft auch absolut fehlerfrei (menschliche Fehler ausgeschlossen).

 

[Oelepoeto]

Soll das die Zukunft sein im Browser zu arbeiten oder ist das eine Notlösung

Das wird sehr viel gemacht und hat für den Softwarehersteller bzw. Betreiber den Vorteil, dass nur eine Server-Installation statt zig Desktop-Anwendungen verwaltet werden muss

 

[mibbio]

Betreiber den Vorteil, dass nur eine Server-Installation statt zig Desktop-Anwendungen verwaltet werden muss

Zusätzlich wird der Anwender nicht zu einem bestimmten Betriebssystem bzw. einer bestimmten Plattform gezwungen, weil es den nativen Client bspw. nur für Windows gibt. Andersrum spart sich der Hersteller das Entwickeln und Pflegen von Clients für mehrere Betriebssystem.
Ein Webanwendung kann man überall nutzen, wo es einen aktuellen JavaScript-fähigen Browser gibt, also von Windows über Linux und MacOS bis zum Tablet.

Man könnte auch noch den Sicherheitsaspekt anbringen, das Browser(-Tabs) oft isoliert vom restlichen System laufen können und die Zugriffsmöglichkeiten auf das darunter liegende OS beschränkt sind.

 

[sikarr]

Begründung ist wohl die Sicherheit!?

Wohl eher Kosten und Flexibilität. Das Lagersystem Selber, also die Datenbank läuft immer noch auf dem Server nur brauchst du kein Extra Programm mehr dafür. Du kannst es quasi von jedem PC aus erreichen und der braucht auch nicht viel Leistung. Das spart Geld und Aufwand da du im Browser auch immer die Aktuellste Version hast.

Soll das die Zukunft sein im Browser zu arbeiten oder ist das eine Notlösung?

Es ist bereits gängige Praxis.

 

[Ranayna]

Browserbasiert ist die Zukunft, weil es zumindest in der Theorie dann ueberall laeuft, wo auch ein Browser laeuft.

Das ist genau das, was Java damals ueberhaupt so gross gemacht hat, aber der Ressourcenverbrauch verschiebt sich dadurch zu einem grossen Teil Richtung Server, und der Client ist nur noch das "Bedienfeld".
Ist die Anwendung verneunftig gemacht, bringt das grosse Flexibilitaet und funktioniert von einem Smartphone genauso wie von der Steuerwarte mit 4 Monitoren.

Weiterer Vorteil, und das ist der Sicherheitsaspekt: Der Client hat keinen direkten Zugriff auf die Daten.

 

[nutrix]

Die Lagerverwaltungssoftware meines Arbeitgebers in der neuesten Version läuft jetzt im Browser. Vorher als eigenständige Anwendung (Enterprise Client Java).

Hallo.

Da herrscht wohl ein Mißverständnis. Der Browser ist nur eine Darstellung mit einer Oberfläche, die Anwendung läuft im Hintergrund auf einem oder mehreren Servern wo anders. Der Browser leitet nur die Daten, die Du dort in der GUI eingibst, durch, und umgekehrt, bekommst Du die Daten von der Anwendung auf den Brower wieder zurück.

Das kann man vergleichen wie die Bedienung als Browser, welche Dir im Restaurant die Bestellung für Dein Essen an Deinem Tisch aufnimmt, aber gekocht wird in der Küche.

 

[Raijin]

Aber unter Strich wird das die Zukunft wahrscheinlich werden. Nur noch cloudbasierte Lösungen, obwohl on-Premise früher viel besser lief.

Das sind aber zwei Paar Schuhe. Browser-basierte Anwendungen haben nicht zwangsläufig etwas mit Cloud vs on-Premise zu tun. Der Webserver für die Anwendung kann in einer Cloud laufen ebenso wie die Datenbank dahinter, aber beides kann genauso gut auch im eigenen Serverschrank laufen - wie meine ASP.NET Anwendung, die ich für unsere Service-Abteilung geschrieben habe.


@avalon74 :
Browser-basiert vs dedizierte Software-Clients unterscheidet sich primär durch die Plattform(un)abhängigkeit. Einen Browser findet man auf so ziemlich jedem Endgerät mit nahezu beliebigem Betriebssystem. Mac, Linux, Windows. Je nachdem was die Webanwendung tut und welche Technologien eingesetzt werden, läuft sie ggfs sogar in einem banalen Smart-TV.

Ein weiterer Vorteil ist, dass der Client selbst - der Browser - keine anwendungspezifischen Updates benötigt. Bei einer dedizierten Client-Server-Anwendung haben einige Updates zur Folge, dass sowohl der Server als auch der Client aktualisiert werden müssen. Jeder Nutzer muss also ein Update installieren, weil sonst die Anwendung sagt "Geht nicht, weil falsche Version". Ein Browser ist jedoch nur für die Darstellung und die Interaktion zuständig, also Tabellen anzeigen, Button-Klicks, etc. Das läuft dann vorwiegend via HTML und JavaScript - beides wird vom Webserver aus an den Browser geschickt. Sprich: Update am Webserver und die Browser-Clients müssen maximal F5 für ein Refresh drücken.


Ob sich das ganze dann innerhalb einer Cloud oder auf einem eigenen Server abspielt, ist der nächste Schritt. Da stimme ich @Shark1705 zu und bin betrachte Clouds im Allgemeinen auch eher skeptisch, weil das nicht selten auch mit Abo-Modellen einhergeht, denen ich nichts abgewinnen kann.

Habe fast täglich Abstürze während der Arbeit, was vorher nicht der Fall war.

Das wiederum ist etwas anderes. "Abstürze" im Sinne von Bluescreen, o.ä. sollten bei Browseranwendungen nicht auftreten. Und wenn, ist das tendenziell ein Problem des Browsers selbst bzw. des Betriebssystems/PCs. Dies sollte sich die IT-Abteilung anschauen.

"Abstürze" im Sinne von "der Browser spuckt Fehlermeldungen aus" oder "Ich klicke den Button, aber nichts passiert" sind wiederum Sache des Webservers und sollten ebenfalls der IT-Abteilung bzw. ggfs dem Hersteller der Anwendung gemeldet werden.

 

[sikarr]

Ein weiterer Vorteil ist, dass der Client selbst - der Browser - keine anwendungspezifischen Updates benötigt.

Nicht zu vergessen das Lizenzthema. Vorher gabs vielleicht nur einen PC weil die Lizenz zu teuer war, so wird u.U. nur eine User Lizenz / Aktiven Benutzer benötigt und man kann sie auf jedem PC mit Browser einsetzten.

Auch muss man bei defekten nicht jedes Mal einen Rechner Neu einrichten und mit Software bespielen um Arbeite zu können. Neuer PC, Adresse in die Browserleiste und fertig.

 

[KitKat::new()]

Ein weiterer Vorteil ist, dass der Client selbst - der Browser - keine anwendungspezifischen Updates benötigt. Bei einer dedizierten Client-Server-Anwendung haben einige Updates zur Folge, dass sowohl der Server als auch der Client aktualisiert werden müssen. Jeder Nutzer muss also ein Update installieren, weil sonst die Anwendung sagt "Geht nicht, weil falsche Version". Ein Browser ist jedoch nur für die Darstellung und die Interaktion zuständig, also Tabellen anzeigen, Button-Klicks, etc. Das läuft dann vorwiegend via HTML und JavaScript - beides wird vom Webserver aus an den Browser geschickt. Sprich: Update am Webserver und die Browser-Clients müssen maximal F5 für ein Refresh drücken.

Sehe da keinen Vorteil, bzw. überhaupt keinen Unterschied. F5 drücken impliziert ja ein aktualisieren. Und, wenns um den Aufwand geht: Apps aus diversen Stores zu updaten benötigt prinzipiell auch 0 Aufwand seitens der Nutzer.

Ergänzung (18. Januar 2023)

und der braucht auch nicht viel Leistung.

mit ziemlicher Sicherheit mehr Leistung als mit einer nativen Anwendung

Ergänzung (18. Januar 2023)

Der Browser ist nur eine Darstellung mit einer Oberfläche, die Anwendung läuft im Hintergrund auf einem oder mehreren Servern wo anders. Der Browser leitet nur die Daten, die Du dort in der GUI eingibst, durch, und umgekehrt, bekommst Du die Daten von der Anwendung auf den Brower wieder zurück.

Das kannst du ohne weiteres gar nicht wissen, ob da so ist. Die Anwendung kann auch im Sinne einer SPA direkt auf dem Client laufen - ähnlich wie die "alte".

 

[avalon74]

Moin,

vorhin wieder passiert, bei Vergabe eines Lagerplatzes für einen neuen Artikel, also wenn eine Aktion ausgeführt wird. Beim Klick auf "Speichern" rausgeflogen mit Meldung "HTTP Status 500 - Internal Server Error". Danach folgen viele Einträge unter den Unterpunkten "Exception" und "Root cause", wie z.B. javax.servlet., java.lang.Error ... Der Begriff "java" kommt in jeder Zeile vor

 

[Piktogramm]

@avalon74
Du solltest das wirklich nicht hier, sondern deiner IT melden.
1. Sowas behindert dich und alle anderen beim Arbeiten
2. Solche Abstürze sind gern mal Sicherheitsrelevant.
3. Die Konfiguration vom Server ist scheiße, Nutzer sollten NIE technische Fehlermeldungen sehen. Denn sieht es ein Nutzer, kann es auch ein Angreifer sehen und je mehr Informationen das System ausspuckt, desto besser ist es für Angreifer.


###################

Was Webapps an sich angeht. Das Versprechen von Java überall zu laufen, weil man gegen die Javaumgebung schreibt und nicht spezifisch für ein Betriebssystem ersetzen die Browser auch nur. Man schreibt halt mittlerweile gegen Javascript bzw. eine generische Wasm Laufzeitumgebung. Viel nimmt sich das nicht, nur dass man mittlerweile leichter (günstiger) Entwickler für Javascript bekommt und das dank Oracle Java tot fragmentiert wurde, anstatt sinnvolle Weiterentwicklung zu sehen.

Was die Performance angeht, das Bild ist an der Stelle nicht einheitlich. Tendenziell ist das Zeichnen von Oberflächen und Netzwerk I/O seitens der Browser so gut optimiert, dass die das besser können als viele GUI-Frameworks für sonstige Laufzeitumgebungen/Programmiersprachen. Genauso ist das Verarbeiten von Daten die als XML oder Json ausgetauscht werden bei Browsern recht flott. Erst bei großen Datenmengen oder großen Rechenoperationen ist Javascript recht langsam. Bei typischen, stark zentralisierten ERP-Anwendungen, wäre es aber recht doof sowas auf Clients zu machen.

 

[avalon74]

Wir sind ein Zentrallager mit entsprechend vielen Mitarbeitern. Problem ist natürlich bekannt. Das war ja auch nie das Thema hier.

Danke für die vielen Beiträge!

 

[Piktogramm]

@avalon74
Naja, du hast Sicherheit erwähnt.. Das was du an Verhalten (des Programms) beschreibst ist ein bzw. mehrere typisches Antipattern was Sicherheit angeht. Ich habe irgendwie auch Zweifel, dass das Problem wirklich bekannt ist. Da ist bekannt, dass da immer mal wieder was abschmiert, welche Sicherheitsimplekationen das hat, scheint aber ignoriert zu werden. Dass es dir als Anwender nachwievor die nicht oder nur bedingt abgefangene Fehlermeldung um die Ohren haut ist ein ZUSÄTZLICHES Problem zur "java exception". Das sollte sich normalerweise auch recht schnell unterbinden lassen (oder der ganze Stack vom Software ist so gammlig, dass man da eskalieren sollte).

 

[Raijin]

Habe fast täglich Abstürze während der Arbeit, was vorher nicht der Fall war.

Beim Klick auf "Speichern" rausgeflogen mit Meldung "HTTP Status 500 - Internal Server Error".

Das hat aber prinzipiell nichts mit dem Unterschied einer nativen Anwendung vs browserbasiert zu tun. Bugs kann es natürlich bei beiden Konzepten geben. Es kann auch sein, dass die Anwendung als solche den Fehler gar nicht verursacht, sondern ein Fehler in der zugrundeliegenden Datenbank vorliegt (zB fehlerhafte Tabellendefinition) - egal ob der Lagerplatz nun über einen installierten Software-Client oder über einen Browser gespeichert wird.

 

[mibbio]

Die Anwendung hat im Prinzip schon grundlegende Mängel bei der Fehlerbehandlung. Unabhängig von der Art der Anwendung sollte der Nutzer den sogenannten Stacktrace generell nicht zu sehen bekommen. Den schreibt man höchstens in ein Logfile und blendet dem Anwender eine informative Fehlermeldung ein. Bei serverseitigen Fehlern (bei HTTP alle 500er Fehlercodes) sollte der Stacktrace auch nur auf dem Server geloggt werden und gar nicht erst zum Client gelangen. Einfach weil da potentiell Informationen zur Funktionsweise des Server bzw. der Serversoftware drin stehen.

 

[Ranayna]

Eines deutet diese Sache auf alle Faelle an, und das ist etwas ich immer und immer wieder sehe:
Die Entwickler reden nicht mit den Nutzern, und Nutzerrueckmeldungen kommen nicht richtig bei den Enwickern an.

So oft ist das auffaellig, das gefuehlt an den Nutzern komplett vorbeientwickelt wird.
Da werden sich Workflows ausgedacht, die dem Entwickler logisch vorkommen, und die vielleicht technisch einfacher umzusetzen sind, die den Nutzer aber in den Wahnsinn treiben, weil sie an der Praxis vorbeigehen.
Natuerlich wird das dann auch nicht erklaert warum das vielleicht besser ist, und die Nutzer sind genervt und "nichts funktioniert".

Umgekehrt sind viele Nutzer auf die "IT", aus welchen Gruenden auch immer, nicht gut zu sprechen. Dann werden Fehler auch einfach mal ueberhaupt nicht gemeldet, weil sich aus Sicht der User eh nichts aendert.

Und man sitzt als IT Supporter zwischen den Stuehlen und versucht zu vermitteln

 

[Raijin]

Die Entwickler reden nicht mit den Nutzern, und Nutzerrueckmeldungen kommen nicht richtig bei den Enwickern an.

Das ist leider tatsächlich häufig so. Eigentlich gibt es bei der SoftwareEntwicklung das Konzept des Lasten- und Pflichtenhefts. Das Lastenheft wird vom Auftraggeber erstellt und beschreibt die Anforderungen, den Soll-Zustand des zukünftigen Systems, während das Pflichtenheft vom Entwickler auf Basis des Lastenhefts erstellt wird und die technische Umsetzung beschreibt.

Leider tun sich aber viele Auftraggeber schon damit schwer, ihre Anforderungen in einfachen Worten zu definieren, von komplexen Arbeitsabläufen ganz zu schweigen. Wenn aber der Auftraggeber schon nicht beschreiben kann was er eigentlich erwartet, kann man diese Erwartungen auch nicht wirklich erfüllen, nicht im Pflichtenheft und im fertigen Produkt erst recht nicht. Der einzige Ausweg: Engmaschige Kommunikation mit dem Auftraggeber und Präsentation des aktuellen Stands, um so möglichst frühzeitig eine falsche Ausrichtung zu korrigieren.

Momentan schreibe ich beispielsweise eine Anwendung für unsere Service-Abteilung auf Basis von ASP.NET. Ständig bekomme ich zwischen Tür und Angel zu hören "Mach mal ne Statistik mit nem Diagramm". Ich muss dem Abteilungsleiter, der natürlich nie Zeit hat, dann alle relevanten einzeln Informationen aus der Nase ziehen. Alle Zahlen? Gefiltert? Absolut? Kumulativ? Balkendiagramm? Tortendiagramm? Nachdem das aaaaaalles mühsam geklärt ist, kommt beim Update natürlich der erste Kommentar "Das Wording gefällt mir nicht". Da kriegt man die Krise...

Lasten- und Pflichtenheft sind meiner Erfahrung nach leider viel Theorie, aber die Praxis sieht häufig anders aus. Es ist eben immer ein Problem, wenn Laien mit Profis kommunizieren (in Bezug auf Software), weil es Laien einfach schwerfällt, sich ausreichend präzise auszudrücken, und weil sie ggfs die technischen Möglichkeiten gar nicht kennen und teilweise im Kopf schon Workarounds basteln und diese dann als Anforderungen formulieren. Das führt ganz schnell zu XY-Problemen.....

Bei etwaigen Problemen und Fehlern ist das nicht anders. Gerade wieder eine Mail von einem Kunden aus Thailand bekommen: "Label-Printer not working". Aha. Aus dem Stegreif fallen mir drei Dutzend verschiedene Ausprägungen von "not working" ein. Von der leeren Etikettenrolle, über ein defektes Netzteil, ein rausgerutschtes USB-Kabel bis hin zu Konfigurationsfehlern. Auch hier wieder: Wenn sich der Auftraggeber nicht mal halbwegs klar ausdrücken kann - wie beim letzten mal "not working" wo das Druckbild schwach war (Tonerband ausgelutscht) - gerät man als Entwickler an seine Grenzen..

 

[LencoX2]

Sicherheit als Grund ist mit tödlicher Sicherheit nicht die ursprüngliche Ursache. Denn mit jedweder Frontend Technologie lässt sich gleichwertige Sicherheit implementieren.

Gründe, dass Desktop Apps in den Browser wandern gibt es viele.

• Standard Technologie, Browser HTML(5)
• Schlanke Clients ohne zusätzliche Installationen
• Versionsaktualisierung einfacher umzusetzen
• wird als moderner empfunden
• wird gerne als Cloud fähig dargestellt
• Browserclient ist abgekapselt vom System (Sicherheit)
• uvm

Es gibt keine pauschale Antwort ob dies oder jenes besser ist