"The JavaScript phenomenon is a mass psychosis"

bashing
javascript

#1

Amen!


Frust-Thread
#2

Amen²

… und weitere Zeichen um auf die 10 vorgeschriebenen Zeichen zu kommen…
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet,


#3

Sitze hier gerade in einem Meeting mit dem Thema:

etabliertes Framework (seit 5 Jahren, c++, Java) wird abgelöst duch REST, Typescript, brave new World

SAUFEN!

SAUFEN!

SAUFEN!


#4

Typescript != Javascript

Der Artikel sagt ja auch explizit, dass es eine Lösung sein kann eine Transpilersprache zu nutzen.

Generell stimme ich aber auch zu, wer freiwillig mit Vanilla Javascript arbeitet, ist mir suspekt


#5

Da stimme ich zu. In letzter Zeit habe ich angefangen, mit MongoDB, Express, React und Node zu “arbeiten”. Und mir graut ehrlich gesagt davor, was gerade in der Welt passiert: Millionen von Entwicklern generieren Milliarden Zeilen Code in einer Programmiersprache, die in vieler Hinsicht und auf viele Ebenen (und, das muss man betonen: Ganz objektiv, und ohne Sprachbashing betreiben zu wollen) schlecht ist.

Die Halbwertszeit dieses Codes und der damit verbundenen Systeme (Frameworks, Frameworks, Frameworks ĂĽberall!) ist so kurz, dass ich bis zu einem gewissen Grad sogar nachvollziehen kann, wenn man gar nicht erst versucht, es gut zu machen. Man kann ein Snippet von Stackoverflow oder aus einem Blog oder von Github kopieren, und das macht, was es soll. Wenn man etwas anderes braucht, kopiert man ein anderes Snippet. Warum sollte man versuchen, nachzuvollziehen, was das Snippet macht, wie es genau funktioniert und welche Sprachfeatures und Frameworks dort wie kombiniert werden, um den gewĂĽnschten Effekt zu erreichen? Warum (und wie, rein technisch und methodisch) sollte man das Snippet kommentieren wenn man das gar nicht weiĂź und versteht?

Die vielgeschmähte “Wegwerfgesellschaft” ist bei den Softwareentwicklern angekommen. Nachhaltigkeit? Für’n Arsch. Jeder, der versucht hat, “nachhaltige” Software auf Basis von Angular 1 zu entwickeln, hat schlicht seine Lebenszeit aufs sinnloseste vergeudet.

*mit den händen wedelt und abwechselnd mit den fingern der rechten und linken hand schnippt* : Wir sind agil. Yeah.

(Braucht jemand ein JDK 1.1? Das erstellt classfiles und JARs, die heute noch funktionieren… (ja, ein bißchen Sprachenbashing ist es - aber das bashing bezieht sich weniger auf die Sprache an sich, sondern eher wie man mit den Schwächen der Sprache umgeht, und das, was offenbar das allgemeine Mindset der so genannten “Web-Developer” ist …)


#6

I’ve been writing web applications for over a decade and it’s utterly shocking how little JavaScript I know!

Vielleicht ist genau das das Problem. Vielleicht sollte man sich einmal vernünftig mit der Sprache auseinanderzusetzen (etwa hiermit), anstatt zu versuchen, sie mit “was-will-ich-machen + javascript” Google Suchanfragen und StackOverflow-Snippets zu erlernen.

JavaScript is that it can actually fail silently at runtime due to syntactical errors!

Javascript-Code wird zur Laufzeit kompiliert, und sollte es wirklich Santaxfehler geben, werden sie in der Konsole ausgegeben. Ein Gegenbeispiel wĂĽrde ich gerne sehen.

What other modern programming language is so bad that a linter is most recommended for safety sake?

Eh, jede? Oder schreibt er seinen Java-Code in notepad.exe? Eine (Skript-)Sprache, die einen Linter braucht - unfassbar :rolling_eyes:

Dann regt sich der Autor über die “Callback Hell” auf, für die es Lösungen jenseits der Promises gibt (etwa Generatoren, async/await). In meinem aktuellen (beruflichen) JS-Projekt hatte ich das Problem gar nicht.

JavaScript hat sicherlich mehr als ein paar Probleme, aber der Artikel basiert größtenteils auf Unwissenheit und Ignoranz.


#7

Buuuh, das verlinkte Buch verwendet ja nichtmal die (arrow) => notation, und beschreibt Promises… Promises!!!, Mann, das ist ja so Februar 2017! Seit März verwendet man async/await - das wird da ja nur als Randnotiz erwähnt. Sowas von L4m3! :nerd:

Mal im Ernst: Die Sprache ist von Grund auf ziemlich vermurxt, und einen richtigen bashing-rant hatte ich ja vor einer Weile schon abgelassen. Und natürlich kann man immer (z.B. auch bei diesem Artikel) mehr “Sachlichkeit” und “Objektivität” einfordern (auch wenn das nur heißt, dass man sich etwas gesagt wünscht, was eher der eigenen Meinung entspricht). Zusätzlich muss jeder, der etwas kritisiert, damit rechnen, dass jemand, der sich (“besser”?) mit dem Thema auskennt, den Kritikpunkt invalidiert. Aber was ich öfter beobachte: Wenn man sagt/feststellt, dass etwas Sche!ße ist, dann wird gerechtfertigt, dass das so ist, und begründet, warum das so ist - das ändert aber nichts an der Sache an sich.

Egal, wie ausführlich man sowas wie Hoisting erklärt: Das ist einfach Murx. Und zu der Frage, was “fail silent” bedeutet, kann man unterschiedliche Meinungen haben. Auch wenn die strenge Typisierung bei anderen Sprachen manchmal wie ein Korsett wirkt, aus dem man sich befreien möchte, und z.B. sowas wie Duck Typing einem das Leben vermeintlich einfacher machen kann: Ich finde, dass

function f(x) {
    return x * 2;
}

// Das
f("some string");

// Oder das (!!!)
f(1234, "this", "is", "ignored");

schlicht nicht möglich sein sollte. Von den absuden Auswüchsen, die der Versuch hat, “Objektorientierung” in die Sprache zu bringen, will ich gar nicht anfangen. “Prototypenbasiert” klingt toll, und genau wie in anderen Bereichen kann Kritik abgeschmettert werden, mit einer Aussage wie: “Du hast das nur noch nicht richtig verstanden” (was soll man auch dagegen argumentieren? “Doch, habe ich - und es ist kagge!” ???)

Aber mal Klartext: JavaScript ist eine Scriptsprache, die eigentlich dem Zweck diente, auf Webseiten so einen tollen Glüh-Effekt über Buttons legen zu können, wenn man mit der Maus drüberfährt. Dass damit heute kritische Infrastrukturen betrieben werden ist …

… ja, sicher, “Massenpsychose” klingt unsachlich, aber … trifft es bei geeigneter Interpretation schon recht genau.


#8

An JavaScript ist eigentlich schon schlimm genug, dass Scripts externer Quellen globale Variablen überschreiben können, weil man es anscheinend es nicht für notwendig empfunden hat, externe Scripts in eine Sandbox zu stecken. Vernünftige Lösung des Problems kann dabei eigentlich nur NoScript sein.

Ich bin ehrlich gesagt froh, dass ich mit JavaScript nicht ernsthaft arbeiten muss; folgendes Blogpost erklärt das auch ganz gut. https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f (Zwar von 2016 ist aber immer noch aktuell).


#9

Klar, jeder liest auch die Konsole staendig, weil das die beste Art Fehler zu melden.

IMHO ist eines der groessten Probleme die Qualitaet der Frameworks und die Geschwindigkiet mit der neue, halbfertige Framework als Ersatz “rausgeschleudert” werden. Die generellen “Sprach-Probleme” von JS sind in ihrer eigenten Liga IMHO

https://dayssincelastjavascriptframework.com/

Mocha, QUnit, Chai… und das nur fuer Unit Tests, beim Build sieht es nicht besser aus, gulp, npm, yarn… dann die Tatsache dass eigentlich nix zuverlaessig funzt was die Dependencies angeht (left-pad, letzte Woche konnte man NodeJS nicht runterladen) und es zig Ausnahmen gibt (PhantomJS im npm repo? Nee… natuerlich nicht, wird munter von Github/Bitbucket runtergeladen)…


#10

Als Entwickler? Sicherlich. Jede Programmiersprache nutzt die Konsole = stdout. Dass die Konsole im Browser über DevTools zu bedienen ist, hat mit JS nichts zu tun. Was wäre denn eine Alternative? Mit einer IDE-Unterstützung lässt man sich die Konsole außerdem direkt in der IDE anzeigen.

Man wird von der Vielzahl der Libraries wirklich erschlagen. Aber man muss auch nicht sofort jeden neusten Shit nehmen. (Die Entscheidung, Bootstrap 4 Alpha (!) bei uns in Produktion einzusetzen, werde ich niemals verstehen…)

Dass es mehrere etablierte Test-Frameworks gibt, sehe ich als Vorteil (die Recherche dazu wiederum als Nachteil…). Ich kann sie ausprobieren und die Library nehmen, die mir am besten gefällt. Chai ist übrigens keine Test-Library an sich, sondern dient lediglich dazu, verschiedene Assertion-Interfaces anzubieten. Damit kann ich sowohl das klassische TDD, als auch zwei Varianten von BDD verwenden, ohne mein Test-Framework zu wechseln:

foo.should.equal('bar');     // BDD should
expect(foo).to.equal('bar'); // BDD expect
assert.equal(foo, 'bar');    // TDD assert

Das gleiche gilt für Build-Tools. Schreibe ich lieber Konfigurationsdateien (=Grunt) oder lieber direkt JS-Code (=Gulp)? Ist der Build-Prozess trivial? Dann bleibe ich bei einfachen NPM-Skripten. Muss ich auf das neue Yarn umsteigen? Nö, aber es bietet einige Vorteile und ist abwärtskompatibel zu NPM. Muss ich mich mit all dem und noch viel mehr als Frontendentwickler auseinandersetzen, während ich in Java einfach JUnit und Maven nehme? Jup…


#11

Etwas philosophisch abschweifend: Ich denke, dass einige der Probleme, die JavaScript hat, in seiner frĂĽheren Rolle verwurzelt sind.

(Eigentlich müßte man dabei, wie bei Java, unterscheiden zwischen der Sprache an sich und dem Ökosystem, das drumherum existiert. Die Sprache ist eine Sache. Die Komplexität, (mangelnde) Qualität, (mangelnde) Nachhaltigkeit und das Zusammenspiel der Frameworks ist eine andere. Den “How it feels to learn JavaScript in 2016”-Artikel, der oben verlinkt ist, wollte ich eigentlich schon früher posten, hatte ihn aber auf die Schnelle nicht gefunden. Ich finde, er trifft es ganz gut: Für jedes Framework, das man verwenden will, gibt es drei Alternativen, und meistens hat jede der Alternativen eine Schwäche oder Einschränkung, die es unbenutzbar macht - außer, wenn man ein weiteres Framework verwendet, um diese Schwäche auszubügeln)

Diese frühere Rolle ist, wie schon gesagt: Ein paar Zeilen JavaScript in eine HTML-Seite reingedengelt, um einen modern aussehenden Button-Hover-Effekt oder ein animiertes Menü zu basteln. Ich denke, dass viele, die keine “Informatische Ausbildung” haben, über diesen Weg mehr oder weniger in die Entwicklerrolle reingestolpert sind. Sie haben eine Webseite gebastelt, da etwas JavaScript drin untergebracht, dann etwas mehr mit JavaScript gemacht, und viel von Stackoverflow kopiert, und das ganze wurde immer komplexer, ohne dass

  • die Sprache JavaScript selbst fĂĽr “komplexere” Anwendungen gedacht war (Klassen, Packages, Module? Nope…)
  • die Entwickler die Grundprinzipien kennten, die dafĂĽr notwendig wären (SOLID? Ohne Klassen? Nope…)

Diese Wahrnehmung ist erstmal spekulativ und subjektiv (und die hatte ich schon vor 5 Jahren, darum müßte sie inzwischen eigentlich falsch sein), und könnte von einigen als ungerechtfertigte Unterstellung aufgefasst werden. Aber es gibt Punkte, die ich zumindest als Indizien dafür ansehe, dass ich damit Recht haben könnte:

Dort heiĂźt es (an der verlinkten Stelle) :

Web and mobile developers have significantly less professional coding experience, on average, than developers in other technical disciplines

wo ca. 40% weniger als 4 Jahre Erfahrung haben, mit dem “Peak” bei 1-2 Jahren (!). Das ganze wird wohl noch verstärkt durch das allgemeine “Mindset”, dass einmal pro Jahr alles bisher erstellte in die Mülltonne geworfen und from Scratch auf Basis des “latest and greatest” Frameworks erstellt wird.

(Abgesehen von solchen Fragen fand ich beeindruckend, wie fragil die ganze Infrastruktur an sich ist - was ja durch das left-pad-desaster deutlich wurde…)


#12

Denke dass das nicht nur nur JS gilt, sondern fuer alle Programmierprachen, alle 5 Jahre verdoppelt sich sich die Anzahl der Entwickler weltweit, d.h. dass 50% aller Entwickler weniger als 5 Jahre Erfahrung haben.

Denke dass die “explosion” von neuen JS Frameworks wirklich eine kulturelle Ursache hat.

IME sehr fragil :frowning:
Wie gesagt, letzte Woche war es NodeJS selber dass fuer ein paar Stunden nicht mehr runtergeladen werden konnte, das hat nicht nur die Entwicklung betroffen, sondern auch Produktivsysteme.

left-pad braucht ja nicht mehr erklaert zu werden :slight_smile:
Warum werden so gut wie keine Proxies/Caches eingesetzt? “We don’t need that, its working most of the time”
Fuer mich sieht dass alles symptomatisch aus, “this is how we roll”…


#13

Ich sehe das Problem JS bei meiner Arbeit, dass Firmen bestimmte Frameworks einsetzen und überhaupt nicht verstehen wie bestimmte Prozesse implementiert sind. Zum Beispiel die Authentifizierung. Da werden Tokens generiert, damit neue Tokens generiert, beide sind aber gültig aber unterschiedlich lange…und das Unternehmen selbst hat keinen Schimmer aber bastelt daran rum um es anzupassen.


#14

Einen Punkt vergesst ihr hier alle: Javascript - die “Sprache” - ist ein kaum erwähnenswertes, flüchtiges Nichts von ein paar Zeilen.

Das macht JS so unglaublich flexibel und abgrĂĽndig, dagegen wirkt Lisp ja bĂĽrokratisch und starr.

Leider ist so etwas in der täglichen Praxis der Software-Entwicklung völlig unbrauchbar, weshalb dieser Agrund jetzt zugekleistert wird mit Frameworks und Cross-Compilern. Für mich ist diese Ecke sowas wie die im Finstern liegenden Klohäuschen bei einem Open Air: nicht wirklich angenehm, aber wenn man wirklich dringend muss macht man die Aufenthaltsdauer so gering wie möglich.


#15

Bin auch nicht von Javascript begeistert. Aber gibt es vernünftige Alternativen, die nicht wieder in Javascript übersetzt werden und in allen gängigen Browsern funktionieren?


#16

Java-Applets

https://docs.oracle.com/javase/tutorial/deployment/applet/doingMoreWithApplets.html

DOM-Manipulation, Events entgegennehmen auch wenn es hier ein klein wenig JavaScript bräuchte.

Eigentlich alles, wofür man JavaScript im großen und ganzen verwendet ist damit möglich, sofern man keinen Browser verwendet der Applets nicht unterstützt. Also mittlerweile kein Browser mehr. Dennoch ist und war alles was die JS-Frameworks heute so bieten, damit schon vor über 10 Jahren mit Leichtigkeit zu machen.

Ok, nicht ganz ernstgemeint, aber rĂĽckblickend sehr amĂĽsant.