Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Discussion: Was ist das beste Framework für Web-Entwicklung?
Ich hab mir jetzt mal 3 "Frameworks" angesehen wenn man das so nennen darf. Anlässlich meiner Arbeit.
1. AngularJS mit TypeScript
2. VanillaJS
3. Blazor.
Und irgendwie haben die alle mehr Probleme als Lösungen... und da frag ich mich natürlich... spinne ich oder sind's die anderen?
Ich würde gerne von euch wissen, was ihr so benutzt, was ihr kennt und ob ihr etwas kennt dass größtenteils problemlos funktioniert.
Fangen wir mal kategorisch an.
1.: Auf Angular möchte ich gar nicht so sehr eingehen, sondern eher auf TypeScript.
Es erfordert einen Build Vorgang
Statt es zu kompilieren wird es nur in JavaScript umgeschrieben und sieht danach einfach schrecklich aus
Man kann es gar nicht richtig debuggen, weil TypeScript nicht nativ im Browser unterstützt wird
es verwendet nichtmal die neuste ECMA Version
Ich verstehe ehrlich gesagt nicht wie nach den Jahren in denen TypeScript existiert, es noch nicht nativ im Browser als neue Script-Sprache gilt.
2.: JavaScript
Es ist nicht objektorientiert
So ziemlich alle populären Bibliotheken sind nur in TypeScript verfügbar und haben nichtmal mehr einen JavaScript port
Viele native Funktionen liefern zwar Typen zurück, die sind aber oft sogar falsch, da die Sprache ja eigentlich keine Typen hat
Kurz: Der Browser will zwar das wir es nutzen aber die Sprache selbst ist im Grunde tot.
3.: Blazor
So ziemlich alles was nah am Browser ist benötigt nach wie vor einen JS-Interop, was den eigentlichen Grund dieses Frameworks negiert.
Erzeugt entsprechend natürlich einen gewaltigen Overhead
Klingt nach wenig, ist dafür aber umso gravierender, denn statt 3 Sprachen, HTML, CSS und JS, hat man jetzt gleich 4, da fragt man sich natürlich wozu dann überhaupt Blazor, wenn es alles sowieso nur komplziierter macht.
Und jetzt zu euch, wie seht ihr diese Punkte? Meint ihr ich reagiere über? Oder haltet ihr das auch für ziemlich penetrante Mangel-Faktoren?
Braucht dein JavaScript auch, wenn du es für Browser ausliefern willst. Jedes große JS Framework hat irgendeine Art von Compiler dabei, und sei es nur Webpack.
Kokujou schrieb:
Statt es zu kompilieren wird es nur in JavaScript umgeschrieben und sieht danach einfach schrecklich aus
Den sollst du dir ja auch nicht anschauen. Wenn ich C kompiliere, schaue ich mir danach auch nicht den generierten Assembler Code an. Wenn du debuggen willst in TypeScript, gibt es SourceMaps. Dasselbe Problem hast du überigens auch mit fast allen anderen JS Web Frameworks, wie z.B. React, dank JSX.
Kokujou schrieb:
Man kann es gar nicht richtig debuggen, weil TypeScript nicht nativ im Browser unterstützt wird
Es ist eher das Gegenteil der Fall. Es sind meist reine JS Bibliotheken mit externen TypeScript Definitions. So oder so kann man beides in beiden Sprachen benutzen.
Kokujou schrieb:
Viele native Funktionen liefern zwar Typen zurück, die sind aber oft sogar falsch
Ich würde niemals behaupten, dass JavaScript eine vollends durchdachte Sprache ist. Aber alle Browser und Node.js und co. folgen demselben Standard. Es ist gut dokumentiert welche Funktion was wann zurückgeben. Oder was ist da "falsch"?
Kokujou schrieb:
So ziemlich alles was nah am Browser ist benötigt nach wie vor einen JS-Interop, was den eigentlichen Grund dieses Frameworks negiert.
Erzeugt entsprechend natürlich einen gewaltigen Overhead
Wieso ist das ein Grund gegen das Framework? Das ist doch gerade der Grund, warum es dieses Framework gibt.
Und Overhead hast du überall in irgendeiner Form. Dafür spart man dann wieder an anderer Stelle, indem sich bestimmte Sachen einfacher umsetzen lassen.
Das mit dem du am besten umgehen kannst. Ein bestes gibt es nicht. Jedes hat Stärken und Schwächen. Hier müsstest du erstmal definieren was dir wichtig ist. Geht gefühlt beim Pattern schon los. Dann geht es mit Kenntnissen in der Firma etc. Weiter. Nur weil du jetzt z.B. Angular als total genial ansiehst, wäre es sinnlos wenn 30 React Leute jetzt umgeschult werden müssten.
Ich Nutz z.B. privat das gleiche wie beruflich, weil ich einfach nicht die Zeit in unnötige Recherche reinstecken möchte. Ich kenn also meine Fallstricke und profitiere aus beiden Welten.
Du kannst auch eine Low Code Umgebung wählen, wenn dir das zu komplex ist. Dann kümmert sich der Anbieter darum dass es läuft. Zumindest die professionellen Tools bieten mittlerweile sehr viele Möglichkeiten.
Im Grunde seh ich persönlich keinen Diskussionsbedarf, weil du sprichst über 2 Welten. Blazor (SSR) und JS (TS) (CSR). TS ist nur ein Aufsatz der das ganze eleganter für die Entwickler macht.
Und warum es immer neue Frameworks gibt, jemand hat sich gedacht das können wir besser oder anders implementiert ist es besser … Tadaa ein neues Framework. Man muss auch nicht permanent den neusten Trends hinterherrennen, eine solide Basis mit der alle arbeiten können ist sehr viel mehr wert.
Braucht dein JavaScript auch, wenn du es für Browser ausliefern willst. Jedes große JS Framework hat irgendeine Art von Compiler dabei, und sei es nur Webpack.
nein. Ich hab mir wegen dme Feedback meiner Entwicklerkollegen ein Framework zusammengebaut das nur mit vanilla javascript funktioniert. kein Build Prozess einfach nur ausführen und fertig. Im Release bundlen wir höchstens noch aber das hat nur was mit dem Caching zutun und behindert die entwicklerarbeit nicht.
M4ttX schrieb:
Debuggen geht auch, sonst wärs wohl komisch, dass Typescript mit Typing oft genutzt wird
also das letzte mal als ich mit vscode was debuggen wollte musste ich meinen firefox mit command line argumenten starten und in der about:config irgendwelche sicherheitssettings ändern sodass mein Address_zeile seitdem so aussieht:
das ist im Fall von VanillaJS debugging. meinst du es geht besser mit TypeScript?
benneq schrieb:
Du kannst in JavaScript genau so objektorientiert arbeiten wie in TypeScript. Oder was fehlt dir da?
Sehr viel leider Gottes. Allein was ich anstellen musste um überhaupt Typen da reinzukriegen grenzt an schwarze Magie. Mittels JSDoc Kommentaren konnte ich das so ein bischen emulieren, aber es gibt eben sehr viele Dinge die schlicht und einfach nicht möglich sind. Das was mich aktuell wirklich am meisten nervt ist dass Events, wenn du sie im HTML Code fängst, keine Typen haben. Ich sag mal so, wenn ich noImplicitAny anmache, krieg ich schon ein paar hudnert fehlermeldungen und das obwohl wir wirklich viel Wert auf Typsicherheit legen.
Das Problem ist dass das zeug eben alles auf Javascript oben drauf gesetzt wurde. Ich würd z.B. auch gerne sowas wie Decoratoren unterstützen um properties oder CustomElement-tags zu definieren, aber jedes mal wenn ich sowas suche brauchst du ein externes Framework. babel z.B.
Ich meine wenn ich mich Entscheide mit C# zu arbeiten, da ist alles drinne. Alles! Attribute, enums (gibt's in JS gar nicht... ), wenn ich mir da ein NuGet Paket installiere dann nur für Dinge die man oben drauf setzt.
benneq schrieb:
Es ist eher das Gegenteil der Fall. Es sind meist reine JS Bibliotheken mit externen TypeScript Definitions. So oder so kann man beides in beiden Sprachen benutzen.
naja dann hatten wir nur pech. WIr z.B. benutzen ein Lightweight framework für webcomponents nennt sich LitHtml. Wir haben gesucht, vielleicht sind wir zu blöd aber das einzige was wir finden ist NPM zeugs. das laden wir uns und finden tonnenweise typescript files. Und wenn wir dann versuchen das zeug irgendwie zu "kompilieren", kommt da immer kompletter murks raus den JavaScirpt gar nicht als import erkennt. weil statt exports zu benutzen es mit irgendeiner anderen voodoo-magie gemacht wird sodass die imports bestenfalls als irgendwelche komischen namen ankommen, die keiner mehr lesen kann...
Darum meine Aussage, wie kann es denn sein dass die einzige Spracher die nativ vom Browser unterstützt wird sich so vehement gegen die Nutzung wehrt?
benneq schrieb:
Ich würde niemals behaupten, dass JavaScript eine vollends durchdachte Sprache ist. Aber alle Browser und Node.js und co. folgen demselben Standard. Es ist gut dokumentiert welche Funktion was wann zurückgeben. Oder was ist da "falsch"?
Naja "falsch" ist es direkt nicht, aber man muss halt sehr oft selbst casten. nehmen wir z.B. QuerySelector. wenn du querySelector("input") machst kriegst du ein HtmlInputElement, wenn du querySelector("input#test") machst kriegst du ein Element zurück, das vielleicht 50% der eigenschaften eines HTMLElement hat jedes mal muss ich es explizit in HtmlElement konvertieren, was schon penetrant ist. selbst die Typen im Catch-Block sind anonym, vermutlich weil du alles throwen kannst, sogar anonyme Objekte.
Es ist jetzt nicht grottenfalsch, aber das sind alles dinge für die mand as Konzept Generics und Casts braucht damit es überhaupt erstmal tragbar wird und allein rauszufinden wie man das mit JSDoc Kommentaren faked hat uns ganzschön arbeit gekostet...
benneq schrieb:
Wieso ist das ein Grund gegen das Framework? Das ist doch gerade der Grund, warum es dieses Framework gibt.
Der Grund warum es Blazor gibt ist JS Interop? OK du hast mich verloren.
Der Grund warum es Blazor gibt ist weil man C# benutzen will, optional vielleicht noch CLient und Server verbinden will ohne sich um den Datenaustausch zu kümmern und eine Typscihere Skript-Sprache zu benutzen.
Wenn man sowieso für das meiste JavaScript interops braucht dann kann man sich den Kram doch gleich ganz sparen und gleich in JavaScript arbeiten oder sehe ich das falsch? Ich meine da wird nichts, gar nichts unterstützt. Du kannst nichtmal querySelectoren machen. Selbst wenn du bei einem Event die Element-Referenz bekommst kannst du damit nichts anstellen, nicht in C#...
als ich das gehört hab war ich so kurz davor Unity3D für UI-Entwicklung zu verwenden... Das trifft noch am ehsten die Anforderung "Typsichere Skript-Sprache"
Bevor let kam gab es mit der var deklaration eine Besonderheit. Jede Angabe von var wird vom Interpreter an den Beginn des Function-Body-Scopes verschoben und dort ausgeführt.
function run() {
var foo = "Foo";
let bar = "Bar";
console.log(foo, bar); // Foo Bar
{
var moo = "Mooo"
let baz = "Bazz";
console.log(moo, baz); // Mooo Bazz
}
console.log(moo); // Mooo
console.log(baz); // ReferenceError
}
run();
Daher gibt es ein paar gute gepflogenheiten, die das Leben vereinfachen.
1. Namespacing -> du machst eine einzige Variable im Window Objekt und da drin machst du dein Zeug.
2. Variablendeklarationen am Beginn der Funktion - das macht es Übersichtlich und durch Beistrichtrennung erzeugst du einen Fehler den du gleich merkst, wenn mal was nicht stimmt. Zusätzlich kannst du leere Variablen initialisieren und mit typeof schauen ob die noch leer sind sowie den dritten operator für den typenvergleich nutzen. Beispiel:
Javascript:
elements.forEach(function(element, index){
var content, // kann später befüllt werden
class_attribute = 'blah-blubb',
content_id = index,
heading_content = document.createElement('a'),
open_content_index = -1,
open_heading_index = -1,
has_open_index = false;
console.log(typeof content);
if ( typeof content === 'undefined' ) {
content = element.innerText;
}
console.log(typeof content);
});
Dadurch behälst du die Variablen immer im Scope und schaust ob typeof content einen string(!) mit dem Wert "undefined" zurückliefert.
3. Funktionen definieren, nur nicht alles in einer Wurst schreiben, verwende sprechende Namen.
4. Für wiederkehrende Operationen, die eine Art Klasse benötigen würden, erzeuge eine Basisvariable nach dem gewünschten Prototyp und erweitere diesen. Diese Variable kannst du dann ähnlich wie Klassen nutzen, interessant zb für viele Downloads, eine file Variable oder in einem Shop eine customer oder eine item Variable, die alle entsprechenden Operationen kann oder für eine Warenkorbfunktion brauchbar wäre.
5. mach mal immer wieder in verschiedenen Funktionen console.log(this); bzw console.log(arguments) diese beiden Variablen sind sozusagen immer dabei.
Das Problem ist dass das zeug eben alles auf Javascript oben drauf gesetzt wurde. Ich würd z.B. auch gerne sowas wie Decoratoren unterstützen um properties oder CustomElement-tags zu definieren, aber jedes mal wenn ich sowas suche brauchst du ein externes Framework. babel z.B.
Babel ist einer dieser ganzen Compiler. Decorators sind zwar Teil des ECMAScript Standards (bzw. noch in Stage 3), aber werden aktuell in keinem Browser unterstützt. Und wie bekommt man das dann zum laufen? Babel nimmt deine Decorators aus dem Source Code und macht daraus JS Code, der sich identisch verhält, aber ohne Decorators arbeitet.
Kokujou schrieb:
Ich meine wenn ich mich Entscheide mit C# zu arbeiten, da ist alles drinne. Alles!
Wieso Pech? Man kann lit-html mit und ohne TypeScript benutzen. Aber wenn du Sprach Features wie z.B. Decorators benutzen willst, dann musst du auch irgendwie dafür sorgen, dass am Ende JS Code dabei rauskommt, der auch von den Clients verstanden und ausgeführt werden kann.
Babel, TypeScript und co. erlauben es uns mit Features zu arbeiten, die es noch gar nicht gibt. Decorators sind aktuell z.B. in Stage 3, und noch nicht Teil finalen Standards.
Kokujou schrieb:
Darum meine Aussage, wie kann es denn sein dass die einzige Spracher die nativ vom Browser unterstützt wird sich so vehement gegen die Nutzung wehrt?
Weil sich die Browser an einen Standard halten: ECMAScript. Sonst wird das wieder wie früher, wo jeder Browser mit seine eigenen Scriptsprachen mitbrachte.
Oder soll immer die aktuellste JS Alternative unterstützt werden? Dann hätten wir nun sicherlich solche Ausgeburten wie CoffeeScript oder Flow mit drin, und den Kram kann man später nicht mehr rauswerfen, wegen Rückwärtskompatibilität - das wäre ein Fass ohne Boden. Aus demselben Grund müssen wir uns auch heute noch mit so unnötigen Dingen wie == und === , null und undefined , und den ganzen anderen JS Fallstricken herumschlagen, wie z.B. array.sort mit undefined Elementen.
Kokujou schrieb:
Naja "falsch" ist es direkt nicht, aber man muss halt sehr oft selbst casten. nehmen wir z.B. QuerySelector. wenn du querySelector("input") machst kriegst du ein HtmlInputElement, wenn du querySelector("input#test") machst kriegst du ein Element zurück, das vielleicht 50% der eigenschaften eines HTMLElement hat jedes mal muss ich es explizit in HtmlElement konvertieren, was schon penetrant ist.
Woher soll die Sprache auch wissen, ob und was genau sich für ein Typ zur Laufzeit hinter diesem QuerySelector String versteckt? Bevor der Code ausgeführt wird, steht das Ergebnis nicht fest - weder der Typ des Elements, noch ob das Element überhaupt existiert.
Du sagst der Browser API ja nur "schau doch mal, ob du irgendein Element mit ID #test hast", und der Browser schaut und gibt dir, was er gefunden hat. Da sind überhaupt keine Typen involviert - die API versichert dir nur, dass es "irgendein HTMLElement" ist.
Kokujou schrieb:
selbst die Typen im Catch-Block sind anonym, vermutlich weil du alles throwen kannst, sogar anonyme Objekte.
So viele Nachteile in TypeScript, und trotzdem willst du es als offizielle Sprache in allen Browsern haben? Dann doch lieber gleich was, das nicht auf den unzähligen Designfehlern von JS aufbaut.
Kokujou schrieb:
Wenn man sowieso für das meiste JavaScript interops braucht dann kann man sich den Kram doch gleich ganz sparen und gleich in JavaScript arbeiten oder sehe ich das falsch? Ich meine da wird nichts, gar nichts unterstützt. Du kannst nichtmal querySelectoren machen.
Mir klingt es so langsam danach, als ob du alles was du zwischen die Finger bekommst versuchst wie VanillaJS zu benutzen. Wenn du VanillaJS benutzen willst, dann benutz es und versuche nicht irgendein Framework dafür zu verbiegen.
Blazor ist kein VanillaJS, genau so wenig wie React, Angular, Vue, Svelte, Qwik, Solid, Astro, ... Jedes dieser Frameworks bietet einen anderen Weg um Webfrontends zu erstellen. Kommt halt auf die Anforderungen an und worauf man seine Schwerpunkte legt.
Kokujou schrieb:
als ich das gehört hab war ich so kurz davor Unity3D für UI-Entwicklung zu verwenden... Das trifft noch am ehsten die Anforderung "Typsichere Skript-Sprache"
Ist doch auch voll legitim, wenn du mit dem Tool sauber und effizient arbeiten kannst. Das ist doch überhaupt der Punkt: "Auswahl" bedeutet, dass es für jede Nische und jeden Anwendungsfäll etwas gibt. Hätten wir eine Lösung, mit der alle zufrieden wären, gäbe die ganzen anderen Sprachen und Frameworks nicht. Ist aber nicht der Fall.
Also nutz Blazor, wenn du damit zum Ziel kommst, oder Unity, oder VanillaJS, oder, oder, oder.
Ich weiß jetzt nicht was das mit Typen zutun hat... Das ist ein komplett anderes Konzept. Das Problem warum JavaScript ohne Typen so hart ist ist: DU hast kein IntelliSense. IntelliSense ist das so ziemlich praktischste Tool überhaupt, ich hab Programmieren gelernt nur durch dieses Feature.
Wenn du keine Typen hast dann sind ReferenceExceptions quasi minütlich. In einem Team ohne Typen zu arbeiten, da brauchst du entweder verdammt gute Leute, verdammt gute Tester oder du kannst das Projekt gleich einstellen weil es dir um die Ohren fliegen wird. Und wir haben weder das eine noch das andere.
Wie soll man denn bitte damit umgehen? Soll man eifnach vor jedem Property-Zugriff eine Abfrage machen ob die Property existiiert? das würde den ganzen Code verdreifachen ohne irgendeinen Mehrwert. Das ist einfach kein Zeitgemäßes Programmieren, du brauchst Typen.
Das Prototyping ist eine nette Referenz, zweifelsohne, und vielleicht kann man damit auch interessante Dinge machen, ansehen werd ich es mir auf jeden Fall, aber mit Typen hat das kaum bis gar nichts zutun.
Ergänzung ()
benneq schrieb:
Babel ist einer dieser ganzen Compiler. Decorators sind zwar Teil des ECMAScript Standards (bzw. noch in Stage 3), aber werden aktuell in keinem Browser unterstützt. Und wie bekommt man das dann zum laufen? Babel nimmt deine Decorators aus dem Source Code und macht daraus JS Code, der sich identisch verhält, aber ohne Decorators arbeitet.
Ja ich weiß und das ist quasi dasselbe KOnzept von TypeScript was mich auch schon wieder wahnsinnig macht, dieses ganze transcodieren. Dann baut das zeug doch in JavaScript ein! Ich meine es gibt doch auch keine NuGet Pakete die dir deinen C# Code in neuen C# Code umwandeln nur um neue Syntax zu unterstützen, weil alles was du brauchst schon in der Basis vorhanden ist.
Darum sollen sie halt einfach TypeScript unterstsützen, nativ, und das gesamte Problem ist behoben. für immer! Ich kapier echt nicht wie das passieren konnte...
benneq schrieb:
Wieso Pech? Man kann lit-html mit und ohne TypeScript benutzen
wenn überhaupt dann nur mit build Vorgang. Und das wollen wir ja eben nicht, da wurde ich massiv angefeindet >.< Ich meine wenn du sagst du hast die neuste Version von lit als reines JavaScript package, dass du mit einem import-statement importieren kannst und dann klassen wie LitElement und Funktionen wie html` und css` benutzen kannst, dann bitte, das ist nicht sarkastisch, wir suchen händeringend danach. unsere Version ist schon seit 2-3 Jahren veraltet.
benneq schrieb:
Weil sich die Browser an einen Standard halten: ECMAScript. Sonst wird das wieder wie früher, wo jeder Browser mit seine eigenen Scriptsprachen mitbrachte.
Aber TypeScript ist doch ein Standard. Laut einer Statistik die mir GPT-kun gerade ausgegraben hat bevorzugen 75% aller entwickler bereits TypeScript, das ist keine Frage von Randfällen mehr. Und das ist von 2021. Aber gut brignt ja auch nix darüber zu diskutieren, die Chance ist eh vorbei und es ist wie es ist, aber ich krieg TypeScript nicht durchgeboxt weil es eben nur irgendeine pseudo-offizielle API ist die irgendwelchen Code umschreibt der dann im Browser kompiliert wird. Ich selbst würds ja benutzen aber wir haben halt diese Stenkerer mit drin, die sich mit diesem ganzen transkodieren zeug und dem Build Vorgang und dem Garbage-Code der da am Ende rauskommt nicht anfreunden können.
Und ich muss dazu sagen, es ist schon verdammt praktisch wenn man z.b. bei nem Tester einfach die Browser-Konsole aufmachen kann und dort im Skript-Tab debugge kann, um zu sehen wo der Fehler liegt, ohne das wären wir wohl noch weiter zurück mit unserer Arbeit als wir eh schon sind. Da kannst du halt nicht sagen "installier mal schnell VSCode"
eben nicht. Was wir kriegen ist irgendein krankhafter ElementNode, der so gut wie keine Properties hat. Den muss man erstmal nach HTMLElement casten. Es gibt dutzende solcher Beispiele bei der JavaScript api. Unser Code ist aktuell zugepflaster mit /** @type {...} */ kommentaren
Ergänzung ()
benneq schrieb:
So viele Nachteile in TypeScript, und trotzdem willst du es als offizielle Sprache in allen Browsern haben? Dann doch lieber gleich was, das nicht auf den unzähligen Designfehlern von JS aufbaut.
Alle Nachteile von TypeScript können mit nativemBrowser-Support behoben werden. Browser-Support heißt kein Build Vorgang mehr. Das transcodieren fällt dann auch weg wenn sies so unterstützen wie's jetzt ist. Und dann ist auch die unterliegende ECMA version egal weils dann nichts unterliegendes mehr gibt. Aber hey, mir isses wurst wenn es die Option gibt C# an Browsern zu unterstützen dann würde ich nackt vor Freude Rad schlagen 🤣
Ergänzung ()
benneq schrieb:
Mir klingt es so langsam danach, als ob du alles was du zwischen die Finger bekommst versuchst wie VanillaJS zu benutzen.
Nein eben nicht, wenn ich Blazor benutze will ich GAR keine JS Interops. Ich will nur C# benutzen wenn ich mit diesem Framework arbeite. Aber wenn natürlich nur so halb bis gar keine Brwoser-Funktionalität im C# code unterstützt wird, dann hast du am Ende nur eins erreichst, dass du 4 Programmiersprachen statt 3 verwendest, C#, JS, HTML und CSS. Ich seh da keinen gewinn.
Aber wenn du mir jetzt z.B. sagst dass JS INterops nur die absoluten Randfälle sind und man problemlos eine komplexe Webanwendung ganz ohne JS Interops errichten kann, dann hab ich das einfach nur falsch verstanden und ehrlich gesagt bete ich zu Gott nach so einer erfolgsmeldung^^ und das als Atheist.
Ergänzung ()
benneq schrieb:
Ist doch auch voll legitim, wenn du mit dem Tool sauber und effizient arbeiten kannst
Ja wenn... Unity ist eine 3D Engine, keine Ahnung ob da was performantes bei rauskommt wenn wir sowas zur UI-Entwicklung verwenden, soweit ich weiß hat das noch nie einer gemacht ^^
Für den IntelliSense musst du JSDoc verwenden, sonst weis er nicht was drin ist. Dann geht der IntelliSense auch mit frei definierten Objekten problemlos.
Sicherzustellen, dass ein Objekt die Properties enthält die du abfragen möchtest, ist mit einer Klasse ebenfalls möglich und vielleicht das was du haben willst.
Btw: Unity wird für die UI Entwicklung genutzt, es gibt sogar einen eigenen Passus wenn man sie dafür auf Embedded Devices verwenden will, s. §16.3.2 https://unity.com/legal/terms-of-service
Einer meiner früheren Dozenten hatte uns mal geraten: regt euch nicht über Dinge auf die ihr nicht ändern könnt 😉.
Verstehe auch nach wie vor das Problem nicht. Man hat gewisse Umstände, mit denen man leben muss. Also sucht man sich ein Framework was eine gewissen Zukunftssicherheit, möglichst stabile API hat, gut dokumentiert ist und deren Handling einem zusagt. Und dann geht es los… Probleme werden immer mal aufkommen, das gehört halt dazu.
Verstehe ich das richtig, dass dein Team keine „Compiler“ einsetzten möchte? Wie stellen sie sich dann ein produktives Arbeiten vor? Viele neue Hilfreiche Funktionen und Erweiterung in JS kann man dann garnicht nutzen, weil ältere Browser das nicht unterstützten.
Selbst wenn Typescript jetzt nativ in den Browser kommen würde, würde es gefühlt noch 10 Jahre dauern bis es beim letzten Endgerät angekommen ist.
Dieses Blazor kenne ich selbst nicht, aber das scheint ja als WASM zu laufen, oder? Ja da gibt es an manchen Ecken Overhead, aber an anderer Stelle hat WASM auch wieder einen großen Vorteil. Nämlich da wo rechenintensive Aufgaben erledigt werden müssen.
Ich denke es kommt drauf an was du mit deiner Anwendung machen möchtest. Am Frontend (im Browser) selber gibt es NUR Javascript seit fast Jahrzehnten und erst seit neuestem wasm.
Blazor ist relativ schnell, da der im Backend ausgeführte Programmcode mit C# läuft. Bei den meisten anderen üblichen Frameworks kommt dort ebenfalls Javascript zum Einsatz.
Auf Wunsch kannst du eine Blazor Anwendung zu wasm kompilieren lassen, dann läuft die Anwendung nach dem initialen Streaming komplett im Browser.
Ziel der typischen Frameworks ist es eben, dass du gar kein Frontend JS Code schreibst sondern fertige Komponenten nutzt, die sich bei Bedarf um alles kümmert. Und Komponenten (Diagramme, Tabellen, 2D Renderer...) gibt es mehr als genug.
Ich habe den Thread teilweise nur überflogen, aber ich frage mich, auf welche Architektur Du abzielst. Soll es eine Frontend-Anwendung werden, die über Web-APIs mit dem Backend kommuniziert? Oder klassisch mit Server-side Rendering, also Templates und so?
Im letzteren Fall stünde ich auch erstmal kurz auf dem Schlauch. Habe ich zum letzten Mal vor vielen Jahren gemacht und wüsste spontan auch nicht, wie ich da TypeScript reinbringen würde oder welchen Bundler ich nehmen sollte. Prinzipiell lässt sich aber zumindest Vue auf diese Art verwenden (bei den anderen beiden großen weiß ich es nicht). Ich habe mir auch Hotwire im Hinterkopf behalten, falls ich diesen Weg mal wieder beschreiten wollen würde, aber keine Erfahrungen damit.
Im Falle von Frontend-Apps bzw. Single Page Apps kommt man um die entsprechenden Tools und einen Build-Prozess nicht wirklich herum, außer, man steht auf Schmerzen. 😛 Ich will jedenfalls keine Vue Single File Components mehr missen, und in Kombination mit Vite und der Vue Browser Extension ist auch Debugging kein Problem, wobei ich das eigentlich noch nie wirklich gebraucht habe - Console Output und Exceptions sind üblicherweise aufschlussreich genug und mit TypeScript passieren viele Fehler erst gar nicht.
Okay statt mir jetzt einzelne Phrasen zum zitieren rauszupicken möchte ich jetzt mal die Richtung leicht ändern. Es scheint ja so dass es nach wie vor auf die typischen drei Möglichkeiten hinaus läuft.
Vanilla JS mit JSDoc - Irgendein Typescript-Framework a la Angular, Vue, etc.. - C# Frameworks wie Blazor.
VanillaJS ist quasi der aktuelle Stand. Es läuft irgendwie, die Leute sind zufrieden, aber es ist weder 100% typ-sicher, noch kann man damit die neusten coolen Coding-Tweaks nutzen und das schlimmste ist, es ist quasi unmöglich dort anständig bibliotheken einzubinden weil die alle JS-Modules sein müssten und das ist einfach nicht der Fall. Korrigiert mich hier gerne wenn ihr da nen weg kennt.
TypeScript hat die erwähnten schwächen, aber jemand meinte man kann TypeScript in VSCode debuggen und das ohne den Browser in der about:config hacken zu müssen und mit spezifischen Command Line Args zu starten um das zum laufen zu bringen? Da nochmal details zu haben wäre cool, aber in die Richtung kann ich zur Not auch selbst Recherche betreiben.
Was C# angeht ist nach wie vor das totale K.O. Kriterium JS Interops, die so gar nicht in das Framework rein passen. Hier würde mich wieder eure Erfahrung interessieren. Habt ihr denn schonmal großere Projekte mit Blazor gemacht? Kommt man um die Interops irgendwie drumrum? Oder habt ihr das als notwendiges Übel einfach bei jeder zweiten Komponente mit reingeschmissen?
Generell würde ich ja zu Blazor tendieren, aber alles in mir sträubt sich dagegen wenn ich mir vorstelle statt 3 gleich 4 Programmiersprachen zu verwenden. Wie macht man denn z.B. so Dinge wie two-way-binding, manual scrolling (a la "scroll to element")?
Ich frag mich immer noch was genau du denn möchtest und womit du Probleme hast.
Wir entwickeln komplexe Web Apps für industriellen Einsatz (keine "Webseiten") in Blazor und fast nie muss man irgendwas manuell über JsInterop lösen.
Es gibt Libraries (Blazorize, MudBlazor, ...) die dir Komponenten für die meisten Bedürfnisse anbieten. Die kümmern sich ums Rendering, Scrolling und Binding.
wirklich? Ich hab ja bisher nur ein bischen mit Blazor rumgepfuscht und mir die spezifikationen durchgelesen... aber wenn das wirklich so ist, dann kann man wohl sämtliche Fälle in denen man Browser Funktionalität bräuchte (Stichwort JS Interop) auch anders lösen, das beruhigt mich etwas..
andy_0 schrieb:
Es gibt Libraries (Blazorize, MudBlazor, ...) die dir Komponenten für die meisten Bedürfnisse anbieten. Die kümmern sich ums Rendering, Scrolling und Binding.
mich würde mal interessieren wie das Scrolling in Blazor funktionieren soll. ich meine scrollen funktioniert doch nur indem ich sowas sage wie document.scrollIntoView oder so. aber vielleicht benutzen dann die Komponenten die interops und es wird einfach nur weg gewrappt.
Die werden das sicherlich so machen. Wenn der Browser speziell reagieren soll, kommt man um Aktionen im Browser nicht drumherum. Ich möchte nicht sagen, dass man JsInterop nie benötigt, es ist aber definitiv kein großes Ding.
Wir nutzen z.B. Apex Charts (große JS Diagramm Library) mit Blazor und es funktioniert ziemlich gut (auch wenn Apex Charts dank JS halt super slow ist). Auch sowas ist möglich ohne direkte Funktionen mit JsInterop aufzurufen. Die Library kümmert such drum.
Also ich habe beruflich mit Blazor schon gearbeitet, und das erfolgreich.
Wir haben eine Arbeitszeiterfassung mit Blazor Server entwickelt und nutzen diese seit etwas über zwei Jahren. Keine Probleme bisher, JSInterop wurde meines wissens nach nicht einmal verwendet.
Anders sieht es mit Blazor WASM aus. Nutzen wir für einige interne Tools mit API-Anbindung und dort wird JSInterop benutzt, vor allem für LocalStorage (JWT-Token etc). Und das ist performancetechnisch so irrelevant, man merkt es garnicht (vorrausetzung, man nutzt es auch richtig, zBsp mit LazyLoading).
Die Diskussion hier ist ja sehr wirr. Irgendwie wird hier alles durcheinander gewuerfelt.
1. Selbstverstaendlich kann man TypeScript debuggen, so lange man die passenden Sourcemaps generieren laesst. Dann kannn man auch einfach die Debug-Tools in Chrome/Firefox oeffnen, Breakpoints setzen im TypeScript-Code etc. So arbeiten eigentlich alle Webentwickler.
2. TypeScript ist als Erweiterung der ECMAScript-Spezifikation zu verstehen
3. Webpack ist ein Bundler, keine Compiler
4. JEDES moderne JS/TS-Projekt wird über einen Transpiler wie Babel und einen Bundler wie Gulp oder Webpack gejagt.
5. KEIN ernstzunehmendes Projekt verwendet "Vanilla" JS. (was soll das ueberhaupt sein? ES05 als kleinster gemeinsamer Nenner?
6. Der Code wird anhand einer passenden Target-Konfiguration (Browserslist etc) auf ein Zielkompilat uebersetzt, das alle zu unterstuetzenden Browser verstehen.
Nichts ist "da oben draufgesetzt". Die aktuelle Spezifikation ist ES13. Da nicht alle Browser die aktuelle Spezifikation nativ unterstuetzen, wird halt transpiliert (Babel). Das hat aber ueberhaupt keinen Nachteil waehrend der Entwicklung, da man trotzdem Debuggen kann, Hot Reload nutzen kann, etc.
Zur Frage an sich:
React mit TypeScript/ES13 fürs Frontend. Go fürs Backend.
