Projektbasiertes Web-Framework

[Kokujou]

Hallo ihr lieben... ich suche jetzt schon ne halbe Ewigkeit im Netz. Ich will mit einem neuen Webframework anfangen und... ich sehe ehrlich gesagt schwarz.

Was ich brauche ist etwas schönes und einfaches. Ich will nicht dass irgendwelche Settings files quer verstreut über das ganze Projekt liegen die ich jedes mal manuell ändern muss wenn ich was hinzufüge oder umbenenne oder lösche. Schön wäre etwas wie Blazor nur weniger unbrauchbar (siehe unten).

Ich sage "projektbasiert" weil z.B. in einem C# Projekt existiert ein Einstellungs-File, die csproj. Und es ist völlig egal ob du was umbenennst oder schiebst, entweder erkennt und löst er das sofort selbst oder er zeigt dir nen Fehler an und wenn du drüber hoverst kannst du es dir fixen lassen.

Ich hab mal ein paar negativ-Beispiele aufgelistet die mich in den letzten Monaten in den Wahnsinn getrieben haben. Ich wollte einfach mal die Chance nutzen und fragen, ob irgendjemand vielleicht mal ein anständiges Web-Framework kennt, oder vielleicht eines der unten genannten in einer brauchbaren Form aufsetzen konnte und die negativen Eigenschaften die ich gleich beschreibe wegbekommen hat. Obwohl ich es stark bezweifle... wär schön wenn mir jemand helfen könnte

Was ich schon hatte:

Angular: Ein riesiges Framework wo du eine dependency injection und ein haufen third party module hast die dir random dein ganzes Projekt zerschießen und nicht mal gelernte Angularists wissen was da los ist. Du hast ein haufen Index und Settings files verstreut über das ganze Projekt die das Verändern der Projektstruktur so unflexibel machen dass du nen Tag der Forschung braucht nur um eine einzige Sache umzubenennen.

WebComponents: Quasi sowas wie Angular lite. Hier hast du nicht diese schreckliche dependency injection aber hast dafür das einzige rausgeschmissen was ich gut finde und das war die High-Level Componente mit Classen und template-html und so weiter. Zumindest so wie wir es aktuell machen...

Blazor: Die Existenzberechtigung dieses Frameworks erschließt sich mir nicht. Hier schreibt man Backend Code um ein Frontend zu rendern. Quasi ein High-Level wrapping für PHP. grundsätzlich geil, aber dass man wegen allem was über den Standard hinaus geht ein Javascript Interop braucht und die ganze App zusammenbricht wenn man ein await in der Razor Site machen will oder ein .Result auf einem Task aufruft disqualifiziert es als Framework.

 

[Toms]

Angular: Ein riesiges Framework wo du eine dependency injection und ein haufen third party module hast die dir random dein ganzes Projekt zerschießen und nicht mal gelernte Angularists wissen was da los ist. Du hast ein haufen Index und Settings files verstreut über das ganze Projekt die das Verändern der Projektstruktur so unflexibel machen dass du nen Tag der Forschung braucht nur um eine einzige Sache umzubenennen.

Das zeigt mir, dass du dich überhaupt nicht tiefergehend mit der Bibliothek beschäftigt hast und wie es aufgebaut ist.

Bei Angular hast du ein (oder mehrere, je nachdem wie modular du das ganze gestalten möchtest) Module, wo alle in dem Module genutzten Components und Services gesammelt importiert werden. Erst dann kannst du beispielsweise die Services in den Components injecten. Was an Dependency-Injection jetzt schlecht sein soll, musst du mir nochmal erklären.

 

[pcBauer]

Hey,

Als "Angularist" kann ich deinen Schmerz verstehen, ich habe da so eine Hassliebe entwickelt zu Angular (und hatte auch vorher schon mit AngularJS zu tun, die Migration bringt einem fast den Burnout..)
Dependency Injection find ich jetzt nicht dramatisch und Umbenennungen kann ne gute IDE trotzdem lösen (auch VS Code mit "Glück" und etwas Geduld, aber ja, das funktioniert in der C#-Welt besser).
Es ist klumpig und man kann sich schnell so viele 3rd party packages reinziehen, dass sie leicht (v.A. Updates) dein Projekt zerschießen, hat man ein kleines Projekt sollten aber auch nicht so viele Abhängigkeiten anfallen, und selbst mit vielen Abhängigkeiten wie bei uns gehen die Updates immer schneller und problemfreier durch.
Ich würde es auf die Lernkurve schieben, je länger man sich mit Angular auskennt, umso mehr weiß man, welcher Fehler wie zu lösen ist, bzw wo der Fehler entspringt.
Aber das ist durchaus auch die Schuld von Angular natürlich, wie erwähnt Komplexität / Lernkurve.

WebComponents alleine konnten mich auch noch nicht überzeugen, da das Gesamtheitliche (wie bei Angular, Router z.B.) fehlt.
Wenn du allerdings nicht weit weg davon willst, solltest du dir Mal Ionic anschauen, früher ein Aufsatz auf Angular, mittlerweile mit eigenem Framework / Compiler namens Stencil, das Web Components erzeugen kann.
Ein Freund von mir (der mein Angular Guru ist ) ist da sehr begeistert von.
Ist aber an Angular angelehnt und wohl auch nicht suuper einfach wie andere Frameworks wie React oder Vue.

Ansonsten wäre in Sachen Einfachheit und Funktionalität dann eben noch Vue weit vorn, habe ich mich noch nicht mit beschäftigt, aber soll ja leichtgewichtig wie React sein aber noch einfacher / intuitiver.
Denke das wäre der beste Ansatzpunkt für dich.

Das mit dem Umbenennen von Dateien / Ändern der Struktur wird aber mehr von der IDE abhängen als vom Framework, so am Rande.

Viel Erfolg

 

[kachiri]

So wie Angular funktioniert fast jedes modernes Framework. Du holst dir die Module, injectest sie, konfigurierst sie aber letztlich in deinem eigenen Projekt und eigentlich nicht über die Modul-Standardkonfigs.
Das Problem bei der Modularität ist halt die Komplexität, umso mehr Module man verwendet. Gerade wenn quasi sämtliche Module von jeweils anderen Entwicklern kommen. Letztlich prüft ja, bevor man eine aktuelle Modulversion nutzt, ob die Dependencies noch passen oder im eigenen Projekt vorher auch was angepasst werden muss.

 

[dasbene]

Wie viele Einstellungs Datein es gibt ist eigentlich irrelevant solange die alle leicht auffindbar sind. Bei den meisten JS Frameworks(Angular, React, Vue.js) baut man sich im regelfall seine eigene Toolchain auf und die Konfikurationsdatein sind halt für die einzelnen Komponenten(Compiler/Transpiler, Linter usw.) und die liegen im basis verzeichnis des "projekts".

Bei C# Projekten kommt halt alles mit quasi einer festen Toolchain von Microsoft, da hat man bei den JS Frameworks mehr freiheit. Zum Thema Blazor und Server Side Rendering (SSR), das hat auch seine Existensberechtigung. Ich würde glatt sagen, dass der großteil der Websites SSR verwendet. Persöhnlich bin ich aber trotzdem von Single Page Applications (SPA) ein Fan. Seit der neuesten version von Blazor mit WebAssembly soll das da auch gehen.

Ich weiß nicht genau wie es bei Angular aussieht aber bei React und Vue.js gibt es durchaus "Hilfsframeworks" welche die Konfiguration vereinfachen. Für React kann man sich react-scripts oder next.js(habe ich noch nicht ausprobiert) und bei Vue.js Nuxt.js anschauen.

Meine persöhnliche Erfahrungen waren mit Vue + Nuxt am besten obwohl ich vorher quasi nie mit frontend technologien gearbeitet habe.
Wenn man im laufe der Zeit dann mehr erfahrung sammelt mit dem Framework und den einzelnen Komponenten, dann versteht man den zusammenhang auch besser und kann dann eine vohandene Toolchain anpassen oder nach den eigenen Vorstellungen neu aufbauen.

 

[Hooo]

Ich bin mir nicht sicher was du am Ende des Tages brauchst / was dich glücklich macht.

Meine Empfehlung wäre Next.js (basiert auf React) mit Typescript.
Nicht allzu viel Konfiguration und man kommt recht weit ohne zusätzliche Bibliotheken.

Aber ich würde tatsächlich empfehlen, schau dir die Empfehlungen hier alle einfach mal an.
Und als Empfehlung würde ich dir die Verwendung von Typescript ans Herz legen, unabhängig vom Framework (wenn unterstützt / gut integriert).

 

[BeBur]

Ruby on Rails baut auf das Prinzip "Convention over Configuration" auf, d.h. erst einmal müssen in erster Linie Abweichungen von der Norm konfiguriert werden. Ein einzelnes Config-Files bietet RoR jedenfalls nicht.
Pro Tipp: Alle Web-Frameworks sind eine Qual in der Einarbeitung. Deal with it. Grund: Große bekannte Frameworks werden groß und bekannt weil sie für kleine bis riesige Projekte geeignet sind und dementsprechend ein professionelles und ausgiebiges Framework zur Verfügung stellen müssen.
Die Alternative sind Frameworks mit denen du wirklich nur Kleinigkeiten bauen kannst. Ich kenne jedenfalls keins.

 

[Kokujou]

Das zeigt mir, dass du dich überhaupt nicht tiefergehend mit der Bibliothek beschäftigt hast und wie es aufgebaut ist.

Bei Angular hast du ein (oder mehrere, je nachdem wie modular du das ganze gestalten möchtest) Module, wo alle in dem Module genutzten Components und Services gesammelt importiert werden. Erst dann kannst du beispielsweise die Services in den Components injecten. Was an Dependency-Injection jetzt schlecht sein soll, musst du mir nochmal erklären.

wir haben viel mit unterprojekten gearbeitet, bibliotheken und so und da hatte natürlich jedes seine eigene dependency injection... und um ein Beispiel zu nennen obwohl wir die dependency injection mehrfach geprüft haben sind übersetzungen und die kommuniktation zwischen die komponenten irgendwann komplett zusammengebrochen und keiner hatte mehr richtig ne übersicht.

Und du hast nicht nur ein File. Du hast ne Angular json, du hast package.json du hast index.ts und spec.ts und lint und was nicht alles. das ist einfach viel zu viel. und nur eine änderung und dir bricht alles zusammen. Und dann ist es nicht nur eine datei sondern auch noch x verschiedene orte in der selben datei... es ist einfach ein massiver overhead und dinge die du manuell machen musst, was ich schrecklich finde.

Wie viele Einstellungs Datein es gibt ist eigentlich irrelevant solange die alle leicht auffindbar sind. Bei den meisten JS Frameworks(Angular, React, Vue.js) baut man sich im regelfall seine eigene Toolchain auf und die Konfikurationsdatein sind halt für die einzelnen Komponenten(Compiler/Transpiler, Linter usw.) und die liegen im basis verzeichnis des "projekts".

des projekts und der 5 unterprojekte. und die werden dann nicht automatisch von der IDE gefunden, glaubt mir, ich habs versucht. ich hab mal veruscht einfach nur den SRC folder zu löschen und alles eine ebene abzuflachen, ich bin fast wahnsinnig geworden weil ich in diese bestimmt 20 config files alle einzeln reingegangen bin und dort nach dem projektnamen und den verweisen gesucht hab... zwishcenzeitlich hatten wir noch so ein krankes file, ich glaub es war die test.ts oder so, da war die Reihenfolge der Imports wichtig, die prettier natürlich sofort beim speichern zerschossen hat... stunden meines lebens die ich nicht zurückkriege >.<

Bei C# Projekten kommt halt alles mit quasi einer festen Toolchain von Microsoft, da hat man bei den JS Frameworks mehr freiheit. Zum Thema Blazor und Server Side Rendering (SSR), das hat auch seine Existensberechtigung. Ich würde glatt sagen, dass der großteil der Websites SSR verwendet. Persöhnlich bin ich aber trotzdem von Single Page Applications (SPA) ein Fan. Seit der neuesten version von Blazor mit WebAssembly soll das da auch gehen.

das problem ist nicht die Tatsache dass es auf dem Server läuft das ist mir total wurst. das Problem ist dass alles was client seitig ist ein Typescript interop versucht. Beispiel: Cookies. Es ist nicht machbar das über C# zu lösen. Ich wollte z.B. ne Übersetzung mit Cookies einbauen. Du speicherst die Sprache in nem cookie und updatest sie. Problem: Wie willst du die Änderung mitkriegen? Erstmal ein Javascript interop zum lesen und schreiben und dann muss die Translate funktion asynchron sein. Warum? Javascript interops sind asynchron. Und weiß der Geier warum, ich habs bis heute nicht verstanden, sobald du asynchrone Funktionen in dem HTML template aufrufst bricht dir alles zusammen. await geht ja gar nicht und .Result friert deine ganze Application ein.

Ich hab auch kein Problem damit wenn ich in der Konfiguration keine Freiheiten habe. Ich meine ich habe niemals irgendwas von dem Angular Settings gebraucht. Das meiste gibt eh nur an wo die Files liegen was, wie ich finde, kompletter unsinn ist! in C# gibts eine csproj wo alles drinne steht. Alles andere funktioniert über den Code selbst. ich hab auch noch nie gesehen dass ich in C# angeben musste wo meine unit tests sind. Der erkennt dass da ein Fact drüber steht und schiebt sie in den Test Explorer. Alles kein Problem. Und was die tslint files soollen weiß ich auch nicht... und nj.json..

für mich gilt: sobald da irgendwo eine datei ist die man händisch anpassen muss hat das Framework versagt. Ihr könnt euch ja selbst mal nen spaß machen und ein unterProjekt erstellen und es dann mal umbenennen oder so. Angular und Konsorten gehen da auf der Stelle drauf und keine IDE ist schlau genug zu erkennen was da passiert.

ich würde es lieben mit Blazor zu Arbeiten wenn da nicht diese kleine Unstimmigkeit mit den Interops wäre. Wenn sie einfach client seitig laufen und das Javascript zu C# umkompilieren würden wäre ich völlig zufrieden.

Übrigens hab ich absolut nichts gegen Typescript das ist sogar relativ einfach in C# zu konvertieren wenn ihr mich fragt, ich hab das mal für ein Frontend gemacht. Das meiste geht über Regex, kA warums da noch kein Online-Tool gibt. Das würde wirklich mehr als ausreichen.

 

[Toms]

Und du hast nicht nur ein File. Du hast ne Angular json, du hast package.json du hast index.ts und spec.ts und lint und was nicht alles. das ist einfach viel zu viel. und nur eine änderung und dir bricht alles zusammen. Und dann ist es nicht nur eine datei sondern auch noch x verschiedene orte in der selben datei... es ist einfach ein massiver overhead und dinge die du manuell machen musst, was ich schrecklich finde.

Willkommen in der Webentwicklung.

btw haben all diese Dateien ihre eigene Aufgabe. package.json hast du bei allen Projekten in denen du mit yarn oder npm Paketmanager arbeitest. Da kommen schlicht die Dependencies rein. Angular.json hält die allgemeine Konfiguration deines Angular-Projektes. In anderen Webframeworks hast du da analog ebenfalls config-Dateien. index.ts, spec.ts halten halt Quellcode bzw. Test-Code. Man muss sich halt mal damit auseinandersetzen, was was ist. Aber das hast du in jeder dir unbekannten Programmiersprache / in jedem dir unbekannten Framework.

Das meiste geht über Regex, kA warums da noch kein Online-Tool gibt. Das würde wirklich mehr als ausreichen.

Weil TypeScript ein strenges Superset von JavaScript ist. Dadurch ist jeder valide JavaScript-Code auch valides TypeScript und du kannst JS/TS nicht stumpf in C# umwandeln. Alleine schon weil es unterschiedliche Ansätze bezüglich der Typisierung sind (bei JavaScript die komplette Abwesenheit von Typisierung)

 

[Dalek]

Suchst du ein klassisches Webframework das HTML auf dem Server rendert, oder ein Framework um eine SPA zu bauen?

Das mit dem Dateien beliebig rumschieben findet man im Javascript Bereich eher nicht, die Imports sind and die Dateistruktur gebunden. Dabei kann aber deine IDE/Editor durchaus helfen.

Die modernen JS Frameworks für SPAs sind halt einfach eine Sammlung von Tools generell, diese Komplexität wird man da nicht so einfach los. Das hält sich aber in Grenzen wenn man z.B. sowas wie Create React App verwendet das die unterliegenden Tools wie Webpack und Babel für einen verwaltet. Dann gibt es viel weniger einzustellen, man bekommt mehr oder weniger eine Standardkonfiguration vorgesetzt.

 

[Kokujou]

Weil TypeScript ein strenges Superset von JavaScript ist. Dadurch ist jeder valide JavaScript-Code auch valides TypeScript und du kannst JS/TS nicht stumpf in C# umwandeln. Alleine schon weil es unterschiedliche Ansätze bezüglich der Typisierung sind (bei JavaScript die komplette Abwesenheit von Typisierung)

das ist mir durchaus klar. Aber warum eigentlich? jedes Backend hat die nämlich ebenfalls in der csproj drin. und dann diese schrecklichen defaults...größer als? nuget gibt dir by default zumindest immer die fixen versionen damit du dir eben nicht ausversehen dein Projekt zerschießt. so wie es bei uns passiert ist...

du kannst JS/TS nicht stumpf in C# umwandeln.

für alles was komplexer ist stimmt das natürlich... aber ich habs für mein gesamtes projekt mal durch exerziert und für das meiste reichte wirklich die basis. ich meine im frontend soll doch kein komplexes library-intensives zeug laufen. wir wissen dass system.collection sich einfahc auf arrays Mappen lassen, das reicht doch aus um sämtliche datenstrukturen anständig zu mocken. inzwischen hat c# sogar anonyme klassen, fast wie in typescript. klar, alles was auf irgendne Library hin deutet ist dann kaputt aber es muss ja nicht perfekt sein

Suchst du ein klassisches Webframework das HTML auf dem Server rendert, oder ein Framework um eine SPA zu bauen?

ist mir eigentlich wurst. mir ist nur wichtig dass es funktioniert und einfach zu bedienen ist. ich hab kein Problem mit Server-Side-Rendering, ist ja populär. mir geht es bei Blazor z.B. wirklich nur um den Code-level. Frage "Wozu benutze ich blazor wenn ich dann doch überall javascript interops habe?", nur darum gehts mir. wäre z.B. das Cookie Handling nativ drinne und könnte ich asynchrone calls in die HTML-templates reinschreiben würde ich sofort mit Freude migrieren.

Das mit dem Dateien beliebig rumschieben findet man im Javascript Bereich eher nicht, die Imports sind and die Dateistruktur gebunden. Dabei kann aber deine IDE/Editor durchaus helfen.

das hab ich leider auch schon mitgekriegt. darum, vielleicht gibts ja welche die nicht javascript basiert sind. balzor ist ja schon ein guter anfang, nur jetzt bitte in funktionierend >.<
und leider können die IDEs zumindest meine IDEs da nicht oder nur sehr begrenzt helfen. VSCode z.B. hat total versagt... und in visual studio ... da läuft mir direkt ein kalter Schauer über den Rücken.

ich versteh nichtmal warum man so viel angeben und dann noch explizit überall exporten muss... veröffentlichst du ein nuget paket dann ist jede öffentliche funktion erstmal exported und kann unproblematisch verwendet werden.
hier musst du erst ein export an die funktion kleben, dann am besten nochmal im javascript explizit export {...} from '...' aufrufen und dann am besten noch n import fürs bundling... was soll das? einmal compiler drüberlaufen lassen, sehen die funktion ist exported oder public oder weiß der Geier und dann kann man sie von überall benutzen. Ist doch kein ding oder?

 

[Dalek]

ist mir eigentlich wurst. mir ist nur wichtig dass es funktioniert und einfach zu bedienen ist. ich hab kein Problem mit Server-Side-Rendering, ist ja populär. mir geht es bei Blazor z.B. wirklich nur um den Code-level. Frage "Wozu benutze ich blazor wenn ich dann doch überall javascript interops habe?", nur darum gehts mir. wäre z.B. das Cookie Handling nativ drinne und könnte ich asynchrone calls in die HTML-templates reinschreiben würde ich sofort mit Freude migrieren.

Blazor ist nicht wirklich reines Server-side rendering, wobei das auch wieder mehrere Varianten hat soweit ich das mitbekommen habe. Es kann per WASM komplett im Browser laufen, oder auf dem Server und redet mit dem Client über Websockets. Aber Blazor ist wirklich Bleeding Edge Technologie, das ist ganz neu und etwas bei dem ich persönlich noch sehr vorsichtig wäre.

Das klassische Equivalent wäre C# mit Razor pages. Das ist dann komplett Serverseitig. Alles was interaktiv sein sollte muss dann natürlich separate in Javascript entwickelt werden. Aber falls du keine besonders interaktiven Sachen machen willst, ist das evtl. am ehesten etwas das deinen Anforderungen entspricht, insbesondere da du C# ja schon zu kennen scheinst.

 

[KitKat::new()]

Das hält sich aber in Grenzen wenn man z.B. sowas wie Create React App verwendet das die unterliegenden Tools wie Webpack und Babel für einen verwaltet. Dann gibt es viel weniger einzustellen, man bekommt mehr oder weniger eine Standardkonfiguration vorgesetzt.

Hat ja Angular schon dabei. Daher wird das wohl nicht das Problem gewesen sein.

Ich wollte einfach mal die Chance nutzen und fragen, ob irgendjemand vielleicht mal ein anständiges Web-Framework kennt,

Imho ist Angular ein anständiges Webframework, dir fehlen jedoch die Skills damit umzugehen.

Dependency Management, Dependency Injection, Dateien verschieben und config-Dateien konfigurieren sind die trivialsten Dinge.
Und über eine Softwarearchitektur sollte man sich allgemein einfach Gedanken machen, dann passiert es auch nicht, dass du einen haufen index und settings-Dateien übers ganze Projekt verstreut hast, deine Projektstruktur nicht mehr ändern kannst oder

übersetzungen und die kommuniktation zwischen die komponenten irgendwann komplett zusammengebrochen und keiner hatte mehr richtig ne übersicht.

Angular ist vielleicht viel, aber dafür liefert es dir eigentlich fast alles auf dem Silbertablet.
Wenn du dich nicht um eine vernünftige Architektur/Organisation kümmerst, fliegt dir das Projekt so oder so ab einer bestimmten Größe um die Ohren.

 

[Kokujou]

Blazor ist nicht wirklich reines Server-side rendering, wobei das auch wieder mehrere Varianten hat soweit ich das mitbekommen habe. Es kann per WASM komplett im Browser laufen, oder auf dem Server und redet mit dem Client über Websockets. Aber Blazor ist wirklich Bleeding Edge Technologie, das ist ganz neu und etwas bei dem ich persönlich noch sehr vorsichtig wäre.

Das klassische Equivalent wäre C# mit Razor pages. Das ist dann komplett Serverseitig. Alles was interaktiv sein sollte muss dann natürlich separate in Javascript entwickelt werden. Aber falls du keine besonders interaktiven Sachen machen willst, ist das evtl. am ehesten etwas das deinen Anforderungen entspricht, insbesondere da du C# ja schon zu kennen scheinst.

ja das weiß ich ... leider der aufbau von blazor und razor sind gut... unser projekt ist leider sehr interaktiv. wie gesagt. cookies... und einige andere spielereien die mir gerade nicht einfallen wo ich stunden verbracht hab um sie zum laufen zu bringen... naja.

Ich glaube gerne dass Angular super toll ist wenn man mal zeit hat 3 Jahre ne Schulung zu machen und zugang zu gelehrten Experten hat. Das habe ich aber leider nicht. Angular ist ganz offensichtlich nichts was man nicht mal schnell aneignet und wenn bei jeder kleinigkeit gleich ne 1 jahres schulung erforderlich ist, dann tuts mir leid aber dann ist das einfach nicht gut.

ich glaube gerne dass es alles bietet was man braucht, aber ein silbertablett ist wenn eine IDE damit umgehen kann ohne ass man irgendetwas händisch machen muss. wenn ich entwickle dann will ich mir nicht sorgen über irgendwelche krankhaften projektkonfigurationen machen müssen. Ich will mir auch keine Sorgen machen dass irgendeine Third Party Library meine Übersetzungen versaut, darüber dass wir mal unsere Projektstruktur ändern, verbessern oder sonstewas.

 

[BeBur]

Du fällst auf die ganz klassischen Fehler rein, die da wären:
"Neu schreiben in Sprache X ist ganz leicht [und würde uns ganz viel Arbeit sparen]" und "Framework X ist viel besser [und würde uns ganz viel Arbeit sparen]".

 

[Toms]

Ich glaube gerne dass Angular super toll ist wenn man mal zeit hat 3 Jahre ne Schulung zu machen und zugang zu gelehrten Experten hat. Das habe ich aber leider nicht. Angular ist ganz offensichtlich nichts was man nicht mal schnell aneignet und wenn bei jeder kleinigkeit gleich ne 1 jahres schulung erforderlich ist, dann tuts mir leid aber dann ist das einfach nicht gut.

Wir haben seit August eine Neuentwicklung in Angular und zwei von vier Teammitgliedern haben vorher noch nie mit JavaScript entwickelt geschweige denn nennenswerte Weberfahrung. Dennoch kommt das Projekt voran und an die ganzen quirks der Webentwicklung gewöhnt man sich recht schnell. Man sollte nur nicht versuchen, Projektstrukturen aus ganz anderen Programmiersprachen / Frameworks auf neue Frameworks und Programmiersprachen anzuwenden.

Angular hat diese und jene Struktur. Das ist ist, da kannst du nicht viel dran ändern.

ReactJS hat eine andere Struktur, die dir vielleicht besser passt. Aber auch an der kannst du nicht viel dran ändern.

Was du willst, ist deine althergebrachte C#-Projektstruktur auf Webprojekte umzumünzen, die anders gewachsen sind und eine ganz andere Toolchain als .NET haben. Aber hey, do your thing.

 

[Kokujou]

Was du willst, ist deine althergebrachte C#-Projektstruktur auf Webprojekte umzumünzen, die anders gewachsen sind und eine ganz andere Toolchain als .NET haben. Aber hey, do your thing.

ja das wär toll, bitte ^-^

ich hab nichtmal ne feste projektstruktur. aber wenn ich manchmal so sehe, da haben wir nen lib ordner und in dem lib orgner ist ein src ordner und so weiter, ich will einfach klare und nachvollziehbare und vor allem flache projekthirarchien wie man es problemlos in C# hinkriegt.

ich will eine Komponente die besteht aus View (Html), Style (Css) und Funktionalität (JS, C#, TS, ...)

in Blazor brauchte man dafür nichtmal ordner. Indem man dort nämlich denselben anfang gibt gruppieren sich die elemente automatisch. was cool ist.

unsere webcomponent hirarchie ist jetzt auch relativ klein und wenn du jetzt noch die 5 json files im projekt root in eine kombinierst dann wäre ich mit dem framework was das abbelangt sogar halbwegs glücklich

 

[KitKat::new()]

ich will eine Komponente die besteht aus View (Html), Style (Css) und Funktionalität (JS, C#, TS, ...)

ng generate component componentName bzw. ng g c componentName gibt dir genau das.

in Blazor brauchte man dafür nichtmal ordner.

Und mit Angular ebenso wenig. Du brauchst nichtmal eine separate Datei:

@Component({
  selector: 'app-root',
  template: `
    <h1>Tour of Heroes</h1>
  `,
  styles: ['h1 { font-weight: normal; }']
})
export class HeroAppComponent {
/* . . . */
}

 

[Kokujou]

vielleicht frage ich einfach mal etwas spezifischer und in eine bestimmte RIchtung:

kennt irgendjemand vielleicht noch andere C#-Basierte Frameworks außer Razor/Blazor/Asp .NET?

Ergänzung (27. November 2020)

mir gehts eigentlich nicht so sehr um die programmiersprache sondern einfach nur damit dass ich es mit visual studio als xxproj datei ausführen kann und somit alle projektinformationen da drin sind und mit dem rest kann ich dann machen was immer ich will. und wenn ich eine komponente in eine 8-Ebenen Tiefe Ordnerstruktur verfrachten will kann ich auch das tun und das nur mit einem simplen Mausziehen. Utopisch oder?

 

[Bagbag]

Du willst ganz offenbar Razor oder wenn Blazor weiter gereift ist wohl das. Warum nimmst du dann nicht genau das?

Du bist wie jemand, der weg von Windows will, dann Linux testet, merkt das es nicht wie Windows ist und deshalb sagt Linux ist scheisse. Was die Person will ist eben Windows und nicht Linux.

In meiner Firma sind alle neuen Webprojekte in Angular (wenige Ausnahmen Blazor). Selbst die Azubis kommen nach ein wenig Einarbeitung mit Angular klar.

Ich behaupte einfach mal ganz frech, dass hier das Problem vor dem Bildschirm sitzt. Wäre das alles so schlecht wie es sich bei dir anhört, wäre Angular nicht so groß geworden.