Fortsetzung JS-Diskussion aus "GreaseMonkey zum Individualisieren des Forums"
-
Shade Of Mine schrieb:
Nathan schrieb:
Und deswegen ist die einzige Kritik, die ich Sone geben kann, dass das Javascript ist.
Denn ich habe noch nie Javascript gesehen, was schön ist, weswegen ich Sones Code auch nicht kritisieren kann*.* Abgesehen davon, dass ich selber nicht gut genug Javascript kann.
Kannst du einen neuen Thread aufmachen? am besten in webzeugs wo du javascript fundiert kritisierst?
Ist hiermit geschehen.
denn javascript ist eigentlich eine ziemlich tolle sprache. es wird halt hauptsaechlich von anfaengern verwendet, was natuerlich zu vielen schlechten js code fuehrt, aber die sprache ansich ist ziemlich gut.
sie hat ihre quirks, keine frage - zB was ist []+[] ? aber generell ist sie ziemlich cool und flexibel.OK, kann sein, dass ich bisher nur Anfängercode gesehen habe und meine Meinung dementspechend geprägt ist.
Aber ich persönlich finde diese Sprache nicht "ziemlich gut".
Ich kann mich ja mit der Seltsamen Art Klassen zu "definieren" anfreunden. Ist alles eine Sache der Gewöhnung.
Ich kann mich mit den Browserinkompatiblitäten anfreunden, ist bei C++ teilweise nicht viel anders.
Ich kann mich mit Java-like new Syntax zum Erzeugen von Objekten anfreunden.
Ich kann mich mit kryptischen Dingen anfreunden.
Ich könnte mich auch mit dem (soweit ich weiß) fehlendem RAII anfreunden.
Ich könnte mich mit alles anfreunden, nur nicht auf eins:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Ich will verdammt nochmal einen Fehler, wenn ich eine Funktion, die (konzeptuell) eine Ganzzahl braucht, mit einem String aufrufe und nicht dass der String "irgendwie" in eine Zahl konvertiert ist.
Ich will einen Fehler, wenn ich mich bei einem Variablenname vertippe und nicht, dass stattdessen eine neue Variable eingeführt wird.
Ich will nicht, dass ich für die Sprache denken muss, sondern die Sprache für mich. Bei soetwas normalem wie einem Funktionsaufruf, will ich nicht erst überlegen müssen, was die Funktion erwartet und was ich der Funktion gebe und ob die automatische Konversion in diesem Fall in Ordnung ist. Ich will einen Fehler, ich will, dass die Sprache diese Gedanken sich für mich macht und ich dann explicit casten muss oder auch nicht, jenachdem. Gut, Javascript ist nicht so sehr ein "Minenfeld" wie PHP, aber genug ist da. Genug, dass ich diese Sprache für nicht schön halte.Die vielen "ich"s zeigen es schon, dass ist meine subjektive Meinung zu Javascript.
Edit: Kann sein, dass vieles aus meiner Kritik auch darauf beruht, dass ich die Sprache nicht gut genug kann, wenn das so ist, bitte korrigier mich.
-
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Dann bleib doch bei deinen statisch typisierten Sprachen
Also mal ehrlich, andere Konzepte ermöglichen andere Herangehensweisen/Möglichkeiten. Nur weil deine erste Programmiersprache jede Variable bei Deklaration typisiert, kannst du jetzt hierbei nicht umdenken?! óÔ"Ich will verdammt nochmal einen Fehler, wenn ich eine Funktion, die (konzeptuell) eine Ganzzahl braucht, mit einem String aufrufe und nicht dass der String "irgendwie" in eine Zahl konvertiert ist.
Dann bau dir die Funktion so, so dass sie dir einen Fehler wirft. Wo liegt das Problem? Das Zauberwort lautet "typeof" -.-
Ich will einen Fehler, wenn ich mich bei einem Variablenname vertippe und nicht, dass stattdessen eine neue Variable eingeführt wird.
Den bekommst du doch auch oO?! Verwechselst das wohl mit PHP!
Ich will nicht, dass ich für die Sprache denken muss, sondern die Sprache für mich. Bei soetwas normalem wie einem Funktionsaufruf, will ich nicht erst überlegen müssen, was die Funktion erwartet und was ich der Funktion gebe und ob die automatische Konversion in diesem Fall in Ordnung ist. Ich will einen Fehler, ich will, dass die Sprache diese Gedanken sich für mich macht und ich dann explicit casten muss oder auch nicht, jenachdem. Gut, Javascript ist nicht so sehr ein "Minenfeld" wie PHP, aber genug ist da. Genug, dass ich diese Sprache für nicht schön halte.
Da wären wir wieder bei deiner Befangenheit gegenüber dynamisch typisierten Sprachen :p
Der Thread ist Bullshit....
Edit:Kann sein, dass vieles aus meiner Kritik auch darauf beruht, dass ich die Sprache nicht gut genug kann, wenn das so ist, bitte korrigier mich.
Davon gehe ich aus
Beschäftige dich eingehender mit ihr und lerne sie lieben
-
epTical schrieb:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Dann bleib doch bei deinen statisch typisierten Sprachen
Also mal ehrlich, andere Konzepte ermöglichen andere Herangehensweisen/Möglichkeiten. Nur weil deine erste Programmiersprache jede Variable bei Deklaration typisiert, kannst du jetzt hierbei nicht umdenken?! óÔ"Liebend gern bleib ich bei meinen statich typisierten Sprachen, warum ich den Thread hier erstelle ist aus der diskussion aus dem ursprünglichen Thread ersichtlich.
Es geht um meine Kritik an Javascript.Ich will verdammt nochmal einen Fehler, wenn ich eine Funktion, die (konzeptuell) eine Ganzzahl braucht, mit einem String aufrufe und nicht dass der String "irgendwie" in eine Zahl konvertiert ist.
Dann bau dir die Funktion so, so dass sie dir einen Fehler wirft. Wo liegt das Problem? Das Zauberwort lautet "typeof" -.-
Wieso muss ich etwas tun, was auch der Interpreter tun kann?
Ich will einen Fehler, wenn ich mich bei einem Variablenname vertippe und nicht, dass stattdessen eine neue Variable eingeführt wird.
Den bekommst du doch auch oO?! Verwechselst das wohl mit PHP!
Kann sein.
Ich hatte mal aber einen schwer findbaren Fehler, der darauf beruhte*. Kann das Beispiel nur nicht mehr reproduzieren.
*Kann auch sein, dass ich die Fehlermeldung übersehen habe.Ich will nicht, dass ich für die Sprache denken muss, sondern die Sprache für mich. Bei soetwas normalem wie einem Funktionsaufruf, will ich nicht erst überlegen müssen, was die Funktion erwartet und was ich der Funktion gebe und ob die automatische Konversion in diesem Fall in Ordnung ist. Ich will einen Fehler, ich will, dass die Sprache diese Gedanken sich für mich macht und ich dann explicit casten muss oder auch nicht, jenachdem. Gut, Javascript ist nicht so sehr ein "Minenfeld" wie PHP, aber genug ist da. Genug, dass ich diese Sprache für nicht schön halte.
Da wären wir wieder bei deiner Befangenheit gegenüber dynamisch typisierten Sprachen :p
Ja.
Ich gebs ganz ehrlich zu: Ich bin zu blöd für dynamisch typisierte Sprachen.
Genauso wie manche für Exceptions zu blöd sind, bin ich zu blöd für dynamisch typisierte Sprachen.
Ich kann/will mich nicht mit Dingen beschäftigen, die mein Compiler/Interpreter für mich erledigen kann.Der Thread ist Bullshit....
s.o.
Edit:
Kann sein, dass vieles aus meiner Kritik auch darauf beruht, dass ich die Sprache nicht gut genug kann, wenn das so ist, bitte korrigier mich.
Davon gehe ich aus
Beschäftige dich eingehender mit ihr und lerne sie lieben Naja, solange ich keinen Grund habe Javascript zu verwenden, will ich es auch nicht (Vorteil von Hobbyprogrammierer :p ).
Das Grundkonzept der Sprache gefällt mir einfach nicht.
-
Nathan schrieb:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Das ist etwa das gleiche Niveau wie
"Ich mag C++ nicht, weil ich kann mich nicht mit einer Sprache abfinden, die keinen Garbage Collector hat, weil Pointer machen alles unsicher"Dynamische Typisierung ist ein erklärtes Feature. Viele Sprachen haben das. Python, Perl, PHP, (C++-Templates,) etc.
Dynamische Typisierung ist nachweisbar beliebt bei vielen Programmierern.
Siehe das Zitat hier: http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages
Statische Typisierung bedeutet nicht "Kompiliert => Korrekt". Im Gegenteil. Man kämpft mit dem Typsystem um es zum kompilen zu bekommen und gewinnt dadurch nichts. Der allererste Unit-Test einer dynamischen Programmiersprache zeigt dir den Fehler auf und das noch bevor dein Programm kompiliert hat. Und nicht nur Typfehler, sondern alle Arten von Fehlern, die der C++-Compiler schweigend durchgehen lässt. Bugs finden und beheben ist in dynamischen Programmiersprachen einfacher als in statischen.Meine Aussage ist vielleicht etwas übertrieben und du kannst gerne dagegen argumentieren, aber bitte denke nicht über JavaScript als schlechte Kopie von C++. Genauso kann man nicht über C++ als schlechte Kopie von Java denken (siehe Zitat oben). Lasse dich auf das Denken ein und entscheide erst dann, nachdem du erste Erfahrungen gesammelt hast.
-
Alle die immer an JavaScript rumnörgeln zeige ich zz gerne dieses Video
https://www.youtube.com/watch?v=Trurfqh_6fQ
allgemein sollte man sich Videos von Douglas Crockford ansehen.
-
emphatisant schrieb:
Nathan schrieb:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Das ist etwa das gleiche Niveau wie
"Ich mag C++ nicht, weil ich kann mich nicht mit einer Sprache abfinden, die keinen Garbage Collector hat, weil Pointer machen alles unsicher"Stimmt. Der Satz war vielleicht ein wenig zu strikt formuliert.
Dynamische Typisierung ist ein erklärtes Feature. Viele Sprachen haben das. Python, Perl, PHP, (C++-Templates,) etc.
Gut, dass du C++-Templates eingeklammert hast.
Die schaffen das Spagat zwischen Typsicherheit und dynamischer Typisierung.
Aber nur weil viele Sprachen etwas haben, heißt das noch lange nichts. Viele Sprachen haben das auch nicht.Dynamische Typisierung ist nachweisbar beliebt bei vielen Programmierern.
Aber nicht bei mir.
Siehe das Zitat hier: http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages
Statische Typisierung bedeutet nicht "Kompiliert => Korrekt". Im Gegenteil. Man kämpft mit dem Typsystem um es zum kompilen zu bekommen und gewinnt dadurch nichts. Der allererste Unit-Test einer dynamischen Programmiersprache zeigt dir den Fehler auf und das noch bevor dein Programm kompiliert hat. Und nicht nur Typfehler, sondern alle Arten von Fehlern, die der C++-Compiler schweigend durchgehen lässt. Bugs finden und beheben ist in dynamischen Programmiersprachen einfacher als in statischen.Kannst du mir bitte ein Beispiel geben, weil so ganz weiß ich nicht, worauf du hinauswillst.
Meine Aussage ist vielleicht etwas übertrieben und du kannst gerne dagegen argumentieren, aber bitte denke nicht über JavaScript als schlechte Kopie von C++. Genauso kann man nicht über C++ als schlechte Kopie von Java denken (siehe Zitat oben). Lasse dich auf das Denken ein und entscheide erst dann, nachdem du erste Erfahrungen gesammelt hast.
Ja, das kann vielleicht mein Fehler gewesen sein, als ich in Javascript programmiert habe.
Genauso wie viele C Idiome in C++ packen, hab ich wohl versucht C++-Idiome in Javascript zu stopfen.
Eigentlich klar, dass das nicht geht.
Gibt es vielleicht irgendwo eine Quelle, wo man gängige dynamische Typisierungsidiome findet?@PRIEST:
Wenn ich Zeit hab, schau ich mir das Video mal an.
-
Nathan schrieb:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Eine Diskussion pro/contra dynamische Typisierung macht keinen Sinn. Das Thema wurde zur genüge durchanalysiert. Alles hat seine vor und seine nachteile.
Deine Kritik an JS ist also, dass es dynamic typing hat?
OK, ich dachte echt schon dass es mal eine sinnvolle diskussion gibt. Ne ne ne ne...
PS:
ich finde solche Diskussionen nicht wert. Denn sie sind so oberflächlich. Das erinnert mich dann immer an eine Mode Diskussion. Aber nein, man kann doch nicht Braun mit Blau mischen, OMG wie furchtbar.Ne, typisierungen haben ihre Vorteile und ihre Nachteile - jeder ernsthafte Programmierer sieht das ein. Natürlich gibt es vorlieben und einige bevorzugen dieses andere jenes - das ist ja kein Problem. Und man kann auch gerne sagen dass sich diese oder jene Sprache nicht gut anfühlt - aber das ist halt keine ernsthafte Kritik an der Sprache.
Ich dachte echt wir haben jetzt was fundiertes. JavaScript hat nämlich historisch bedingt schon einiges kontroverses zu bieten. Aber wir reden hier nur über so primitive Sachen wie Typisierung und Syntax rum.
-
Shade Of Mine schrieb:
Nathan schrieb:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Eine Diskussion pro/contra dynamische Typisierung macht keinen Sinn. Das Thema wurde zur genüge durchanalysiert. Alles hat seine vor und seine nachteile.
Ja, da stimme ich dir vollkommen zu.
Deine Kritik an JS ist also, dass es dynamic typing hat?
OK, ich dachte echt schon dass es mal eine sinnvolle diskussion gibt. Ne ne ne ne...
Entschuldigung.
PS:
ich finde solche Diskussionen nicht wert. Denn sie sind so oberflächlich. Das erinnert mich dann immer an eine Mode Diskussion. Aber nein, man kann doch nicht Braun mit Blau mischen, OMG wie furchtbar.Ne, typisierungen haben ihre Vorteile und ihre Nachteile - jeder ernsthafte Programmierer sieht das ein. Natürlich gibt es vorlieben und einige bevorzugen dieses andere jenes - das ist ja kein Problem. Und man kann auch gerne sagen dass sich diese oder jene Sprache nicht gut anfühlt - aber das ist halt keine ernsthafte Kritik an der Sprache.
Ich dachte echt wir haben jetzt was fundiertes. JavaScript hat nämlich historisch bedingt schon einiges kontroverses zu bieten. Aber wir reden hier nur über so primitive Sachen wie Typisierung und Syntax rum.
Über Syntax regt man sich ein,zweimal auf und gewöhnt sich dran.
Aber Typisierung ist nicht auf diesem Level zu sehen.
Typisierung ist keine "so primitive Sache". Typisierung beeinflusst Design, sowohl der Corefeatures als auch der eigenen Programme. Grundlegend.
Ich muss zugeben, ich habe mich oben falsch ausgedrückt:
Erst die Mischung aus dynamischer Typisierung und schwacher Typisierung macht die komplette Sprache, so kaputt, wie sie ist (gut, nciht nur, anderes ist auch nur unintutiv hoch 15).
Beispiel, Operator ==:
0 == 0 -> true, logisch
0 == false -> true, logisch, false ist 0
'0' == '0' -> true, logisch
'0' == 0 -> true, ok, string wird zu Zahl konvertiert
'0' == false -> true, '0' wird zu 0 und 0 ist false
'false' == false -> false, ah ja, ok merken wir uns: Bei verschieden Operanden wird beides offenbar zu einer Zahl konvertiert
null == 0 -> false, was? null ist nicht 0? Das funktioniert sogar in C++! OK, obige Regel gilt nicht mit 0
null == '0' -> false, ok null ist auch nicht 0
null == NaN -> false, ok, das war eigentlich zu erwarten
null == undefined -> true, ah, null ist undefined
null == false -> false, was? wenn etwas false ist, dann doch wohl null!
OK, null ist nicht false, aber !null ist true! Was? null ist nicht false, aber !null ist true! WTF? (Gleiches Spielchen mit undefined)
(Gut, man könnte jetzt mit === argumentieren, aber wo ist das entsprechende für < ? (Beispiel unten))
Weiter:
Logik sagt uns: Wenn !(x < 0) und !(x > 0) dann x == 0.
Javascript sagt: null < 0 = false, null > 0 = false, aber null != 0. Jup, das ist logisch ... nicht.
Der Spaß geht weiter mit Arrays:
[1, 2, 3] < [1, 2, 5] -> true, ok, das ist intuitiv
[1, 3, 1] < [1, 2, 5] -> false, ok, das ist intuitiv
[1, 2, 3] > [1, 2, 3] -> false, ok
[1, 2, 3] < [1, 2, 3] -> false, ok
[1, 2, 3] == [1, 2, 3] -> false, WTF? Das ist gleich! Das ist das selbe Array!
Zum Glück gibts ja noch <= :
[1, 2, 3] <= [1, 2, 3] -> true, ja, ok, wenn dus sagst...function-Objekte:
var func1 = function() {}; var func2 = function() {};func1 < func2 -> false
func1 > func2 -> false
func1 == func2 -> richtig: false, hach ich liebe die Regeln mit < und > bei Javascript... nicht.Und nebenbei:
Math.min() ist nicht kleiner als Math.max(). Jup, Math.min() ist also größer als Math.max()? Ach, nein, ist es auch nicht. Aber sie sind - as always - auch nicht gleich.var foo = [0];foo == foo -> true, logisch, sind ja gleich
foo == !foo -> true, was, sind sie doch nicht? Wie jetzt ist foo jetzt foo oder !foo?
Mein Glaube an die Logik hat sich soeben verabschiedet...
Und der Grund dafür ist dynamische Typisierung. Ist es zuviel verlangt gewisse Operatoren unter gewissen Umständen zu verbieten? Ja?
Ich will über das da oben nicht nachdenken müssen. Ich will es nicht.
Muss ich noch weitermachen?
-
Was du schreibst ist laecherlich. Ich wuerdige das keiner weiteren Antwort. Finde ich schade, denn es gibt vieles was bei JavaScript diskussionswuerdig waere. Aber die typisierung, ne, das ist zum lachen.
-
epTical schrieb:
Ich will einen Fehler, wenn ich mich bei einem Variablenname vertippe und nicht, dass stattdessen eine neue Variable eingeführt wird.
Den bekommst du doch auch oO?! Verwechselst das wohl mit PHP!
Nee, was kriegst du denn da für einen Fehler?
function f() { var namex = 1; namey = 2; // legt ne globale Variable 'namey' an }
-
Shade Of Mine schrieb:
Was du schreibst ist laecherlich. Ich wuerdige das keiner weiteren Antwort. Finde ich schade, denn es gibt vieles was bei JavaScript diskussionswuerdig waere. Aber die typisierung, ne, das ist zum lachen.
Das ist diskussionswürdig!
Hast du meinen Beitrag überhaupt gelesen?Aber da du offenbar keine Lust hast mit mir zu diskutieren, sondern dich lieber wie ein bockiges Kind verziehst, kann der Thread auch geschlossen werden.
Dein Verhalten find ich nämlich lächerlich, aber das hat hiermit nichts zu tun.
-
Nathan schrieb:
Das ist diskussionswürdig!
Nein, ist es nicht.
Das ist Allgemeinbildung für Programmierer. Das Thema kann gegoogled werden, es gibt keine Argumente die neu sind.
-
Shade Of Mine schrieb:
Nein, ist es nicht.
Das ist Allgemeinbildung für Programmierer. Das Thema kann gegoogled werden, es gibt keine Argumente die neu sind.Ist aber eines der Standardargumente gegen PHP und der Grund weshalb in der Sprache === eingeführt wurde, was natürlich aus bestimmten Gründen ebenfalls kaputt ist. logische Operatoren müssen logisch sein. Ich schliße mich da Nathan an: warum gibt es in den obigen Fällen keine Fehler? Warum müssen Objekte, die logisch nicht vergleichbar sind, vergleichbar sein?
Warum ist [1,2,3] == [1,2,3] nicht wahr?
Natürlich kann es Sinn machen und Argumente geben, aber sind diese Argumente auch tragfähig im Vergleich mit den Gegenargumenten?
Wee sieht es da denn noch mit Wartbarkeit und Fehleranfälligkeit aus? Wenn eine Funktion nicht meckert, wenn ein Argument null ist, aber dann irgendein Müll hintenr auskommt, wie soll mand enn den Fehler finden? Muss man wirklich jdes funktionsargument eigenhändig mit typeof und null-tsts guarden?
Ich bin kein Experte in JS, eigentlich sogar ziemlich unbedarft, also von daher die Frage: wie wird das in der Praxis gehandhabt?
------
Ich sehe ein, das man bei einer scriptsprache für das Web keinen Compiler haben will und statische Typisierung sowie Type-checking nicht unbedingt machbar ist. Aber dann muss die Sprache beschränkt sein.
-
otze schrieb:
Warum ist [1,2,3] == [1,2,3] nicht wahr?
Ist es in Java auch nicht. Manche finden Reference-Semantics besser als Value-Semantics.
-
jawas schrieb:
otze schrieb:
Warum ist [1,2,3] == [1,2,3] nicht wahr?
Ist es in Java auch nicht. Manche finden Reference-Semantics besser als Value-Semantics.
Aber 2==2? und müsste bei reference semantik nicht [1,2,3] < [1,2,3] vollkommen undefiniert sein? oder werden die Zeigeraddressen verglichen und das Ergebnis ist zufällig? warum hier value semantik?
-
otze schrieb:
Warum müssen Objekte, die logisch nicht vergleichbar sind, vergleichbar sein?
Ist in C++ auch nicht anders
Das hat mit der automatischen Umwandlung von Typen zu tun. Man beachte zB das safe bool idiom in C++.Warum ist [1,2,3] == [1,2,3] nicht wahr?
Siehe Java.
Weil es nicht das selbe Objekt ist.Du vergleichst hier referenzen.
Wee sieht es da denn noch mit Wartbarkeit und Fehleranfälligkeit aus? Wenn eine Funktion nicht meckert, wenn ein Argument null ist, aber dann irgendein Müll hintenr auskommt, wie soll mand enn den Fehler finden? Muss man wirklich jdes funktionsargument eigenhändig mit typeof und null-tsts guarden?
Willkommen in der Welt der schwachen dynamischen Typisierung. Ich erklaere hier jetzt wirklich nicht was da die Vorteile sind - es laesst sich googlen.
Ich bin kein Experte in JS, eigentlich sogar ziemlich unbedarft, also von daher die Frage: wie wird das in der Praxis gehandhabt?
Einfach mal zB das hier lesen: http://stackoverflow.com/questions/2690544/what-is-the-difference-between-a-strongly-typed-language-and-a-statically-typed
dyanmisch weak typing ist eine Design Entscheidung. Sie bietet vorteile gegenueber strong static typing und nachteile.
btw, JavaScript kennt auch nicht wirklich unterschiedliche Typen nach denen man starkes Typisierung machen koennte - denn alle User Defined Datatypes sind vom Typ Object
Aber OK, machen wir daraus einen JavaScript Anfaenger Fragen Thread. Wenn jemand Fragen hat warum etwas so ist wie es ist in JavaScript, einfach mal fragen.
PS:
was richtig cool waere, ich weiss es ist eine wunschvorstellung von mir, wenn man an ein neues Thema offen heran gehen wuerde. Anstelle von "Ich kenne JS nicht, aber JS muss ja sucken" waere ein "Ich kenne JS nicht, weshalb macht X denn Y in JS?" soviel cooler.
-
Nathan schrieb:
Ich kann mich ja mit der Seltsamen Art Klassen zu "definieren" anfreunden.
Erstes Problem: in Javascript gibt es keine Klassen und wenn man mit der Sprache Spaß haben möchte, sollte man auch aufhören in Klassen zu denken. Das grundlegende Abstaktionsmittel in Javascript ist die Funktion. Diese ist dort sehr viel mächtiger als traditionell in imperativen Sprachen üblich.
Ich kann mich mit Java-like new Syntax zum Erzeugen von Objekten anfreunden.
Genauso gehört auch 'new' in JS zu den Sachen um die man besser einen Bogen macht. Es gibt zwar durchaus ein paar Anwendungsgebiete, aber die ergeben sich dann mit ein bisschen Erfahrung von selbst. Als Anfänger: Finger weg.
In Javascript programmiert man eher wie in Lisp, nicht wie in Java oder C++. Es ist eine nette funktionale Sprache mit C-ähnlicher Syntax. Das kann man nutzen. Man kann sich das Leben aber auch schwer machen, indem man mit einem imperativen oder klassenbasierten OOP-Mindset an die Sache herangeht. Diese Teile der Sprache sind wirklich nicht toll.
Bei C++ sehen die meisten Forenteilnehmer doch auch ein, dass man mit einem Java-Ansatz nicht unbedingt schönen Code schreibt. Das gilt durchaus auch für andere Sprachen.