Welche Technologie für Webentwicklung (Frontend) stand ende 2018

Hallo liebe Community,

ich komme eher aus der Backend, bzw. Serverentwicklung und hatte bisher recht wenig mit Frontendentwicklung, bzw. Webapplikationen am Hut. Das soll sich nun ändern, da ich gerne für ein privates Projekt eine Webseite zur Darstellung von Informationen umsetzen möchte. Dieses Projekt ist durch einen Windows-Dienst (.Net Framework 4.6.2) in Verbindung mit einer SQL-Datenbank realisiert. Konkret sollen unterschiedlichste Elemente wie Text, Bilder oder Tabellen aus der Datenbank dargestellt werden. Auch sollen über die Webseite ein paar Funktionen des Dienstes angestoßen werden können.

Nun habe ich mich etwas eingelesen, bin aber von der Fülle an Informationen etwas überfordert. Ich wende mich an euch, da ich gerne mit aktuellen Technologien arbeiten will, aber mir nicht ganz sicher bin, was man denn für solch eine Angelegenheit verwendet. Was ich weiß: Die Web-Applikation muss nicht auf Linux laufen, weshalb ich gut auf .Net Core verzichten kann.
_
Somit seht für mich fest, ich würde gerne ASP.NET als Framework verwenden. Ist es nun ratsam, mit WebForms zu arbeiten, also mit XHTML und CodeBehind-Daten oder Mit Asp.Net MVC? Da wäre rein von der Architektur her eine bessere Trennung von Funktionen und Aussehen der Inhalte gegeben. Verwendet man da dann die Version 4 oder 5? Sollte man RazorPages verwenden, bzw. in wie fern bringt mir das Vorteile?_

Vielleicht kann mir jemand von euch bei ein paar Entscheidungen helfen. Allem voran ist meine Intention dieses Beitrags auch anderen Entwicklern aufzuzeigen, was es denn Stand Ende 2018 für Möglichkeiten gibt.

Vielen Dank schon mal für eure Unterstützung!
Gruß mipa_acc

Hallo mipa_acc,

die folgende sarkastische Aussage kann ich mir leider nicht verkneifen, aber der Wunsch nach aktuellen Technologien und WebForms widerspricht sich schon sehr 😉

.NET Core bedeutet nicht zwangsweise ein Arbeiten und Linux. .NET Core bietet die Möglichkeit auch unter Linux u.a. lauffähig zu sein. Ob es genutzt wird ist eine andere Sache.

Ich würde ASP.NET Core basierend auf .NET Core verwenden (serverseitig), dann bist du mit den aktuellen Technologien dabei.

Clientseitig kannst du in Angular, React oder Vue? schauen.

Sollte man RazorPages verwenden, bzw. in wie fern bringt mir das Vorteile?

Ein Vorteil ist dass keine extra Controller mit der passenden Action explizit erstellt werden muss.
Wenn du also serverseitig nur simples HTML zurückliefern willst (Layout + Page gerendert durch Razor) und der Rest passiert am Client, indem er via WebAPI vom Server die Daten lädt, so ist das ganz praktisch. Siehe auch Introduction to Razor Pages in ASP.NET Core

mfG Gü

Hallo mipa_acc,

dazu ergänzend:
Web-Programmierung - Fragen zur Herangehensweise.
Der richtige Einstieg in die Webentwicklung - Roter Faden?

Gruss

Coffeebean

Davon abgesehen, dass ich den Eindruck habe, dass Du das Ziel von .NET Core und .NET Standard evtl. noch nicht ganz verinnerlicht hast: willst Du mit ASP.NET arbeiten und dabei modern bleiben, was sich empfiehlt, dann kommst Du an .NET Core (Gott sei dank) gar nicht vorbei:
ASP.NET Core 3.0 nur noch mit .NET Core, nicht mehr mit .NET Framework (Platzhalter)

Und auch für .NET Framework fokussierte Entwickler heisst es: .NET Standard ist die Zukunft.

Hallo liebe Mitbenutzer des Forums,

vielen Dank für eure Informationen. Wie ihr schon bemerkt habt bin ich außerhalb des Frameworks wirklich nicht versiert, deshalb auch so eine unproffesionelle Fragestellung. Leider ist es mit meinem Wissensstand nicht leicht, sich einen roten Faden durch die Webentwicklung anzulesen, durch eure Beiträge wird mir das sicherlich leichter fallen. Vielen Dank schonmal dafür. Ich werde mir nun im Detail eure Infos durchlesen und mich dann ggf. an dieser Stelle wieder melden.

Viele Grüße
mipa_acc

Ich häng mich mal gerade aus dem Fenster und gebe mal meine beschränkte Sichtweise wieder.

• Ohne dass ich die Anforderungen kenne -

Das was jetzt kommt, kann auch gaaaanz anders gesehen werden - man darf mich gerne dafür rügen 😉
Insbesondere die Framework-Frage ist religiös.

Hier ein einfacher Entscheidungsbaum:

1.

Ihr könnt C#/.NET Framework und könnt mit WPF/WinForms UIs bauen.
Ihr habt noch wage Erinnerungen an PHP-Experimente und habt gehört, dass HTML5 und Bootstrap ganz gut sein sollen.

Ihr findet Responsive Webdesign gut https://de.wikipedia.org/wiki/Responsive_Webdesign.
Der Gedanke, dass man sich mit Progressive enhancement auf das Notwendigste konzentriert und später fancy Javascript hinzunimmt gefällt euch.https://de.wikipedia.org/wiki/Progressive_Verbesserung
Eure Website ist nicht besonder dynamisch und wenn man auf eine Button auf der Website klickt, dann darf sich die Seite auch mal neuladen.

->

.NET Core (≥2) + ASP.NET Core
serverseitiges Rendern von HTML (Razor, MVC)
Bootstrap als CSS-Framework

2.

Ihr glaubt, dass die Webseite mehr Dynamik braucht. Ihr scheut nicht davor Javascript/TypeScript zu erlernen.
Ihr findet allerdings objektorientiertes Programmieren gut. DependencyInjection mögt ihr https://de.wikipedia.org/wiki/Dependency_Injection.
Eine ordentliche Schichtenarchitektur https://de.wikipedia.org/wiki/Schichtenarchitektur findet Ihr wichtig.

->

.NET Core (≥2) + ASP.NET Core

WebAPI (RESTful)
Angular ≥7
Bootstrap, Angular Material https://material.angular.io/, oder selber bauen
PWA

3.

Ihr habt es voll drauf mit JavaScript/TypeScript. OO ist euch nicht immer wichtig. Ihr scheut nicht vor "bleeding edge"-Technologien.
Eure Entwickler brauchen keine Leitplanken. Die Gefahr von big-ball-of-techo-mutt seht Ihr nicht. Gerne baut ihr eure Microservice neu.
Die Halbwertszeit eure Anwendungen ist gering. Webpack-Config schreiben rockt.

->

.NET Core (≥2) + ASP.NET Core ... oder doch lieber node.js
WebApi (RESTful oder GraphQL)
React oder Vue
PWA

... ich finde #2 ganz gut

Ein sehr interessantes Thema, zumindest für uns. Wir programmieren seit sehr vielen Jahren eine Datenbankanwendung eher im Backend. Für das Frontend nutzen wir seit Urzeiten den Team Developer von der Firma OpenText (früher Gupta/Centura/Unify).

Unsere Anwendung läuft bisher nur unter Windows. Ein Großteil der Geschäftslogik wird bisher lokal auf der jeweiligen Arbeitsstation durchgeführt, was aus heutiger Sicht mehr als suboptimal ist. Daher versuchen wir immer mehr auf dem Server auszulagern – mit reinem Backend-Code gelingt das auch gut, aber nun haben wir ein größeres Problem:

Unser uraltes Entwicklungssystem Team Developer trennt Programmlogik von der GUI nicht wirklich. Wir möchten jedoch zukünftig einen schlanken Client haben, der sich nur um die GUI kümmert, während die gesamte Programmlogik auf einem Server ausgeführt wird. Ziel soll sein, auf Team Developer komplett zu verzichten.

Wir stellen uns dabei einen Client vor, der sich ausschließlich um die Benutzerinteraktion kümmert während auf dem Server Geschäftslogik und Datenspeicherung zentral erledigt werden.

Nun sind wir auf diesen interessanten Thread gestoßen. Der hat mich veranlasst, die ersten Recherchen zu starten, um zu eruieren, was für uns in Frage kommt. Ehrlich gesagt, fühle ich mich ein wenig wie der Ochse vor dem Berg 😃 An dieser Stelle muss mich als kompletter Neuling outen, was dieses Thema angeht.

Vielleicht erzähle ich ein bisschen über unsere Anwendung, um abzuwägen, was für uns eher in Frage kommen könnte:

Unsere Anwendung besteht hauptsächlich aus zwei Komponenten: Masken (Forms) und Tabellen – mehr gibt es nicht. Die Anwendung ist eine reine Datenbankanwendung, die typisch Daten entgegen nimmt und darstellt. Fast hinter jeder Eingabe (Maskenfeld oder Tabellenspalte) verbirgt sich eine Nachverarbeitung, die die Eingabe prüft und u. U. weitere Werte anhand der Eingabe anpasst. Also eigentlich eine relativ langweilige und statische Geschichte.

An diesem Aufbau wird sich auch zukünftig nichts ändern. Und genau dafür suchen wir die richtige Technologie – wir wollen keinen Overkill, den wir nie brauchen werden, sondern nur die passenden Werkzeuge, die uns ermöglichen, unser Ziel zu erreichen und eine gewissen Beständigkeit aufweisen. Aus den Antworten hier habe ich folgende Produkte herausgepickt, wobei ich mir nicht sicher bin, welches für unsere Anforderungen das geeignete ist: Razor, Angular,React undr Vue.

Zu uns selbst: Wir programmieren C# und SAL (Team Developer – davon gehen wir aber weg). C++-Kenntnisse sind ebenfalls vorhanden. Wir verfügen nur rudimentär über Java-Kenntnisse, wobei wir uns diese auch gerne aneignen würden, wenn diese notwendig wären. PHP, Pearl, Phyton & Co. kommen bei uns nicht in Frage.

Razor sieht einigermaßen gut aus, aber die Angst bleibt, dass MS irgendwann keine Lust mehr darauf hat und es irgendwann nicht mehr unterstützt. Angular scheint fast alles zu können, aber ich habe den Eindruck, dass dies eine Nummer zu groß für unsere Bedürfnisse ist. Vue hat mir bisher einen guten ersten Eindruck vermittelt und zu React bin ich aus zeitlichen Gründen noch nicht gekommen.

Dieser Eindruck ist aber von einem Laien auf diesem Gebiet – daher habe ich mich hier dran gehängt, um die Kommentare der Experten zu lesen.

Ich hoffe auf tolle Tipps und bedanke mich für eure Mühe und Geduld!

während die gesamte Programmlogik auf einem Server ausgeführt wird.

Da wärt ihr die ersten, die das schaffen.
UX-Elemente brauchen i.d.R. oft Logik-Wissen, daher ist es leider unvermeidlich ein gutes UX und (gewisse) doppelte Logik zu führen.
Das gleiche gilt für die Validierung von Eingaben.

Aus den Antworten hier habe ich folgende Produkte herausgepickt, wobei ich mir nicht sicher bin, welches für unsere Anforderungen das geeignete ist: Razor, Angular,React undr Vue.

PWAs bzw. SPAs sind _eigentlich _keine Data-Driven Applications, wie Du sie offensichtlich beschreibst bzw. willst - dafür sind SPAs in der Basis nicht gedacht.

Wir verfügen nur rudimentär über Java-Kenntnisse, wobei wir uns diese auch gerne aneignen würden, wenn diese notwendig wären.

Java != JavaScript.

Razor sieht einigermaßen gut aus, aber die Angst bleibt, dass MS irgendwann keine Lust mehr darauf hat und es irgendwann nicht mehr unterstützt.

🤔 🤔

Okay, und Du glaubst es gibt irgendeine Technologie, die nicht in X Jahren abgekündigt wird bzw. sich weiter entwickelt.
Okay.

Angular scheint fast alles zu können, aber ich habe den Eindruck, dass dies eine Nummer zu groß für unsere Bedürfnisse ist.

Angular ist ein vollständiges Framework.

Vue hat mir bisher einen guten ersten Eindruck vermittelt und zu React bin ich aus zeitlichen Gründen noch nicht gekommen.

Vue und React sind einfache Bibliotheken.
Beide Technologien sind keine Frameworks und decken daher auch nicht alle Aspekte einer Anwendung ab.
Das fängt schon dabei an, dass React keine Funktionelität für HTTP besitzt. Darum muss man sich komplett selbst kümmern.

(...) UX-Elemente brauchen i.d.R. oft Logik-Wissen, daher ist es leider unvermeidlich ein gutes UX und (gewisse) doppelte Logik zu führen.
Das gleiche gilt für die Validierung von Eingaben. Ja, das ist klar. Es ging weniger um Validierungen, sondern eher um die große Geschäftslogik (z. B. Buchen eines Auftrages, was u. a. Waren-, Debitor- und Sachposten verursacht). Das alles macht unser Programm heute monolitisch immer lokal am jeweiligen Arbeitsplatz. Dadurch werden zu viele Daten übers Netzwerk hin und her geschaufelt und das Programm ist zudem auf Windows genagelt.

PWAs bzw. SPAs sind _eigentlich _keine Data-Driven Applications, wie Du sie offensichtlich beschreibst bzw. willst - dafür sind SPAs in der Basis nicht gedacht. Ich glaube, ich habe mich missverständlich geäußert. Auf der Serverseite soll eine Serveranwendung die Geschäftslogik und die Datenverwaltung bzw. Datenhaltung erledigen (C# und SQL-Server, MySQL und/oder SQLBase). Ich suche eine Lösung für das Frontend, die mit unserer Serveranwendung kommuniziert.

Java != JavaScript. Auch richtig.
Okay, und Du glaubst es gibt irgendeine Technologie, die nicht in X Jahren abgekündigt wird bzw. sich weiter entwickelt. Sicher nicht, als Neuling möchte aber auf etwas setzen, was aus heutiger Sicht Bestand hat. Was in 5 oder 10 Jahren passiert, dass überlasse ich meiner Kristallkugel, die leider ziemlich schlecht funktioniert.

Angular ist ein vollständiges Framework.

(...) Vue und React sind einfache Bibliotheken.
Beide Technologien sind keine Frameworks und decken daher auch nicht alle Aspekte einer Anwendung ab.
Das fängt schon dabei an, dass React keine Funktionelität für HTTP besitzt. Darum muss man sich komplett selbst kümmern.

Das ist eine Aussage. Deswegen habe ich grob unsere Umgebung beschrieben, um besser einschätzen zu können, was für uns in Frage kommen könnte. Ich gehe davon aus, dass unsere Anforderungen nicht allzu groß sind – vielleicht reicht Vue aus. Nach Beschreibung sollte die Lernkurve flacher als bei Angular verlaufen. Wenn das aber nicht reicht, dann hilft mir die flachere Lernkurve nicht wirklich. Genau das versuche ich gerade, zu ergründen.

Dadurch werden zu viele Daten übers Netzwerk hin und her geschaufelt und das Programm ist zudem auf Windows genagelt.

Die Datenmenge senken SPAs nicht garantiert; Server-Side/Single-Page Applications mit neutralen Technologien wie HTML machen Dich aber natürlich unabhängiger vom Client - das ist durchaus im Fokus.

Sicher nicht, als Neuling möchte aber auf etwas setzen, was aus heutiger Sicht Bestand hat.

Das kann alles und nichts sein.

Wenn Du Dir aber Razer anschaust, dann basiert Razor auf einer stabilen Technologie und hat eine Umgebung im Fokus, die als die Zukunft gesehen wird.
Aussagen wie "keine Lust etwas weiter zu entwickeln" helfen Dir aber bei der Kristallkugel nicht 😃

Erstmal vielen Dank! Es ist nicht immer einfach, einen Pfaden bei für einen einer neuen Sachen zu finden.

Die Datenmenge senken SPAs nicht garantiert; Server-Side/Single-Page Applications mit neutralen Technologien wie HTML machen Dich aber natürlich unabhängiger vom Client - das ist durchaus im Fokus. Unsere Anwendung verarbeitet heute – abgesehen von wenigen Stored Procedures – alles clientseitig. Das bedeutet, dass alle zu verarbeitenden Daten zum Client transportiert werden müssen. Im LAN kein großes Problem aber übers Internet... Davon gehen wir weg. Die Clientunabhängigkeit ist ebenfalls ein zentrales Argument.

Das kann alles und nichts sein.

Wenn Du Dir aber Razer anschaust, dann basiert Razor auf einer stabilen Technologie und hat eine Umgebung im Fokus, die als die Zukunft gesehen wird.
Aussagen wie "keine Lust etwas weiter zu entwickeln" helfen Dir aber bei der Kristallkugel nicht 😃 Heißt das, dass Razor auch eine Alternative für unseren Einsatzzweck sein könnte?

Heißt das, dass Razor auch eine Alternative für unseren Einsatzzweck sein könnte?

Razor bedient die WebAssembly - und die wird durchweg als potentielle Zukunft bezeichnet.
Sie löst nicht alle Probleme heutiger JavaScript-Applikationen - aber viele.
WebAssembly bringt das Web auch u.a. zu C++ näher.

WebAssembly ist aber noch in den Kinderschuhen; wird aber bereits von allen aktuellen Browsers unterstützt.
Ob man damit schon heute eine produktive Anwendung entwickeln sollte... kommt drauf an.

Hallo und guten Morgen!

Vielen dank für den Denkanstoß! Ich habe mir Razor angeschaut und mich in WebAssembly ein wenig eingelesen. Auch Blazor habe ich nicht übersehen. Das alles lässt natürlich das Herz eines C#-Entwicklers höher schlagen, wenn auch heute nicht ganz sicher ist, wie und in welche Richtung sich das alles entwickelt.

Wir haben eine lange Durststrecke vor uns – wir müssen in den nächsten Jahren Schritt für Schritt eine über 20 Jahre alte Anwendung komplett umschreiben, diese aber gleichzeitig parallel zur Neuentwicklung am Leben halten. Da es sich hierbei um ein langjähriges Projekt handelt, will man natürlich auf beständigen Technologien setzen. ASP.NET Core, Razor, WebAssembly, Blazor usw. machen Lust, keine Frage! Und wenn diese Technologie sich durchsetzt, wären wir einigermaßen vorne dabei. Schwierige Entscheidung...

Meine anfängliche Abneigung bezüglich Microsoft, was dieses Thema angeht, ist historisch bedingt. Hier nur ein Beispiel: Wir begannen vor vielen Jahren einige Anwendungen zu entwickeln, die auf Windows Forms basierten. Dann hieß es, keine wirkliche Zukunft mehr, ihr müsst auf WPF umsteigen. Haben wir brav gemacht. Fürs Internet sollte damals Silverlight herhalten. Dann hieß es UWP. Große Aufregung! Und jetzt soll .NET Core 3.0 WPF und Windows Forms mit sogar Einbindung von UWP-Elementen unterstützen. Das alles ganz von Windows Mobile abgesehen... Das kann schon mürbe machen.

Wenn sich das so zugetragen hat, dann würde ich Dir da aber schon auch die Mitschuld geben.
Bei neuen Technologien liegt die Pflicht der Evaluierung für die eigenen Geschäft nicht bei Microsoft, sondern bei Dir.

Und alle von Dir aufgezählten Technologien hatten ihre Daseinsberechtigung - entwickeln sich aber weiter oder werden abgelöst.
Willkommen in der Welt der Software. 👍

Wenn ihr nun im Ernst die Erwartung habt eine Technologie zu finden, die wieder 20 Jahre bleibt, dann würde ich an eurer Stelle keine Migration starten...

Na tja, wir sind etwas offtopic geraten 😃 In den Anfängen von .NET gab es nicht viele Alternativen. C++ und Qt standen damals zur Diskussion bei uns – das wäre sicher auch eine sehr gute Alternative gewesen; aber rückblickend ist es immer einfacher...

Wir werden ASP.NET Core, Razor usw. evaluieren. Wenn es sich nach einem halben oder einem Jahr herausstellt, dass dies nicht der Bringer war, machen wir einen Rückzieher. Wir versuchen auf jeden Fall so viel Code wie möglich, serverseitig so zu implementieren, dass bei einem möglichen Umsatteln auf eine andere Technologie wie z. B. Angular oder Vue, die Schmerzen sich in Grenzen halten. Die Hoffnung ist aber die, dass dies nicht notwendig sein wird.

Nochmals vielen Dank!

Coder007, kann ich nachvollziehen. Allerdings können wir das Rad der Zeit nicht mehr zurückdrehen. Hoffen wir, dass unsere Entscheidung die richtige ist.