|
|
|
|
| Zitat von [KdM]MrDeath
sprich mir nach: du willst kein plain js schreiben.
| |
Hm, ich halte die Aussage für irreführend. Ich weiß was du meinst, würde aber trotzdem konkretisieren auf: Man will im Frontend keine komplexen Webapp-UIs mit vielen DOM-Manipulation ohne Lib / Framework schreiben.
Das ist aber nur ein kleiner Teil von JS. Ich klammer mal bewußt die Serverseite mit node/deno aus, wo es eh unumgänglich ist und beziehe mich mal nur aufs Frontend:
Die DOM-Api von JS ist gar nicht so verkehrt für kleine Use-Cases. Und darüber hinaus sind die anderen offiziellen JS/Web-APIs (https://developer.mozilla.org/de/docs/Web/API) am Zahn der Zeit, mit denen muss man sich einfach Außeinandersetzen.
Also ohne "plain JS" zu schreiben zu wollen oder zu können, limitiert man sich schon unnötig stark und schreibt auch garantiert keinen sauberen React-Code.
Der Vorteil von React, Vue & Co. ist neben einem lebendigen Ecosystem halt vor allem die Implementation eines Virtual DOM, was alleine die Render/Paint Performance in den Browsern für Webapps mit vielen UI-Interaktionen super intelligent löst.
Aber auch da kann man kleiner Stapeln und sich z. B. HyperHTML anschauen.
|
|
|
|
|
|
|
Naja, JS will man halt wirklich nicht schreiben. Sondern Typescript :>
|
|
|
|
|
|
|
Aber Typescript macht ja erstens schlechten JS-Code halt aber auch nicht besser, und ist ja zweitens auch kein sinnvoller Vorschlag für einen Einsteiger.
|
|
|
|
|
|
|
| Zitat von Tenz
und ist ja zweitens auch kein sinnvoller Vorschlag für einen Einsteiger.
| |
Wieso nicht?
|
|
|
|
|
|
|
Ok, ich merke schon ich bin noch viel zu sehr an der Oberfläche, als das ich mir darüber Gedanken machen sollte
Aber gut zu wissen das man für gewisse Funktionalität lieber mal in ein Framework schauen sollte, statt sich selbst eine Krücke zu überlegen, wie man es irgendwie hinbekommen kann.
Da mein JS Teil aber bisher eigentlich nur darauf basiert ein paar Tabellen aus Code in HTML und umgekehrt zu verwandeln, ist mir zumindest (rein aus Funktionssicht) kein größeres Problem untergekommen.
|
|
|
|
|
|
|
| Zitat von Tenz
Aber Typescript macht ja erstens schlechten JS-Code halt aber auch nicht besser
| |
Gebe ich dir völlig recht, ich wollte nur ein wenig sticheln Ich finde es sehr wichtig die Browser APIs im Allgemeinen gut zu kennen, weil Abstraktionen halt nie alles abdecken.
Aber gerade als Einsteiger würde ich Typescript empfehlen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 06.12.2021 11:26]
|
|
|
|
|
|
| Zitat von Noxiller
Gibts bei Git o.ä. sowas wie "roast my code"?
Am besten zu einfachen, kleinen Programmen wo Leute ihren Code vorstellen und der wird durch erfahrene Programmierer kommentiert/ verbessert?
Immer wenn ich meinen Code sehe denke ich mir, dass macht doch kein normaler Mensch so
| |
https://codereview.stackexchange.com/
Oder hier posten.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 06.12.2021 12:22]
|
|
|
|
|
|
| Zitat von SkunkyVillage
| Zitat von Tenz
und ist ja zweitens auch kein sinnvoller Vorschlag für einen Einsteiger.
| |
Wieso nicht?
| |
Weil TypeScript einen gewissen setup effort erfordert, der auch deutlich leichter fällt, wenn man sich schon mit JS und Web-Entwicklung auskennt (vor allem je nach Framework). Ich würde auch von jedem TypeScript-Entwickler erwarten, dass er JavaScript beherrscht und versteht, denn im Zweifelsfall muss er das ja auch debuggen.
/ TypeScript und einsteigerfreundlich, da sind wir halt echt noch nicht. Klar, wenn das Framework das direkt shipped, isses was anderes. Aber ansonsten ist ein Einsteiger doch schon froh, wenn er die Quickstart-App eines beliebigen Frameworks lokal zum Laufen bekommt.
// Außerdem macht dynamischen Code schreiben fun, also fakka uuuu!
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Ameisenfutter am 06.12.2021 12:34]
|
|
|
|
|
|
Und warum debugged man nicht einfach im TypeScript Code?
|
|
|
|
|
|
|
| Zitat von SkunkyVillage
Und warum debugged man nicht einfach im TypeScript Code?
| |
Weil das weitere Konfiguration erfordert? Willste dem Einsteiger jetzt auch noch erklären, was eine Source Map ist?
/ Ihr solltet für euch vielleicht mal gerade rücken, was "einsteigerfreundlich" bedeutet. Vielleicht erinnert ihr euch mal an eure ersten Gehversuche im Coden zurück.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ameisenfutter am 06.12.2021 12:38]
|
|
|
|
|
|
Ich find es gerade für Einsteiger gar nicht so verkehrt, wenn man sich mal hinsetzt und seine Tool- und Devchain einrichtet und konfiguriert.
Plain-JS führt doch echt irgendwie ins Nichts.
|
|
|
|
|
|
|
Man könnte natürlich erstmal mit so universell wichtigen Themen wie Routing, Models oder Event Subscription anfangen, aber klar, Hauptsache er arbeitet typbasiert und hat ne schicke Pipeline.
|
|
|
|
|
|
|
Einem Quereinsteiger mit Entwickler-Background, der möglichst schnell ins Berufsleben zu einer Butze will die aktiv Produkte entwickelt, würde ich auch TS für sein Curriculum nahelegen.
Aber jemand der neu in der Web-Entwicklung ist und gerade seine ersten Schritte macht: Da gäbe es so gefühlt 100 andere Dinge vorher.
Also zumindest ist gerade Noxiller mein Kontext und hier wird etwas zu schnell mit absoluten aussagen geschossen.
Ich habe 100x lieber einen Anfänger, der plain JS kann in meinem Team, als einen Anfänger dir alles irgendwie mal in einen Topf gebracht hat und für den sich die Zusammenhänge dennoch nicht erklären.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Tenz am 06.12.2021 12:49]
|
|
|
|
|
|
| Zitat von Ameisenfutter
| Zitat von SkunkyVillage
Und warum debugged man nicht einfach im TypeScript Code?
| |
Weil das weitere Konfiguration erfordert? Willste dem Einsteiger jetzt auch noch erklären, was eine Source Map ist?
/ Ihr solltet für euch vielleicht mal gerade rücken, was "einsteigerfreundlich" bedeutet. Vielleicht erinnert ihr euch mal an eure ersten Gehversuche im Coden zurück.
| |
Ich würde sagen das Debuggen ist TypeScript sogar möglicherweise leichter, zumindest wenn man von nicht typisiertem Code wie JS kommt
Abgesehen davon verhindert TypeScript eventuell gleich mal einige Fehler bevor man debuggen muss.
Würde jetzt auch nicht sagen, dass man damit starten muss, stimme nur nicht den Aussagen dass es unbedingt einfacher ist in JavaScript zu debuggen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von KingGinord am 06.12.2021 12:49]
|
|
|
|
|
|
Dass jemand, der von einer typbasierten Sprache kommt, sich mit TypeScript intuitiv leichter tut, steht außer Frage. Ob das jetzt die größte Hürde beim Einstieg in die Webentwicklung ist, bezweifle ich.
|
|
|
|
|
|
|
| Zitat von Tenz
Ich habe 100x lieber einen Anfänger, der plain JS kann in meinem Team, als einen Anfänger dir alles irgendwie mal in einen Topf gebracht hat und für den sich die Zusammenhänge dennoch nicht erklären.
| |
Da ist implizit die Frage womit man eigentlich anfangen "sollte".
Ich wünsche mir heute ich hätte nicht mit PHP (zumindest im simplen(!) PHTML Kontext) und JS angefangen. Als ich mir dann Java und co. angeschaut habe / musste, bin ich gleich erstmal ordentlich auf die Fresse gefallen ohne überhaupt die Probleme angehen zu können, die ich eigentlich lösen sollte (auch in der Uni).
|
|
|
|
|
|
|
| Zitat von Ameisenfutter
Dass jemand, der von einer typbasierten Sprache kommt, sich mit TypeScript intuitiv leichter tut, steht außer Frage. Ob das jetzt die größte Hürde beim Einstieg in die Webentwicklung ist, bezweifle ich.
| |
Ja gut stimmt, vllt kenne ich das einfach nur so rum. Mir geht es da auch nicht unbedingt um die Typen, sondern um die Art des Debuggings und schauen was im Prozess falsch läuft.
Hab eben in der WebEntwicklung angefangen und kam danach erstmal nicht damit klar, keine LaufzeitFehler entdecken zu können ohne dafür mir dafür erstmal anderen Kram einrichten und verstehen zu müssen (selbst bei Python)
|
|
|
|
|
|
|
Joa, ich auch. War fit in C# und ABAP und hab mich dann bei JS gewundert, wieso zur Hölle hier alles mit Strings referenziert wird.
Woher weiß der Compiler das???????
|
|
|
|
|
|
|
| Zitat von Tenz
Einem Quereinsteiger mit Entwickler-Background, der möglichst schnell ins Berufsleben zu einer Butze will die aktiv Produkte entwickelt, würde ich auch TS für sein Curriculum nahelegen.
Aber jemand der neu in der Web-Entwicklung ist und gerade seine ersten Schritte macht: Da gäbe es so gefühlt 100 andere Dinge vorher.
Also zumindest ist gerade Noxiller mein Kontext und hier wird etwas zu schnell mit absoluten aussagen geschossen.
Ich habe 100x lieber einen Anfänger, der plain JS kann in meinem Team, als einen Anfänger dir alles irgendwie mal in einen Topf gebracht hat und für den sich die Zusammenhänge dennoch nicht erklären.
| |
Ich habe eben angefangen mir ein paar Sachen zu TS anzuschauen und verstehe zwar wo es hingeht, aber sehe noch nicht wie mir das helfen soll.
Und das ist für mich definitv das Zeichen, dass ich noch viel zu weit davon entfernt bin es sinnvoll nutzen zu können.
Aktuell stehe ich eher vor Fragen, ob es normal ist etliche Java Scripte in der HTML einzubinden oder eher bad practice.
Ich habe verschiedene Funktionen/Funktionsgruppen die ich aus Gründen der Übersicht jeweils in eigene JS Files packe und diese dann in der HTML als src eintrage.
Das wirkt irgendwie falsch, aber hunderte Zeilen Code in eine Script File rotzen triggert mich dann doch zu sehr
/e
Ich habe ja bereits in Java programmiert und habe zumindest schonmal was anderes als JS gesehen
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Noxiller am 06.12.2021 12:59]
|
|
|
|
|
|
Dafür gibt es bundler (webpack /parcel) die dir die einzelnen Dateien in eine Datei packen.
Wie stark man splittet kommt dann auf den anwendungsfall an.
|
|
|
|
|
|
|
| Zitat von KingGinord
Da ist implizit die Frage womit man eigentlich anfangen "sollte".
Ich wünsche mir heute ich hätte nicht mit PHP (zumindest im simplen(!) PHTML Kontext) und JS angefangen. Als ich mir dann Java und co. angeschaut habe / musste, bin ich gleich erstmal ordentlich auf die Fresse gefallen ohne überhaupt die Probleme angehen zu können, die ich eigentlich lösen sollte (auch in der Uni).
| |
Et jeht doch um Einstieg für etwas Webentwicklung, bzw. noch konkreter in Noxillers fall: Frontend.
Du kannst im Web ohne Setup eine html-Datei anlegen, die in deinem Browser öffnen und loslegen. Du kannst Browser-Devtools auf jeder Website aufmachen und frei in die Console hacken. Das ist nur möglich weil das Produkt welches ausgeliefert wird, kein kompilierter Code, sondern letztendlich dynamisch typisiertes plain JS ist. Und das ist letztendlich meiner Meinung nach die Stärke des Webs: es ist offen, es ist zugänglich, es ist nachhaltig.
Für so einen Anfänger löst TS doch rein gar nichts. TS löst meiner Meinung nach ganz spezielle Probleme: Es verbessert die Wartbarkeit und Interoperability zwischen Code & Entwickler und zwischen den Entwicklern. Es ist kein Must-Have für JS per se, vor allem keine technische Notwendigkeit damit die Sprache überhaupt funktioniert (im Gegenzug zu Java z. B.).
@noxiller
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Tenz am 06.12.2021 13:08]
|
|
|
|
|
|
Wollt gerade sagen, webpack macht Dir daraus eine .js, die Du dann einbinden kannst.
Das kann dann auch gleich den Code eindampfen (minify) und (wenn gewünscht) obfuscaten.
Allerdings ist das auch wieder Aufwand, wenn man das automatisch haben will.
Bei uns ist ja einfach ALLES gedockert, was nicht bei drei auf dem Bäumen war. Und dann noch auf Mac. Hach. Filesystem überwachen? Mmmh, leider nicht so richtig (geht zwar inzwischen, aber wir stoßen das Kompilieren trotzdem von Hand an).
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KDO2412]Mr.Jones am 06.12.2021 13:12]
|
|
|
|
|
|
| Zitat von Tenz
TS löst meiner Meinung nach ganz spezielle Probleme: Es verbessert die Wartbarkeit und Interoperability zwischen Code & Entwickler und zwischen den Entwicklern. Es ist kein Must-Have für JS per se, vor allem keine technische Notwendigkeit damit die Sprache überhaupt funktioniert (im Gegenzug zu Java z. B.).
| |
Es ist so. TS glänzt vor allem in Teams und ist die Antwort auf bestimmte Probleme, die durch (zu) große JS-Projekte mit mehreren beteiligten Entwicklern entstehen. Und weil TS eben im Grunde ein Workaround ist (ist halt nicht nativ, dol wit et), gibt es bestimmte Trade-Offs (z.B. Konfigurationsaufwand oder Source Maps).
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ameisenfutter am 06.12.2021 13:13]
|
|
|
|
|
|
| Zitat von [KdM]MrDeath
sprich mir nach: du willst kein plain js schreiben.
die zeiten von jquery&co sind zum glück vorbei.
ich persönlich bin sogar mittlerweile positiv angetan von typescript, das javscript ökosystem ist immer noch jenseits von gut und böse und die sprache kann auch nicht alles, aber die gröbsten schnitzer von JS kriegt man damit gut umgangen
flow hat sich in javascript ja nie so wirklich durchgesetzt...
| |
Ich finde plain JS echt sehr OK, vor allem, wenn man halt nicht die letzten Schundclients supporten muss. Wenn ich im Web was baue, dann entweder Vanilla JS oder TypeScript.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 06.12.2021 13:22]
|
|
|
|
|
|
Leute, warum so kompliziert, wenn man auch einfach Rust zu wasm kompilieren kann?
|
|
|
|
|
|
|
Software-Entwickler sind so ein unsympathisches Volk.
Global ranking of technologies
1. Whatever I use
2. Whatever other people use
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ameisenfutter am 06.12.2021 13:27]
|
|
|
|
|
|
| Zitat von Ameisenfutter Vielleicht erinnert ihr euch mal an eure ersten Gehversuche im Coden zurück.
| |
90er. C, Linux, grunz. Der Einstieg muss hart sein.
|
|
|
|
|
|
|
Vielleicht hilft's, dass es bei mir noch nicht so lange her ist. Die Schmerzen sind noch gut in Erinnerung.
|
|
|
|
|
|
|
Ich habe den Scheiss ja selbst unterrichtet. Webbrowser sind nicht die Plattform, auf der ich jemandem programmieren beibringen will. Eher im Gegenteil.
|
|
|
|
|
|
|
| Zitat von SwissBushIndian
| Zitat von Ameisenfutter Vielleicht erinnert ihr euch mal an eure ersten Gehversuche im Coden zurück.
| |
90er. C, Linux, grunz. Der Einstieg muss hart sein.
| |
FORTRAN 77 fixed format <3
|
|
|
|
|
|
Thema: Software-Entwicklung 0 ( new SammelThread() ) |