Laden...

Grundsätzliche Machbarkeit: "Mehrere Fenster" und Blazor/Razor?

Erstellt von ans vor 2 Jahren Letzter Beitrag vor 2 Jahren 677 Views
A
ans Themenstarter:in
4 Beiträge seit 2017
vor 2 Jahren
Grundsätzliche Machbarkeit: "Mehrere Fenster" und Blazor/Razor?

Ich komme aus der reinen Windowsentwicklung. Die Anwendung an der ich beruflich mitarbeite, soll (endlich) einmal auf neue Techniken umgestellt werden, am liebsten wäre meinen Chef eine Webanwendung. Bevor ich mich in eine Technik tiefer einarbeite, möchte ich zumindest die Grundsätzliche Machbarkeit von dem ein oder anderen Feature abklären.

Unser Bestandsanwendung ließe sich zwar weitgehend in einem einzelnen Browserfenster unterbringen, aber es gibt wichtige Anwendungsszenarien/Komfortfunktionalitäten bei mehreren Monitoren, wie z.B. das herauslösen/verteilen bestimmter (auch gleichartiger) Anwendungsbereiche auf unterschiedliche Browserfenster/Monitore (z.B. mehrere gleichartige Planungsansichten zu jeweils unterschiedlichen Ressourcenkonstellationen). So wie ich mir Single-Page-Applications (SPA) vorstelle, hört sich dieses, für uns nicht ganz unwichtige Feature, eher wie ein Problem an.

Ist so etwas auch unter SPA-Anwendungen (speziell mit Blazor) realisierbar (Idealerweise mit Beispiellinks oder ähnlichen)? Falls es ggf. mehrere Möglichkeiten gibt (ich stelle mir jetzt banal als mögliche "unschöne" Lösung das Öffnen der "Gesamtanwendung" in mehreren Browserfenstern vor), welche? Wo stecken ggf. Fallstricke?

Würde gerne das Problem zumindest abgehakt wissen, bevor ich mich ggf. in Techniken verrenne, die ungeeignet für unser Anwendungsszenario sind.

190 Beiträge seit 2012
vor 2 Jahren

Hallo,
ich hab von Blazor keine Ahnung, aber Google hat mir folgenden Link ausgespuckt: Multiple Windows In ASP.NET Core Blazor

  • Wer lesen kann, ist klar im Vorteil
  • Meistens sitzt der Fehler vorm Monitor
  • "Geht nicht" ist keine Fehlermeldung!
  • "Ich kann programmieren" != "Ich habe den Code bei Google gefunden"

GidF

2.078 Beiträge seit 2012
vor 2 Jahren

Geht auf jeden Fall, es sagt ja niemand, dass alles nur eine SPA sein muss.
Doch ich würde es nicht pauschal so machen, sondern nur auf Anforderung (z.B. ein Button "Abdocken").
Oder ganz allgemein gesprochen: "Ist so etwas [...] realisierbar?" kann man so gut wie immer mit "Ja" beantworten ^^
Das teilen der Zustandsdaten zwischen den "Dialogen" stelle ich mir aber etwas komplizierter vor, als beim Desktop.

Aber muss es denn eine Web-Anwendung sein oder ist das eher ein "das macht gerade jeder"?
Der große Vorteil vom Web ist ja die Flexibilität auf allen möglichen Geräten, aber hier scheint ja nur der Desktop realistisch zu sein?

J
641 Beiträge seit 2007
vor 2 Jahren

Wir hatten auch ne multi Window WPF UI, nun nutzen wir DockSpawn in HTML. Ich hab das nach TypeScript konvertiert.
In wie weit du das mit Blazor nutzen kannst weiß ich nicht, siehe https://github.com/node-projects/dock-spawn-ts

Wir haben dann 2 UIs gebaut, die eine nutzt eben Dockspawn, die andere für Touch Devices ist ne Single Window UI. Die Fenster darunter sind die gleichen nur das Docking nutzen wir bei kleinen Geräten eben nicht. Wobei DockSpawn in der von mir gepatchten Version auch mit Touch funktioniert.

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor 2 Jahren

In modernen Browsern ist jeder Tab ein eigener Prozess mit einem eigenen Kontext, der die anderen Tabs nicht kennt.
Keine SPA, PWA... etc egal mit welchem Framework kann dieses Grundkonstrukt ändern. Das ist ein Sicherheitsfeature.
Jeder Tab ist daher ein eigene Instanz einer SPA/PWA... egal wie viele Du davon öffnest.

Eine Kommunikation auf der Client-Seite zwischen verschiedenen Instanzen (=>SPA) funktioniert über eine extra API: BroadCastChannel API.
BroadcastChannel - Web APIs | MDN

C
2.121 Beiträge seit 2010
vor 2 Jahren

Nur weil es Webanwendungen gibt und viele glauben sie müssten sie deswegen für alles einsetzen, ist das trotzdem noch nicht überall sinnvoll 🙂

Man denke an Onlinebanking, wo man ein Problem kriegt wenn man aus Gewohnheit "zurück" klickt - und dann auf einer abgelaufenen Session steht und sich dann vielleicht direkt neu anmelden muss damit man weiter kommt. Lästig! Und undurchdacht!
Oder andere Anwendungen die es oft auch im professionellen Umfeld gibt, wo die ganzen Aspekte die hier angesprochen werden (mehrere Ansichten, verschiebbar und so) entweder einfach gar nicht existieren oder plump und nur unzureichend simuliert werden.

Ganz davon zu schweigen vom Aktualisierungskonzept einer Ansicht. Wenn ich zum umsortieren einer Liste einen Durchlauf "Anfrage an den Server - Antwort vom Server - Neuaufbau der kompletten Ansicht" abwarten muss, das kanns nicht sein.

Das Argument "läuft auf jeder Platform" mag stimmem. Nur was hilft es mir wenn etwas zwar auf jeder Platform läuft, ich das aber gerade im Firmenumfeld gar nicht brauche weil es dort nur Windows gibt? Für diese rein in der Theorie existierende Freiheit gebe ich die ganzen Vorteile einer richtigen Anwendung auf.
Wie viel Lob darf ich dafür erwarten?

Dazu kommt dass eine professionelle Anwendung für mich subjektiv gesehen einfach nichts in einem Browsertab zu suchen hat, neben dem sich Katzenvideos, Nachrichtenseiten, Facebook und ähnliches tummeln.

am liebsten wäre meinen Chef eine Webanwendung

Da haben wir das Problem.
Warum wäre ihm das am liebsten? Ist er die Art Chef, der mit der Thematik nichts zu tun hat und der Begriff "Webanwendung" das einzige ist was ihm dazu zufällig irgendwo begegnet ist?
Informiere ihn dass man nach der Aufzählung der Vorteile nicht zu lesen aufhören darf, da kommen meistens noch die Nachteile 😉

16.806 Beiträge seit 2008
vor 2 Jahren

Da haben wir das Problem.
Warum wäre ihm das am liebsten? Ist er die Art Chef, der mit der Thematik nichts zu tun hat und der Begriff "Webanwendung" das einzige ist was ihm dazu zufällig irgendwo begegnet ist?
Informiere ihn dass man nach der Aufzählung der Vorteile nicht zu lesen aufhören darf, da kommen meistens noch die Nachteile 😉

Wo soll das ein Problem sein? Ich kann nicht erkennen, dass das eine invalide Aussage wäre - das zu behaupten wäre an dieser Stelle unseriös.
Wir kennen die Anforderungen nicht und auch nicht die Quelle der Aussage.

Dass eine Webanwendung heutzutage im Gesamtkontext in den aller meisten Alltagssituationen eher Vorteile hat als Nachteile gegenüber einem Fatclient; das ist ja denke ich ein nicht abstreitbarer Consent.

Man denke an Onlinebanking, wo man ein Problem kriegt wenn man aus Gewohnheit "zurück" klickt - und dann auf einer abgelaufenen Session steht und sich dann vielleicht direkt neu anmelden muss damit man weiter kommt. Lästig! Und undurchdacht!

Sicher ist das kein Technik Problem, sondern einfach nur Implementierungssache. Seit ~10 Jahren ist es problemlos möglich auf den Back-Button zu reagieren.
Ich kenne zwar noch die Zeit, in der der Back Button die Session ungültig gemacht hat - aber alle meine Banken bzw. deren Online Banking / Depot / ... -Portale unterstützt das heutzutage .
Weil ein Entwickler oder ein Team eine Funktion nicht implementiert, die ganze Technik infrage zu stellen..?? Well...

Oder andere Anwendungen die es oft auch im professionellen Umfeld gibt, wo die ganzen Aspekte die hier angesprochen werden (mehrere Ansichten, verschiebbar und so) entweder einfach gar nicht existieren oder plump und nur unzureichend simuliert werden.

Okay, also auch nur Kritik an der Implementierung...?

Ganz davon zu schweigen vom Aktualisierungskonzept einer Ansicht. Wenn ich zum umsortieren einer Liste einen Durchlauf "Anfrage an den Server - Antwort vom Server - Neuaufbau der kompletten Ansicht" abwarten muss, das kanns nicht sein.

Das ist in Fat-Clients, die ihre Datenbank mit 839 TB an Daten nicht lokal haben, nicht anders - zumindest wenn Du ein simples Nachladen der Daten meinst.
Ansonsten auch hier: halt Implementierungssache - Full Load vs. Partial Load.

ich das aber gerade im Firmenumfeld gar nicht brauche weil es dort nur Windows gibt?

Aus Firmensicht im Jahr 2021: wie viele Menschen haben sich in einem Bewerbungsprozess gegen mich entschieden, weil ich nur Windows biete?
Und da ich in der Vergangenheit Jobs abgelehnt habe, weil mir eine IT aus der Vergangenheit auferlegt werden sollte, verstehe ich das.
IT ist dazu da, dass die MA arbeiten können - nicht sie daran hindern. Und jeder sollte zumindest hauptsächlich die Tools und Plattformen haben, die ein MA produktiv macht (natürlich alles mit Einschränkungen).
Aber gerade bei Office Tools darf das OS kein Hindernis mehr sein.

Dazu kommt dass eine professionelle Anwendung für mich subjektiv gesehen einfach nichts in einem Browsertab zu suchen hat, neben dem sich Katzenvideos, Nachrichtenseiten, Facebook und ähnliches tummeln.

Persönliche Sicht. Meine Sicht: Wie professionell ist eine Firma, wenn sie ihre gesamte Strategie auf konventionellen Technikfundamenten aufbaut, die mich in einem modernem Umfeld einschränkt? 🙂

C
2.121 Beiträge seit 2010
vor 2 Jahren

Ja, einige Punkte sind eine Frage der Implementierung. Aber die erlebe ich eben hier und da ziemlich mager.
Das Argument "jetzt alles als Webanwendung" alleine ist noch nicht genug. Man muss es dann schon auch gescheit machen - wenn das nicht passiert, ist kein Wunder dass so ein Eindruck entsteht.
Selbes mit "wir haben eine Umgebung in der man tolle Dinge anstellen könnte, aber das was letztendlich passiert ist ein Rückschritt" 😉

16.806 Beiträge seit 2008
vor 2 Jahren

Das gilt aber für jede Art von Applikation.
Aus meinem Alltag kann ich sagen, dass Desktop-Applikationen bei mir den Eindruck hinterlassen, dass sie Jahre hinterher hinken.
Für mich perfektes Beispiel: Office Suite. Und Microsoft gibt sich noch sehr viel Mühe, im Gegensatz zu den aller meisten anderen Unternehmen, vor allem Mittelstand.

Moderne Features sind viele Monate zuerst in der Web-Fassung, bevor sie - wenn überhaupt - im Desktop landen.
Daher: "Das Argument Desktop is besser, weils ja lokal läuft" - eher "meh".

J
641 Beiträge seit 2007
vor 2 Jahren

Ich hab vorher unsere UI in WPF entwickelt, und jetzt im Browser.
Und da muß ich sagen, im browser bin ich um Welten schneller. Wenn ich da was teste, dann mach ich kurz den Debugger auf, spiele noch ein bisschen an meinen Styles rum und übernehm das dann.

Ich wüsste nicht welches UI Framework ich auf dem Desktop im Moment einsetzen würde... WinForms, WPF -> irgendwie wird beides zwar nach NET6 portiert, aber wirkliche Entwicklung gibts nicht mehr, UWP -> nutzt das jemand?, MAUI -> noch nicht fertig, Blazor -> ist das jetzt Silverlight in neuem Gewand?

Wir machen unsere UI im Moment nur noch im Browser, und ich muß sagen wir sind um Welten Produktiver als wir es in Silverlight und dann WPF waren.

Natürlich setze ich nicht für jedes Mini Tool eine HTML UI auf, da nutze ich dann schon mal WPF. Aber ne große Business Anwendung, HTML und gut.

cSharp Projekte : https://github.com/jogibear9988

C
2.121 Beiträge seit 2010
vor 2 Jahren

Dass der Entwickler da produktiver ist mag sein. Aber wie sieht es für den Anwender aus?

16.806 Beiträge seit 2008
vor 2 Jahren

Und Du meinst man kann das für den Anwender generell pauschalisieren?
Denke, dass das dünnes Eis ist. Vor allem in den aller meisten Situationen.

Ein Office MA ist vermutlich mit vielen Tools im Browser effizienter.
Ein CADCAM MA vermutlich nicht.

Hinzu kommt, dass UX sich immer verändern wird.
Und dass Browseranwendungen sich schneller verbreiten als alles andere, wird deren UX positiv verändern und User werden automatisch im Browser immer effizienter.
Dann wären da noch all die manuellen Installationen: eine Desktop App muss installiert / verteilt werden - das skaliert nicht. Eine Webanwendung ist für alle sofort da.
Dutzende Millionen werden jedes Jahr in ITs verbraten, weil Apps auf den PCs gewartet werden müssen.

Man wird sich dem nicht entziehen können.

Blazor -> ist das jetzt Silverlight in neuem Gewand?

Die Frage zeigt, dass Du Dir das keine 5 Min angeschaut hast 🙂

  • Silverlight war eine proprietäre Konkurrenz zu Flash / JavaFX.
  • Blazor basiert auf dem offenen Web Standard WASM; also ByteCode im Browser.
J
641 Beiträge seit 2007
vor 2 Jahren

Die Frage zeigt, dass Du Dir das keine 5 Min angeschaut hast 🙂

  • Silverlight war eine proprietäre Konkurrenz zu Flash / JavaFX.
  • Blazor basiert auf dem offenen Web Standard WASM; also ByteCode im Browser.

Wenn du das meinst...

Silverlight hat auch auf eine offene Plugin Schnittstelle im Browser aufgesetzt. (Die wurde zumindest von verschiedenen Browsern unterstützt).
Ja Open Source war es damals noch nicht.
Im Endeffekt lädst du auch ein abgespecktes Netframework und führst es im Browser aus.
Ich sehe im Moment nicht wirklich einen Vorteil wenn man Blazor als UI Framework verwendet.

  • Perfomance ist schlechter als von anderen Frameworks (da ja jeglicher DOM Zugriff immer über Javascript laufen muß, d.h.ich kann auch gleich ein JS Framework verwenden).
  • Ich muss mich trotzdem mit JS beschäftigen. Weil es gibt immer irgendwas was dann mit Blazor nicht/noch nicht funktioniert, und dann muss ich mich doch mit JS beschäftigen, also kann ich es auch gleich tun.

cSharp Projekte : https://github.com/jogibear9988

J
641 Beiträge seit 2007
vor 2 Jahren

Da man Silverlight schon mit https://opensilver.net/ in Blazor nachgebaut hat ist die Aussage wohl nicht so ganz falsch.

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor 2 Jahren

Silverlight war niemals eine offene Schnittstelle, sondern immer ein proprietäres Plugin.
Das Ding lief auch niemals in allen Browsern sondern nur in denen, für die Microsoft Plugins zur Verfügung gestellt hat. Chrome zB hat hier nie offen mit Microsoft zusammen gearbeitet sondern (dann) nur eine PP-API Schnittstelle für solche Techniken angeboten.
Adobe ist auf den Zug aufgefahren, Microsoft nicht - daher flog Silverlight aus Chrome raus.

Blazor basiert auf WASM, einem offenen WebAssembly Standard => https://caniuse.com/wasm
WebAssembly war zwar früher mal zuerst als native Ausführungsruntime für Browser gedacht, mittlerweile läuft das Zeug auch direkt auf einem PC oder auch zB. direkt auf Kubernetes als Backend Runtime.
WASM ist die native Runtime - und dafür gibt es für viele Sprachen (C++, Rust, JavaScript) auch entsprechende Compiler.
Am Ende kommt eben ByteCode raus - absolut Null Komma Null vergleichbar mit Plain-JavaScript Code, der im Browser interpretiert wird oder gar mit Silverlight.

Ich muss mich trotzdem mit JS beschäftigen. Weil es gibt immer irgendwas was dann mit Blazor nicht/noch nicht funktioniert, und dann muss ich mich doch mit JS beschäftigen, also kann ich es auch gleich tun.

Ja - WASM hat einen optionalen DOM Zugriff, um eben kompatibel zu sein - aber das ist kein Muss.
Dass man bei manchen Dingen bei Blazor JavaScript braucht ist dem geschuldet, dass nicht alle Funktionalitäten aus dem DOM heute in WASM existieren.
Der JavaScript Teil ist also der Fallback - und gilt nicht nur für Blazor, sondern alle WASM Frameworks.

Die Argumentation, dass Du "gleich JavaScript" nehmen kannst ist so ähnlich wie C# ~10 Jahre auf Windows: man kann 99,99% der Anwendungen wohl mit C# machen, aber nen paar Dinge braucht man ab und zu dann doch ein C++ Fallback.
Hey, also gleich alles mit C++ machen, weil ganz ohne komm ich halt nicht aus.
Merkste, dass das eher Quatsch ist, oder? 🙂

Perfomance ist schlechter als von anderen Frameworks (da ja jeglicher DOM Zugriff immer über Javascript laufen muß, d.h.ich kann auch gleich ein JS Framework verwenden)

Das ist leider technisch absolut falsch 🙂
WASM und der DOM sind parallele Konzepte. WASM kann aber auf dem DOM zugreifen, umgekehrt geht das nicht.
Vereinfacht ausgedruckt sind beides "Runtimes im Browser für Client Code". Aber WASM basiert nicht auf DOM.
Die Performance spricht des weiteren für WASM, weil eben Byte Code und nichts interpretiert werden muss.
Grundlagen zum Konzept hier: https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
Und noch zum Them Performance mit WASM hier: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/

Aber ja, neben .NET, Rust... kannst Du auch JavaScript über einen Compiler zu WASM formen.
Das kann die WebAssembly sogar von Haushaus.

ist die Aussage wohl nicht so ganz falsch.

Sie ist leider extrem falsch wie die kurze Zusammenfassung zeigt 🙂
Silverlight mit Blazor gleichzustellen ist ungefährt so als würde man ein Volvo aus 1980 mit einem Tesla Y vergleichen: sehen beide von Aussen so aus wie ein Auto - innen ist aber alles fundamental verschieden.
SL und Blazor sind in der gesamten Technik (Sicherheit, Threading Modell, Architektur, Schnittstellen) völlig verschieden. Sie haben nicht im entferntesten etwas miteinander zutun, ausser das beide "etwas auf der UI im Browserfenster anzeigen".
Weil jemand mit einer offenen Technik etwas nachbaut, das wie Silverlight klingt macht es trotzdem nicht zu einem Silverlight Klon.

WASM ist ein wirklich zukunftsfähiges Modell, was Silverlight nicht war.
Gönn Dir 2-3 Stunden Grundlagen Tutorial dazu - dann wirst merken, dass Du da wohl paar Dinge einfach bislang vielleicht falsch verstanden hast.

J
641 Beiträge seit 2007
vor 2 Jahren

Ich finde den Blogbeitrag zu den Microsoft Technologien gut: Thoughts on Microsoft, and Blazor - Peter's
Wobei bei Blazor Server bin ich jetzt nicht unbedingt seiner Meinung, aber natürlich hat er mit der Dependency Hölle der JS Bibliotheken recht.
Und auch das ganze EMS, Require und AMD Module zeugs machts natürlich nicht gerade einfach. Vlt. wird ja in ferner Zukunft da auch Deno was bewirken und Nodejs verdrängen. Der Vorteil hier wäre halt das es ein set von Standard Module gibt. Oder Blazer wird richtig groß. Wer weiß...

cSharp Projekte : https://github.com/jogibear9988