Warum JavaScript so seltsam ist // deutsch

[@Metalkillsrap]

Ich bin gerade völlig begeistert. Das ist ohne Zweifel einer der besten deutschsprachigen Kanäle zum Thema Softwareentwicklung. Großes Lob und bitte weiter so!

[@thenativeweb]

[gr] Vielen, vielen Dank 😊

[@user-hw7pi2ld2r]

Klasse Video! Und ein Video welches alle wichtigen Sprachmerkmale der einzelnen Versionen zusammenfasst, fände ich extrem hilfreich. Vielleicht auch mit der Info, welche Versionen in welchem Umfang von den jeweiligen Browsern unterstützt wird.

[@thenativeweb]

[gr] Vielen lieben Dank - und auch Danke für das Feedback wegen des Versionsvideos, das arbeiten wir gerne ein 😊

[@gunsncodes6665]

CSS kam laut Wikipedia erst 1996 heraus. Habe damals 1998 in der Schule im Informatikunterricht ein wenig HTML gelernt. CSS hat keiner erwähnt.

[@cs_devel]

Eine sehr gute Erklärung, warum JavaScript so seltsam ist. Ich hatte damals im "Browserkrieg" mit der Entwicklung begonnen und smoit live miterlebt, welche Tweaks man teilweise machen musste, damit die Seiten in den verschiedenen Browsern wenigstens ähnlich liefen. Heute bin ich, was die Entwicklung angeht, bei neuen Projekten oder Refactoring fast vollständig auf TypeScript gewechselt und nutze zum Teil die neuen Features, aber bei weitem nicht alles, was möglich ist. Es ist schwer, den Überblick zu behalten und dem Zeitgeist zu folgen. Deshalb finde ich die Anmerkung zu den Videos mit den Sprachmerkmalen zu den einzelnen Version, eine tolle Sache, nur sollte man hier nicht beim "Urschleim" anfangen. Eine Möglichkeit wäre allerdings auch, ähnlich zum Mozilla Developer Network MDN, die Features allgemein darzustellen und praxisnähere Beispiele dazu zu bringen. Ich weiß, das wird ein riesiger Aufwand, der aber durchaus geschätzt werden würde. Die Beispiele auf MDN sind oft...wie sagt man es politisch korrekt...praxisfern.

[@ronny332]

Sehr interessant zusammen gefasst. Ich bin schon quasi ein Urgestein im Web und seit spätestens dem IE6 Chaos aktiv mit JavaScript beschäftigt. Die einzelnen Ecken und Kanten sind noch im Gedächnis, aber so eine Auffrischung ist wirklich willkommen. Vielen Dank!

[@thenativeweb]

[gr] Vielen Dank, das freut mich sehr 😊

[@amadeus.mueller]

17:15 Das ist eine sehr geschickte Konstruktion die du da schön beschreibst. Einen Standard zu modularisieren bzw. featuresieren damit diese implementiert werden können und später sauber im Standard sind. So entsteht weniger Verzögerung bis das Feature genutzt werden kann.

[@SoundsBy80K]

Wirklich gut zusammengefasst.. habe mich schon länger gefragt woher die historischen Merkmale kommen.

[@thenativeweb]

[gr] Vielen Dank, freut mich, dass ich für mehr Klarheit sorgen konnte 😊

[@coolchop]

Sehr cooler Flug durch die Geschichte. Vielen Dank dafür. ❤️

[@thenativeweb]

[gr] Sehr gerne 😊

[@DirtycoDe1337]

Cooles Video, hat Spaß gemacht, die Geschichte mal durchzuhören und es waren auch noch ein paar Sachen dabei, die ich nicht kannte, obwohl ich den Browserkrieg noch live miterlebt habe ;).

[@thenativeweb]

[gr] Das freut mich, danke schön 😊

[@thestype]

Schönes Video! Tatsächlich habe ich mal bei einer JS Konferenz dem TC39 Panel beigewohnt, sehr interessanter Einblick! Moderne Browser haben die ECMA Sprachfeatures endlich weitgehend implementiert. Besonders ES-Module Support ist wegweisend und der Wegfall des IE11 Supports. Mittlerweile bin ich dabei das Build Tooling komplett zu reduzieren, Babel weg (!) Webpack Dev Server weg (!) Bundling sieht bei neuen Web Apps einfach ganz anders aus und davon profitieren moderne Anwendungen und ihre Benutzer.

[@thenativeweb]

[gr] Danke schön 😊

[@chaoskai9380]

Sehr geiles Video. Ich liebe Javascript und mal was über die Hintergründe zu erfahren ist wirklich cool. Ich finde es immer wieder spannend, neue Sachen in / über Javascript zu lernen. Letztens habe ich in einem Live-Stream das object spreading entdeckt. Einfach nur cool so kleine Features. Danke für die ganzen Videos

[@thenativeweb]

[gr] Sehr gerne - und danke für das schöne Feedback 😊

[@flyingsquirrel3271]

Spannendes Video :) Obwohl ich "seltsam" für einen Euphemismus halte. Ich halte diesen ewigen Abwärtskompatibilitätszwang für außerordentlich schädlich, nicht nur in der Softwareentwicklung. Im Falle von JS frage ich mich, ob man da nicht mal nen Strich drunter machen könnte und was neues Entwickeln, das den heutigen Ansprüchen ganz anders entspricht. Klar, das ist aufwändig, aber nirgendwo so gerechtfertigt, wir dort. Man stelle sich ein Web vor in dem nicht tausende aufgeblasene Frameworks, willkürlich dran gezimmerte Funktionen und Schlüsselwörter und gar compiler, die halbwegs vernünftig designte PLs nach JS kompilieren mehr nötig sind. Letzteres alleine ist schon das krasseste Armutszeugnis für eine high level PL - dass Leute sowas überhaupt entwickeln zeigt überdeutlich, das mit den Abstraktionen in JS etwas grundlegend nicht stimmt. JS kann ja gerne im ist-Zustand neben der neuen Technologie noch in den Browsern weiter existieren so für 5-10 Jahre, aber warum muss die Menschheit heute noch unter den immensen Fehlentscheidungen einzelner Entwickler aus den Anfängen des interaktiven Internets leiden? Übrigens, was mich noch interessiert hätte in der Geschichte ist, wo da ActionScript/Flash reinpasst. Also zeitlich und technologisch. Im Grunde war das doch eine Alternativlösung, die auch auf Ecma-Script beruhte, oder?

[@thenativeweb]

[gr] Was ActionScript und Flash angeht, fehlt mir persönlich leider die Erfahrung. Ja, ActionScript basiert auf EcmaScript, und ActionScript 3 hat wohl auch einiges aus der verworfenen Version EcmaScript 4 aufgegriffen, aber mehr als das kann ich nicht wirklich sagen. Tut mir leid 😕

[@thenativeweb]

[gr] Das ist richtig, das spreche ja aber nicht gegen eine zusätzliche Sprache, in der müsste man ja nicht auf die Abwärtskompatibilität Rücksicht nehmen. Im Prinzip passiert ja genau das mit WebAssembly gerade …

[@flyingsquirrel3271]

@@thenativeweb Genau das meine ich. WebAssembly finde ich auch äußerst vielversprechend :)

[@MarcPeterBallay]

toll und spannend. Danke.

[@christianhorauf9958]

Was mich nach wie vor irritiert sind Generator Funktionen, für mit yield irgendwie Zwischenergebnisse einer Funktion zurück liefern können. Wo ist da genau der Unterscheid zu closures? Gibt es Praxis Beispiele ( also keine komplexen Algorithmen für die sich js ja wohl eher weniger eignet) bei denen man mit Generator Funktionen einen viel besser strukturierten Code erhält? Und wann wird der Code vor und nach dem yield genau ausgeführt?

[@monfort537]

Meines Wissens bedienen Closure- und Generator-Funktionen komplett unterschiedliche Anwendungsfälle. Generatoren sind beispielsweise nützlich, wenn ich unendliche Datenströme habe. Durch einen Generator kann ich mit next(), in Verbindung mit yield, eine bestimmte Anzahl Datensätze abgreifen und diesen Vorgang beliebig wiederholen. Ein Closure ist ja eher dazu da um Logik zu kapseln.

[@thenativeweb]

[gr] Vielen Dank für Dein Feedback - da würde sich tatsächlich ein eigenständiges Video zu yield anbieten, das Thema ist ja doch etwas komplexer … ich nehme es mal auf in unsere Themenliste!

[@aptfx]

Guy L. Steele Jr. ist nicht nur eine der Personen die an der Scheme-Spec mitgearbeitet haben (neben Sussman) sondern auch am ANSI Common Lisp Standard (ist neuer als Scheme) und.... Java. Der Grund: Steeles Erfahrungen mit Sprachspezifikationen von z.B. Scheme und ANSI Common Lisp. :). Scheme ist ja häufig für seine sehr kurze Spezifikation bekannt Der ANSI Common Lisp Standard ist dazu das Gegenteil. Während Scheme eher eine akademische Motivation hatte, war Common Lisp als Zusammenführung unterschiedlicher Lisp-Systeme dieser Zeit gedacht mit einer Ausrichtung als industriell einsetzbare vollwertige Programmiersprache. Der Sprachstandard ist etwa 1500 Seiten lang und erstaunlich durchdacht. Natürlich gibt es Aspekte in Common Lisp, die auf diesen "Amalgam"-Hintergrund hinweisen, aber es ist wirklich faszinierend wieviel Detailverliebtheit in jede einzelne Entscheidung geflossen ist. Was "Lisp-Sprachen mit non-Sexp Syntax" angeht gibt es tatsächlich einen Vorgänger dieser Idee: Dylan. Diese Ursprünglich bei Apple entstandene Idee ist effektiv ein sehr an Common Lisp angelehnter Kern mit einer "gewöhnlicheren" ALGOL/C-Artigen Syntax. Die Sprache sollte ursprünglich für den Apple Newton eingesetzt werden. Faszinierend: Damit ist Swift tatsächlich nicht die erste bei Apple entstandene "richtige" Programmiersprache. (Natürlich gibt es noch AppleScript, dass ja aber nur für Automatisierung gedacht war). Mit der Rückkehr von Steve Jobs zu Apple kam durch NEXT auch noch die Programmiersprache "Objective C" dazu. Bis heute finde ich Objective C als bessere Realisation von OOP in C als Stroustrups "C++". Was bei JavaScript ebenfalls noch interessant ist: Das OOP-System lehnte sich an neue Ansätze an die man bei Sun mit der Programmiersprache Self entwickelt hat. Die Idee dazu war, dass man auch die Metaebene eines Objektsystems im Objektsystem selbst beschreibbar macht. Dazu entwickelte man das Prinzip der Prototypen. Einen anderen Ansatz dazu bieter Common Lisp mit seinem "Metaobject Protocol" (MOP). Das minimalistische Scheme besitzt kein Objektsystem, aber die Lehrbücher enthalten viele Beispiele wie man mittels z.B. Closures sein eigenes Objektsystem bauen kann. Ein Konzept, dass ich bis heute bei anderen Programmiersprachen vermisse ist das "Condition & Restart"-System von Common Lisp. Im Prinzip handelt es sich dabei um eine Exceptionsystem (Exceptions heißen in Common Lisp "Conditions"). Der Unterschied: Conditions machen nicht sofort einen Stack-Unwind sondern _bleiben_ exakt in der Umgebung in welcher die Condition signalisiert wurde. Man kann dann den Fehler direkt dort behandeln. Alternativ kann man mittels "Restarts" auch in der Umgebung "Rücksprungpunkte" verankern. Die Behandlung kann dann einen dieser Rücksprungpunkte auswählen und die Ausführung dort fortsetzen (inkl. vorherigem Unwind des Stacks zu dieser Stelle). Das erlaubt es z.B. APIs zu schreiben die bestimmte Conditions signalisieren ("File not found", "File not writeable") und dann an der Verwendungsstelle der API mit einem "Condition Handler" zu behandeln. Mit passenden Restarts kann man so z.B. die Ausführung wiederholen oder eben einfach die Condition ignorieren und weitermachen. Das System integriert sich auch perfekt in den bereits in die Sprache integrierten Debugger. D.h. der Debugger meldet die Condition und bietet die Verfügbaren Restarts im Konsolenfenster (oder einem GUI-Dialog) an. Der Nutzer kann interaktiv einen Restart wählen und die Ausführung so fortsetzen. In vielerlei Hinsicht ist Common Lisp "modernen" Sprachen immer noch voraus. Sprachen wie Java oder C# wirken nahezu primitiv dagegen. Der ANSI Standard wurde zwar nie erneuert, aber für bestimmte neue Features wurden Spezifikationen entwickelt die von den verschiedenen Common Lisp-Implementierungen umgesetzt wurden. Es gibt z.B. neue APIs für Multicore-Programming. Es gibt mit "CLIM" auch ein GUI-Framework. Common Lisp besitzt heute auch einen Package-Manager und ein zugehörigen Loader. Mit "Quicklisp" kann man Lisp-Libraries auf einfache Weise herunterladen und in sein Lispsystem installieren. Quicklisp ist dabei selbst eine Lisp-API - d.h. man lädt libraries nicht über CLI-Tools sondern direkt in das laufende Lispprogramm. Generell werden Lispprogramme meist _im_ laufenden Programm entwickelt. Der Compiler ist selbst einfach nur eine Funktion "compile". Man kann sich zu jeder Funktion mit "disassemble" auch den generierten Maschinencode anschauen. Bugs können im laufenden System gepatcht werden ohne dass das Programm beendet werden muss. Werden z.B. Klassen erweitert/umdefiniert, so kann man festlegen wie die alten Instanzen im laufenden Programm auf die neue Klassendefinition umgewandelt werden sollen. Common Lisp kann auch durchaus sehr lowlevel werden. So kann man z.B. mittels Deklarationen festlegen, dass Objekte nicht auf dem Heap sondern auf dem Stack erzeugt werden (dynamic-extent-Deklaration). Man kann auch in jeder einzelnen Funktion unterschiedliche Optimierungsgrade festlegen.

[@dcxng6913]

Ich verwende let, const, async + await, fetch, arrow functions, destructuring, import, export ob ich alle neuen kenne glaube nicht aber versuche mich auf den aktuellen Stand zu halten. Videos über neue Features z.b. für ES2022 wären sehr interessant.

[@thenativeweb]

[gr] Danke für Dein Feedback 😊

[@DJTechnostyler]

Mal wieder ein super Video! Weiter so! Nur das Intro mit wem "und wenn du dich für XYZ interessierst, dann Abbo" finde ich irgendwie zu lang. Das solltest du abkürzen. Zum Thema: Ich persönlich bin seit es3 dabei und habe eigentlich alles durch gemacht. Heute verwende ich natürlich die neuen Keywords, auch weil sie viele Fehlerquellen vermeiden, wie z.B. das zugreifen auf eine Variable, die weiter unten mit var definiert wurde. Ich muss aber auch die alte Variante leider immer noch verwenden und kann viele Features wie beispielsweise auch Promises nicht nutzen, weil der Bundler das einfach nicht zulässt... Das DOJO Toolkit ist wirklich nicht so pralle. Ich würde nicht jede Version mal durchkauen, aber so die, die noch nicht in jedem Browser drinne sind und dann ein Jährliches Format, dass erklärt, was demnächst kommt. Das fände ich mega. Das Gleiche kann man auch für TypeScript machen.

[@thenativeweb]

[gr] Vielen, vielen Dank (und das Intro ist ab dem neuesten Video jetzt auch etwas kürzer) 😊 Was Dojo angeht, wusste ich gar nicht, dass das noch benutzt wird … das ist natürlich schade, wenn man wegen Altlasten nicht komplett auf die modernen Konstrukte gehen kann. Wegen "und dann ein jährliches Format" und "das gleiche kann man auch für TypeScript machen" - danke für das Feedback, wir gucken mal, wie wir das einarbeiten 😊

[@lokthar6314]

Danke für dein Video! Wie ist deine Haltung zu Go?

[@thenativeweb]

[gr] Du meinst, wie ich Go insgesamt so einschätze, was ich von der Sprache halte, was ich gut und was ich schlecht daran finde, oder …?

[@lokthar6314]

@@thenativeweb genau :-)

[@thenativeweb]

@@lokthar6314 [gr] Wir haben Go vor etlichen Jahren mal eine zeitlang gemacht, haben Go dann aber (bewusst) den Rücken gekehrt. Es gab durchaus Dinge, die ich an Go mochte, aber auch einiges, was ich nicht gelungen fand. Gruselig fand ich zum Beispiel das Modulsystem, das damals über Vendoring gelöst war - da hat sich in der Zwischenzeit aber einiges getan, da stecke ich aber nicht tief genug drin, um da eine wirklich fundierte Meinung zu haben. Insgesamt finde ich es eine interessante Sprache, die man sich durchaus mal angucken kann (oder sollte), aber sie reizt mich persönlich dann doch nicht genug, um mich da tiefer mit zu beschäftigen. Falls es Dich interessiert, ein kleiner Überblick zu Go: kzbin.info/www/bejne/g3SWc4KpjcSBb7s

[@lokthar6314]

@@thenativeweb Vielen Dank für deine ausgewogene und gut argumentierte Antwort! Ich werd mir das Video gleich anschauen, LG

[@thomask.7978]

Habe jahrelang jQuery verwendet und gar nicht gemerkt, dass das "normale" Javascript inzwischen z. B. auch mit komplexen Selektoren klar kommt. Viele neue Features muss man erst mal verstehen. Wieso brauche ich eine Fetch-API, wenn Ajax seit Jahren seinen guten Dienst tut. Wieso muss / soll ich Funktionen importieren, die in einer anderen Datei mit "export" deklariert sind. Promises wollen mir nach wie vor syntaktisch nicht ins Hirn. Syntax-Sugar durch Arrow-Functions sieht erst mal fachmännischer aus, ist aber auch so ein Ding, wo man drei mal hingucken muss, wenn da diese einzeiligen Kurzformen stehen. In den neuen Features stecken viele Lösungen zu Problemen, die mir gar nicht bewusst / bekannt waren / sind. Die Fragen, die ich mir dann so stelle sind: Ist es schneller, ist es einfacher zu verstehen, spart es Speicher oder Traffic, kann ich jetzt essentiell etwas tun, was ich vorher nicht tun konnte. Z. B. bei Modulen (import) müsste ich fast immer Nein sagen. Das einzige, was mich da überzeugt hat, ist das man Funktionen unter einem anderen Namen importieren kann, um Namenskollisionen zu vermeiden. Suche mir jetzt gleich nochmal ein "Why modules ?" - Video raus.

[@shioli3927]

Arrow Funktionen sind nicht nur syntax sugar, "this" bleibt in der ganzen Arrow Funktion das gleiche und es wird kein eigenes "this" für die Funktion erstellet. Promises und async/await sind sehr toll, solltest du dir genauer anschauen. Kommt eigentlich überall vor mittlerweile. Großteils wird async/await ausreichen ist etwas leichter zu lesen als promises. Im grunde ist async/await nur Syntax sugar für ein Promises. Du kannst auch ohne weiteres beide mischen. Mit promises hat man etwas mehr Flexibilität in edge Cases, da du z.B. die resolve Funktion statt gleich auszuführen dir für später merken kannst z.B. wenn dein API token ausläuft kannst du dir den callback merken, einen neuen API token abfragen und dann alle requests die fehlgeschlagen sind nochmal probieren mit dem neuem token. Fetch war schon lange überfällig nur für Ajax calls jQuery überall einzubinden ist Schwachsinn. XMLHttpRequests (XHR) waren vor fetch und diese sind mittlerweile sehr in die jahre gekommen. Speedmäßig tut sich da nicht viel, fetch ist schneller bei der json deserialization. Der eigentliche request wird nicht schneller. jQuery ist allgemein kein speed wunder, das benützt auch nur das was in js verfügbar ist (also XHR oder fetch, vermutlich XHR). Modules wenn du mit jQuery arbeitest (vermutlich keine Single Page Application (SPA)) kann ich schon sehen wie man den sinn nicht ganz greift. In den ganzen SPA frameworks die wir jetzt haben (vue, angular etc) ist das ganze viel wichtiger. Weil dort alles was jemals in das global scope geschrieben wird dort auch bleibt bis der Benutzer die seite komplett schließt. Ein Seitenwechsel in einer SPA wechselt nicht die seite sondern tauscht Elemente mit javascript aus und schreibt was anderes in die url bar im browser nur damit der user sieht das er jetzt logisch sich auf einer anderen "seite" befindet. Aber ein Seitenwechsel findet nie statt. Kein wirklicher Seitenwechsel = gefühlt schnellere Anwendung und Transitions zwischen seiten sind möglich, aber auch dass das global scope nie resetted wird. D.h. irgend ne Unterseite irgendwo kann Auswirkungen haben auf irgendeine komplett andere Unterseite irgendwo anders im code wenn du ohne groß drüber nachdenken Sachen ins global scope schreibst. Deswegen gibt es Import / export. Damit kannst du Programme schreiben die lesbar bleiben die nie auch nur eine einzige variable ins global scope schreiben müssen. Vorher ging das meines Wissens nach gar nicht wenn du Funktionen von einem js file in einem anderem benutzen wolltest musstest du irgendwas ins global scope schreiben anders gab es keinen austausch.

[@thomask.7978]

@@shioli3927 Bedanke mich recht herzlich für die tolle, hilfreiche und im guten Geiste geschriebene Antwort.

[@K_Andreas]

Danke! Frage: Wie und wo erfahre von allen Neuerungen bei JS?

[@thenativeweb]

ECMAScript 2016 bis 2021 kzbin.info/www/bejne/qKOxe2qnaayciZI ECMAScript 2022 kzbin.info/www/bejne/mJeTdqRvopqbgsU ECMAScript 2023 kzbin.info/www/bejne/iYrMf6ebm7uFgrs Zu 2024 haben wir noch kein Video gemacht, weil die 2024er-Version nicht interessant war, das koppeln wir dann vielleicht im kommenden Jahr mit der 2025er. Generell, wenn Du wissen willst, ob es zu einem bestimmten Thema ein Video von uns gibt, guck mal hier: app.thenativeweb.io/

[@S3R43o3]

Sehr sehr toller Kanal Danke für das kostenfreie wenn auch nicht kostenlose know how ! =)

[@thenativeweb]

[gr] Vielen lieben Dank 😊

[@ikemkrueger]

Meine Daumenregel ist, wenn ich durch neue Sprachfeatures weniger Code schreiben muss, und dadurch die Lesbarkeit verbessert wird, benutze ich die Sprachfeatures. "Async" und "await" gefällt mir z.B. viel besser als "Promises". Die sind von der Lesbarkeit her furchtbar.

[@cafeleche]

Super Video, Danke 🤩

[@thenativeweb]

[gr] Sehr gerne 😊

[@btx47]

Ich nutze mittlerweile nur noch TypeScript und nutze alle verfügbaren Sprachmerkmale

[@Tesla42]

D.h. auch man könnte SVG direkt in JS einbinden? Also die Zahlen in SVG einfach gegen Ausdrücke ersetzen?

[@thenativeweb]

[gr] Mit EcmaScript for XML wäre das möglich gewesen, und mit JSX ist das heutzutage auch möglich, also das ist im React-Umfeld durchaus gängig, so vorzugehen.

[@Tesla42]

@@thenativeweb gut, da habe ich bisher noch keine Beispiele gefunden.

[@thenativeweb]

@@Tesla42 [gr] Guck Dir zum Beispiel mal blog.logrocket.com/how-to-use-svgs-in-react/ an …

[@Tesla42]

@@thenativeweb das ist leider nicht das was ich will. Ich möchte einfach SVGs erstellen, wo ich einzelne Parameter gegen Variablen, Funktionen oder Inline-Berechnungen ersetzte.

[@peterlange5624]

Kein Wunder, daß SICP von den gleichen Autoren im April 2022 als Javascript Edition erscheint. Die letzte, überarbeitete Auflage von SICP erschien 1996.

[@thenativeweb]

[gr] Das ist die beste Nachricht des Tages 🎉 Für alle, die es interessiert: Es ist bereits vorbestellbar - siehe www.amazon.de/dp/0262543230

[@ettoreatalan8303]

Kurze Zusammenfassung zum Video: Ein Mann mit komischen Ansichten (Brendan Eich) hat innerhalb von 10 Tagen einem LISP-Dialekt eine Java-Syntax übergestülpt und die *_European_** Computer Manufacturers* Association hat das Ganze dann standardisiert. Alle Erwartungen wurden erfüllt.

[@thenativeweb]

[gr] Wenn man es so formuliert, klingt es tatsächlich noch deutlich seltsamer 🤣 (Und das Schlimme ist, das ist ja nicht mal verkehrt …)

[@yahmk3978]

Vielen Dank!

[@thenativeweb]

[gr] Sehr gerne 😊

[@jeyt436]

Als ich begann, JS zu lernen, kam sie mir gar nicht seltsam vor. Hatte mir vorher nur Python angeschaut. Da waren vor allem die geschweiften Klammern um Codeblöcke neu. Und natürlich die Wörter let und var.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@jeyt436]

@@thenativeweb bitte

[@automatenmark5051]

Eigentlich ist es echt lustig, dass gerade JavaScript derart populär geworden ist

[@gregcyrus2739]

Linux: Everything is a file. JS: Everything is a function. (Ich liebe solche Paradigmen)

[@thenativeweb]

[gr] Ja, das trifft es ganz gut 😊

[@Sourcer3r]

JS: Everything is an object. (Außer Keywords, bis es5) Danke an Lisp 😉

[@dcxng6913]

Ecmascript 4 XML landete glaube ich als ActionScript 3

[@thenativeweb]

[gr] Ja, wobei ich mir nicht ganz sicher bin, ob komplett oder nur in weiten Teilen.

[@bibamann]

Und jetzt ohne Scheiss: ActionScript 3 ist so die schönste Sprache, die mir bisher untergekommen ist. Was damit gemacht wurde (flash) steht auf einem anderen Blatt, aber als Sprache war die ja echt nur Zucker.

[@luricci8471]

ich habe die Serverseite weitgehend fertig und muss demnächst die Client Seite entwickeln, deshalb wird wohl die aktuellste modernste Javascript Version die erste Wahl sein obwohl es draussen viel Schrott gibt

[@orange-vlcybpd2]

"unübersichtliche und seltsame Versionsgeschichte"? In dieser Hinsicht kann man DotNet kaum überbieten :D

[@zeitiger]

Naja 1995 war CSS noch nicht wirklich ein Ding, da war man eigentlich auf HTML beschränkt.

[@thenativeweb]

[gr] Ja, da hast Du recht - CSS gab es damals zwar schon, aber noch nicht so wirklich verbreitet, das kam erst 1996/97.

[@longingbydesign]

Verschachtelte Tabellen überall...

[@silentwater79]

Und meiner Meinung nach auch an einer grottigen, schlecht lesbaren Syntax. Die Syntax mag zwar an Java angelehnt sein, ist aber in vielen Bereichen einfach grottig gemacht worden.

[@thenativeweb]

[gr] "Automatic Semicolon Insertion" aka Semikola sind optional wäre da mein Favorit … 😉 (Gibt aber noch einiges mehr, was keine gute Idee war / ist)

[@silentwater79]

Nutze lieber Typescript als pur Java Script und währe auch dafür, das Browser nativ Type Script unterstützen.

[@thenativeweb]

[gr] Früher war das bei mir anders - ich habe lange Zeit einen großen Bogen um TypeScript gemacht. Heute kann ich mir das allerdings nur noch schwerlich vorstellen, ohne den Compiler "quasi als jemand erfahreneres, die/der mir über die Schulter schaut" zu arbeiten 😊

[@videobytrkx]

Das heißt einfach Entwickler und damit sind Frauen und Männer gemeint. Hört auf mit dieser Gender Kacke

[@moritz1997me]

Finde ich auch extrem nervig und ablenkend. Darum keinen Daumen hoch oder gar Abonnement für dieses Video :(