Diskussion:JavaScript/Archiv/001

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:JavaScript/Archiv/001#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:JavaScript/Archiv/001#Thema_1

Scriptsprache, keine Programmiersprache?

Stimmt das wirklich alles, wie es da steht? Soweit ich weiß, ist JavaScript doch eine Skriptsprache und keine Programmiersprache, und das mit dem objektorientiert ist auch nicht wirklich zwingend. Kann jemand bestätigen, daß die Syntax so ähnlich ist wie die von Java (das ja eine C++-ähnliche benutzt)?

Mein Stand der Dinge war bisher eher:

• Netscape hat JavaScript erfunden, trotz der Namensähnlichkeit hat es aber nicht mit Java zu tun.
• um der Sprache etwas mehr Glaubwürdigkeit zu verleihen wurde sie später der ECMA zur Standardisierung vorgelegt.
• danach wurd sie auch dem W3C vorgelegt, da Microsoft aber inzwischen mit JScript eine eigene Sprache erfunden hatte, wurde keine von beiden zum Standard erhoben, sondern stattdessen ein Standard zur Erstellung von Skriptsprachen entwickelt, der dann zu DOM wurde.

Der letzte Satz ist nicht richtig: DOM heisst Document Object Model und hat mit der Sprache direkt nichts zu tun. Mit der Sprache greift man aber auf die Objekte zu, aus denen ein Dokument aufgebaut ist.

--SoniC

Ich kenn mich da auch nicht aus. Allerdings ist die Syntax ähnlich C und damit Java. Eine Skriptsprache ist auch eine Programmiersprache.

--Vulture

OK, aber Skriptsprache finde ich trotzdem genauer, Programmiersprache klingt immer so nach Informatikstudium :-). Und wie ist das mit den Schnittstellen zu DOM? Kann man das wirklich so schreiben?

Ja siehe http://www.w3.org www.w3.org

--SoniC

Naja, eigentlich ist weder Programmiersprache noch Skriptsprache. (Bei Skriptsprache denke ich hier an Shell-Skripte zum Beispiel.) Dafuer ist sie durch den Browser IMHO rechtlich zu sehr eingeschraenkt. Wie waere es mit "Web-Skriptsprache"?

--Evolux

aalso:

• Syntax ist wie in allen C/C++-Verwandten (wozu neben Java und JS auch noch PHP gehört).
• Erfunden wurde das ganze als "LiveScript" von Netscape, dann in JavaScript umbenannt.
• MS JScript ist im Grunde das gleiche, aber erweitert um einige DHTML-Funktionen und vor allem um Funktionen für das Scripting des Betriebssystems.
• DOM hat mit der Syntax nichts zu tun, wohl aber mit den Objekten in der Sprache. Und eben diese waren anfangs Alternativ zu den JScript-Erweiterungen, heute kann der MSIE beides.
• Netscape selbst hat dem ganzen auch noch einige Objekte verpasst, die nicht in dem ECMA-Standard gelandet sind (document.layers). Diese sind heute ausgestorben.

TheK 19:48, 27. Jun 2004 (CEST)

--MatthiasSchulze

Habe Details zu Vererbung und Prototypen ergänzt. So ok?

--XRay 14:26, 24. Dez 2004 (CET)

Umlaute

Die Umlaute aus den Beispielskripten habe ich ersetzt, da dies in den Skripten bzw. XHTML- oder HTML-Seiten zu Problemem (oder Fehlern) führen könnte, zum Beispiel abhängig davon, ob jemand ISO-8859-15 oder UTF-8 als Zeichensatz nutzt.

Zu dem Umlauten in Kommentaren etc. Ja, Umlaute dürfen auftreten, sie müssen nur mit dem Zeichensatz passen. Probleme gibt es in der Regel dann, wenn man zum Beispiel XHTML-Dateien erstellt, diese mit UTF-8 verfasst, dann aber Umlaute in ISO-8859-1 einbringt. Daher gehe ich eher den Weg, Umlaute zu vermeiden.

Wie geht es weiter mit dem Abschnitt »Datenstrukturen und Objekte«?

Ich frage mich, welche Objekte bzw. Eigenschaften und Methoden dort genannt werden sollen. Worauf gründet sich die Auswahl der dort aufgelisteten? Momentan ist die Liste sehr bunt und folgt keinem Schema. Es sind einige ECMAScript-Objekte genannt, nämlich Array, String, Date und Math. Deren Eigenschaften und Methoden sind aber nicht annähernd vollständig genannt, es fehlen oft gebrauchte, während selten gebrauchte genannte sind. Von den ECMAScript-Standardobjekten fehlen z.B. Boolean, Number und RegExp. Welchen Sinn hat es, überhaupt einige willkürliche Objekte aus ECMAScript zu nennen? Für die spärliche Dokumentation der in Netscape-JavaScript eingeführten Objekte gilt das umso mehr. Warum gerade von window diese drei Funktionen und warum gerade das screen-Objekt? Unter »Function Objekt« ist dann ein Beispiel für eine Function-Expression aufgeführt, die dort wenig zu suchen hat (d.h. genauso viel, wie ein gewöhnliches Function-Statement, denn das erzeugt auch Function-Objekte). Können wir da irgendwie eine sinnvolle Ordnung hineinbringen? Ich persönlich sehe für eine Enzyklopädie wenig Sinn in einer notorisch unvollständigen Dokumentation von ein paar willkürlich ausgesuchten Objekten. Ich würde den Teil auf ein Minimum streichen, aber ich frage lieber vorher hier. Das hieße allgemeinere Erklärungen, was die ECMAScript-Objekte darstellen (Prototypen-Objekte für Datentypen- und strukturen) und welche Objekte in JavaScript das Rückgrat bilden (window, document, location usw.). --molily 03:34, 24. Feb 2005 (CET)

"Mittlerweile wurden auf dieser Basis zusätzlich normale Klassen implementiert, wohl in der Annahme, damit den Einstieg zu erleichtern." Das ist so nicht richtig. Weder die aktuelle JavaScript Version (1.5) noch der aktuelle ECMAScript Standard 262 (dritte Version) kennen Klassen. (=> evtl. einfach Streichen?)

Außerdem würde ich vorschlagen alles was nicht Teil der JavaScript/ECMAScript Sprachen an sich ist zu entfernen (verschieben). Also insbesondere Objekte die Teil einer "Host Umgebung" sind. (Sprich Browser DOM Objekte wie window)

Zu den privaten Eigenschaften (JavaScript spezifisch wegen __parent__): function Foo(){var priv=1;this.get=function(){return priv;}}; var foo=new Foo();alert(foo.get());foo.get.__parent__.priv=10;alert(foo.get());

--Unbekannt (anm. elias)

JavaScript bezieht sich eigentlich immer auf den ECMA-262 Standard. Deswegen sollte diese Seite erstmal diesen Standard behandeln und frei von den proprietären Implementierungen beschreiben. Zusätzlich kann ein Kapitel wie zb "Javascript und Browser" eingeführt werden, wo wichtige Unterschiede oder Implementierungen beschrieben werden.

$elias 17:37, 16. Mai 2005 (CEST)

Da möchte ich teilweise widersprechen. »JavaScript« bezeichnet die Konvention, die sich nach der Erfindung von Netscapes (clientseitigem) JavaScript breit durchgesetzt hat (von serverseitigem JavaScript einmal abgesehen). Dies umfasst etwa window als Hostobjekt, document, location usw. (Strenggenommen sind diese Objekte allesamt nach wie vor proprietär, weil sie nie konsensuell standardisiert wurden.) Unter dem Stichwort JavaScript sollte daher auch vornehmlich dieses JavaScript beschrieben werden. Falls wir ECMAScript als solches möglichst allgemein und gesondert beschreiben wollen, dann sollte das unter dem Lemma ECMAScript passieren (momentan eine Weiterleitung zu JavaScript). Es gibt nämlich mehrere ECMAScript-Anwendungen. Z.B. in der englischen Wikpedia ist en:ECMAScript ein eigenständiger Artikel, wenngleich die Beschreibung der Sprache in en:JavaScript residiert. --molily 17:32, 17. Mai 2005 (CEST)

Ja du hast recht, da lag ich Falsch. JavaScript ist schon eine konkrete Implementierung. Aber man könnte zb bei Datentypen, Kontrollstrukturen etc die im Standard definiert sind auf ECMAScript verweisen und ggf. dann nur die proprietären Elemente beschreiben. Ich hab hier schon eine kleine Einleitung für einen ECMAScript Artikel geschrieben die von englischen Äquivalent und dem ECMA-262 Dokument inpiriert sind. Werde versuchen das diese Woche noch brauchbar zu machen. $elias 20:13, 17. Mai 2005 (CEST)

Alles neu?

Mit Verlaub, aber ich empfinden diesen Artikel als ein Vorzeigebeispiel, wie man es nciht machen soll. Die Kontrollstrukturen im Einzelnen zu behandeln, oder konkrete Listen von Methoden sind kein enzyklopädischer Stil. Sogar der Abschnitt "Geschichte" ist eine Liste. Wie wäre es mit einem Entwurf für einen Neustart? --Pjacobi 14:41, 22. Mai 2005 (CEST)

Obwohl ich den Artikel mit vielen Edits korrigiert habe, habe ich mich bisher gehütet, die Struktur zu verändern und von anderen eingefügte Abschnitte und Inhalte zu streichen. Dass der Artikel zu einer Art Tutorial geworden ist, habe ich oben schon kritisiert.

Wenn es nach mir ginge, würde ich folgende Bereiche komplett streichen, da sie m.E. der Aufgabe einer Enzyklopädie widersprechen: Die Beschreibung der Kernobjekte im Einzelnen, Kontrollstrukturen, Private Eigenschaften, Benutzerinteraktion, Fehlerbehandlung. Von Funktionen den Teil bis Konstruktor-Funktionen. Den Rest von Funktionen und Vererbung würde ich in einen Abschnitt einarbeiten, der die Besonderheiten von JavaScript beleuchtet (Funktionen sind Objekte und was daraus folgt; Prototypische Vererbung). Geschichte kann man weitesgehend eindampfen, diese Listen stehen auch woanders im Netz (Quelle ist AFAIK sowieso http://www.mintert.com/javascript/).

Da offenbar viele die jetzige Herangehensweise bevorzugen, fürchte ich, dass ein solcher radikaler Edit nur Reverts nach sich ziehen würde?! -- molily 18:39, 22. Mai 2005 (CEST)

Vielleicht sollte man statt groß drumherumzureden mal den Artikel wirklich umkrempeln. Wikipedia ist ein Enzyclopädie und ich finde das so weiter gehende Sachen wie Fehlerbehebung etc. rausgelassen werden sollten , da mich das jetzt eher an eine Einführung in JavaScript erinnert. Es gibt andere Internetangebot wie Selfhtml wo das näher erklärt wird, daher muss das nicht in einem Wikipedia Artikel stehen. -- Crossroad 18:18, 20. Okt 2005 (CEST)

ist JS objektorientiert?

Die Behauptung, dass JavaScript eine OOP Sprache darstellen soll, ist falsch. Es fehlen die typischen objektorientierten Ansätze wie Polymorphie, Abstrakte Basisklassen, sowie Interface-Klassen. In der Fachliteratur spricht man von einer objektbasierenden Sprache mit objektorientierten (siehe Professional Javascript 2ND Edition der P2P Serie) Ansätzen, welche aber lange nicht zu Ende geführt sind. So zum Beispiel die Scope/Context-Strategie von JavaScript, welche jedem sauberen OOP-Ansatz wiederspricht. Die Sourcen des Rhino-Projektes (JS-Parser/Interpreter des Mozillas) zeigen diese gravierenden Unterschiede zu OOP sehr deutlich.

Meines Erachtens sollte diese Stelle sofort aus dem Wiki entfernt werden, da diese zu Verwirrung führt und schlussendlich dem Benutzer eine fehlerhafte Information liefert.

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 1. Nov 05

nee, die kriterien was OO ist und was "nur" objektbasierend sind in der fachliteratur höchst unterschiedlich dargestellt. abstrakte basisklassen und interface-klassen sind jedenfalls kein allgemein akzeptiertes kriterium für "echte" OO. was du genau unter "Scope/Context-Strategie" verstehst und inwiefern das einem OOP-ansatz wiederspricht ist mir auch nicht ganz klar.. -- ∂ 22:21, 1. Nov 2005 (CET)

Soviel zum Thema "Was ist OOP": <http://www.uni-koeln.de/rrzk/kurse/unterlagen/oopintro/general/begriffe.htm> Vielleicht solltest du dies einmal überfliegen, denn ohne Abstrakte Basisklassen, sowie Interface-Klassen gibt es keine Polymorphie im Sinne von OOP - Ohne Polymorphie kein OOP. Zudem werden bei der JavaScript prototype-Vererbung nur die Wertetypen kopiert; bei Referenztypen wird der Zeiger auf ein Objekt kopiert; dies ist nicht im Sinne von OOP. Die Scope/Context-Strategie ist ein Basiskonzept von EcmaScript (siehe <http://www.ecma.ch> unter ECMA-262 Standard), welches die einzelnen Scopes (Variablenzugriff in den Verschachtelungsebenen - Chained-Scopes) beschreibt. Einen globalen Scope (this-Ptr auf globales Wnd-Objekt), wie JavaScript über einen verfügt, ist vor allem bei objektbasierenden Scriptsprachen anzutreffen. Auf jeden Fall kann JavaScript keine OOP-Sprache sein: Mein Korrekturvorschlag: "JavaScript ist eine objektbasierende Web-Skriptsprache mit objektorientierten Ansätzen. Ursprünglich wurde JavaScript von der Firma Netscape unter dem Namen LiveScript entwickelt, um statische HTML-Seiten dynamisch zu gestalten."

Anmerkung: Siehe en-Artikel: <http://en.wikipedia.org/wiki/JavaScript>

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 2. Nov 05

habe mir den link oben mal angesehen, der mir doch sehr C++-lastig vorkommt, und da steht zu lesen: Im Zusammenhang mit OOP meint Polymorphie genau das, was der obige Abschnitt beschreibt: daß ein Pointer (eine Referenz) auf Objekte verschiedenen Typs zeigen kann und die gleiche Message je nach Objekttyp eine andere, spezifische Reaktion hervorruft.. ein "interface-klasse" - komisches wort, eine klasse hat ein interface (=schnittstelle), aber sie ist keines - braucht man dazu mit sicherheit nicht. wenn ich zwei JS-objekte habe die die selbe message verstehen und unterschiedlich darauf reagieren, also zwei unterschiedliche, aber gleichnamige methoden haben, dann passiert genau das im zitat beschriebene: abhängig vom objekttyp wird mal die eine, und mal die andere methode aufgerufen. du darst dabei nur nicht den fehler machen, typ und klasse zu verwechseln.

chained scopes gibt es (eingeschränkt) übrigends auch in java - da muß man halt noch eine inner class drumrum packen und es wird "magisch" ein zweiter this-pointer erzeugt. damit, daß es einen globalen scope hat, ist JS sicher keine strikt objektorientierte sprache mehr, aber der eigentlich wichtige punkt "alles ist ein objekt" wird davon nicht berührt. -- ∂ 14:20, 4. Nov 2005 (CET)

Ein gravierendes Problem an der objekt basierenden Implementation von JavaScript ist, dass der mitgelieferte Vererbungsalgo nicht dem einer OOP-Vererbung entspricht (siehe oben). Weiterhin steckt hinter einem Objekt irgend etwas (void-ptr in C++). Vielliecht ist ein Hund oder ein Vogel dahinter; solltest du auf dem Hund *fliegen()* aufrufen, gibts einen Fehler; d.h. es gibt keine Interfaces, was OOP allerdings vorschreibt (Design-Patterns basieren stark darauf). Wie möchtest du denn sichergehen, dass eine Methode auf einem Objekt existiert? Immer den fnc-Pointer abfragen? Dies sollte ja gerade OOP verhindern. Aber whatever, es scheint eher eine Glaubensfrage zu sein, als eine Sachfrage; wie du ja auch schreibst, ist JS sicher keine strikt objektorientierte Sprache, daher sollte man JavaScript auch nicht so verkaufen.

Meiner Meinung nach ist JavaScript sehrwohl objektorientiert. Lediglich wird die eher "unpopuläre" Prototypen-Vererbung eingesetzt und nicht die bekanntere Klassen-Vererbung! Dubaut 13:36, 7. Mär 2006 (CET)

Der in englisch verfasste Artikel ist mir wesentlich sympatischer.

P.S: ein "interface-klasse" - komisches wort - Ein Interface ist eine besondere Form einer Klasse, die ausschliesslich abstrakte Methoden und konstante Eigenschaften enthält. Um eine Interface-Klasse zu kennzeichnen, wird meist ein I-Prefix vor den Klassennamen geschrieben: IDataProvider.

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 7. Nov 05

was an dem "vererbungsalgo" nicht oop sein soll ist mir immer noch nicht klar, sorry. wenn du den lexikalischen lookup meinst: den haben andere auch.

daß hinter jedem objekt "irgendwas" steckt, also Duck Typing verwendet wird, ist kein argument: Smalltalk (Programmiersprache), die OO-sprache überhaupt, hat auch keine typisierten referenzen. du gehst einfach gar nicht sicher, ob es die methode gibt - dafür hat smalltalk die methode doesNotUnderstand.

ein paar desing-patterns mögen darauf basieren, aber die sind dazu da spezifische probleme mit bestimmten sprachen zu lösen, definieren aber sicher nicht, was OO ist und was nicht.

nochmal zurück zum "komischen wort": eine klasse besteht aus einem interface und einer implementierung, aber sie ist kein interface. klar, java ist weiter weil man interfaces unabhängig von der implementierung definieren kann. dummerweise geht es umgekehrt nicht, eine klasse bringt immer implizit auch ein interface mit, diese trennung ist in modernen sprachen wie Sather klarer.

wie ich schon sagte, ist die definition was OO ist extrem umstritten - und JS erfüllt meiner meinung nach die wichtigsten kriterien durchaus. überzeug mich, daß dem nicht so ist, aber verwechsle nicht Statisches Typing mit OO! -- ∂ 22:18, 12. Nov 2005 (CET)

GRINS, ich glaube nicht, dass man dich noch vom Gegenteil überzeugen kann ;). Dies ist auch nicht wirklich mein Ziel :D. Zum lexikalischen Lookup (bei JS prototype-Vererbung): In JavaScript werden bei der Vererbung die Referenztypen nicht neu kreiert sondern einfach die Referenz kopiert. Beispiel:

function Wheel() { }

function Car()
{
  this.color = "red";
  this.wheels = [ new Wheel(), new Wheel(), new Wheel(), new Wheel() ];
}

function Ford()
{
  // beinhaltet color = "red"
  // enthält eine neue referenz von wheels[]
};
Ford.prototype = new Car();

function Mustang()
{
  // beinhaltet color = "red"
  // beinhaltet eine referenz zu wheels[] in Ford (gleiche Referenz wie Focus hat -> keine *echte* Vererbung)
};
Mustang.prototype = new Ford();

function Focus()
{
  // beinhaltet color = "red"
  // beinhaltet eine referenz zu wheels[] in Ford (gleiche Referenz wie Mustang hat -> keine *echte* Vererbung)
};
Focus.prototype = new Ford();


// kreiere Instanzen
var focusInstance = new Focus();
var mustangInstance = new Mustang();
alert(focusInstance.wheels == mustangInstance.wheels); // gibt true aus

Ob diese merkwürdige Eigenschaft einer OO-Implementierung in JS einzigartig ist, kann ich nicht beurteilen. Es entspricht meiner Meinung nach keiner OO-Vererbung, viel eher einem Ansatz einer OO-Implementierung, welcher nicht zu Ende geführt wurde. In einem Punkt sind wir gleicher Meinung: Die definition von OO ist extrem umstritten und statisches Typing ist nicht erforderlich. Aber wenn man in einer *strikten* OO-Sprache vor jeden Fnc-Call ein if (typeof(obj.someThingIsThere) == 'Function') {} (ansonsten gibts einen Fehler) schreiben muss, dann mag sein, dass die Sprache zwar im Grundsatz nach den OO-Regeln implementiert wurde, allerdings nicht alle Sprachdefinitionen den OO-Anforderungen (siehe C++/Java/C#/...) entsprechen. Wenn JS über eine doesNotUnderstand() methode verfügen würde, wären wir auch in diesem Punkt gleicher Meinung.

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 13. Nov 05

Seltsame OOP-Definition, wie schon gesagt, würde dies ja auch Smalltalk (Programmiersprache), Self (Programmiersprache), CLOS ausschliessen. Bloss nicht die Links anklicken! Anscheinend sind fast alle unsere Programmiersprechenartikel sehr kurz oder sehr seltsam. --Pjacobi 15:00, 14. Nov 2005 (CET)

Generell zu deiner Aussage: Ich finde WIKI grossartig, es ist eine feine Sache, das Wissen weltweit gratis zur Verfügung zu stellen; habe das Projekt auch schon mehrfach donated. Allerdings sollte der Inhalt korrekt sein, d.h. nach dieser Diskussion kann man konkret Punkte für und gegen JavaScript verfügt über OOP auflisten (QS). Wie schon gesagt, ob andere Programmiersprachen auch über eine derartige Implementation der Vererbung verfügen, kann ich nicht beurteilen, da ich mit C++/Java/C-Sharp aufgewachsen bin. Es widersprach einfach allem bisher Gelernten über OOP, daher habe ich es hier aufgelistet. Ob nun JavaScript wirklich OO ist, sollte man den Leser entscheiden lassen, da deutliche OO-Sprachelemente vorhanden sind, allerdings auch widersprüchliche Elemente existieren.

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 14. Nov 05

Wie etwas implentiert ist, ist doch egal. Dass C++ als Preprozessor für C implementiert werden kann, spricht ja auch nicht dagegen, dass C++ eine OOP ist. Allerdings fehlen C++ eine Eigenschaft in Bertrand Meyers Liste (in ISBN 0136290310), um als vollwertige OOP zu gelten: Das automatische Deallozieren von nicht länger benutzten Objekten. --Pjacobi 20:16, 14. Nov 2005 (CET)

Okay GRINS... ich werde den Link mit dem Zaunpfahl nutzen und mir das beschriebene Buch zu gemüte führen, thx. Was schliessen wir nun aus dieser Diskussion? Mein Vorschlag: "JavaScript ist eine Web-Skriptsprache mit objektorientierten Ansätzen..." :)

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 14. Nov 05

M.E. ist die Aussage, dass JavaScript im Gegensatz zu klassisch objektorientierten Sprachen keine Klassen einsetzt, sondern statt dessen Objekte als Prototypen verwendet bereits recht treffend. Vielleicht sollte man noch ergänzen (falls es in diesem grausamen Artikel nicht schon irgendwo steht), dass die Benutzung der OO-Merkmale optional ist (wie auch bei C++). In der Anfangszeit der OOP hielt man es ja manchmal für besser, in einer Art Erziehungsdiktatur diese Entscheidung dem Programmierer abzunehmen. --Pjacobi 21:14, 14. Nov 2005 (CET)

Version/Autoren; Zitat Molily K: (rev. welche merkmale von OOP Javascript hat und nicht, wäre an anderer stelle genauer zu klären. aber nicht bereits den ersten satz zerhacken! vielleicht einigt man sich mal auf der diskussionsseite)

Es ist eine Einigung im Sinne aller Beteiligten zu stande gekommen: JavaScript ist weder 100% OOP noch kann man von absolut objektbasierenden Eigenschaften sprechen. Man kann also die Aussage wagen, dass JavaScript objektorientiert ist, da auch andere Sprachen (z.B. C++) nicht alle Anforderungen an OO erfüllen (GC-Problem), aber trotzdem als OO-Sprachen bezeichnet werden. Die Aussage, JavaScript sei objektbasierend, ist ebenfalls korrekt, da JavaScript nicht alle OO-Anforderungen erfüllt und zudem klare Merkmale einer prozeduralorientierten Sprache aufweist. Es ist also eine Gratwanderung und man wird es nicht zu 100% festlegen können. Daher ist es schlussendlich eine Glaubensfrage, dies ist auch aus der gängigen JavaScript-Literatur deutlich ersichtlich. Der erste Satz ist also auf das Zielpublikum anzupassen; will man eher dem allgemeinen Ruf von OO (JavaScript ist OO) oder der Definition von OO (JavaScript ist objektbasierend <http://en.wikipedia.org/wiki/Object-based>) Beachtung schenken.

--Mcdark (prj-admin <http://www.jstools.net>) 15. Dec 05

Ich bin gerade zufällig auf den Artikel gestoßen. Meine Meinung: bei Objektorientiertheit gibt es Abstufungen. Da schließ ich mich Mcdark an. Da ist zum einen Smalltalk als absolut objektorientiert, dann C++ und Java, die es schon nichtmehr ganz so eng sehen. Man könnte vielleicht als Kompromiss schreiben, dass in JavaScript objektorientiert gescriptet werden kann. AccountAlive

Alles neu!

PHP als Vorlage-Artikel.

PHP ist nicht exzellent, aber sehr brauchbar und allgemeinverständlich. JavaScript und PHP lassen sich in punkto Verbreitung und Bedeutung schon miteindander vergleichen. Ein Artikel über JavaScript muss keineswegs länger sein als einer über PHP!

Gliederungs-Vorschlag

Definition, Stichworte

Browser, Internet: Verbreitung, dynamisches HTML, Scriptsprache,

1. Geschichte (Neu schreiben. Tabelle bringt nix. Im übrigen ist die Geschichte nicht gerade unspannend.)
2. Verwendung
   1. wofür wird Javascript normalerweise verwendet
   2. was geht sinnvollerweise nur mit Javascript (zwei Frames gleichzeitig öffnen, <form action""> ändern, Plausibilitätsprüfung von Formularen...)
   3. was geht nicht mit Javascript (Passwort)
   4. einfache Beispiele
   5. Leistungsfähigkeit: Groß-Projekte und kommerzielle Produkte auf JavaScript-Basis
   6. Missbrauch
3. Sicherheit
   1. Sandbox-Prinzip
   2. Exploit-Geschichte. Stand (aktuell)
   3. Wie kann man's abschalten?
4. Besonderheiten beim Programmieren mit Javascript
   1. Cross-Browser, debugging
   2. Objekte: wie eine HTML-Seite in Objekte zerlegt wird (vor und nach DOM)
   3. Interaktion: der event-handler
5. Schnittstellen (Stellung zu anderen Techniken)
   1. HTML: im Code (z.T. im Tag: onMouseover), als separate Datei
   2. "dynamisches HTML"
   3. CSS
   4. ActionScript (Macromedia)
   5. JScript
   6. Server seitiges Javascript
   7. Verhältnis server- und cliente-seitige Scripts - Interaktion.
6. Sprachelemente
   • Da käme stark zusammen-kondensiert rein, was z.Z. unter Punkt 2 bis 11 steht. Prinzip: "Kontrollstrukturen sind die selben wie bei...", mit externen Links, z.B. zu SelfHTML
7. Weblinks

Ist bislang das einzige Unterkapitel, das halbwegs was taugt.

Begründung

In meiner Hitliste schlechter Wiki-Artikel ist JavaScript ganz oben. Die Autoren haben sich wohl kaum Gedanken darüber gemacht, an welchen User sich der Artikel richten soll. Ist es niemandem in den Sinn gekommen, dass hier ganz normale Internet-User nachschauen wollen, ob sie in ihrem Browser Javascript aktivieren oder deaktivieren sollten? Oder dass ein Programmierer, der sich nicht mit JavaScript auskennt, einen Eindruck gewinnen möchte, was die Sprache kann, und was nicht?

Bei der Definition haben sich Autoren heftigste Gedanken gemacht, ob Javascript denn eine Programmiersprache ist. Wo's drauf ankäme, dass das Zeugs vom BROWSER interpretiert wird, steht da: JavaScript auf dem Client ausgeführt. Ja, das wird M$-Word und der Acrobat-Reader auch.

Oder folgender Schmonz: "Mittels einer Schnittstelle zum Document Object Model (DOM) können Elemente der Webseite manipuliert werden, nachdem diese zum Client übertragen wurden."

• Elemente einer Webseite "manipuliert"?? Mit document.write war Javascript schon unter Netscape 2 (bei 3 weiss ich's sicher) in der Lage, komplette Webseiten zu generieren, PopUps zu öffnen, etc. etc.
• "Mittels einer Schnittstelle zum Document Object Model" ist auch so ein Käse. Die Forumular-Elemente wurden von Javascript schon immer "manipuliert", einen <input type=""hidden"> gibts wahrscheinlich nur zu dem Zweck, dass dort Werte per Javascript geändert werden.

Statt dessen wird hier so eine Art vergleichende Semantik am Beispiel Javascript abgehandelt - fernab von brauchbarer Theorie und vor allem Praxis. Wo es beim Javascript-Programmieren tatsächlich darauf ankommt, den Code ständig mit den aktuellen Browsern zu testen und Debugger einzusetzen, steht da was über try...catch...schnarch...

Überflüssige Details raus!

Ein neues Element an das Ende des Array anhängen. Derlei gehört, wenn überhaupt in das Lemma arrays. (Ich verwende ständig arrays, habe diese Funktion aber weder in PHP, geschweige denn in Javascript jemals gebraucht.)

Stilistisches

• Allen Objekten können zur Laufzeit neue Eigenschaften hinzugefügt. Wann denn sonst??? Wir reden hier über eine Scriptsprache!
• Switch-Kontrollstruktur etc: Quellcode ohne jede Erläuterung. Gehört sowieso nicht hierher, sondern in das Lemma Switch. Und unkommentiert gehörts nirgendwo in Wikipedia rein.
• "Interessant ist die Tatsache, dass JavaScript im Gegensatz zu klassisch objektorientierten Sprachen keine Klassen einsetzt, sondern statt dessen Objekte als Prototypen verwendet.".
  Eigentlich hats mich ja nicht interessiert, was Prototypen sein sollen, aber als ich unter dem Lemma Prototyp nachgesehen habe...

Fazit

• auf einer anderen Seite komplett neu bauen
• Löschantrag für die alte Version
• ersetzen

--Asw-hamburg 03:59, 2. Nov 2005 (CET)

Die Gliederung sieht bis auf einige Schwachstellen sehr brauchbar aus - den Vergleich zum Artikel PHP verstehe ich aber nicht, die Gliederung geht über den (m.E. überhaupt nicht vorbildhaften PHP-Artikel) zum Glück hinaus.

Im Detail scheinst du in eine fragwürdige Richtung zu wollen. Ist es niemandem in den Sinn gekommen, dass hier ganz normale Internet-User nachschauen wollen, ob sie in ihrem Browser Javascript aktivieren oder deaktivieren sollten? Wikipedia ist aber keine Howto-Sammlung. Daran krankt der Artikel doch gerade! Ein Artikel zu JavaScript muss nicht die Frage Wie bediene ich meinen Browser beantworten, genausowenig wie er dem Leser JavaScript beibringen kann.

Deine Kritik am Satz zum DOM verstehe ich nicht. Was soll der Vergleich zu document.write? Operationen am Knotenbaum mit W3C-DOM ist eine komplett andere Geschichte als das primitive DOM von Netscape Client Side JavaScript, das das Ändern von Formularfeldern erlaubt. Manipulation meint etwas ganz anderes, nämlich ein beliebiges Ändern des Knotenbaums. Nein, das geht nicht mit konventionellem JavaScript. Und <input type="hidden"> ist auch nicht nur für JavaScript geschaffen worden.

-- 83.129.36.29 20:28, 3. Nov 2005 (CET)

Zu Besonderheiten beim Programmieren mit Javascript:

Cross-Browser, debugging - Was auch immer damit gemeint ist? Bitte nicht erklären, wie man JavaScripte debuggt, sondern allgemein die Problematik der browserübergreifenden und kompatiblen Verwenden von Objekten usw.

'Objekte: wie eine HTML-Seite in Objekte zerlegt wird (vor und nach DOM) - Darunter kann ich mir nichts vorstellen, was ist gemeint? Kurze Erklärung des DOM Core/DOM HTML?

Interaktion: der event-handler - Die Erläuterung des Event-Handlings sollte eher schon am Anfang unter Verwendung geklärt werden, wie die gesamte Einbettung in HTML und Zusammenarbeit mit HTML. Man kann ja nicht in Abschnitt 2 die Verwendung schildern, aber erst in Abschnitt 4 beschreiben, wie JavaScript-Logik in ein HTML-Dokument eingeflochten wird.

Sachverhalte wie das Sandbox-Prinzip sollten schon relativ am Anfang (zumindest einführend) angesprochen werden, wo der Einsatzbereich und die Fähigkeiten/Ziele von JS grundlegend umrissen werden. -- molily 20:47, 3. Nov 2005 (CET)

Lob zu Abschnitt 12

Hallo,
ein Lob an den/die Schreiber des Artikels für Abschnitt Zwölf! Genau dieses Thema (Eigene Objektmethoden, Vererbung durch Prototyping), einfach erklärt, hab ich anderswo vergeblich gesucht.
(Negativbeispiel ist Selfhtml. Doku schweigt sich aus, der Feature-Artikel ist fehlerhaft).

Vorschlag: Wir machen aus diesem Artikel ein Wikibook, und schreiben für die Enzyklopädie eine neue, verkürzte Version. Aber bitte nicht löschen, wäre echt schade.

--Nils Holgerson 14:09, 12. Mär 2006 (CET)

(Eigentlich etwas früher, aber grade erst das mit den Tilden gecheckt)

Stimmt das wirklich alles, wie es da steht? Soweit ich weiß, ist JavaScript doch eine Skriptsprache und keine Programmiersprache, und das mit dem objektorientiert ist auch nicht wirklich zwingend. Kann jemand bestätigen, daß die Syntax so ähnlich ist wie die von Java (das ja eine C++-ähnliche benutzt)?

Mein Stand der Dinge war bisher eher:

• Netscape hat JavaScript erfunden, trotz der Namensähnlichkeit hat es aber nicht mit Java zu tun.
• um der Sprache etwas mehr Glaubwürdigkeit zu verleihen wurde sie später der ECMA zur Standardisierung vorgelegt.
• danach wurd sie auch dem W3C vorgelegt, da Microsoft aber inzwischen mit JScript eine eigene Sprache erfunden hatte, wurde keine von beiden zum Standard erhoben, sondern stattdessen ein Standard zur Erstellung von Skriptsprachen entwickelt, der dann zu DOM wurde.

Der letzte Satz ist nicht richtig: DOM heisst Document Object Model und hat mit der Sprache direkt nichts zu tun. Mit der Sprache greift man aber auf die Objekte zu, aus denen ein Dokument aufgebaut ist.

--SoniC

Ich kenn mich da auch nicht aus. Allerdings ist die Syntax ähnlich C und damit Java. Eine Skriptsprache ist auch eine Programmiersprache.

--Vulture

OK, aber Skriptsprache finde ich trotzdem genauer, Programmiersprache klingt immer so nach Informatikstudium :-). Und wie ist das mit den Schnittstellen zu DOM? Kann man das wirklich so schreiben?

Ja siehe www.w3.org|http://www.w3.org www.w3.org

Ich habe das früher auch so gesehen, aber seit ich mir das umfassende Werk von O'Railly zu gemüte geführt hat, erinnert mich JavaScript auch immer mehr an Informatikstudium. Dubaut 13:32, 7. Mär 2006 (CET)

--SoniC

Naja, eigentlich ist weder Programmiersprache noch Skriptsprache. (Bei Skriptsprache denke ich hier an Shell-Skripte zum Beispiel.) Dafuer ist sie durch den Browser IMHO rechtlich zu sehr eingeschraenkt. Wie waere es mit "Web-Skriptsprache"?

--Evolux

aalso:

• Syntax ist wie in allen C/C++-Verwandten (wozu neben Java und JS auch noch PHP gehört).
• Erfunden wurde das ganze als "LiveScript" von Netscape, dann in JavaScript umbenannt.
• MS JScript ist im Grunde das gleiche, aber erweitert um einige DHTML-Funktionen und vor allem um Funktionen für das Scripting des Betriebssystems.
• DOM hat mit der Syntax nichts zu tun, wohl aber mit den Objekten in der Sprache. Und eben diese waren anfangs Alternativ zu den JScript-Erweiterungen, heute kann der MSIE beides.
• Netscape selbst hat dem ganzen auch noch einige Objekte verpasst, die nicht in dem ECMA-Standard gelandet sind (document.layers). Diese sind heute ausgestorben.

TheK 19:48, 27. Jun 2004 (CEST)

--MatthiasSchulze

Wie ihr seht sind die Unterschiede zwischen Programiersprache und Scriptsprache schwer zu definieren, deswegen würde ich darauf garnicht rumreiten und es evtl. nur Beiläufig erwähnen. Viel wichtiger wäre zu erwähnen das JS eine interpretierte Sprache ist.

$elias 17:37, 16. Mai 2005 (CEST)

Habe Details zu Vererbung und Prototypen ergänzt. So ok?

--XRay 14:26, 24. Dez 2004 (CET)

Die Umlaute aus den Beispielskripten habe ich ersetzt, da dies in den Skripten bzw. XHTML- oder HTML-Seiten zu Problemem (oder Fehlern) führen könnte, zum Beispiel abhängig davon, ob jemand ISO-8859-15 oder UTF-8 als Zeichensatz nutzt.

Zu dem Umlauten in Kommentaren etc. Ja, Umlaute dürfen auftreten, sie müssen nur mit dem Zeichensatz passen. Probleme gibt es in der Regel dann, wenn man zum Beispiel XHTML-Dateien erstellt, diese mit UTF-8 verfasst, dann aber Umlaute in ISO-8859-1 einbringt. Daher gehe ich eher den Weg, Umlaute zu vermeiden.

Artikel droht auszuufern

Es werden immer mehr irrelevante Details eingefügt, anstatt die Substanz zu erneuern - könnt ihr euch bitte an der Diskussion beteiligen (siehe oben), damit eine vernünftige Lösung gefunden wird? -- molily 7. Jul 2005 11:14 (CEST)

Ich möchte mich dem anschliessen! Viiiel zu viiiel! Schon auf den ersten Blick erschlagen einen zuviele Details, die nicht in die Wikipedia gehören. (Wurde hier alles schon irgendwie gesagt.) --83.135.5.126 20:41, 30. Aug 2006 (CEST)

Als zufällig vorbeikommender User kann ich über die seite folgendes sagen: diese seite hat (vor allem gegen den schluss hin) nichts mehr mit einem artikel, der in eine enzyclopedie gehört, zu tun. es gleicht mittlerweile mehr einer einführung in die scriptsprache. z.T. werden Details wie das try-catch-finally konstrukt erklärt. daher: wäre super wenn sich jemand die mühe macht, den artikel zu entrümpeln. --212.241.81.152 14:40, 6. Sep 2005 (CEST)

Beifall und Zustimmung. Nur ein Beispiel: Hier wird sogar die Objektorientierung erklärt, im Abschnitt "Öffentliche und private Methoden und Eigenschaften" zB. Das hat hier tatsächlich nichts zu suchen . -- Benutzer:60.234.145.15

»Sogar« ist witzig. Objektorientierung ist eine der wichtigsten Eigenheiten von JavaScript. In dem besagten Abschnitt wird sicher das allgemeine OO-Konzept der Kapselung beschrieben - aber jeweils mit speziellem Bezug auf JavaScript. Wo bitte ist das in der Wikipedia verständlich und mit Praxisbezug beschrieben, sodass es der Leser auf JavaScript übertragen könnte? Objektorientierte Programmierung#Kapselung bleibt vollkommen allgemein. Da steht eben: Die Möglichkeiten zur Spezifizierung der Zugreifbarkeit sind je nach Programmiersprache unterschiedlich. Der kritisierte Abschnitt soll daran anknüpfend die JavaScript-spezifische Kapselung beschreiben. OO-Sprachen wie JavaScript mit Prototypen, prototypischer Erweiterung, Konstruktorfunktionen, Funktionsobjekten usw. werden im Artikel Objektorientierte Programmierung überhaupt nicht bedacht. JavaScript ist in dieser Hinsicht auch ziemlich einzigartig, sodass die Übertragung von allgemeinem OOP-Wissen (Klassen und Co.) schwer ist.

"Objektorientierung ist eine der wichtigsten Eigenheiten von JavaScript" ???

Javascript ist wohl das blödeste Beispiel für OOP. Ob ins Lemma Objektorientierte Programmierung ausgerechnet Javascript-Beispiele gehören, halte ich für fragwürdig. Überhaupt haben Objekte in Javascript nur deswegen eine Bedeutung, weil man ohne Kenntnis darüber die ganze Syntax nicht versteht. (document.images[3].src, z.B.). Derlei hat aber mit dem Generieren von Objekten (geschweige denn von Klassen) nix zu tun. Man kann zwar in Javascript auch Objekte bauen, weil's halt Java zum Vorbild hatte. Aber verwenden tut doch kaum jemand dieses Feature.

Daher: irrelevant und raus damit.--Asw-hamburg 04:26, 2. Nov 2005 (CET)

Jaja. OOP mit dem Prototypen-Konzept ist eine herausragende Eigenschaft von Javascript. Wenn das nicht beschrieben werden soll, dann frage ich mich, was überhaupt noch an Javascript programmiertechnisch eigenartig ist. Alles andere habe ich schon geschrieben. Falls du einmal JavaScripte gesehen hast, die über eine gewisse Komplexität hinausgehen, findest du immer das Erzeugen eigener Objekte. »Kaum jemand nutzt es« ist ein Nullargument. -- 83.129.36.29 20:11, 3. Nov 2005 (CET)

kann ich nicht zustimmen. zuerst: javascript hat java nicht zum vorbild. es hat die gleichen schlüsselwörter, und irgendein marketingfuzzi hat mal beschlossen es sollte so heißen, aber die sprache an sich ist völlig anders. für jemanden der mit C++ oder java großgeworden ist das schwer zu verstehen, daß man einfach keine klassen braucht um OO zu bekommen. es reicht objekte in den rang von prototypen zu erheben.

auch was die vereinheitlichung von funktion und objekt angeht ist JS einfach ein gutes stück weiter. diese vereinheitlichung und auch die einbeziehung von konzepten aus der funktionalen programmierung ist etwas, was JS schon ewig hat, während erst die nachfolger von java und C# wie zum beispiel Xen, Scala (Programmiersprache) oder Boo in dieser hinsicht langsam gleichziehen.

natürlich, javascript hat kein statisches typing - das war als JS geschaffen wurde für eine derart dynamische sprache einfach nicht möglich. man musste, wenn man darauf nicht verzichten wollte, eben eine sprache wie java bauen, die näher an der maschine und weniger abstrakt ist. das einzige wo C++ wirklich deutlich weiter ist, ist generische programmierung.

wenn's dich übrigends böckt, es reichen wenige handvoll zeilen um klassen nachzubauen - nur will das eigentlich niemand, weil es nicht viel bringt. -- -- ∂ 20:54, 3. Nov 2005 (CET) heute mal weeeit aus dem fenster gelehnt

Ich würde ja die Kritik einsehen, dass der Abschnitt an sich deplatziert ist (siehe oben), aber die jetzige Umsetzung halte ich für in sich stimmig. Man kann einen solchen Zusammenhang, wenn man ihn denn beschreibt, nicht völlig ohne Erläuterung des Kontextes beschreiben. Und der allgemeine OOP-Artikel schildert den Kontext m.M.n. nicht ausreichend. -- molily 05:16, 15. Sep 2005 (CEST)

Dann muss der geändert werden. Wenn der Artikel schon das bißchen OOP von Javascript nicht erhellt...--Asw-hamburg 04:26, 2. Nov 2005 (CET)

Ich finde, das könnte auf die Wikibooks ausgelagert werden. -- Benutzer:213.39.223.91

Gute Idee. Allerdings schreibe ich persönlich schon an einem Buch über JavaScript, nämlich an SELFHTML. Daher möchte und kann ich nicht gleichzeitig am JavaScript-Wikibook arbeiten. Vor allem müsste man dort bei Null anfangen. Mitarbeiter gibts auch noch keine (fast genau wie hier). Darauf habe ich nicht einmal Lust. Wer mag sich dessen annehmen? -- molily 05:43, 20. Sep 2005 (CEST)

Mir scheints eher das man den Artikel eher zu einer kleinen Scriptsammlung gemacht hat statt nur wichtige Eigenschaften der Sprache zu beschreiben. -- Crossroad 18:11, 20. Okt 2005 (CEST)

Aus der Wikipedia:Qualitätssicherung/2. November 2005

• Wichtige Unterkapitel fehlen, statt dessen neun überflüssige Unterkapitel
• keine Allgemeinverständlichkeit
• fachliche Mängel (z.B.: Javascript als Beispiel für OOP

Was ist daran falsch? JavaScript IST eine objektorientierte Sprache, lediglich (wie schon weiter oben erwähnt) wird das eher unpopuläre System der Prototypen-Vererbung und nicht die Klassen-Vererbung angewendet. Dubaut 13:39, 7. Mär 2006 (CET)

• offenbar keine Akzeptanz

→ Diskussion:JavaScript

--Asw-hamburg 05:19, 2. Nov 2005 (CET)

JavaScript habe nichts mit Java zu tun

Das ist nicht richtig, insofern als Netscape Inc. die Syntax nachträglich und in Kooperation mit Sun an Java angepaßt hat; gleiche Schreibungen (Syntax) sind also weder ein Zufall noch einfach nur eine Folge davon, daß beide Sprachen sich am an Schreib-Stil von C orientiert haben; sondern Netscape hat ganz bewußt die Syntax von JavaScript der von Java angeglichen.

Meines Wissens existierte die Sprache schon vor dem Deal mit Sun unter dem Namen LiveScript. Es gab eine nachträgliche Anpassung der Syntax? Hast du dazu Quellen? Mir ist dazu nichts bekannt. Meines Wissens änderte sich zwischen LiveScript und JavaScript lediglich der Name (bzw. es änderte sich einiges von Netscape 2 zu Netscape 3, aber keine Sprachgrundlagen im Sinne einer »Anpassung an Java«). Ich lasse mich aber gerne vom Gegenteil überzeugen, wenn du Quellen nennst. -- molily 13:22, 23. Mär 2006 (CET)

Es ist richtig, daß die Sprache schon vor der Kooperation mit Sun existierte, man kann natürlich auch nur etwas an etwas anderes anpassen, wenn es schon vor der Anpassung existiert.

Dass ich die Quelle der Information aufzufinden, jetzt Zeit aufwenden werde, halte ich eher für unwahrscheinlich, da dies extrem aufwendig wäre, weil ich 1. nicht nur ein Buch oder nur 4 Web-Seiten über JavaScript gelesen habe und weil ich 2. solche Texte normalerweise nicht mit der Absicht lese, Beweise zu sammeln, um diese anderen Lesern vorzulegen. Benutzer:Parzi Irgendwann im Kosmos irgendwann danach.

Trotzdem bleibt JavaScript eine Erfindung von Netscape und auch die Idee, den Namen JavaScipt zu verwenden, geht meines Wissens auf Netscape zurück. Dass JavaScript eine eingetragen Marke von Sun Microsystems sein soll, wie der Artikel behauptet, erscheint mir daher äußerst fragwürdig.

Überarbeitet

Ich habe mal das ganze Handbuch zu JS rausgeschmissen; das gehört in Wikibooks rein, aber nicht in eine Enzyklopädie. Ich habe auch noch jede Menge anderes Zeug rausgejagt, das einfach nicht in den Artikel gehört.HD - B - @ 11:02, 30. Apr 2006 (CEST)

Der Hinweis dass der Artikel lang ist, ist durchaus berechtigt. Es ist aber sicher keine Lösung des Problems einseitig aktiv zu werden und erst mal einfach zu löschen und zu warten, dass andere den Inhalt in das Wikibook verschieben. Deshalb erst mal ein 'Revert' HJH 22:47, 30. Apr 2006 (CEST)

Das meiste steht bereits im Wikibook. Ich werde die bereits migrierten Inhalte hier löschen. -- molily 00:01, 1. Mai 2006 (CEST)

Kann jetzt eigentlich langsam mal der Überarbeiten-Baustein raus? --jpp ?! 13:13, 10. Mai 2006 (CEST)

Ich bräuchte mal Hilfe

Guten Tag, allerseits! Ich hab ein Problem, aber ich frage mich grade, ob hier die richtige Adresse ist. Ich benötige nämlich eine Funktion in JavaScript oder zu Mindest eine Internetseite, von der ich die holen könnte. Aber ich hab jetzt die Diskusion hier verfolgt und bin zu dem Schluss gekommen, dass Wiki nun mal eine Enzyklopädie und kein Fachhandbuch ist. Dennoch möchte ich hier mein Problam erläutern, weil ich voller Zuversicht bin, dass dies hier Fachleute lesen, die mir bestimmt helfen können.

Also folgendes: Ich hab von der Schule im Informatikunterrich die Aufgabe bekommen ein Programm mit html und JavaScript zu schreiben. Ich bin schon ziemlich weit gekommen, aber nun brauch ich einen festgelegten Befehl, der folgendes bewirkt: Der Nutzer des Programmes hat ein Wort eingegeben. Nun soll der Computer das Wort in einem zweiten Fenster wiedergeben, aber vorher die letzten drei Buchstaben des Wortes gelöscht haben. Weiß jemand wie der Befehl, die letzten 3 Buchstaben zu löschen, heißt? Ich hab leider kein Benutzerkonto auf Wiki. Drum müsste man mir die Antwort hier drunter schreiben. Sorry, dass ich jetzt noch mehr Platz beanspruche ...

-- Orpheus ex umbra 17:06 7.Mai.2006

moin, kuck dir die methoden des String-prototypen mal genau durch, und du wirst die lösung finden. mehr will ich jetzt nicht schreiben, schließlich ist es deine hausaufgabe. -- ∂ 17:18, 7. Mai 2006 (CEST)

Tausend Dank! Ich hab's gefunden! -- Orpheus ex umbra 14:26 10.Mai 2006

Was mit JavaScript nicht funktioniert

Im Artikel heißt es folgende Dinge seien mit JavaScript nicht möglich:

1. wirksamer Passwortschutz, da das Passwort in Klartext im Quelltext der Seite stehen würde oder zumindest der Verschlüsselungscode, so dass es rekonstruiert werden kann
2. Auslesen der IP-Adresse oder des Internetproviders

Punkt 1 halte ich nicht für korrekt, da folgendes Vorgehen durchaus sinnvoll sein könnte. Persönliche Daten sind auf dem Server etwa einer MySQL-Datenbank gespeichert. Diese Daten sollen an den Benutzer sicher übertragen werden. Ein Serverprogramm etwa in PHP programmiert, könnte die Daten verschlüsselt, z.B. als Textvariablen innerhalb von generiertem JavaScript, übertragen. Der Benutzer könnte in ein Formular (<input type=password ...>) den geheimen Schlüssel eintragen. Eine JavaScript-Funktion könnte die Daten dann entschlüsseln und darstellen. Die Eingaben, insbesondere das Passwort zur Entschlüsselung, brauchen nicht übertragen werden.

Welchen Sinn Punkt 2 ergeben sollte, scheint mir rätselhaft. Benutzer:Fsswsb 30.05.06

Mit einem Formular und CGI geht es natürlich, es geht um einen rein JS-basierten Passwortschutz. Bei 2 gibt es das rein technische Problem, dass ein Rechner mehrere IP-Adressen hat (u.a. 127.0.0.1) und der Browser und damit das JS nicht so ohne weiteres erkennen kann, welche die nach außen sichtbare ist, von Proxies usw. gar nicht zu reden.--Gunther 19:19, 30. Mai 2006 (CEST)

Wenn ich das jetzt richtig verstehe geht es um die Internetadresse des Clients (REMOTE_ADDR). Diese kann auf dem Server ausgelesen werden. Der kann Server damit erkennen von welchem Rechner bzw. Client Daten übertragen wurden. Ich kann aber nicht recht nachvollziehen warum es von Interesse sein sollte diese in JS auszulesen. Folglich sehe ich es nicht als Nachteil, dass dies nicht möglich ist.

(nicht signierter Beitrag von Fsswsb (Diskussion | Beiträge) 20:16, 30. Mai 2006)

Ja und?--Gunther 20:19, 30. Mai 2006 (CEST)

Zu 1: Wenn der Angreifer nicht mithören kann, ein Directory Listing und Spiders nicht erlaubt sind, und einige andere Voraussetzungen erfüllt sind, die mir gerade nicht einfallen, könnte dann etwas wie

 pwd = "password"; // aus Formular auslesen
 hash = hashfct(pwd);
 this.location.href = hash + ".htm";

einen gewissen (wenn auch schwachen) Schutz liefern? Horrorist 21:39, 30. Mai 2006 (CEST)

Die Hashfunktion kannst Du Dir sparen, das ist in jedem Fall security by obscurity.--Gunther 21:54, 30. Mai 2006 (CEST)

Ja, genau. Ich wollte damit auch nur sagen, dass ein "reiner" JS-Passwortschutz möglich ist, ohne dass das Passwort im Quelltext steht bzw. daraus rekonstruiert werden kann. Ob der noch "wirksam" ist, möchte ich nicht beurteilen. Die Hashfunktion kann unter Umständen auch Vorteile haben... Horrorist 00:20, 31. Mai 2006 (CEST)

Ich halte die ganze obige Diskussion und auch Teile des Artikels für überflüssig. Es werden hier immer zwei Sachen miteinander vermischt: clientseitige Programmierung und JavaScript. Dabei werden Argumente beliebig von einem auf das andere Thema übertragen. Z.B. Passwortschutz. Dieser ist in vernünftiger Weise selbstverständlich nicht innerhalb eines autonomen Programms möglich. Das ist jedoch keine Eigenschaft von JavaScript. --Squizzz 00:30, 31. Mai 2006 (CEST)

Warum "Überarbeiten"?

Das Bapperl ist deswegen drin, weil die Wikipedia eine Enzyklopädie ist (bzw. werden soll), dieser Artikel aber nicht im enzyklopädischem Stil geschrieben ist. Besonders deutlich:

• Das Mini-Tutorial muss raus
• Die alberne Liste mit Ratschlägen "gutes/böses JavaScript" muss raus

HD hatte dankenswerterweise bereits im April aufgeräumt, aber anscheinend können einige selbstverliebte Mitarbeiter nicht vertragen, dass Ihr Text unter den Tisch fallen soll. Schade.

Pjacobi 00:03, 31. Mai 2006 (CEST)

Fachartikel einleiten

Ich meine, dass eine Einleitung dem Laien eine Vorstellung von der Sache geben und nur allgemein verständliche Begriffe verwenden soll. Fachtermini hingegen gehören in den Teil nach der Einleitung. Das halte ich für die Methode der Wahl, abschreckungsfrei zu schreiben. Vorteil: Möglichst Viele profitieren, und mancher Laie fühlt sich ermuntert, weiter zu lesen. Können wir uns darauf verständigen, dass eine Einleitung diese Funktion haben soll?

Wenn wir darin d'accord gehen, stehen die Begriffe, die während der letzten zwei Tage in die Einleitung gelangt sind, diesem Ziel entgegen. Der interessierte Laie steigt aus, wenn er von diesen Termini begrüßt wird: "Elemente", "Hyperlinks", "Formularfelder", "Attribute", "Funktionen", "Ereignisse", "Events", "Anweisung" "<input onclick="dosomething()""

Laien sind in meinen Augen weder HTML-Programmierer noch die Computer-Versteher meines Freundeskreises, sondern z. B. Klempner, Ärzte, Schriftsteller oder sehr junge Menschen, die noch erkunden wollen, ob eine Sache ihres Interesses wert ist.

Wollen wir diese Leute nicht aussperren, sondern als Leser gewinnen, gehören Fachbegriffe in den Teil nach der Einleitung. Diese Trennschärfe und das Augenmaß für den zumutbaren Stil sind wir den Lesern schuldig.

Ich bin dafür, dass die Autoren der genannten schwer verdaulichen Termini sie in den Teil nach der Inhaltsübersicht verlegen, dort sachgemäß einfühen und die Einleitung so bekömmlich wie möglich gestalten.

"Den Stil verbessern, das heißt den Gedanken verbessern." Nietzsche

Mit besten Grüßen

--IZazen 14:15, 31. Mai 2006 (CEST)

In der aktuellen Einleitung steht, dass JavaScript bei ASPs verwendet wird. Meines Wissens kommt dort jedoch JScript zum Einsatz. Generell scheinen mir im Artikel die Begriffe JavaScript, ECMA262 und JScript teilweise synonym verwendet zu werden. --Squizzz 18:38, 31. Mai 2006 (CEST)

JavaScript und JScript sind (mehr oder weniger konforme) Implementationen des Standards ECMAScript. Dieser Artikel behandelt alles zusammen. --Pjacobi 19:51, 31. Mai 2006 (CEST)

Dann muss aber noch extrem viel getan werden, denn momentan behandelt der Artikel nicht alles zusammen bei Wahrung der Unterschiede. ECMAScript hat den konkreten JavaScript-Anwendungsbereichen und -Funktionen erst einmal nichts zu tun, auf die der Artikel ausgerichtet ist. -- molily 16:08, 1. Jun 2006 (CEST)

Ganz mein Reden, der Artikel ist in vielen Teilen falsch ausgerichtet. Zum Anwendungsbereich Webclient-Programmierung ist ja auch zu bemerken, dass der Artikel Document Object Model nicht gerade überfüllt ist. --Pjacobi 16:24, 1. Jun 2006 (CEST)

ECMAScript

Natürlich handelt der Artikel von ECMAScript, nicht nur weil der REDIRECT hierherzeigt, sondern hauptsächlich weil JavaScript eine Implementation des Sprachstandards ECMAScript ist. Nur ganz wenige, noch zu überarbeitende Teile des Artikels, sind JavaScript-spezifisch, insbesondere der Abschnitt "Geschichte". --Pjacobi 17:44, 8. Jun 2006 (CEST)

elseif

In JavaScript gibt es im Gegensatz zu anderen Programmiersprachen keine Kontrollstruktur

if ... elseif .... Stattdessen kann man zwei If-Anweisungen verwenden, von denen die
erste die zweite als Else-Code aufnimmt:

steht im widerspruch zu

Beliebig viele "Else if"-Blöcke sind erlaubt:

ist ein "elseif" so wie im codebeispiel auf der artikelseite angegeben nun möglich:

if (Bedingung) {
    Anweisungen;
} else if (Bedingung) {
   Anweisungen;
} else if (Bedingung) {
   Anweisungen;
} else {
   Anweisungen;
}

oder nur über den trick:

if (Bedingung) {
    Anweisungen;
} else {
    if (Bedingung) {
        Anweisungen;
    } else {
        Anweisungen;
    }
}

?

Gary Luck Diskussion 15:25, 21. Jun 2006 (CEST)

Ein „elsif“ ist nich möglich, ein „else if“ jedoch schon. Der Unterschied liegt darin, dass „elsif“ ein eigenes Wort wäre das für sich allein vom Parser erkannt wird. Bei „else if“ ist das nicht der Fall. Dies ist nur eine Kurzschreibweise für „else { if ...}“. Der Unterschied ist für den Programmierer in der Regel jedoch unwichtig. --Squizzz 18:54, 21. Jun 2006 (CEST)

--> "Inkrementier-Ausdruck" erklären und/oder Verlinken! Konnte als Schüler zunächst nichts mit anfangen!

Unausgewogenheit Sprachdefinition<->Laufzeitsystem?

Also, wenn der Artikel so ausführlich auf die Sprachdefinition und die Eigenschaften des Objektsystems eingeht (was ich nicht schlecht finde, auch wenn man es vielleicht "lexikographischer" machen könnte), dann sollte auch zumindest kurz die Einbindung der üblichen JavaScript-Implementierungen in die Browser besprochen werden. Das "window"-Objekt beispielsweise taucht am Ende so "en passant" auf, ohne dass es vorher mal erwähnt wurde. Man sollte also zumindest kurz sagen, dass die JavaScript-Runtime auf bestimmte Weise die "aktuelle Seite" und den Browser im Objektgraphen abbildet, man sollte die wichtigsten vordefinierten Objekte nennen etc. Im Moment hängt die ausführliche Erklärung der Sprache selbst etwas zusammenhanglos in der Luft.

Multi io 21:46, 1. Sep 2006 (CEST)

Missbrauch

Seine Webseite vor Datenraub zu schützen ist wohl kein Missbrauch einer Scriptingsprache. Desweiternen gibt es doch sicher ernsthafte Missbrauchszenarien. Wie auch schon gebracht, siehe Popups. Ich bin der meinung dieser Teil sollte auf neutraliät geprüft werden und generell werweitert bzw. überarbeitet werden.

Eddy 13:35, 7. Sep 2006 (CEST)

Da man Inhalte auf Webservern so nicht vor "Raub" schützen kann, ist der Einsatz dazu sinnlos. Ob es Missbrauch ist oder ein Mittel sich lächerlich zu machen ist Ansichtssache.

Wenn du Angst hast, dass es dir gestohlen wird, dann veröffentliche es halt auch nicht. --ChristianErtl 18:09, 19. Mai 2007 (CEST)

Was aber rein sollte: Fast alle Würmer, Trojanische Pferde und sonstige Schädlinge brauchen JavaScript oder ähnliches, um wirksam zu werden. Somit ist Javascript-Abschalten auch ein Sicherheitsgewinn (unter Verlust von Komfort). --217.91.18.104 11:07, 19. Dez. 2006 (CET)

Naja, Firefoxnutzer haben es da gut! Wer die Erweiterung NoScript nutzt, kann selber entscheiden welche Seiten Scripte ausführen, alle anderen werden unterdrückt. --MfG, Bkmzde 08:33, 30. Jan. 2007 (CET)

Ich schreibe gerade eine Studienarbeit in welcher ich die unter Missbrauch genannten Punkte aufgreifen möchte. Ich finde die Überschrift jedoch auch nicht allzu passend / neutral genug. Als Bsp. wäre z. B. die Reduzierung des Traffics zu nennen, die durch eine Verschleierung von Grafiken entsteht. Klar ist es für den Benutzer auf den ersten Blick nur ärgerlich, jedoch muss man es auch wirtschaftlich sehen, da die Kosten für den erhöhten Traffic bei einer großen Webseite letztendlich mit großer Wahrscheinlichkeit wieder beim Benutzer landen. Leute die bisschen Ahnung haben kommen natürlich trotzdem an die Links, aber die Verschleierung ergibt meines Erachtens trotzdem Sinn. Mein Vorschlag: Übreschrift "Missbrauch" entfernen und einfach mit etwas in der Art weitermachen: "Außerdem wird die Skriptsprache oftmals dafür verwendet um die Interessen des Betreibers einer Webseite durchzusetzen. Diese Verwendung wird vom Benutzer oftmals als störend empfunden. Dazu gehören folgende Anwendungsgebiete:" Gruß --Knowledgeisnotwisdom 20:37, 5. Jun. 2008 (CEST)

im Artikel finde ich nichts, was deiner Beschreibung entspricht. Zum Thema Grafiken im Abschnitt Missbrauch steht da nur was zum Kontextmenü. Solltest du das meinen verstehe ich nicht, was das für eine Trafficeinsparung ergeben soll.--Fritzbruno 16:29, 6. Jun. 2008 (CEST)

Nun ja, wenn der Benutzer auf das Kontextmenü über einer Grafik zugreifen kann, dann gibts dort den Punkt "Grafikadresse kopieren" bzw. "Grafik anzeigen" und dann is die Adresse in der Adressleiste des Browsers zu sehen. Und nehmen wir mal an es ist ein "brisantes Bild" und der Link wird z.B. im IRC gepostet, dann kommen sehr schnell paar GB / TB Traffic zustande... Mit etwas KnowHow kriegt man natürlich trotzdem leicht den Link raus, aber man muss halt wissen wie und das weiß nicht jeder Hans Wurst. ich würde es einfach neutraler und sachlicher finden, wenn man "missbrauch" entfernt und einfach schreibt: "Außerdem wird die Skriptsprache dafür verwendet um die Interessen des Betreibers einer Website durchzusetzen. Diese Verwendung wird vom Benutzer oftmals als störend empfunden und wird als „schlechter Stil“ angesehen. Dazu gehören folgende Anwendungsgebiete:" - sag mir was dagegen spricht? MfG

Achso und das man sich mit javascript schadcode einfangen kann fehlt mir irgendwie auch, da geb ich meinem vorredner recht... --Knowledgeisnotwisdom 20:39, 6. Jun. 2008 (CEST)

Eine Webseite ist im Allgemeinen immer dazu da, die Interessen des Betreibers durchzusetzen. Wenn diese darin bestehen, die Browserfunktionalität des Besuchers mit JavaScript zu stören, kann man das sehr gut als Missbrauch bezeichnen. Schadcode kann man sich dagegen mit JavaScript nicht einfangen. Es ist zwar so, dass sich viele Browserlücken mittels JavaScript ausnutzen lassen, das ist aber kein Problem von JavaScript an sich. -- net 00:53, 7. Jun. 2008 (CEST)

Stimmt auch wieder. Naja gibt wohl auch wichtigere Themen, dann lassen wir das ma so (obwohl das mit dem traffic ein gutes argument ist, dass der punkt mit den links nicht immer als missbrauch zu gelten ist, sondern eher ein schutz sein kann...) naja whatever --Knowledgeisnotwisdom 01:22, 7. Jun. 2008 (CEST)

ich muss nur noch mal auf deinem Grafikbeispiel rumreiten: Für derlei Probleme gibt es sinnvollere Lösungen, zB serverseitige Techniken, die das Bild nur vom Server ausliefern lassen, wenn es von einer eigenen Seite angefordert wird. Da die Manipulation am Browser also nicht mal nötig, geschweige denn irgendwie effektiv ist, finde ich die Bezeichnung "Missbrauch" sehr treffend.--Fritzbruno 07:02, 7. Jun. 2008 (CEST)

Liste von objektorientierten Programmiersprachen

http://de.wikipedia.org/wiki/Liste_von_objektorientierten_Programmiersprachen Hier steht noch immer JavaSkript in der Liste, ich erwähne das mal hier.

Im Artikel wird im ersten Link "OB" noch immer nach "OO" verlinkt. Ich möchte den Erstellern des wikis nicht reinmurksen, daher ändere ich das nicht selbst. (nicht signierter Beitrag von 84.140.37.94 (Diskussion | Beiträge) 09:35, 21. Apr. 2006 (CEST))

Neue Einleitung

Ich hab die Einleitung etwas überarbeitet. Alles in allem ist der Artikel eigentlich eine Symbiose aus DOM 0 und JavaScript. Vielleicht sollte man beides trennen? Die Sprache hat sich mittlerweile schon lange von den Browsern losgelöst... Cookies/HTML/alert etc. sind alles nicht Teil von JavaScript (siehe z.B. VBS im IE oder die Beispiele mit Tcl vom W3C in der HTML Spec) sondern vom Browser. --Volatile 12:40, 19. Apr. 2007 (CEST)

Client- oder Serverseitig?

Der Artikel widerspricht sich. In der Einleitung steht (hab's mal stehen lassen): "Es gibt daneben in JavaScript geschriebene Programme, die serverseitig ausgeführt werden. Der HTML-Code wird also serverseitig erstellt und an den Webbrowser geliefert." Im "Überblick" heißt es dagegen: "JavaScript ist eine objektbasierte Skriptsprache, die im Unterschied zu serverseitigen Skriptsprachen wie zum Beispiel Perl oder PHP, clientseitig eingesetzt wird" Was denn nun? Meines Wissens gibt es kein serverseitiges JavaScript. Falls doch, hat jemand ein Beispiel dafür? --Kjuu 15:42, 18. Apr. 2007 (CEST)

Doch es hat sich nur nicht durchgesetzt, Netscape hatte immer auch Serverprodukte im Angebot! --Popolfi 18:41, 6. Apr. 2008 (CEST)(nachträgliche Signatur)

Es gibt einige Verwendung für JavaScript außerhalb des Web-Browser und außerhalb von Web-Applikationen im Allgemeinen. JavaScript wird beispielsweise - oft aber in angepasster oder erweiterter Form - gerne für Anwender-Scripte in Applikationen genutzt. Es gibt aber auch komplette Server-seitige Web-Frameworks, zum Beispiel eine Ruby on Rails Portierung. Die kommende Version 3.0 des Spring Frameworks wird eine Server-seitige JavaScript-Integration enthalten. Manchmal kommt die Sprache auch für DSLs zum Einsatz oder um einfach Tests schreiben zu können. Allerdings hat sie sich außerhalb des Browser bisher wirklich kaum durchgesetzt.

Ansichtssache, VBScript und JScript sind eng verwandt und laufen auf dem gleichen Windows Scripting Host. Wo also VBS läuft kann auch JScript laufen! --Popolfi 18:44, 6. Apr. 2008 (CEST)

---

JScript und JavaScript nicht kompatibel??

Der Sprachkern von JScript ist haargenau JavaScript, incl. diverser als Designfehler angesehener Dinge, bei denen MS darauf bestand, sie drinzulassen. Dass die DOM-Bibliotheken an einigen Stellen anders sind, hat damit nix zu tun. MS hat mit JScript auch keine "eigene" Sprache entwickelt, sondern die Netscape-Implementation nachgebaut, und zwar sehr sorgfältig. Und dass das ganze den Browser-Krieg auslöste, halte ich auch für eine recht zweifelhafte Behauptung. Ich wäre dafür, diesen Absatz zu ändern. Multi io 06:32, 16. Feb. 2007 (CET)

"Beide Sprachen sind nicht kompatibel zueinander, allerdings sind sie sich ähnlich" irgendwie ziemlich ungeschickt formuliert dieser Satz, weil wenn jetzt jemand wenig/keinerlei Ahnung von JScript hat und danach im Wiki sucht landet er wieder auf der Javascriptseite ohne irgendwelche zusätzlichen Infos über JScript. (Weder in den Links, noch generell irgendwelche Infos über JScript, zu Javascript findet man aber Links zu Mozilla...) --Lastwebpage 00:40, 31. Mär. 2007 (CEST)

wikibooks

ist ja schon sehr viel, vieleich ein wikibook?

Ich finde es nicht wirklich angebracht, fast schon so etwas wie ein kleines Tutorial oder eine Sprachreferenz in einen Artikel einzubauen. Daher denke ich, man sollte diese Inhalte in ein Wikibook verschieben. --84.175.111.148 13:54, 31. Mär. 2007 (CEST)

öffentlich und privat

Ich weiß es einfach nicht ob das wirklich so richtig ist, das sollte mal jemand nachlesen ob das wirklich so stimmt:

Funkionen,Elemente innerhalb der Funktion

privat

Funkionen,Elemente innerhalb der Funktion mit einem Verweis auf die aktuelle Instanz (this)

öffentlich

Das mag ja durchaus stimmen, nur wiederspricht das irgendwie dem was die meisten anderen Programmiersprachen unter öffentlich und privat verstehen. --Lastwebpage 00:52, 31. Mär. 2007 (CEST)

IMHO sollte man hier unbedingt statt "privat" eher "lokal" benutzen und statt "öffentlich", "Methode" oder "Instanz-Variable". Die Begriffe "privat" und "öffentlich" werden sonst sehr leicht mit den Schlüsselwörtern "private" und "public" verwechselt. Wenn man es genau nimmt ist der Abschnitt "Öffentliche und private Methoden und Eigenschaften" überflüssig und irreführend. (nicht signierter Beitrag von 87.187.228.41 (Diskussion) 13:08, 29. Mai 2007)

Ich bin kein OOP-Fachmensch, aber inwiefern widerspricht diese Einteilung der in der OOP üblichen (siehe Datenkapselung (Programmierung))? In JavaScript gibts zwar keine Klassen, sondern nur Instanzen, die durch Konstruktoren erzeugt werden, aber wieso funktioniert dort die Unterscheidung private - public nicht? -- molily 21:19, 29. Jun. 2007 (CEST)

Java & SUN

Java ist eine Marke von SUN aber doch nicht JavaScript!!!!

Da Netscape ja auf die Marke Java bei der Benennung zurückgegriffen hat, ist sicherlich auch JavaScript eine Marke von Sun. --ChristianErtl 14:50, 23. Jun. 2007 (CEST)

Siehe hier: http://www.sun.com/suntrademarks/#J --ChristianErtl 14:57, 23. Jun. 2007 (CEST)

Ergänzung zu Vererbung unnötig

Der Text nach dem Satz »Ein weiteres Beispiel zum Verständnis der Vererbung:« im Abschnitt »Vererbung« sagt nichts neues und erklärt die Vererbung auch nicht nochmal verständlicher. Er stellt lediglich fest, dass wenn man einem abgeleiteten Prototyp (PKW) eine Methode gibt, die nicht bei Instanzen eines anderen abgeleiteten Prototyps (Motorrad) existiert. Ach was. Als »Lösung« wird zunächst das doppelte Notieren, dann das bessere Notieren beim Ursprungsprototyp (Kraftfahrzeug) vorgestellt. Ist ja auch alles richtig, aber gehört das dort wirklich hin? Dass dem PKW-Prototyp eine Methode angehängt wird, hat sowieso nur exemplarische Gründe. Logisch gesehen würde man wahrscheinlich allen Kraftfahrzeugen eine Eigenschaft Radanzahl und Methode zeigeRadanzahl geben - die sind natürlich nicht eigentümlich für PKWs. Wenn sich einer daran stört, bitte das ursprüngliche Beispiel mit PKW.prototype.Radanzahl und PKW.prototype.zeigeRadanzahl ändern. Die Ergänzung werde ich daher herausnehmen. -- molily 21:45, 29. Jun. 2007 (CEST)

Alles hat ein Ende !

Ich habe mir diesen Artikel nun mehrfach durchgelesen und dachte zunächst ich könnte durch einige kleine Änderungen etwas zu seiner Qualität beitragen. Nach reiflicher Überlegung bin ich zu dem Schluß gekommen : "Irgendwo ist da Hopfen und Malz verloren". Nochmehr nachdem ich mir die Diskussionsbeiträge angeschaut habe. Da hat nichts Hand und Fuß. Der Artikel schweift aus in Allgemeinpläze wie 'Skriptsprache'; 'objektorientiert',.... dann geht die Diskussion in die Richtung ob denn nun oder nicht. Meinen Beitrag dazu möchte ich dann doch einigen ersparen, so ich eine sinnvolle eher darin sehen würde ob denn nun Javascript überhaupt als Programmiersprache bezeichnet werden kann. Jedenfalls wird im Artikel auf syntaktische Details eingegangen, die meines Erachtens hier nichts zu suchen haben (auch aufgrund der etwas redundanten Linkliste), während auf relevante Dinge wie beispielsweise der Verfügbarkeit (Existenz ?) von Interpretern die nicht in Browser eingebettet sind oder tatsächlich vorhandenen Entwicklungumgebungen überhaupt nicht eingegangen wird.

Ich bitte alle Beteiligten sich zu überlegen ob es nicht am sinnvollsten sein könnte den Artikel vollständig zu löschen und komplett neu aufzubauen !

samtrot

PS: Babel kennt keinen Hopfen

*seufz* das hab ich mir auch schon hin und wieder gedacht, und an neuschreiben. warum javascript allerdings keine programmiersprache sein sollte, müsstest du mir erklären. -- ∂ 10:46, 6. Jul. 2007 (CEST)

Wenn dir der Artikel zu wenig Inhalt bietet, warum nimmst du dann vorhandene Informationen wie „JavaScript ist eine objektbasierte Programmiersprache“ oder „Bei JavaScript interpretiert ein Interpreter einer Script-Engine zuvor aus Quelltext (JIT-)compilierten Bytecode“ raus? Deine heutigen Änderungen haben IMO den Artikel jedenfalls nicht besser gemacht. Miste doch lieber den Absatz Sprachelemente aus. Die syntaktischen Ausschweifungen haben in dem Artikeln nämlich wirklich nichts verloren.

BTW: Bitte signiere deine Beiträge hier in der Diskussion. -- net 12:04, 6. Jul. 2007 (CEST)

die geschichte mit dem interpreter ist so nicht richtig: mag sein, daß eine JS-engine das so macht, es gibt aber diverse andere möglichkeiten und die spec macht da keinerlei vorschriften. -- ∂ 12:54, 6. Jul. 2007 (CEST)

Der Text ging ja auch mit „oder (seltener) den Quelltext direkt.“ weiter und war schon richtig. -- net 13:21, 6. Jul. 2007 (CEST)

nein. direkt auf dem quelltext wäre zwar möglich, aber ich bin mir ziemlich sicher, daß das niemand freiwillig versucht. wohl eher operiert die engine auf dem AST. aber selbst wenn sie maschinencode erzeugte, wäre das eine eigenschaft der engine, und nicht der sprache! -- ∂ 16:13, 9. Jul. 2007 (CEST)

Benutzerfreundlichkeit?

Inwiefern ist eine Website nicht benutzerfreundlich nur weil sie JavaScript voraussetzt? Vielleicht ist es bekannt das selbst die Vorgaben des W3C inzwischen JavaScript umfassen. Wer sich vor Angriffen via JavaScript schützen will sollte entsprechend vorsorgen. Bei Firefox hilft dabei z. B. die Erweiterung NoScript hervorragend. --Sturmkind 08:34, 21. Jul. 2007 (CEST)

Ähm, sie benachteiligt Browser und Zugangssysteme, die kein JavaScript unterstützen. -- molily 22:28, 30. Sep. 2007 (CEST)

Deswegen findet man auch noch so oft Heu an Tankstellen um der großen Anzahl reitender Bürger gerecht zu werden. Mal ehrlich welcher Browser mit Verbreitung kann kein Javascript. --83.171.156.78

Hilfe

Wisst ihr, wo man das JavaScript downloaden kann? Denn im Google hab ich nichts gefunden.--Frogger14 11:37, 16. Aug. 2007 (CEST)

einen JS-interpreter? ein bestimmtes, in JS geschriebenes skript? -- ∂ 11:44, 16. Aug. 2007 (CEST)

Was ist NJS

...obwohl auch eigenständige Anwendungen mit anderen Interpretern wie NJS möglich sind.

Entweder muss es heißen ...obwohl auch eigenständige Anwendungen mit anderen Interpretern als NJS möglich sind.oder ...obwohl auch eigenständige Anwendungen mit anderen Interpretern, wie NJS, möglich sind. In beiden Fällen stellt sich die Frage, was NJS ist. Weder Kiki noch Google kenne dieses Kürzel. Man sollte das imho entweder erklären oder löschen.--91.7.115.42 20:13, 23. Okt. 2007 (CEST)

http://www.njs-javascript.org/ -- ∂ 21:03, 23. Okt. 2007 (CEST)

Wer entwickelt JS offiziell weiter? In den Artikel?

Tag, wer entwickelt JavaScript nun eigentlich offiziell weiter und definiert Standards? Ich kann leider keinerlei eindeutige Informationen entdecken. Nach der Praxis hat Mozilla die Entwicklung übernommen aber inwieweit ist das offiziell und inwieweit definiert Mozilla die Standards die dann alle anderen Browser ebenfalls umsetzen? --Rudi 16:33, 21. Dez. 2007 (CET)

Niemand. Mozilla entwickelt proprietäre Zusätze für den Kern und nennt die »JavaScript Versionsnummer« (bisher 1.6, 1.7, 1.8). Andere Browser haben diese Erweiterungen soweit ich weiß nocht nicht oder nur sehr punktuell übernommen. Eine Weiterentwicklung von ECMAScript, also dem eigentlic hmaßgeblichen Standard, findet in der Arbeitsgruppe TC39 von ECMA statt: http://www.ecmascript.org/ Dort wird aber eine ganz neue Sprache entwickelt. -- molily 16:55, 18. Mär. 2008 (CET)

Web-basierte Sprache?

Im Artikel wird Javascript als Web-basierte Sprache bezeichnet bzw. in der Diskussion unten wird sogar vorgeschlagen, sie explizit so zu definieren. Das ist aber nicht korrekt: Zwar wird Javascript hauptsächlich im Web eingesetzt, aber nicht ausschließlich: Z.B. die Adobe CS2-Suite (Photoshop, Indesign) ist scriptfähig, wobei ausser VBscript und Applescript auch Javascript als plattformübergreifende Sprache benutzt werden kann. Das hat nichts mehr mit dem Web zu tun. Das DOM sieht dort auch anders aus, z.B. gibt es kein window-Objekt, sondern statt dessen das Objekt "application" und noch viele andere, die in Javascript für's Web nicht existieren. Totzdem ist es reines Javascript, wird jedenfalls von Adobe so bezeichnet. Jedes andere DOM tut's also prinzipiell auch, daher ist Javascript grundsätzlich unabhängig vom Browser-DOM und somit vom Web, w.z.b.w. Eine auffällige Eigenschaft von Javascript ist z.B. die Tatsache, dass keine System-Aufrufe möglich sind, eine Einschränkung, die z.B. in der die CS2-Suite für VBscript oder AppleScript nicht gilt, wohl aber für JavaScript dort. Habe mal die Einleitung des Artikels entsprechend umgeschrieben. --Kjuu 13:58, 18. Apr. 2007 (CEST)

JavaScript ist der Name für das einst von Netscape gestartete Sprachenprojekt, das ganz klaren Bezug aufs Web hatte. In Nicht-Web-Anwendungen wird insofern - um mal begrifflich scharf zu sein - nicht JavaScript, sondern ganz einfach eine andere ECMAScript-Implementierung verwendet. Dass Adobe den Unterschied begrifflich einebnet, ist marketing-technisch erklärbar, aber technisch Unsinn. JavaScript ist gleich ECMAScript + DOM 0 (»Browser Object Model«) + W3C DOM + Web-spezifische proprietäre Browserfeatures. JavaScript verhält sich zu ECMAScript ungefähr so wie z.B. XHTML zu XML. XML ist der Rahmen, XHTML die konkrete Sprache.

Lange Rede, kurzer Sinn, es ist nicht sonderlich klug, alle ECMAScript-Implementationen als JavaScript zu bezeichnen, sondern eben nur die, die im Web/HTTP/HTML/Browser-Kontext lebt. Leider mischt der Artikel ECMAScript und JavaScript momentan völlig. Z.B. »[JavaScript]wird auch gerne als Skriptsprache für Spiele eingesetzt« - gemeint ist einfach irgendeine ECMAScript-Implementation (und davon gibts tatsächlich viele), nicht JavaScript im genannten Sinne! -- molily 21:31, 29. Jun. 2007 (CEST)

Eben. Es sollte einen Artikel ECMAScript geben, statt eines Redirects hierher. Dort kann dann auch auf die anderen Anwendungszwecke eingegangen werden. -- iGEL·대화·Bew 16:52, 31. Aug. 2007 (CEST)

Dafür. ECMAScript sollte Hauptartikel sein, und JavaScript wirklich nur das behandeln, was JavaScript von ECMAScript abhebt. Spätestens mit Erscheinen von ECMAScript5 (also jetzt) find ich's echt schlecht, keinen eigenen Artikel dazu zu haben. --Fusselwurm 22:32, 8. Dez. 2009 (CET)

Anwendungsbeispiel (JavaScript)

Anwendungsbeispiel: (Quadrat einer Zahl berechnen) funktioniert nur eingeschränkt, die Ausgabe "Bitte gib eine gültige Zahl ein!" erscheint nicht, stattdessen kommt "Das Quadrat von NaN ist NaN!" als Ausgabetext. Offenbar ist hier ein Fehler in "if (Zahl == NaN)", bitte korrigieren! Meine Kenntnisse erstrecken sich nicht auf JavaScript. Dank im Voraus! Timothy da Thy 14:16, 17. Jun. 2008 (CEST)

sollte jetzt funktionieren--Fritzbruno 08:26, 6. Jul. 2008 (CEST)

Ich habe das bisherige Anwendungsbeispiel durch eine typische Anwendung, die - allerdings stark vereinfachte - Validierung einer Formulareingabe, ersetzt. Inhaltlich sind sich die beiden Beispiele ähnlich (Verarbeitung einer Eingabe) aber der praktische Nutzen von JavaScript wird im neuen Beispiel deutlicher.--Fritzbruno 12:48, 7. Jun. 2009 (CEST)

Neues Fass aufmachen: Sprachklassifizierung allgemein und Diskussion der aktuellen Einleitung speziell

Hallo in die Runde,

seit Jahren bin ich nur stiller Beobachter des zähen Ringens um Formulierungen, die versuchen, der Sprache »JavaScript« gerecht zu werden.

Die aktuelle Einleitung jedoch muß offensichtlich in grober Unkenntnis des dem Sprachkern zugrundeliegenden Sprachkonzepts geschrieben worden sein. Jede Formulierung im Satz - Zitat: »Es ist eine dynamisch typisierte, objektbasierte Sprache, ähnlich den objektorientierten, jedoch ohne Polymorphie und Vererbung.« - ist falsch bis auf - Zitat: »... dynamisch typisierte ...«.

Deshalb melde ich mich hier zu Wort, um die Dikussion zur kompletten Umformulierung der Einleitung anzuregen, bevor ich durch eigenmächtiges Ändern meinerseits eine neue Kaskade an *Wiederherstellen / erneut ändern* lostrete und allgemeinen Mißmut und Unwillen heraufbeschwöre.

Die von mir vorgeschlagene und zu diskutierende Neufassung kommt folgendermaßen daher:

Der als ECMAScript (ECMA 262) standardisierte Sprachkern von JavaScript beschreibt eine moderne, schlanke, objektorientierte aber klassenlose Skriptsprache, die dennoch allen objektorientierten Programmierparadigmen unter anderem auch - aber eben nicht ausschließlich - auf der Basis von Prototypen gerecht wird. Obwohl im Grunde eine funktionale Skriptsprache, läßt sich in JavaScript sowohl prozedural als auch rein funktional bzw. objektorientiert programmieren. ECMA 262 kann damit ohne weiteres auch als Multiparadigmensprache bezeichnet werden.

In JavaScript representieren sich alle Daten bis auf die Typen [Undefined] und [Null] bzw. bis auf die primitiven Werte [boolean], [number] und [string] als Objekte. Funktionen sind ebenfalls Objekte, deren im Funktionsrumpf gebundenen Anweisungen über den call-Operator bzw. über call-Methoden ausgeführt werden.

Gekapselte Daten sind lokale Werte bzw. Objekte einer Funktion. Diese begrenzte *Sichtbarkeit* von Daten kann bei Datenstrukturen durch ineinander verschachtelte Funktionen (Funktion in Funktion) gezielt ausgenutzt und über Referenzierungskonzepte ebenso gezielt getunnelt werden.

Schon auf dieser Grundlage läßt sich fuer alle nativen JavaScript-Objekte das Signal-Slot-Konzept implementieren, sodaß ereignisorientiertes Programmieren, auch losgelöst von DOM-Events, allein mit den Mitteln des Sprachkerns möglich ist.

Vererbung wiederum erfolgt in JavaScript ausschließlich über Delegation; entweder direkt über eine der call-Methoden oder implizit über den Objekt-Prototypen eines jeden Objekt-Konstruktors. Letztgenannter leistet dabei die Abstraktion zur Vererbung (im Sinne von *ist ein* ), während die zuerst angesprochenen Methoden der Umsetzung des Aggregationskonzepts (*hat ein*) dienlich sind.

Weitere Formulierungen, die bei Bedarf ohne weiteres übernommen bzw. angepasst werden können, finden sich auf Benutzer_Diskussion:Pseliger

so long - peterS. - 13:18, 10. Jul. 2008 (CEST)

Nach drei Tagen Stille hab' ich jetzt mal vorsichtig Hand angelegt, und hoffe, daß jemand die Änderungen (unter Entwurf) mitbekommt, diskutiert und möglicherweise auch freigibt.

so long - peterS. - 14:22, 13. Jul. 2008 (CEST)

Konvention Konstruktor-Funktionen

Hallo,

eine Javascript-Konvention besagt, dass Namen von Konstruktor-Funktionen immer mit einem Großbuchstaben beginnen sollten. Diese Konvention wird in den Code-Beispielen leider nicht eingehalten. (Der vorstehende nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 141.12.206.239 (Diskussion • Beiträge) 10:16, 13. Nov. 2008 (CET))

Rollover-Effekte als Missbrauch?

Das ist ja wohl Blödsinn. Ich wüsste nicht warum das hervorheben des gerade aktiven Punktes eines Menüs durch farbliche Veränderung (Ersetzen der Menüpunktgrafik) einen Missbrauch und schlechten Stil darstellen sollte. Dann betreibt ein nicht gerade geringer Prozentsatz sowohl kommerzieller als auch gewerblicher Seiten Missbrauch von Javascript. Diese Behauptung ist schlichtweg unseriös und wohl von persönlichen Abneigungen des Beitragsautors beeinflusst.

Hier ist der beanstandete Abschnitt: http://de.wikipedia.org/wiki/JavaScript#Missbrauch

Letzter Punkt.

Schon weg, ich sehe da ebenso wenig Missbrauch. ···- ·-· ··· -·· ·· ··· -·- 19:02, 23. Feb. 2009 (CET)

PS: Es ist insofern 'Missbrauch', dass man den gleichen Effekt in den meisten Fällen auch ohne JS umsetzen kann (mit der CSS-Pseudoklasse :hover). li.yourclass:hover {background-image: url(hintergrund2.png);} ändert zum Beispiel die Hintergrundgrafik des überflogenen Elements (außer im Internet Explorer 6, da braucht man entweder Tricks oder muss sich wieder auf Javascript stützen). --···- ·-· ··· -·· ·· ··· -·- 11:08, 10. Mär. 2009 (CET)

Schreibweise

Mich wundert das verwendete Binnenmajuskel im Namen. Ich lese normalerweise immer Javascript, was wohl vor allem auch an hören Verbreitung liegt. Der Wortschatz stimmt da mit meiner Meinung auch überein. --87.78.32.142 18:57, 4. Mär. 2009 (CET)

JavaScript wurde von Netscape mit genau dieser Schreibweise veröffentlicht. Außerdem kann ich keine größere Verbreitung für Javascript erkennen. Sämtliche mir bekannten Bücher schreiben JavaScript und in Zeitschriften sieht es nicht anders aus. -- net 19:15, 4. Mär. 2009 (CET)

Das wir Namen in der Wikipedia an die Rechtschreibung anpassen sollte bekannt sein... wo wir wohl hinkämen wenn als Artikelnamen ECl@ss verwenden würden. Das Binnenmajuskel auch das Lesen von Texten stört sollte auch bekannt sein. Auf dieser Diskussionsseite hier wird auch oft die Schreibweise Javascript verwendet. --87.78.32.142 21:59, 4. Mär. 2009 (CET)

Ich zitiere mal aus WP:NK:

Ausnahmen von dieser Regel können in solchen Fällen gemacht werden, wo eine Anpassung nicht sinnvoll ist (z. B. c’t, iTunes), und wenn die unkonventionelle Schreibung eindeutig die üblichere Schreibung ist und diese den Lesefluss und Wortverbindungen nicht stört (z. B. LaTeX).

JavaScript ist die üblichere Schreibung und stört auch den Lesefluss nicht. -- net 00:16, 5. Mär. 2009 (CET)

Funktionlale Sprache?

"Obwohl im Grunde eine funktionale Skriptsprache"

Wo soll Javascript eine funktionale Sprache sein? Javascript ist doch ganz klar eine imperative/objektorientierte sprache. Kann das mal jemand klarstellen?

die Stichworte zum funktionalen Aspekt lauten »Lambda-Kalkül« und in diesem Zusammenhang dann »Rekursion« und »Currying« - weniger theoretisch dann auf alle Fälle »Closure«s.

und noch zwei Links zu ähnlich gelagerten Diskussionen im Forum von SELFHTML:

- klassenlose vollwertige und flexible oo auf funktionaler basis

- Grundkonzepte

so long - peterS. - 00:55, 02. Mai 2009 (CEST) (ohne Benutzername signierter Beitrag von Pseliger (Diskussion | Beiträge) )

was ein quark. brendan eich sagt dazu "I'm not proud, but I'm happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients." und "I still think of it as a quickie love-child of C and Self". man kann in JS halbwegs funktional programmieren, aber das war's dann auch: seiteneffekte sind nicht die ausnahme, sondern die regel. point-free zu programmieren ist unangenehm. objekte und prototypen spielen eine nicht ganz unwichtige rolle. -- ∂ 01:24, 2. Mai 2009 (CEST)

Statische Variablen und Objekt-Eigenschaften

Im Bereich "Öffentliche und private Methoden und Eigenschaften" wurde ein Beispiel für die Definition eines Prototypen gegeben. Innerhalb des Prototypen werden die privaten Variablen private_eigenschaft = "privat" und die private Methode private_methode... definiert und der Autor behauptet es handle sich hierbei um private Eigenschaften. Das hat mich etwas verwirrt, da meines es sich meines Wissens nach hier um statische Variablen/Methoden handelt, oder liege ich hier falsch? Mich würde interessieren ob es überhaupt möglich ist private Eigenschaften Objektspezifisch zu definieren!?

Nein, das interpretierst du falsch. In dem Beispiel wird in der prototype funktion gezeigt, dass du dort keinen Zugriff auf die privaten Variabeln hast. statische Variabel gibt es so in JS nicht. Und ja es ist möglich private attribute und Methoden zu definieren, so wie es in dem Beispiel getan wird. Struppi 11:49, 16. Mär. 2009 (CET)

Etwas Hintergrund:

function meinObjekt (parameter) {

    /* this konservieren */
    var self = this;

    /* "private Eigenschaft", lokale Variable der Konstruktorfunktion */
    var private_eigenschaft = "privat";

    /* öffentliche Eigenschaft des erzeugten Objekts */
    this.oeffentliche_eigenschaft = "öffentlich";

    /* "private Methode", ebenfalls lokale Variable der Konstruktorfunktion */
    var private_methode = function () {
        window.alert(private_eigenschaft + " " + self.oeffentliche_eigenschaft);
    };

    /* privilegierte öffentliche Methode des erzeugten Objekts */
    /* Hier wird mit dem Abschluss der Konstruktorfunktion eine Closure erzeugt, die
       ihren alten Kontext mit lokalen Variablen konserviert und so die "privaten
       Methoden" bzw. Eigenschaften noch kennt, während von außen nicht mehr darauf
       zugegriffen werden kann. Damit ist es möglich, ohne explizite Deklaration
       private Eigenschaften u. Methoden zu erzeugen.
     */
    this.privilegierte_methode = function () {
        window.alert(private_eigenschaft + " " + this.oeffentliche_eigenschaft);
        private_methode();
    };
}

// ruft die öffentliche Methode auf, die ihrerseits die Private aufruft
(new meinObjekt()).privilegierte_methode();

Siehe auch Closure. ···- ·-· ··· -·· ·· ··· -·- 15:53, 20. Mär. 2009 (CET)

Sichtbarkeit privater Eigenschaften

Im Beispiel des Abschnitts "Öffentliche und private Methoden und Eigenschaften" wird in einer nicht-privilegierten Methode der Zugriff auf eine private Eigenschaft mittels typeof(private_eigenschaft) versucht. Das dies nicht funktioniert, wird zwar im Text erklärt, aber das Codebeispiel irritiert, weil beim Lesen die Vermutung aufkommen könnte, man könne wenigsten den Typ der privaten Eigenschaft ermitteln. Deshalb habe ich mir mal erlaubt an die Codezeile den Kommentar 'gibt "undefined undefined" aus' anzuhängen, obwohl das später im Text noch erklärt wird. (nicht signierter Beitrag von 78.43.35.44 (Diskussion | Beiträge) 11:58, 15. Mai 2009 (CEST))

Wo bleibt die Kritik

an Javascript? Einen hauptsächlichen Nachteil kann ich sofort nennen: Es verzögert den Seitenaufbau und die Bedienbarkeit von Internetseiten auf nicht mehr ganz taufrischen Computern bis zur (Un-)Zumutung. Paradebeispiel ist ebay, dessen Seiten so quälend langsam geworden sind, daß man damit nicht mehr sinnvoll arbeiten kann. Der Taskmanager zeigt ein manchmal fast schon minutenlanges Gerödel von 50 bis teilweise über 90 % (!) Prozessorauslastung nur des Threads des Internet-Explorers an, der mit ebay beschäftigt ist. Ich frage mich, was zum Teufel dort im Hintergrund alles zu "erledigen" ist (vermutlich beschäftigt sich die Seite überwiegend mit sich selbst). Anzeigen, die Hauptfunktion jedes Webbrowsers, erfordern allein nie und nimmer einen solchen Rechenaufwand. (nicht signierter Beitrag von 89.244.66.7 (Diskussion | Beiträge) 12:42, 22. Jun. 2009 (CEST))

Das hat mit der Skriptsprache wenig zu tun, das liegt daran dass die Webseite von eBay schlichtweg grausam geschrieben ist und der Internet Explorer eine vollkommen unzureichende JavaScript- bzw. JScript-Engine besitzt. Alle alternativen Browser (Mozilla Firefox, Safari, Google Chrome und Opera) sind hier schlichtweg um das mehrfache performanter, Microsoft hinkt auch weiterhin massiv in Sachen Performance, Standardkompatibilität und Innovationen hinterher. --Vanger ^!–!? 13:26, 22. Jun. 2009 (CEST)

Kritik steht im Abschnitt JavaScript#Missbrauch. Deine spezielle Kritik an den Programmierkünsten der EBAY-Verantwortlichen lässt sich hingegen nicht verallgemeinern.--Fritzbruno 19:00, 22. Jun. 2009 (CEST)

Ja, stimmt, mit Opera läßt sich ebay besser bedienen, scheint also auch am Browser zu liegen. Außerdem ist amazon auch eine in dieser Hinsicht "schlimme" Internetseite, denn die ist, wenn man in ihr mit dem Internet-Explorer surft, ähnlich träge wie ebay.... -- 89.244.65.85 21:17, 16. Jul. 2009 (CEST)

weder ebay noch amazon sind hier Thema - bitte listet hier nicht noch mehr Erfahrungen mit irgendwelchen Seiten auf--Fritzbruno 06:59, 17. Jul. 2009 (CEST)

weiterführender Weblink?

Kann mir jemand das Weiterführende an dem ebusiness-akademie.de-Link zeigen? ich finds nicht. --217.84.18.237 13:31, 2. Jul. 2009 (CEST)

Befehlsübersicht

Schön fände ich auch eine Befehlsübersicht - der Befehle, die in den wichtigsten Browsern unterstützt werden. Wie z. B. hier: http://www.office-loesung.de/ftopic336244_0_0_asc.php Das wäre doch schon einmal ein Anfang.

Gruß Hans-Jürgen -- 88.68.212.25 15:07, 21. Sep. 2009 (CEST)

so etwas gehört eher in ein Tutorial, nicht in Wikipedia.--Fritzbruno 20:20, 21. Sep. 2009 (CEST)

dynamische vs. schwache Typisierung

Im Artikel steht "JavaScript ist dynamisch typisiert, d. h. der Datentyp einer Variablen kann sich während der Ausführung eines Scripts ändern". Werden hier nicht die Begriffe dynamische Typisierung und schwache Typisierung verwechselt? Dynamische Typisierung bezeichnet doch, dass der Typ einer Variablen zur Laufzeit und nicht zur Übersetzung bestimmt wird. Die Möglichkeit, dass eine Variable verschiedene Typen während des Programmablaufs annehmen kann, wird mit schwacher Typisierung bezeichnet. Was ist denn hier gemeint? -- Freischlad 10:40, 8. Okt. 2009 (CEST)

CommonJS

Warum wurde der Link zu CommonJS entfernt? Dabei handelt es sich doch um eine Spezifikation einer Standardbibliothek. Nicht um eine Standardbibliothek, sondern nur eine Spezifikation (gibt diverse Implementierungen). --Wikieditoroftoday (disk.) 21:46, 24. Okt. 2009 (CEST)

Ich wollte mich im Spec-Abschnitt auf JS beschränken, daher hab ichs (wie auch E4X) rausgenommen. Ist das Projekt offiziell? Es sieht so oder so artikelrelevant aus, erst recht wenn einzelne Frameworks auch Artikel haben. Sobald es hier einen Artikel hat, kann man es auch im Fließtext verlinken. --Seine Idempotenz 22:04, 24. Okt. 2009 (CEST)

Da es zur Zeit nur eine Version 0.1 gibt, weiß ich nicht, ob es sich lohnt einen Artikel dafür anzulegen. Hier wird zu schnell gelöscht. Aber man könnte es bereits so in dem Artikel einbauen. --Wikieditoroftoday (disk.) 22:25, 24. Okt. 2009 (CEST)

So hatte ich mir das gedacht. Gute Nacht :-) --Seine Idempotenz 01:41, 25. Okt. 2009 (CEST)

JS 1.8

Könntet ihr die Codebeispiele euklid und ggTbitte wieder auf gängige ECMAScript-3-Syntax umstellen. Die proprietäre JS-1.8-Kurzschreibweise zu erwähnen mag am Rande Sinn machen, aber ein Beispiel für eine JS-Funktion sollte nicht nur im Spidermonkey funktionieren. Bitte in den Beispielen an etablierte JS-Syntax halten. Irgendwann war die Funktion ggT auch mal menschenlesbar. Durch die ganzen Programmierkniffe hat sie jegliche Anschaulichkeit verloren -- 88.130.125.170 14:00, 11. Nov. 2009 (CET)

In 1.5-er Syntax mit Boilerplate:

function euklid (a, b) {
	return b ? euklid(b, a%b) : a
}

function ggT () {
	return (function (args) {
		return !args[1]
			? (function () {
				return args[0] || 0
			})
			: (function () {
				return euklid(
					args[0],
					ggT.apply(null, args.slice(1))() )
			})
	})(Array.prototype.slice.apply(arguments))
}

Besser? --Seine Idempotenz 14:45, 11. Nov. 2009 (CET)

PS: Funktionales JS schreibt sich mit 1.8 nunmal schöner, die 1.5er-Syntax hat dort einfach zu viel Ballast. Und wer die Funktion, egal in welcher Syntax, versteht, hat damit einen großen Teil von JS verstanden. Auch kleine Funktionen (Tip: lesenswerter Link) können es in sich haben, und kompakte Beispiele ziehe ich in einem Wikipediaartikel vor. (Okay, bei Perl wäre das was anderes, aber JS ist nicht Perl.) --Seine Idempotenz 15:01, 11. Nov. 2009 (CET)

JScript forward

Könnte man für JScript eine eigene Seite machen? Mich interessiert nun halt die alte MS-Version und nicht Sun...

Gibt es doch? Siehe JScript. --Seine Idempotenz 21:14, 4. Feb. 2010 (CET)

Datentypen

http://de.wikipedia.org/w/index.php?title=JavaScript&diff=next&oldid=67085253

Diese Änderung halte ich nicht für gelungen. Dabei sind essentielle Informationen herausgefallen, die zum Verständnis von JS wichtig sind. Man sollte grundsätzlich zwei Sachen unterscheiden:

• Die tatsächlichen internen ECMAScript-Typen,
• die Rückgabe des typeof-Operators.

Der typeof-Operator ist ein »Bad Part« von ECMAScript, damit kann man nicht erklären, wie ECMAScript tatsächlich funktioniert. Ich bin der Meinung, die Beschreibung der Typen einer Programmiersprache sollte nicht bloß an der (im Falle von ECMAScript irreführenden) Oberfläche kratzen. Wenn hier von Datentypen die Rede ist, sollte das konsistent zum Begriff »Type« im ECMAScript-Standard erfolgen.

Wirklich grundlegend ist die Unterscheidung zwischen Primitive Values und Objects. Nur wenn man den verstanden hat, sind auch die Datentypen JavaScripts verständlich und typeof sinnvoll nutzbar.

Alle anderen Werte - reguläre Ausdrücke, Arrays und der Wert null inbegriffen - sind vom Typ object.

Null ist vom Typ null. Es ist kein Object (im Sinne von Primitive vs. Object), auch wenn typeof null dummerweise "object" zurückgibt. Das neue Beispiel mit new String() macht ein Fass auf, das gerade dieser Edit geschlossen hat, indem er Primitives vs. Objects nicht mehr erklärt. Das Beispiel ist eher verwirrend, denn für new String udgl. gibt es keinen praktischen Anwendungsfall.

Da müsst ihr euch einfach mal entscheiden, was unter »Datentypen« laufen soll: Entweder die Beschreibung der ECMAScript-Datentypen oder die Beschreibung des typeof-Operators, der einem über erste keine zuverlässige Auskunft gibt. -- molily 01:11, 18. Jan. 2010 (CET)

Meine Absicht war in dem edit, von Otto Normalentwickler und seinen Bedürfnissen auszugehen: und der benutzt halt typeof. Daß null intern irgendwo ein eigener Typ ist, ist ihm ziemlich egal - weil die Sprache es ihm durch nichts verrät... Daß new String() nicht sinnvoll ist, ist klar - aber man findet es noch oft genug in freier Wildbahn. Das Beispiel war dazu gedacht zu zeigen, warum es halt in der Wirkung nicht das selbe ist wie ein Stringliteral. Aber du hast recht, wahrscheinlich wäre ein extra Unterabschnitt zu "typeof" besser gewesen. Eigentlich war's schön, wie die Typen vorher kurz und bündig erwähnt wurden. -- Fusselwurm 11:34, 6. Feb. 2010 (CET)

Was wichtig ist

Ich finde die Frage, ob Java von bestimmten Puristen als objektorientierte Programmiersprache angesehen wird völlig irrelevant. JavaScript enthält zumindest einige Features objektorientierter Programmiersprachen.

Wichtig ist: JavaScript ist die Skriptsprache für Skripte, die in HTML eingebunden werden und vom Browser ausgeführt werden. Die Sprache ist standardisiert und der Standard ECMA-262 wird heute von praktisch allen gängigen Browsern unterstützt. Daher ist JavaScript die Programmiersprache zur Ausführungen von Berechnungen, wie Überprüfungen von Formulareingaben, die auf dem Rechner des Anwenders (Client) ausgeführt werden sollen.

Ich kann eigentlich nicht erkennen, dass der Artikel dringend überarbeitet werden muss. Benutzer:Fsswsb 30.05.06

Besteht vielleicht die Möglichkeit eine Tabelle in die Seite zu ein zu pflegen, aus der ersichtlich ist, welche der gängigsten Browser welche ECMA Version mindestens unterstützen? Danach hab ich nämlich gerade gesucht und leider nicht so wirklich was gefunden. --Daimonion1980 14:59, 15. Mär. 2010 (CET).

Eine solche Tabelle wäre nicht sonderlich aussagekräftig, denn die in den Browsern enthaltenen JS-Engines unterstützen alle weitesgehend ECMAScript 3. Der Standard ist von 1998. Manche Browser unterstützen bereits einzelne Neuerungen aus ECMAScript 5, welcher letztes Jahr erschienen ist.

Microsoft hat kürzlich ein Dokument veröffentlicht, welches die Abweichung ihrer JScript-Implementierung von ES3 detailliert beschreibt. Im Prinzip unterstützen aber alle Browser die Grundzüge von ES3. -- molily 02:55, 8. Apr. 2010 (CEST)

Exzellenter Artikel

Die Autoren haben wirklich sehr gute Arbeit beim Verfassen des Artikels geleistet. Weiter so. ;)

84.184.189.92 01:57, 4. Mai 2010 (CEST)

Quellcode verschleiern

Was ist so schlimm daran seinen Quellcode vor den Benutzern zu verbergen? Deinen Backend Code gibst Du ja auch nicht her? Finde der Punkt sollte raus. (nicht signierter Beitrag von 84.184.179.139 (Diskussion | Beiträge) 19:36, 5. Mai 2010 (CEST))

Alle Techniken, die auf JavaScript bauen, funktionieren ohne selbiges nicht, in diesem Fall wäre eine per JS verschleierte Seite einfach unbrauchbar. Insofern ist dieser Punkt hier berechtigt! HTML/CSS ist mit Programmcode nicht zu vergleichen.--Fritzbruno 16:02, 6. Mai 2010 (CEST)

JavaScript aktiv ?

Wie stelle ich fest, ob bei mir JavaScript aktiv ist ? Anlaß für meine Frage ist dies hier. Die Hilfseite hat mir nicht weitergeholfen. --michelvoss 14:57, 24. Mai 2010 (CEST)

tippe folgendes in die Adresszeile des Browsers: javascript:alert("aktiv"). Drücke die Enter-Taste.

wenn dann ein Fenster mit dem Text "aktiv" erscheint ist JavaScript aktiviert.--Fritzbruno 15:45, 24. Mai 2010 (CEST)

Danke!

Hab' garnicht geahnt, daß die Lösung so einfach ist. Deshalb gleich auf Hilfeseiten als ALLERERSTE Antwort unter J verewigt und zusätzlich getwittert, damit Wikipedia noch ein paar hundert Nutzer mehr bekommt.--Michel Voss 16:37, 24. Mai 2010

Anfängerversion

24. Mai 2010

Eine Meisterleistung wäre es wenn es Autoren schaffen würden, eine kurze Anfängerversion dieses Artikels zu erstellen.

"JavaScript ist eine Skriptsprache, die hauptsächlich für das DOM-Scripting in Web-Browsern eingesetzt wird" zwingt Menschen, die diese Fachsprache nicht "beherrschen", sich immer weiter durchzuklicken, um den Inhalt zu verstehen. --Michel Voss 16:01, 24. Mai 2010 (CEST)

Unterstützte JavaScript Version von Chrome

Hallo, mir ist nur eine kleine Sache aufgefallen und zwar wird in der Liste der Browser mit JavaScript unterstützung angegeben, dass Google Chrome JavaScript 1.7 ab Version 1.0 unterstützt. Das stimmt leider so nicht ganz. Es werden leider nur ein paar Sprachfeatures von 1.7 unterstützt allerdings nahezu alle von 1.5

Beispiel: In 1.7 ist spezifiziert, dass Arrays eine indexOf Methode haben, diese unterstützt Chrome allerdings nicht. (Es gäbe noch weitere Beispiele, will aber niemanden langweilen :-) )

-- Boinji 09:37, 28. Jul. 2010 (CEST)

Codebeispiel mit Katze

Wer hat sich bitte dieses gemeine Code-Beispiel einfallen lassen in dem eine Katze getötet wird? Wäre toll wenn sich jemand kreativer mal ein besseres ausdenken könnte :/

-- blah (nicht signierter Beitrag von 86.33.222.40 (Diskussion) 20:46, 30. Jul 2010 (CEST))

Kopiervorlage Internetquelle

Kopiervorlage Internetquelle scheint hier unbekannt, deshalb weigere ich mich diese Version als gesichtet zu kennzeichnen. (Unterschied | Versionen) . . K! JavaScript‎ [sichten]; 21:29 . . (+18) . . Michelvoss (Diskussion | Beiträge) (→Entwicklung)--michelvoss 23:44, 15. Aug. 2010 (CEST)

Duck Typing

Meiner Meinung nach ist Duck Typing keine Spracheigenschaft, sondern eine Programmiertechnik, und sollte daher aus dem Infokasten entfernt werden -- 95.113.18.98 23:50, 30. Aug. 2010 (CEST)

Damit liegst du aber daneben. Folge den Link zur Duck Typing und lies es mal sorgsam durch. Verwirrt war ich nur über das dort Gelesene. Eigentlich wird darunter nämlich verstanden, dass zur Laufzeit einer Variable unterschiedliche Typen/Objekte zugeordnet werden können. Der Interpreter prüft dann zur Laufzeit ob diese Operation im aktuellen Kontext möglich ist und führt diese aus.--178.24.70.200 09:21, 15. Sep. 2010 (CEST)--178.24.70.200 09:22, 15. Sep. 2010 (CEST)

Einleitung

"Der als ECMAScript (ECMA 262) standardisierte Sprachkern von JavaScript beschreibt eine moderne, schlanke, dynamisch typisierte, objektorientierte, aber klassenlose Skriptsprache, die dennoch allen objektorientierten Programmierparadigmen unter anderem auch – aber eben nicht ausschließlich – auf der Basis von Prototypen gerecht wird."

Dazu gleich mehrere Fragen:

• Was soll mit "Sprachkern" gemeint sein? Das habe ich noch nie gehört.
• Wieso "modern"? "schlank"?
• "dennoch"? So wie der Satz dasteht, bedeutet das: "Obwohl der [...] Sprachkern von Javascript eine [...] Skripsprache beschreibt, wird diese allen OOP Programmierparadigmen [...] gerecht." Das kann ja wohl nicht gemeint sein, oder?

Ja, hier muss man etwas kleinlich sein, weil der erste Absatz der wichtigste ist, und inhaltlich frei von derlei Obskuritäten sein sollte -- 95.113.18.98 00:22, 31. Aug. 2010 (CEST)

der letzte Teil ist sogar wiedersprüchlich. Wirkliches OOP kennt selbst auch keine Klassen, sondern wenn dann nur Klassenobjekte, die nichts anderes als Objekte sind (Objekte einer "Klasse" werden erzeugt, in dem man dem Klassenobjekte sagt, ich möchte ein Objekt deiner "Klasse" haben. Es gibt demnach keinen new Operator). Weiter sollte man auch im Artikel schreiben, dass der new Operator in JS nicht die Funktion eines klassischen new erfüllt, sondern eher eine Copy-Methode auf das Prototype eines Objektes ist. Modern ist JavaScript, weil es eine protypen orientierte Sprache ist. Schlank, weil JavaScript wirklich sehr schlank aufgebaut ist, nahezu typlos, wenige Operatoren, etc... Ich würde shcon fast so weit gehen und JavaScript nicht als objektorientiert, sondern als prototypenbasiert zu kennzeichnen. Folgende Teile von Paradigmen fehlen:

* (Polymorphie) Überladung von Operatoren und Methoden (bedingt, WebKit unterstützt dies, Mozilla nicht)

* (Datenkapselung) Vererbung privater Variablen/Methoden nur über Umwege möglich

--Karolherbst 16:03, 29. Okt. 2010 (CEST)

AOP in JavaScript

AOP ist an sich kein offizielles Paradigma in JavaScript, jedoch lässt sich in JavaScript sehr einfach jedoch auch eingeschränkt aspektorientiert programmieren.

var oldAlert = window.alert;

window.alert = function newAlert(str){
	document.write(str);
}

Hier wird die ganz gewöhnliche alert methode am window objekt überschrieben. Wenn man weiter ins AOP geht, dann macht man folgendes:

Function.prototype.oldCall = Function.prototype.call;
Function.prototype.call = function newCall(){
	alert('Methode ' + this.name + ' wird ausgeführt');
	this.oldCall();
}

Hier wird sogar was bei jedem Funktionsaufruf etwas eingeschläußt. Da man hier direkt im Functionobjekt ist, weiß man welches Objekt eine Methode aufruft und an welchem Objekt dies geschah. Hiermit können die in AOP üblichen Patterns für Methodenaufrufe umgangen werden und das gleiche Ergebnis erzielt werden. Ich weiß, dass dies eher selten pder fast gar nicht getan wird. Jedoch ist das ein sehr schönes Beispiel, was mit Prototypenbasierte Programmierung alles möglich ist. Für mich ist der Artikel etwas zu viel nach einem falschen OOP Ideal geschrieben und zeigt nicht wirklich, was an JS so mächtig ist. Selbst im Artikel über Prototypenbasierte Programmierung steht kein Wort über das überschreiben von bestehenden Methoden. --Karolherbst 15:40, 8. Nov. 2010 (CET)

eigenschaft der sprache

ich finde diese beschreibung wie 99% aller beschreibungen von js an der sprache vorbei geht. javascript ist nicht in den rahmen der normal prozeduralen oder oop einzuordnen. kasnn zwar dahin verbogen werden, sie ist allerdings vielmehr verwand mit ki sprachen wie lisp. siehe eure eigene referenz: http://de.wikipedia.org/wiki/Scheme javascripts herausragende eigenschaft, characteristikum ist das /lernfähige/ objekt("the mutable object"). lernfähig im sinne der ki.

wir haben ein objekt das nichts kann

A={}

und ein Object das eine fähigkeit und eine eigenschaft hat.

B={
 'eigenschaft':1,
 'faehigkeit':function(){alert('ich kann was');}
}

nun kann A die fähigkeit von B /lernen/:

A['faehikeitvonb'] = B['faehigkeit'];

damit macht prototyping auch sinn! js ist eine ki sprache von grund auf und kann zwar anderes imitieren. das zu tun und zu vergessen was js wirklich ist, führt aber zu den üblichen problemen. ausgezeichnetes beispiel für eine komplette missachtung der charakteristik der sprache ist der satz:

JavaScript ist dynamisch typisiert, d. h. der Datentyp einer Variablen kann sich während der Ausführung eines Scripts ändern, was manchmal zu Fehlern bzw. unerwünschten Effekten führt.

der wert einer "variable" kann sich nicht nur ändern: es ist eines der herausragenden merkmale der sprache. zu fehlern führt von etwas anderem aus zu gehen.

delete( Objekt.eigenschaft);

eine abfrage der eigenschaft führt zu dem exakt natürlich richtigen ergebnis: "weiss nicht was das ist"('undefined'). "das objekt hat vergessen". damit reagiert js sehr ähnlich zu einem realen objekt. es liegt natürlich in der verantwortung das sinnvoll einzusetzen. deswegen braucht eine sprache wie js auch diesen zusätzlichen wert 'undefined' - weil ein objekt eben über eigenschaften verfügen kann oder nicht und sich das per "lernen und vergessen verändert. im browser ist es gut, dass js diese eigenschaft hat. dadurch lässt sich ein browser an bedürfnisse anpassen, eigenschaften und funktionen nach bedarf hinzugefügt und entfernt werden.

ich habe mir gerade den englischen artikel angesehen: wäre vielleicht das beste diesen artikel durch eine übersetzung des englischen zu ersetzen. ist weniger irreführend und falsch als dieser deutsche. vielleicht macht es sinn den artikel auf das wesentliche zu reduzieren(damit auch fehler zu umgehen). wer javascript lernen will wird das nicht über wikipedia tun.

private (nicht signierter Beitrag von 84.57.52.143 (Diskussion) 01:19, 5. Jan. 2011 (CET))

Den Artikel zu zerstören, um ihn durch eine sklavische Übersetzung aus dem Englischen zu ersetzen, ist so ziemlich der armseligste Vorschlag, den ich seit Langem gelesen habe. Leistung statt Abschreiben! Vielfalt statt Nachäfferei! Also: Nein, es wäre nicht besser, den Artikel durch eine Übersetzung des englischen Wikipedia-Artikel zu ersetzen. Außerdem wäre es wahrscheinlich nur schlechtes Deutsch. --Parzi 01:22, 6. Jan. 2011 (CET)

deutsch kan ich nicht glänzen... leider. es ging mir nicht um sprache sondern inhalt und richtigkeit. vielfalt ist da nicht unbedingt zielführend. hier gibt es so etwas wie richtig(er) und falsch(er). inhaltlich ist das englische richtiger und das deutsche falscher(böse könnte auch geagt werden themaverfehlung).

ich muss ausholen um zu erklären: javascript ist als richtige sprache mit einem konzept entworfen. das wurde kaum verstanden. dokumentation zur sprache wurde fast ausschließlich von leuten geschrieben, die sie nicht verstanden haben. mindestens 10 jahre gab es kein einziges js buch, dass die sprache wenigstens vom ansatz richtig beschrieben hat. mittlerweile hat sich das geändert, die sprache wird mehr und mehr verstanden. andere sprachen übernehmen mehr schlecht als recht konzepte aus js(reflection frameworks). die falschen bücher sind leider geblieben und nur wenig brauchbares kommt langsam(am besten sind beschreibungen diverser toolkits). den wohl bekanntesten, öffentlich hörbaren, rundumschlag machte crockford von yahoo und schafte es der welt etwas verständlich zu machen. allerdings machte er auch einen großen fehler(sieht er mitlerrweile auch so - siehe bemerkung auf seiner seite). der fehler: er versuchte die sprache in konzepte zu pressen, die für sprachen mit klassen(starre, undynamische objekte, instanzen nach "blaupausen" erstellt, frühes linken. im völligen gegensatz zu js.) entwickelt worden sind. er hat erst der sprache klassen aufgepfropft und dann klassisches oop für sprachen mit klassen genutzt(aber zumindest richtig). folge ist, das framworks seine auffassung nachahmen. soweit, dass crockfords ansätze nun wiederum in js aufgenommen werden und js klassen bekommt. auch die create methode die kommen wird ist aufnahme einer crockfort idee. völlig ohne bewertung ob das gut oder schlecht ist(ist einfach so), ist es bezeichnend, dass js verändert wird um programierern gerecht zu werden, die sie verwenden, wie sie eigentlich nicht funktioniert(e). wie gesagt nicht unbedingt schlecht, dadurch hat js eine sehr lebendige weiterentwicklung. paradigmen sind schön, nur wo js sitzt ist ein loch in den paradigmen in europa. in den usa ist es wenig anders da dort informatik studenten traditionell oft mit lisp anfangen zu programmieren. das multiparadigmisch, wie im artikel dargestellt kommt zwar, weil in die sprache paradigmen, die angewendet werden(wenn es nicht originär geht, verbiegt man die sprache eben dahin: das geht mit js, was eben ein wichtig charakteristikum der sprache ist) in sie aufgenommen werden, sie folgt originär einem speziellen konzept, dass von scheme oder self kommend zu etwas fassbar neuen entwickelt wurde. wie gesagt, das wohin js konzipiert wurde finden ganz langsam eingang in andere sprachen(stichwort reflection). sofern war js mit seinem ansatz zumindest in teilen seiner zeit wohl zu sehr vorraus(ob zum guten oder schlechten) um verstanden zu werden. nach so viel missverständnis ist es bei dieser sprache m.e. besonders wichtig von ihr auszugehen und nicht von etwas andern um die verwirrung nicht noch größer werden zu lassen.

weiter ist es mir eigentlich egal, was in wikipedia steht. allerdings stosse ich auf leute, die mit wikipedia argumentieren und darauf verweisen statt auf verlässliche quellen. in sofern sehe ich eine verantwortung bei wikipedia dinge inhaltlich richtig darzustellen. viele worte: ja, ein versuch verständnis zu finden. ich will es nicht ganz weg lassen "vielfalt" zu hören oder "sklavisch", bei der darstellung eines sachverhaltes, der real existent ist, lässt mich den kopf schütteln(ist wie "bloss nicht sklavisch eine realität akzeptieren, wir bauen uns unsere eigenen realitäten, phantasievoll vielfältig"). (nicht signierter Beitrag von 88.65.142.43 (Diskussion) 12:38, 8. Jan. 2011 (CET))

Du hast geschrieben: ich will es nicht ganz weg lassen "vielfalt" zu hören oder "sklavisch", bei der darstellung eines sachverhaltes, der real existent ist, lässt mich den kopf schütteln [...].
Ich habe den Eindruck, dass bei viele Wikipedia-Zuträger dazu neigen, das englischsprachige Wiki zu überschätzen und es unreflektiert als Referenz nutzen. Das erinnert mich daran, dass ich kürzlich einer Kurzpräsentation beiwohnte, in der jemand den Entwurf eines Grundlagenpapiers für eine Institution vorstellte. Er erklärte, dass man sich weitgehend allgemeinverständlich ausdrücken wollte, damit es auch jeder verstehe und schloss seine Präsentation damit ab, dass er das "Mission Statement" aus dem Entwurf vorlas und an der Wand zeigte. In diesem bemüht allgemeinverständlichen Dokument stand also wirklich "Mission Statement", was offensichtlich schon im Englischen ein farbloser, quasi verwaltungssprachlicher Ausdruck ist, etwa mit "Aufgabenfeststellung" zu übersetzen. Das Beispiel soll sagen: Es ist oft wenig hilfreich Inhalte – oft bloß, weil es bequem erscheint – aus englischen Dokumenten unreflektiert zu übernehmen. Besser scheint es mir selber nachzudenken. Ich sehe aber, dass immerhin Du vor allem inhaltliche Gründe anführst, insofern gestehe ich ein, Dich vielleicht unterschätzt oder falsch eingeordnet bzw. mich etwas zu heftig ausgedrückt zu haben. -- Parzi 20:52, 8. Jan. 2011 (CET)

BTW: Nach aktuellen deutschsprachigen JavaScript-Büchern habe ich mich kürzlich auch wieder einmal umgesehen. Auf Deutsch gibt es tatsächlich seit Langem nur einige – teilweise erweiterte – Neuauflagen von Büchern der hierzulande erfolgreichsten JavaScript-Autoren (Steyer, Koch, Wenz, Seeborger-Weichselbaum u. dgl.). Anscheinend nichts wirklich Neues oder Tolles. Aber immerhin soll im März die deutsche Übersetzung eines Buches von Microsoft-Press kommen. Vermutlich werde ich es mir kaufen. Kennst Du diesen Microsoft-Titel aus dem Englischen? -- Parzi 17:53, 8. Jan. 2011 (CET)

tip: /be. brendons seite. http://brendaneich.com/ die quelle. keine abgehobene oder langatmige whitpaper ohne ihnhalt sondern sehr konkret und lebendig. dort auch auch http://blip.tv/file/3837048. sehr schön, .. [ btw er fast darin am anfang die sprache zusammen: 1rst class functions, closures, prototypes, objects, arrays. davon finden lediglich closures erwähnung in diesem artikel... ]

b) http://www.ecmascript.org vor allem auch die mailing listen(kathegorie community).

c) doug crockford. kritisch betrachten! brendon wird manchmal recht deutlich gegen ihn. aber immerhin hat er es geschaft, dass die leute ihm glauben und ein paar seiner(nach /be fixen?) ideen in js eingeflossen sind. http://www.crockford.com/

(nicht signierter Beitrag von 88.65.142.43 (Diskussion) 21:08, 8. Jan. 2011 (CET))

noch ein letztes, typisches object erstellen in js:

        var Lampeprototyp={
            'an':false,
            'anschalten':function(){ this.an = true; }
        };
        var lampenbaubeschreibung = function(){
           this.ausschalten=function(){this.an = false; }
        };
        lampenbaubeschreibung.prototype = Lampeprototyp;
        Lampe = new lampenbaubeschreibung();
        Lampe.ausschalten();
        Lampe.anschalten();

es moduliert damit(ob das gut oder schlecht ist:?) im gegensatz zum klassenansatz die realität nach. wenn ich mir in der realität eine Lampe bauen lassen will kann ich einem handwerker entweder eine beschreibung geben oder einen prototypen, nach dem die Lampe gebaut werden soll oder beides. genau so funktioniert js. genau das mache ich oben: ich habe einen Lampenprototypen und zusätzlich zu dem will ich noch ausschalten können. also fertige ich eine beschreibung an, in der steht, dass ausschalten möglich sein soll. zusätzlich hänge ich den lampenprototyp an die beschreibung. dann gebe ich die beschreibung an einen handwerker: new. zurück bekomme ich eine Lampe, wie ich sie wollte und kann sie auch so nutzen. der klassenansatz macht komplett anderes. der klassenansatz erklärt wie objekte aussehen auf einer metaebene und nicht im "leben"(reflection springt in die lücke). jetzt habt ihr genug anregungen und ich lasse euch mindestens ein halbes jahr in ruhe überlegen was ihr machen wollt oder nicht. viel spass. (nicht signierter Beitrag von 88.65.142.43 (Diskussion) 18:46, 9. Jan. 2011 (CET))

"private" Eigenschaften

folgendes geht auch. Finde ich für das Verständnis besser, da man keine Notationsweisen vermischt und sich nur auf eine Sache konzentrieren muss (function() oder this.func = function() ).

function Katze() {
	var lebensZahl = 7;
	function maunz() {
		return (lebensZahl > 0) ? "miau" : "örks";
	};

	this.toeten = function () {
		lebensZahl -= 1;
		alert(maunz());
	}
};
var otto = new Katze();
otto.toeten(); // miau

--Karolherbst 14:42, 2. Nov. 2010 (CET)

siehe auch:

http://wiki.ecmascript.org/doku.php?id=strawman:private_names

auch die frage, welchen zweck "private" erfüllen soll. abstraktion, wie bibliotheken, die für interne veränderungen offen bleiben wollen und ein interface garantieren. an dem zweck festgehalten gibt es vielfältige möglichkeiten das zu erreichen. (nicht signierter Beitrag von 84.57.0.184 (Diskussion) 19:04, 5. Jan. 2011 (CET))

nebenbemerkung didaktisch ist es vielleicht noch besser generell die schreibeweise zu nutzen:

 
 var handle = function()...
 this.handle = function()... 
 objekt.handle = function()
 ...

me wird dadurch gerade in so einem beispiel klarer, was gemacht wird. es nimmt der funktion den touch besonders zu sein. var handle = "hallo"; und var handle = function(); macht m.e. die analogie greifbarer(javascriptiger: latebinding!).

noch eine idee didaktischer natur: statt Katze, ein kleingeschriebenes verb. es ist eine funktion. selbst mit new bleibt es lediglich ein konstruktor für eine katze, ist selber aber keine(und klassen gibt es in js sowieso nicht und darin besteht die verwechslungsgefahr). var katze_bauen=function() gäbe mit new katze_bauen() sinn. die funktion Katze ist keine katze sondern erstellt eine. sind arbeitschritte, die zum erstellen nötig sind. es ist eine factory für katze, wenn du so willst. vorallem aber keine katze. endlich bleibt der ausführungskontext erhalten aber die funktion Katze() ist weder der ausführungskontext noch ist es eine katze. auch das objekt "Katze()" ist keine katze. da herrscht viel verwirrung, daher der vorschlag. das ist wirklich "lediglich" eine funktion, die was "tut". im zusammenhang mit new bekommt sie das noch unfertige objekt und darf daran herum basteln.(typische verwirrung[falsch!] z.b.: "katze=new Katze(); katze.prototype=unsin" oder ähnlicher unsin...)

illustriert(geht leider so nicht mit allen browsern, __proto__ ist nicht überall zugänglich - ist aber damit plastischer.):

 
Tier={ 
     pfote:4,
     auge:{
        linkes_auge:1
     }
}

Hund={
 __proto__:Tier
}
Katze={
 __proto__:Tier
}

mit konstruktor und new passiert das gleiche, so sieht man nur mehr. wenn ich nun Hund.pfote abfrage bekomme ich die variable von tier. wenn ich Hund.pfote=3 setze, dann wird eine /zusätzliche/ variable in Hund /erzeugt/ die pfote von Tier überdeckt. in folge wird danach eben der wert dieser neuen variable zurück gegeben. beim erstellen von Hund wird die variable aber noch nicht neu erzeugt, sondern einfach die originale von Tier genommen(sprache mit klassen erzeugen die membervariable mit neu bei der konstruktion, js nicht). mit Hund.auge.linkes_auge=5 passiert genau das zu erwartende, nämlich Katze.auge.linkes_auge ist damit auch 5. genau so funktioniert konstruktor+prototyp. der prototyp wird nicht neu erzeugt. es wird einfach auf die vorhandene variable zugegriffen. schreiben wird die variable allerdings im neuen objekt angelegt. normal ist das verhalten von js effizient und variablen neu erzeugen solange auf sie nur lesend zugegriffen wird ist reiner overhead. ein erzeugen "on demand" ist gut. eine call kette in konstruktoren, so dass die objekte neu erzeugt werden(immitieren von klassen - richtig), ist generell nicht so gut aufgrund des overheads. hoffe das macht es ein bischen klarer. alles "first class". vielleicht noch call kette(simulation von klassen) ist so was:

 
var konstruktor_super = function(){
  this.blarb=
}
var konstruktor_next = function(){
  konstruktor_super.call(this,...)
  this.bluf=
}
var konstructor_further = function(){
   konstruktor_next.call(this,...)
 this.blaf=
}
...
//abgeleitetes objekt erstellen:
var objekt = new konstructor_further();
//z.b. superobjekt selber erstellen
var superobjekt= new konstruktor_super();

(nicht signierter Beitrag von 84.57.21.163 (Diskussion) 11:52, 15. Jan. 2011 (CET))

(nicht signierter Beitrag von 88.65.142.43 (Diskussion) 14:02, 8. Jan. 2011 (CET))

das wäre ein beispiel für eine bibliothek, die private braucht zur abstraktion(kein new!!):

 
    var publicobject={
      //... öffentliches interface   
      //.. alles was hier steht ist direkt verwendbar durch andere die es einbinden
    };

    (function(){
        //private geschichten was hier steht ist nicht direkt verwendbar durch leute die einbinden

       var a = 5;
       var b = "blah";
       // es kann aber kontrolliert verfügbar gemacht werden.
       publicobject.Agetter=function(){
           return a;
       };
    })();

(nicht signierter Beitrag von 88.65.142.43 (Diskussion) 20:54, 9. Jan. 2011 (CET))

Typische Anwendungsgebiete

• Mehrere Frames auf einmal wechseln oder die Seite aus dem Frameset „befreien“

ich würde eher sagen, dass durch JS es nicht notwendig ist überhaupt Frames zu verwenden. Auch ist der Zugriff auf Frames mittels JS sehr stark eingeschränkt, da man so sonst leicht an kritische Informationen gelangen kann (Frame zeigt Anmeldeformular einer anderen Seite an). So muss die Informationen über die URL getragen werden, um ein Frame zu modifizieren, was nicht wirklich im Sinne von JS ist. Da jedoch PHPMyAdmin diese Technik verwendet, um auch sehr alte Browser ansprechen zu können, möchte ich dies jetzt erstmal nicht ändern und die Meinung von anderen wissen --Karolherbst 14:24, 11. Nov. 2010 (CET)

de facto ist dies ein typisches Anwendungsgebiet. Dass es per AJAX indessen Alternativen zu Frames überhaupt gibt sowie die Framesproblematik an sich spielt dabei keine Rolle (letztere wird auf der entsprechenden Seite hinreichend behandelt). Deine Meinung über Frames und den Sinn von JavaScript (?) ist hier ebenfalls irrelevant (WP:POV). Leichtes googeln nach entsprechenden Scripten sollte dir den Verbreitungsgrad dieser Anwendungsform demonstrieren, unabhängig von irgendwelchen von dir bevorzugten Seiten. Also bitte belasse den Text so, wie er ist!--Fritzbruno 16:22, 11. Nov. 2010 (CET)

Naja es ist halt so, dass man kaum noch auf Seiten stößt (außer zb phpMyAdmin, wie schon von mir angesprochen), die so funktionieren. Früher war das sicherlich sehr weit verbreitet, als Ajax noch sehr unbekannt war. Heute ist es allerdings nicht mehr so typisch und es wird auch in der Allgemeinheit dringend davon abgeraten Frames zu verwenden. --Karolherbst 17:06, 11. Nov. 2010 (CET)

wie gesagt: letzteres spielt keine Rolle, Antiframingscripte finde ich noch sehr oft (verwende ich auch standardmäßig selbst), in den einschlägigen Foren sind Fragen nach Möglichkeiten, 2 Frames gleichzeitig zu ändern, keine Seltenheit. Dass das natürlich eine Anfängerfrage ist und du demzufolge allein schon deswegen nicht darum darauf stößt, dass Anfängerseiten meist auch inhaltlich uninteressant sind, ist wahrscheinlich die Ursache für deinen Eindruck.--Fritzbruno 06:39, 12. Nov. 2010 (CET)

mein eindruck ist eher, das betonung auf "zwei frames" von js ablenkt zu einem nebenplatz frames. früher wie erwähnt war es typisch, dass leute so gut wie gar nicht js genutzt haben und in dem nischendasein einzig solche kleinigkeiten damit gelöst wurden. heute wird die mächtigkeit von javascript als sprache entdeckt und wird mehr und mehr richtig in js programmiert. somit ist die heraushebung dieses beispiel als "typisch" für javascript etwas komisch. es ist als würde als typisches beispiel für die verwendung eines autos "radio hören" angegeben werden: tatsächlich, dafür kann ein auto mit autoradio(analog javascript, wenn frames in seiner umgebung existieren) verwendet werden. es ist einfach nicht js /typisch/. js typisch ist ajax, dynamische web, web- _applikationen_(!), bibliotheken, actionscript, dynamische pdf seiten(js in acrobat), als scriptingsprache in java(js ist auch in java enthalten) oder als scriptsprache in spielen im allgemeinen, scripting von desktop umgebungen bzw userinterfaces usw.(nicht signierter Beitrag von 84.57.0.184 (Diskussion) 21:21, 5. Jan. 2011)

gewöhn dir mal an, deine Diskussionsbeiträge zu signieren! Dein süßer Auto-Vergleich hinkt gewaltig. JS für Framemanipulation vs. AJAX entspricht eher Fahren von A nach B vs. Urlaub mit dem Autoreisezug. Die traditionelle Nutzung von JavaScript zur einfachen Webseitenmanipulation (wie Bilderaustausch, Antiframing, 2-Frames-tauschen, ...) existiert nach wie vor, wird durch AJAX oft nur elegant ergänzt, schau dich nur auf den entsprechenden Foren um.--Fritzbruno 13:50, 8. Jan. 2011 (CET)

von mir aus nimm das beispiel "urlaub mit dem autoreisezug" auch das wäre keine typische anwendung eines autos. eher eines zuges. nein, die sache ist: was machst du groß mit javascript bei frames ansteuern? da kommt doch die sprache so gut wie gar nicht zum einsatz: "parent.einframe" - und das ist jetz typisch für javascript? ok. (nicht signierter Beitrag von 88.65.142.43 (Diskussion) 14:52, 8. Jan. 2011 (CET))

Ich hab das Gefühl, du willst hier nur stänkern (nicht mal die Signaturregel kannst du berücksichtigen), also endet die Diskussion hier für mich.--Fritzbruno 16:35, 8. Jan. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Fritzbruno 07:37, 22. Mai 2011 (CEST)

Wiederholungen

irgendwie steht im artikel ne menge doppelt und dreifach drin zb in entwicklung, überblick und geschichte ist vieles gleich, vielleicht könnte man da mal die doppelungen rauslöschen, denn keiner will das gleiche mehrmals lesen beispiel: " ...wurde die Sprache aus Marketinggründen erst in LiveScript und letztendlich in JavaScript umbenannt: Um dem damals aktuellen Java-Trend zu entsprechen, entstand mit LiveConnect eine Schnittstelle zwischen Java und LiveScript, was sich im neuen Namen JavaScript ausdrücken sollte..." "... Trotz des ähnlichen Namens und einer ähnlichen Syntax ist JavaScript grundlegend verschieden von der Programmiersprache Java... Die Namensgleichheit erklärt sich wohl vor allem aus der Absicht, aus Marketinggründen eine Verbindung mit den damals sehr populären Java-Applets herzustellen..." "...die zu diesem Zeitpunkt LiveScript heißt ... eine Kooperation, die die Interaktion von LiveScript direkt mit Java-Applets zum Ziel hat. Sun entwickelte die nötigen Java-Klassen, Netscape die Schnittstelle LiveConnect und benennt die Sprache in JavaScript um ..." dreimal erklärt, warum das ganze nach javascript umbenannt wurde --82.113.121.196 18:03, 5. Apr. 2011 (CEST)

externer link auf droeppez.de

gudn tach!
der edit-war um den link auf droeppez.de/download/js-tut/index.html ist nun schon jahre alt, aber eine diskussion darueber habe ich nicht gefunden. die hintergruende zum edit-war sollen an dieser stelle egal sein, um die diskussion nicht ausufern zu lassen.
ich bitte nun um rein inhaltliche meinungen darueber, ob der link in der link-liste zum artikel aufgefuehrt werden sollte.
gemaess WP:EL sollen nur die externen links vom feinsten sein. nur das beste, was zu finden ist, soll verlinkt werden. im deutschsprachigen raum ist das afaics immer noch selfhtml (auf selfhtml.org), auch wenn die aktuelle version 8.1.2 von 2007 ist. (ich muss mich allerdings an dieser stelle fuer befangen erklaeren, da ich zu selfhtml einen besonderen draht habe.)
die droeppez.de-doku dagegen ist anscheinend 2006 das letzte mal aktualisiert worden. das wird bestaetigt z.b. durch einen veralteten expliziten link auf selfphp3.de (wo mittlerweile gar nix mehr zu php3 gesagt wird). inhaltlich ist selfhtml ausfuehrlicher und wesentlich umfangreicher. ich sehe deshalb nicht, was droeppez.de zu einer wertvollen ergaenzung fuer diesen artikel machen koennte.
weitere meinungen sind erwuenscht. -- seth 14:46, 22. Apr. 2011 (CEST)

Ähnliche Überlegungen hatten mich zum ersten Entfernen des Links bewogen, die Seite ist keine Ergänzung zu SelfHTML, inhaltlich veraltet und unvollständig, dazu sind die verwendeten Begriffe irreführend (zB. "Attribute" und "Funktionen" statt "Eigenschaften" und "Methoden" von Objekten). Eine fruchtbare Diskussion mit dem Einbringer des Links kam leider nie zustande, trotz mehrmaliger Aufforderung, doch mal die Beweggründe darzustellen.--Fritzbruno 19:20, 22. Apr. 2011 (CEST)

Wäre ich auf die Begriffe angesprochen worden, hätte ich gefragt, ob wir uns wirklich um (weitgehende) Synonyme streiten wollen, und wäre ich 2009(!) auf das Veröffentlichungsdatum angesprochen worden, hätte ich gefragt, wann denn DOM, CSS und ECMA262 rausgekommen sind. Wenn die Leute ein paar Synonyme kennen, ist das übrigens eine gute Voraussetzung, um im Deutschunterricht gute Ausdrucknoten abzugreifen. (nicht signierter Beitrag von 87.170.162.106 (Diskussion) 00:25, 23. Apr. 2011 (CEST))

Danke. Meine Argumente hatte ich bereits auf Seths Diskussion ausführlicher anbringen dürfen, dafür herzlichen Dank.

1.) Unterschiedliche Handbücher erhöhen die Wahrscheinlichkeit, daß potentielle Rezipienten eins finden, das ihren persönlichen Ansprüchen genügt. Diese Ansprüche mögen sehr unterschiedlich sein und nicht immer kann man ihnen allein durch sachlich richtige Darstellung, die natürlich als Voraussetzung gegeben sein muß, optimal genügen. Das ist einer der Gründe, warum manch einer Opel, manch einer Volkswagen und manch einer Fiat fährt und warum verschiedene Autos manchmal verschiedene Farben haben. Das ist einer der Gründe, warum verschiedene Leute in verschiedenen Häusern mit verschiedenen Wohnungen mit verschiedenen Grundrissen wohnen. Das ist einer der Gründe, warum es nicht verkehrt sein kann, wenn sowohl Bublath als auch Yogeshwar als auch Lesch die Welt erklären, und das auf unterschiedliche Arten aber doch mit untereinander konsistenten Inhalten. Manchem hilft es auch sehr, dieselbe Sache von verschiedenen Leuten mit unterschiedlichen Begriffen und Bildern erklärt zu bekommen. Vielleicht sollten ja lieber 20 statt 2 Handbücher verlinkt sein, siehe bitte meine Ausführungen zur "Verwendung von Kautschuk" auf Seths Diskussion. Mir hat es jedenfalls immer sehr geholfen, mehrere Bücher von unterschiedlichen Autoren zum selben Theme zu lesen.

2.) Ich möchte auch meine Worte zur (im Rahmen der Möglichkeiten) freien Lehrerwahl zu bedenken geben, ebenfalls auf Seths Diskussion.

3.) Eine vermutlich rhetorische Frage (hängt von den Antworten ab): Wovor soll der Nutzer bei der Verlinkung mehrerer Handbücher geschützt werden? Daß er möglicherweise statistisch betrachtet unnötig Unmengen seiner wertvollen Zeit vertrödeln könnte? Mit einem JavaScript-Handbuch doch wohl selbst dann nicht, wenn man nicht zur direkten mentalen Zielgruppe (siehe bitte freie Lehrerwahl) gehört, oder? (nicht signierter Beitrag von 87.170.162.106 (Diskussion) 00:25, 23. Apr. 2011 (CEST))

Ich sehe in der verschiedenen Begrifflichkeit weniger Synonyme sondern mangelnde Sachkompetenz, dieser Eindruck wird aber vor allem durch die übrigen von mir erwähnten Mängel (veraltet, unvollständig) geprägt, und es waren in erster Linie diese, die mich zur Entfernung des Links bewogen haben. Die Seite erfüllt für mich schlichtweg nicht die Anforderung "vom feinsten".--Fritzbruno 09:03, 23. Apr. 2011 (CEST)

In der synonymen Verwendung der Worte "Funktion" und "Methode" sowie "Eigenschaft" und "Attribut" siehst Du also Anzeichen für mangelnde Sachkompetenz? Dann will ich das einfach mal so als rhetorische Fragen im Raum stehen und auf die Kopfhaut einwirken lassen. Übrigens: Wo war jetzt speziell auf die Sprache "JavaScript" bezogen nochmal der Unterschied zwischen "Funktion", "Prozedur" und "Methode"? Daß es den Unterschied in Pascal gibt, ist mir schon klar. Der Unterschied zwischen "Eigenschaft" und "Attribut" war in der JavaScript-Welt welcher? Gibt es auf diese Spielwiese bezogen vielleicht auch noch einen wesentlichen Unterschied zwischen "Parameter" und "Argument"? Und eine Dokumantation soll veraltet sein, wenn sie nicht so wesentlich viel neuer ist als die Normen (ECMA262, DOM3, CSS2), auf die sie sich bezieht? Und auch, wenn ein VW Lupo deutlich weniger umfangreich ist als ein Maybach, würdest Du den Lupo deswegen als unvollständiges Auto bezeichnen? Das dürfte dann auch den Themenkreis des "vom Feinsten" ausreichend anschneiden. -- 87.170.144.15 20:59, 25. Apr. 2011 (CEST)

Die mir geläufige ECMA-262 ist von 2009, so alt ist das noch nicht. Die Begriffe Methode, Eigenschaften usw. sind darin (en) enthalten, bitte lies selbst nach, um dir die Unterschiede herauszuarbeiten. Beim Vergleich der Inhaltsverzeichnisse erklärt sich für mich der Begriff "unvollständig" von selbst. Der Vergleich mit den PKW hinkt, es liefe auf einen Vergleich von einem PKW mit Kat, Airbag, ABS, etc. zu einem ohne dergleichen hinaus, bei dem zusätzlich noch die Bezeichnung der Gänge von 1-2-3-4 in A-B-C-D geändert wurde (es wäre mir lieber und würde die Diskussion versachlichen, wenn du auf willkürliche Vergleiche verzichten könntest - danke).--Fritzbruno 08:58, 26. Apr. 2011 (CEST)

Die fünfte Edition(!) ist von 2009, OK. Der Begriff "function" ist übrigens in den JavaScript-Quelltexten enthalten. Die Definitionen von "Funktion", "Methode" und "Prozedur" brauche ich nicht nachzulesen, als alter Pascaler kenne ich die auswendig und benutze sie deshalb auch mit der gezeigten Sicherheit und Selbstherrlichkeit. Es ist ganz sicher weder ein Zeichen von Intelligenz noch von Kompetenz, die Übersetzung des Schlüsselwortes "function" in "Funktion" zu bemängeln, und das Schlüsselwort lautet nunmal "function". Weiterhin habe ich keinen Grund, auf irgendwelche Vergleiche (Gleichnisse, Analogieschlüsse) zu verzichten, denn erstens verzichtet niemand, der das beherrscht und ganz bei Trost ist, darauf, und zwar weder im Denken noch im Argumentieren, und zweitens bin ich ganz sicher nicht hier, um Dir einen persönlichen Gefallen zu tun. Nur weil Du wie gezeigt keine passenden Vergleiche findest, heißt das lange nicht, daß ich aus Solidarität gleich mit verzichten muß. Ich bin hier, um das Ganze schnellstmöglich hinter mich zu bringen, und nicht, um einmal bei den Paralympics im Diskutieren teilgenommen zu haben. -- 87.170.141.92 12:46, 26. Apr. 2011 (CEST)

Ich hatte ja gehofft, nach der Diskussion aufs seths Seite wärst du etwas sachlicher geworden, aber ich habe mich getäuscht. Ich sehe keinen Grund, mit dir auf diesem Niveau zu diskutieren. Ich bleibe bei meiner Meinung: die Seite gehört nicht zu "vom feinsten". Offensichtlich bist du nicht bereit, irgendwelche Sachargumente, die mich vom Gegenteil überzeugen könnten (Stichworte "veraltet, "unvollständig"), zu liefern, und da ist alles weitere Geschreibe müßig.--Fritzbruno 18:15, 26. Apr. 2011 (CEST)

gudn tach!

zu der sache mit den methoden und funktionen: diese begriffe werden tatsaechlich in oo sprachen haeufig synonym verwendet, vgl. Methode (Programmierung). das ist imho kein punkt ueber den es sich in diesem kontext zu diskutieren lohnt.

zum auto-vergleich: die mache ich auch gern, und die hinken selbstverstaendlich immer irgendwo, wenn man es nur hinreichend detailliert anschaut. aber in diesem fall sehe es hier aehnlich wie Fritzbruno, naemlich dass der vergleich schon im ansatz hinkt. ein polo und ein maybach haben verschiedene funktionen/adressaten. der vergleich zwischen selfhtml und droeppez ist imho eher der zwischen einem zwei autos, wobei das eine nur vorteile gegenueber dem anderen hat. (so etwas gibt es bei autos vermutlich nicht.) auf den punkt gebracht: welchen vorteil hat droeppez gegenueber selfhtml? den einzigen vorteil, den ich bisher sehe ist ein rein subjektiver, der bisher nur von 87.170.* vermutet/angenommen wird. -- seth 22:05, 26. Apr. 2011 (CEST)

Hoch geschätzter Fritzbruno, was die Diskussion mit Dir angeht, kann ich mich nur bei Seth für seine Moderation und sein sachliches Schiedsurteil bedanken, denn ansonsten stünden hier immernoch die Behauptungen im Raum, man dürfe JavaScript-Methoden in der deutschen Sprache nicht "Funktion" nennen (obwohl sie in der Sprache selbst "function" heißen) und das Verwenden von Gleichnissen in einer Diskussion auf Wikipedis würde wohl in Zukunft als aggressive Kriegshandlung gewertet.-- 87.170.144.208 12:19, 27. Apr. 2011 (CEST)

Es werden im Unterabschnitt Weblinks/Dokumentationen ja schon jetzt drei Ressourcen genannt: eine Online-Ressource, ein online verfügbares Buchkapitel und ein E-Book. Wenn ich in Google Books suche, wieviele Bücher das Javascript-Kapitel von Selfhtml zitieren, finde ich über 10 Bücher aus "richtigen Verlagen", d.h. ohne Zählung von Studienarbeiten und Bezahlverlagen. Für Droeppez finde ich nur eine Diplomarbeit. Das ist ja schon eine Art der unabhängigen Wertung, die eine klare Sprache spricht. Vielleicht kann Herr Kritzner ja einen Review an reputablem Erscheinungsort vorlegen, der seinem Handbuch eine im Vergleich zu anderen Ressourcen bessere oder auch nur andersartige, aber gute Qualität bescheinigt. Meinungen haben wir alle viele. --Minderbinder 11:19, 23. Apr. 2011 (CEST)

Wozu brauchst Du externe Bescheinigungen? Es ist ja nicht so, daß man es kaufen oder aus der Bibliothek holen müßte, um es selbst bewerten zu können. Außerdem verändert das alles nichts an der Tatsache, daß es Lernenden hilft, wenn sie dieselbe Sache aus verschiedenen Mündern unterschiedlich erklärt hören oder aus verschiedenen Federn unterschiedlich formuliert lesen, solange die unterschiedlichen Erklärungen in sich konsistent sind. Mir hat es jedenfalls immer sehr geholfen und mich außerordentlich im Lernen beschleunigt, wenn alternative Formulierungen verfügbar waren. Und ich schieße jetzt einfach mal aus der Hüfte: Wenn man die 20 bestverständlichsten und beststrukturiertesten deutschsprachigen JavaScript-Handbücher auflisten würde, dann wäre es dabei. Ich lehne mich auch mal aus dem Fenster und sage: Es wäre auch noch unter den zehn besten. Und die sechzehn besten sollten schon von der Wikipedia verlinkt werden, einfach, damit man Lernenden mit ausreichend verschieden formulierten Handbüchern aushelfen kann. Außerdem muß man hier, angesichts dessen, daß die Wikipedia nicht das Neue Testament ist, auch nicht unbedingt das Konzil von Nicäa nachspielen, um mal eine Metapher zu gebrauchen. Weiterhin muß man auch nicht ausgerechnet beim Programmieren mit dem Sparen an Dokumentationen anfangen, denn es gibt deutlich trivialere Themen auf Wikipedia, die sowohl wesentlich umfangreicher als auch bedeutungsärmer verlinkt sind. -- 87.170.144.15 20:59, 25. Apr. 2011 (CEST)

grundsaetzlich ist das lesen nicht nur eines buchs von vorteil, das moechte niemand bestreiten. allerdings sollen in der wikipedia nur die besten buecher verlinkt werden. selfhtml ist wohl nach wie vor eines der bekanntesten deutschsprachigen handbuecher zu javascript. droeppez hat zu selfhtml vermutlich einen zu grossen abstand (in puncto reputation oder verbreitung, aber auch in puncto umfang), um zu der javascript-literatur zu gehoeren. um das gegenteil zu belegen, waeren dinge, wie sie von Minderbinder genannt wurden, hilfreich.

falls es handbuecher gibt, die aspekte beleuchten, die bei selfhtml zu wenig behandelt werden, die jedoch fuer javascript von grosser relevanz sind, so koennte man auch ohne, dass es sich um ein ach so bekanntes handbuch handelt, ueber eine verlinkug nachdenken. aber selbst das ist afaics bei droeppez nicht der fall. -- seth 22:05, 26. Apr. 2011 (CEST)

Auf die Argumentation mit der Reputation lasse ich mich nicht ein. Wenn jemand beispielsweise, so wie ich, den Bronstein und den Stöcker benutzt, dann gibt der doch den Bronstein als Quelle an und schweigt über den Stöcker. Das ist nicht schön für den Stöcker, ist aber so üblich. Was den Umfang angeht: Da dürften sich hauptsächlich die Beispielesammlungen, also das, was man als "Kür" bezeichnet, unterscheiden. Der Pflichtteil dürfte, JavaScript 1.5 betreffend, wohl vollständig abgehandelt sein. Mir ist nicht klar, was da so direkt fehlen sollte.

Zur Verlinkung eines speziellen Beispiels: Die Verlinkung auf dem Ajax-Artikel hätte dermaßen exakt zu "JavaScript on demand" gepaßt, aber wie die Faust auf's Auge oder der Arsch auf den Topf. Zeig mir bitte nur eine Stelle im Netz, wo das nochmal so allgemeingültig, vollständig, kurz, zielstrebig, gut dokumentiert und einfach dargestellt ist wie dort. Also das paßt wirklich so dermaßen, der Link muß dort einfach rein. Gerade an der Stelle ist die bestehende Entscheidung für mich völlig unverständlich und nicht nachvollziehbar, denn gerade dieser Artikel ist hilfreich, trifft es genau auf den Punkt und ist nicht wirklich in Einfachheit, Verständlichkeit und Übersichtlichkeit übertreffbar. An dieser Stelle (und wenn es nur diese eine Stelle sein sollte) ist damit sogar der Anspruch "vom Feinsten" in mehrerlei Hinsicht erfüllt, aber trotzdem wird der Link zensiert.

Was den Anspruch "vom feinsten" allgemein angeht: Der Anspruch ist nicht ganz realistisch und möglicherweise, wenn man sich rein technokratisch die Verwirklichung von Bildungszielen als Primärziel setzt, auch nicht immer dienlich. Außerdem: Kürze, Übersichtlichkeit und Schlichtheit würde ich nicht als "nur Nachteile" bezeichnen. Nichtmal ein Trabant hat "nur Nachteile" gegenüber einem Maybach, und das, obwohl ein Trabi nur eine Rennpappe ist. Außerdem heißt "vom Feinsten" ja auch: Es gibt wenig Besseres. Du wirst zwischen SELFHTML und dem Dröppez-Handbuch nicht viel finden. Auch, wenn Du die Lücke dazwischen als sehr groß empfindest, so ist sie nicht sonderlich gut gefüllt. Beim Sport ist ja auch egal, wie groß der Abstand zwischen erstem, zweitem und drittem ist, zum Schluß stehen alle auf dem Treppchen.-- 87.170.144.208 12:19, 27. Apr. 2011 (CEST)

Was On-Demand JavaScript im Ajax-Artikel angeht, möchte ich dich noch mal auf WP:WEB hinweisen: „Ein weiterführender Weblink am Ende eines Artikels muss sich direkt auf das im Artikel besprochene Thema beziehen, also weder auf einen Oberbegriff noch auf einzelne Teilaspekte.“ On-Demand JavaScript ist (wie du sicherlich zugeben wirst) nur ein ganz kleiner Teilaspekt von Ajax, der im Artikel nur einmal erwähnt wird und mit einer sehr guten Quelle belegt ist. Das ist für den Artikel ausreichend. --net 13:18, 27. Apr. 2011 (CEST)

@87.170.*: werden auf droeppez regulaere ausdruecke erklaert oder wie man "Math" verwendet? ich habe dort nichts darueber gefunden, obwohl beides sehr wichtig fuer programmierung (auch in javascript) ist. spontan habe ich uebrigens ein weiteres online-handbuch gefunden, dass mir wesentlich umfangreicher und aktueller als droeppez erscheint: http://openbook.galileocomputing.de/javascript_ajax/. -- seth 22:11, 27. Apr. 2011 (CEST)

Das galileocomputing-Online-Tutorial ist deswegen auch unwidersprochen bereits unter Weblinks/Dokumentationen aufgelistet.--Fritzbruno 08:11, 28. Apr. 2011 (CEST)

Man sieht ganz deutlich, daß Ihr Euch die Begründungen so richtig erst im Nachhinein überlegt. Zuerstmal muß das Handbuch raus, warum, das kriegen wir später. Erstmal bewerten und nachher recherchieren, was man da gerade bewertet hat, so mag ich das. Ja, Math- und RegExp-Objekt werden selbstverständlich im Anhang A erklärt. Wo genau, das verrate ich Euch frühestens nach Reparatur des sogenannten "Spamschutz"-Filters. Und das riesig lange unübersichtliche englischsprachige Handtuch von ajaxpatterns.org wollt Ihr mir für die deutschsprachige Leserschaft doch hoffentlich nicht ernsthaft als die bessere Alternative verkaufen. Wenn man mit sowas zugeballert wird, braucht man sich ja nicht wundern, daß sich die Leute vor dem Programmieren fürchten und daß es immer heißt "zu kompliziert" und "da traue ich mich nicht ran". Klar, wenn einem solch eine Mentalität aufgezwungen wird, dann ist es wirklich zu kompliziert. Aber das ist Euch sowieso völlig egal, denn was interessieren Euch die Leser?

Über das "Gesetz" mit dem Inhalt „Ein weiterführender Weblink am Ende eines Artikels muss sich direkt auf das im Artikel besprochene Thema beziehen, also weder auf einen Oberbegriff noch auf einzelne Teilaspekte.“ kann ich nur sagen: Damit kann ich überhaupt nichts anfangen, und wenn man sich die Wikipedia, die Artikel und die Verlinkungen ansieht, merkt man, daß auch kaum jemand sonst mit dieser "Regelung" so richtig viel anfangen kann. De Facto gibt es auf der Wikipedia sehr viele sehr nützliche Querverweise, die nicht diesen Kriterien entsprechen. Ich werde jetzt auch keine Beispiele nennen, denn ich will ja nicht, daß sofort irgendwelche Leute, die sich berufen fühlen, losziehen und alles weghacken. Den zitierten Satz in WP:WEB könnt Ihr also mit der Begründung "genauso unrealistisch wie nicht handhabbar wie kontraproduktiv wie sinnlos" ersatzlos streichen.

Gut, OK, ich fasse zusammen: Ihr habt eine Entscheidung getroffen, warum, ist völlig egal, und auch, wenn es eine Fehlentscheidung ist, wollt Ihr sie unbedingt durchsetzen, denn es ist der wahnsinnig wertvolle böse Wille einiger anscheinend sehr wichtiger und bedeutender "Personen", und der muß unbedingt geachtet und respektiert werden. Gut, OK, jetzt kann ich mich natürlich fragen: "Was hatte ich erwartet?" Ehrlich gesagt hatte ich genau das erwartet, denn mit Verhaltensbiologie kenne ich mich aus und so unprimitiv ist der ganze Vorgang auch wieder nicht, daß ich den nicht überblicken würde. -- 87.170.165.81 11:40, 30. Apr. 2011 (CEST)

gudn tach!

fuer alle ausser dich war die sperrbegruendung klar. wir versuchen sie dir hier nun zu erklaeren und gehen auf deine argumente ein. ich ueberlege mir also nicht nachtraeglich argumente, sondern formuliere bisherige nur detailreicher aus und von mir aus entgegne ich auch dem einen oder anderen argument, das ich vorher nicht in meine ueberlegungen eingeschlossen hatte. aber bleiben wir doch bei der sachebene:

das math-kapitel habe ich nun gefunden, es erklaert fast nichts, sondern listet nur die mathematischen funktionen auf, ohne auf definitions- und wertebereiche einzugehen. das regexp-kapitel habe ich ebenfalls gefunden, es ist unvollstaendig bis falsch, z.b. stehe "*" fuer eine "Folge aus beliebig vielen gleichen Buchstaben". das ist weniger als die halbe wahrheit. essentiellen regexp-faehigkeiten wie capturing oder alternativen werden voellig uebergangen. das manual ist voller solcher maengel und insofern weit hinter dem, was man als "vom feinsten" bezeichnen koennte. insofern sehe ich auch keine fehlentscheidung meinerseits. -- seth 13:21, 30. Apr. 2011 (CEST)

Das Math-Kapitel erklärt fast nichts? Du meinst also, man sollte die Zielgruppe auf Leute erweitern, die weder einen Taschenrechner bedienen können noch jemals Mathematikunterricht hatten? Vielleicht sollte man, falls Analphabeten vorbeikommen und gern programmieren lernen möchten, als Allererstes die Buchstaben und Satzzeichen erklären. Und zu regulären Ausdrücken: Das ist ein Thema für sich. In einem HTML-Handbuch kann man JavaScript erklären, muß man aber nicht. In einem JavaScript-Handbuch kann man beispielsweise auch CSS oder reguläre Ausdrücke erklären, muß man aber nicht, weil nämlich für CSS und reguläre Ausdrücke extra Handbücher existieren und mit Aufführung der Schnittstelle alles gesagt ist. Zu dem Gequatsche mit "vom Feinsten" hatte ich eigentlich ausreichend viel gesagt, aber wenn Euere Gebetsmühlen einmal am Drehen sind, dann haben die scheinbar so viel Schwung, daß Euer hohles Geschwätz noch ewig nachhallt und einfach nicht aufhört. Und ja, die Sperrbegründugn ist klar: Ihr habt ein bißchen Macht, Ihr habt entsprechende Charaktere, Ihr seid einfach eine Art von Lebensform, die aus irgendeinem Grund einfach nur eine völlig beschissene Verhaltensbiologie gepaart mit entsprechender Erkenntnisfähigkeit und passendem Erkenntniswillen zeigt. Die Begründungen sind schließlich immer klar. Schon 2009 war klar, warum Fritzbruno den Link rausgenommen hat, denn wie man sah, hatte er den vollen Durchblick, prima Argumente und Du brauchtest ihm auch kein bißchen mit ein paar schwächlichen Pseudoargumenten nachhelfen. Man hat in dieser Diskussion hier förmlich gesehen, daß Fritzbruno das aus fachlicher Kompetenz heraus gemacht hat und daß all die anderen sich dem wohlüberlegten und hervorragend begründet formierten Mob aus fachlich-sachlichen Erwägungen heraus angeschlossen haben. Ich möchte hier nochmal besonders die Fachkompetenz des Netzspions nochmal lobend herausstellen, und auch CC und C34 hatten mit ihrem "Ich will! Ich will! Ich will! (mit dem Fuß aufstampfen)" hervorragende Sachargumente, denen Du mit Deinen schwachen Pseudoargumentierungsversuchen gar nicht hättest unter die Arme zu greifen brauchen. Nein, solche Leute machen das schon ganz richtig, werden nur von Kompetenz und nicht von niederen Motiven getrieben, und ich möchte mich nochmal ausdrücklich entschuldigen: Natürlich gehört diese Sorte "Mensch" nicht auf den Scheiterhaufen gebunden, sondern dieser Sorte "Mensch" gehören Lehrstühle für Informatik übertragen und möglichst viel Macht über andere Menschen gegeben, denn diese "Leute" sind durchgehend kompetent, ehrenhaft und man kann diesen "Leuten" ohne jegliche Bedenken sein Leben und überhaupt alles anvertauen.-- 87.170.144.56 09:52, 12. Mai 2011 (CEST)

Rein sachlich betrachtet habe ich die Diskussion gewonnen. Besser gesagt: Die Sachargumente haben gewonnen. Kommt da endlich mal eine Siegerehrung und hat das langsam mal Auswirkungen auf den Inhalt des Verlinkungsbereichs im Artikel? -- 87.170.158.77 09:58, 18. Mai 2011 (CEST)

Wie bei Stefan Raab - da beurteilt der Autor sich selbst. Dementsprechend ist auch die Aussage einzuschätzen. Meine Meinung: droeppez.de ist verzichtbar. --Vanger ^!–!? 11:12, 18. Mai 2011 (CEST)

Fang doch bitte mal mit verstehendem Lesen an. Am besten in umgekehrter Reihenfolge: Die Forderung nach der Erklärung regulärer Ausdrücke ist illegitim, da es für reguläre Ausdrücke extra Handbücher gibt und somit die Erklärung der Schnittstelle ausreicht. Man muß auch niemandem das Kraftwerk erklären, um jemanden zu befähigen, den Stecker seines Küchenmixers in die Dose zu stecken. Die Forderung nach Aufblähung der Beschreibung des Math-Objekts ist sinnfrei, zumindest für jeden, der einen Taschenrechner bedienen kann. Die sogenannten "Argumente" von Fritzbruno, N**s**, CC und C34 konnte nichtmal der lustige Seth (siehe auch und vor allem dessen Diskussionsseite) gelten lassen, und Dein "Argument" ist wieder exakt gleichwertig mit dem von N**s**, CC und C34: Böser Wille um des bösen Willens wegen, das heißt: ungültig. Nicht nur ich soll mit Sachargumenten diskutieren, sondern Du gefälligst auch. Deine Diskussionsleistung soll nach exakt demselben Prinzip bewertet werden wie meine. Du sollst keinerlei Sonderrecht genießen, ohne Argumente einfach mit Begründung "persönliche Vorliebe" irgendwas vom Tisch wischen zu dürfen. Und selbstverständlich bewerte ich meine Diskussionsleistung auch selbst. Sieh Dir Deinen "Beitrag" doch mal an, der besteht nur aus durch nichts belegbaren Behauptungen. Du weißt doch gar nicht, worüber Du sprichst, und selbst der lustige Seth hat gleich erstmal aus der Hüfte heraus behauptet, der Umfang sei nicht ausreichend, bevor er den Umfang überhaupt erkundet hat. Meine Argumentation hingegen bezog sich überhaupt kein Bißchen auf eine wie auch immer angebliche oder tatsächliche Großartigkeit des Handbuchs, sondern ich habe lediglich Informationsvielfalt aufgrund unterschiedlicher Geschmäcker und Lerngewohnheiten eingefordert. Auf qualitative Bewertungen (auch der Konkurrenz) habe ich übrigens absichtlich verzichtet, um Vorwürfe wie Deinem Stefan-Raab-Vergleich mühelos als Lüge vom Tisch wischen zu können, was ich hiermit mache. Vielleicht solltest Du Dir einfach in Zukunft angewöhnen, das durchlesen, worauf Du antwortest, damit Du das Thema in Zukunft nicht erneut vollständig verfehlst. Außerdem kann Deine persönliche Meinung, und nichts weiter war es, kein Kriterium für irgendwas sein, was tatsächlich die Allgemeinheit betrifft. Außerdem liegen hier Daten vor, die beweisen, daß Deine persönliche Meinung und Behauptung nicht mit den tatsächlichen Bedürfnissen der Allgemeinheit übereinstimmt. Es ist einfach nicht wahr, was Du erzählst. Man könnte es auch gelogen nennen. Wenn hier also etwas verzichtbar ist, dann Dein Diskussions"beitrag", wenn man das denn überhaupt so nennen will. -- 87.170.163.223 13:45, 18. Mai 2011 (CEST)

zurück zu den Fakten, hier mal der Stand der Erkenntnisse laut jeweils eigenen Angaben:

• SELFHTML: Version 8.1.2 vom 01.03.2007
• JavaScript und AJAX (galileo-openbook): Copyright © Galileo Press 2007
• Eloquent JavaScript: © Marijn Haverbeke (license), written March to July 2007, last modified on May 13 2011.

das ist alles nicht ganz taufrisch, dies ist aber für mich kein Argument, nun ausgerechnet

• dro***ez: Stand 27. Januar 2004

zusätzlich aufzunehmen. Evtl. wäre es sinnvoller für den Autoren, statt hier die Artikeldiskussion zu füllen, einfach mal die fraglichen Seiten zu überarbeiten. --Fritzbruno 16:28, 18. Mai 2011 (CEST)

Ja gut, wenn Du Dich unbedingt gleich um reichlich zwei Jahre vertun willst, dann mach das. Natürlich zu Ungunsten des Autors, versteht sich. Der 11.09.2006 (steht zumindest dort) ist natürlich auch viel länger her als der 01.03.2007. Ganze sechs Monate, ein ganzes halbes Jahr, was für ein Unterschied. Vielleicht hat man sich mit SELFHTML auch einfach mehr Zeit gelassen, schonmal daran gedacht? Vielleicht hat SELFHTML einfach sechs Monate gebraucht, um nachzuziehen, könnte das sein? Welches Verfallsdatum haben eigentlich ... nehmen wir mal ... die Maxwellschen Formeln? Ein JavaScript-Handbuch ist weder ein Handy noch ein Auto, also worüber genau redest Du hier eigentlich? Außerdem geht es nicht um die Aufnahme. Aufgenommen war es längst. Hast Du eigentlich erst gefragt, dann gewartet und dann rausgerissen, oder hast Du erst rausgerissen und einfach nur gleichzeitig Bescheid gesagt? Daß Du keine Antworten auf Deine damalige Aktion bekommen hast, kann man übrigens auf zwei Arten interpretieren: 1.) Deine Interpretation: Alle sind einverstanden und deshalb erntest Du keinen Widerspruch und hast freie Hand. 2.) Meine Interpretation: Für das, was Du getan hast, bestand keinerlei Handlungsbedarf, den Verantwortlichen ist es antgangen und deshalb hattest Du auch keinen Zuspruch. Wie wäre das: Anstatt, daß wir hier diskutieren, warum wir Deinen Vandalismus rückgängig machen sollten, machst Du Deinen Vandalismus einfach rückgangig und wir diskutieren, warum man Deinen Vandalismus wiederholen sollte. Anstatt daß es draußen ist, und ich kämpfe, daß es wieder rein kommt, machst Du es einfach wieder rein und kämpfst dafür, daß es raus kommt, wie wäre das? Ach nein, auf die Art und Weise hättest Du ja überhaupt keine Chance, Deinen Willen durchzusetzen, und das Ergebnis, daß Du Recht bekommst, wo Du nicht Recht hast, muß ja schon vorher feststehen. Denn schließlich hast nur Du das Recht, alle anderen vor vollendete Tatsachen zu stellen, aber auf gar keinen Fall andersrum. -- 87.170.134.155 20:27, 18. Mai 2011 (CEST)

sorry, wenn ich das falsche Datum nahm (das aus dem Kap. "Querverweise, ..."), ich fand gerade das von dir erwähnte "letzte Überarbeitung: 11.09.2006" sowie ein weiteres "Daten Stand 09.11.2001 - 04:37:43". Letztlich änderte diese erneute Sichtung nichts an meinem Eindruck, dass die Seiten inhaltlich veraltet sind und für die anderen Links auch keine inhaltliche Ergänzung darstellen. Dass JavaScript fortentwickelt wurde seit 2001, 2004 oder 2006 (die aktuelle Version 1.8 ist von 2008) setze ich als bekannt voraus.--Fritzbruno 21:20, 18. Mai 2011 (CEST)

Wenn ein Kapitel nicht mehr überarbeitet wurde, dann liegt das wahrscheinlich daran, daß kein Handlungsbedarf zu seiner Überarbeitung bestand und daß es zu Redaktionsschluß immernoch richtig war. Und dann hat Dich niemand nach Deinem persönlichen Eindruck gefragt, am wenigsten ich. Persönliche Eindrücke sind irrelevant, das steht auch implizit in den Richtlinien. Wie oft muß man Dir das sagen, bis Du es einmal glaubst oder verstehst? Wenn Du nicht persönlich angegriffen werden willst, dann mußt Du Deinen persönlichen Eindruck außen vor lassen und Dich auf harte Fakten beschränken. Daß bekannt ist, was Du als bekannt voraussetzt, setzt ich auch voraus. Von wann genau war SELFHTML nochmal, von vor dem 1.8.2008 oder von nach dem 1.8.2008? Mensch, der 1.3.2007, war der vorher oder war der nachher? Und natürlich hat sich die Programmiersprache grundlegend geändert, alles wurde über den Haufen geworfen, da ist nichts abwärtskompatibel, und Handbücher für einmal ratifizierte und immernoch gültige Standards veralten natürlich auch jemals, wenn nicht gar innerhalb von vierundzwanzig Stunden ... oh Mann, was soll man noch sagen, wenn man mit Leuten wie Dir diskutiert? Siehst Du wenigstens ein, daß man mit Dir nicht diskutieren kann? Das ist doch Niveau Bundestag, aber nicht technische Dokumentation. Und dann soll man ruhig bleiben und nicht ausrasten, ich fasse es ja nicht. Darf ich wenigstens erwähnen, daß Du da gerade wiedermal kompletten Mist erzählt hast, und zwar nicht meiner Meinung mach, sondern tatsächlich, signifikant, meßbar, nachweisbar oder wie immer man es nennen will? Und was ist jetzt mit meine Vorschlag? Mach doch mal den Link wieder rein und diskutiere, wieso man ihn rausnehmen sollte. Mach doch erstmal Deinen Vandalismus rückgängig und frag dann nach, ob Du rausreißen sollst. Erst rausreißen und dann fragen ist falsch, das ergibt sich implizit aus den von Dir ach so hoch gepriesenen und eingeforderten Richtlinien. Mach das rückgängig und versuche es dann andersrum, dann wirst Du ja sehen, wie weit Du kommst. Ach ja, signieren soll ich ja auch noch, grrrrrrr ... -- 87.170.128.193 22:25, 18. Mai 2011 (CEST)

„Wenn ein Kapitel nicht mehr überarbeitet wurde, dann liegt das wahrscheinlich daran, daß kein Handlungsbedarf zu seiner Überarbeitung bestand und daß es zu Redaktionsschluß immernoch richtig war.“ so wie das Kapitel über die beiden "aktuellen" Browser, allen voran Netscape (mit längst nicht mehr funktionierendem Link, da es die Fa. nicht mehr gibt). OK, danach beginnt ein Rückfall in deinen alten Diskussionsstil und daher habe ich das nicht weiter gelesen.--Fritzbruno 22:53, 18. Mai 2011 (CEST)

Tja, es gibt zwar eine Empfehlung, URLs nicht einfach verschwinden zu lassen, aber wenn dann doch mal eine entgegen der Empfehlung verschwindet, dann zeigt der Link in's Leere. Weißt Du eigentlich, wie viele in's Leere weisende Links ich schon auf der Wikipedia repariert habe, um die sich vor mir sehr sehr lange keiner gekümmert hat? Nee, weißt Du nicht, und ich weiß es selbst nicht. Ich habe nämlich nicht mitgezählt. Ich kann mir jetzt also aussuchen, ob ich sage: "Sei mal nicht päpstlicher als der Papst" oder "Kehrt mal vor Euerer eigenen Tür". Und Du brauchst in keinen anderen Stil zurückzufallen, Du hast Dich nämlich nie um einen anderen Stil bemüht. Ich hingegen habe festgestellt, daß Bemühungen um Freundlichkeit nicht honoriert, sondern hauptsächlich als Schwäche interpretiert und schamlos ausgenutzt werden. Warum sollte ich etwas tun, was konsequent bestraft wird? -- 87.170.128.193 00:34, 19. Mai 2011 (CEST)

@87.170*: Du pochst irgendwie viel zu stark auf AGF zu deinen Gunsten. AGF ist vor allem zu Gunsten der anderen gemeint. Immer. Wenn du so stark überzeugt bist, dass deine Doku eine gute Ergänzung ist, müsste sich das doch einfach nachweisen lassen (z.B. durch Angabe von ein paar Beispielen, wo sie unbestreitbar den Konkurrenten überlegen ist) ... Ein Argument der Form "Es könnte ja sein, dass es irgend einem Leser hilft" trifft auf alle denkbaren Dokus zu. --Daniel5Ko 23:22, 18. Mai 2011 (CEST)

Das ist nicht richtig. Die AGF sind zugunsten der Allgemeinheit gemeint, und je nachdem, ob mein Ansinnen der Allgemeinheit nutzt oder nicht, können die AGF auch ganz klar zu meinen Gunsten ausfallen, wenn nämlich zu meinen Gunsten und zugunsten der Allgemeinheit dasselbe ist. Das kann ja durchaus mal vorkommen. Und es könnte nicht nur sein, daß unterschiedlich formulierte Bücher zum selben Thema den Lesern helfen, sondern es ist nachweislich so. Wäre es eine reine Vermutung und wüßte ich nicht ganz genau, wovon ich rede, würde ich nicht darauf bestehen. Das habe ich selbst ausprobiert und mit mir millionen ... naja, zumindest tausende andere Leute. Und was soll eigentlich das ... naja ... Gerede von Überlegenheit? Ist das hier eine militärische Operation, um Gebiete für ein Volk ... ähhhh ... für Daten ohne Raum zu erobern? Dann war es doch gar nicht so falsch von mir, das Ganze als Informationskrieg einzustufen. Warum sollen in Deutschland eigentlich Türken leben? Sind die uns Deutschen irgendwie überlegen? Bitte interpretiere das jetzt nicht als ausländerfeindlich. Das sollte es nämlich nicht sein, ganz im Gegenteil. -- 87.170.128.193 00:34, 19. Mai 2011 (CEST)

Du kannst meine Tipps zu Herzen nehmen, musst es aber natürlich nicht. AGF ist nur meta-mäßig zu Gunsten der Allgemeinheit gedacht. Der Punkt ist folgender: Nimm an, dass jeder, der etwas entgegen deinem Sinn tut, dabei denkt, das richtige für die Allgemeinheit zu tun. Wenn du das verinnerlichst, kommst du möglicherweise zu viel überzeugenderen Argumentationen. Wie die hier konkret aussehen könnten, habe ich schon beschrieben. Zum Thema Überlegenheit: Du kannst dir die Rosinen herauspicken und sagen: "genau an diesen Stellen: [Stelle1, Stelle2, Stelle3] ist meine Doku besser, (nämlich wegen [Grund1, Grund2, und Grund3]) und deshalb sollte sie aufgenommen werden". Das hast du bisher nicht getan.

Ich persönlich behaupte allerdings auch nicht, dass die bereits vorhandenen Weblinks einer besser als der andere sind. Die Vehemenz deines Anliegens wirkt aber seltsam. --Daniel5Ko 01:08, 19. Mai 2011 (CEST)

Deiner Annahme, daß jeder, der etwas entgegen meinem Sinn tut, einen Fortschritt für die Allgemeinheit beabsichtigt, kann ich mich nicht anschließen, weil sie sich nicht mit meinen Erfahrungen deckt. Dafür springen einfach zu viele Hitmen in der Welt herum, ob das nun Journalistic Hitmen oder Economic Hitmen oder Politic Hitmen sind, spielt dabei keine Rolle. Dafür gibt es auch, was hier wohl keine Rolle spielen dürfte aber trotzdem erwähnt werden sollte, zuviel Korruption und Rechtsbeugung. Außerdem kann, wer erstmal nach Gutdünken vollendete Tatsachen schafft und sich die Begründung nachträglich zusammensucht, unmöglich das Interesse der Allgemeinheit auch nur im Blickfeld haben. Außerdem brauche ich nur ein einziges unwiederlegbares Argument: Das Lesen unterschiedlich formulierter Bücher zum selben Thema beschleunigt den Lernvorgang. Dem von Dir geforderten Schwanzlängenvergleich würde ich mich gern verweigern, denn nicht auf die Länge kommt es an, sondern was man damit macht. Aber wenn Du es unbedingt willst: In der Kürze liegt die Würze. Die Einfachheit, Schlichtheit und Schnörkellosigkeit sorgt für eine unübertreffliche Übersichtlichkeit. Sieh Dir beispielsweise das Objektdiagramm im Anhang A oder das Klassendiagramm im Anhang A plus an. Sieh Dir dir dezente, unaufdringliche grafische Gestaltung an. Sieh Dir an, wie viel Information auf einen Bildschirm paßt und was man dabei alles übersichtlich im Blick hat. Weniger ist manchmal bis oft mehr, so auch in diesem Fall. Wenn ein Handbuch den Lernenden nicht mit überladener Unübersichtlichkeit überfordert, dann jenes. -- 87.170.138.148 11:18, 19. Mai 2011 (CEST)

unsachlichen beitrag und antworten darauf geloescht. fuer privatdiskussionsn sind die user talk pages gedacht. -- seth 21:30, 19. Mai 2011 (CEST)

nachtrag: diskussionen abwuergen ist keine loesung. wenn vandalismus vorliegt, kann man z.b. VM nutzen. aber ein pauschales EOD fuer jedermann gibt es nicht. das sage ich bestimmt nicht aus sympathie der ip-adresse gegenueber, sondern weil das gegen die wiki-prinzipien verstoesst. -- seth 23:11, 23. Mai 2011 (CEST)

abwürgen würde bedeuten es gäbe eine Diskussion. Diese sehe ich hier nicht, insofern betrachte ich diesen Part eigentlich als beendet, da es mE. keine neuen inhaltlichen Beiträge gibt und eine Verlagerung ins Archiv andererseits einen Neuanfang mit Tabula rasa bedeutet hätte. Die Auslegung, dies würde gegen wiki-Prinzipien versoßen, teile ich daher nicht. Aber es erscheint mir auch nicht so relevant, um hier eine Grundsatzdiskussion führen zu wollen. Meinetwegen also erledigt--Fritzbruno 23:36, 23. Mai 2011 (CEST)

Was bitte soll hier denn noch diskutiert werden? Die IP konnte bisher nicht darlegen, warum ihr Link so super toll ist, dass es den Spam (der zum Eintrag in der SBL geführt hat) gerechtfertigt hätte. Gibt es also noch irgendeinen klärungswürdigen Punkt, der diese massive Zeitverschwendung hier rechtfertigen würden? --net 23:32, 23. Mai 2011 (CEST)

weitere sachfremde beitraege entfernt.[1] -- seth 09:33, 28. Mai 2011 (CEST)

tabula rasa wuerde bedeuten, dass der ganze quark noch mal durchgekauft werden muesste. das will wohl niemand. ich fang jetzt eine neue zwischenueberschrift an, aber archivieren der bisherigen diskussion waere schlecht, weil sonst etwaige neue user evtl. bereits durchgekaute argumente noch mal bringen wuerden. bitte bleibt nun alle sachlich beim thema. -- seth 23:24, 26. Mai 2011 (CEST)

zwischenueberschrift

nicht alle argumente waren gleich gut (von beiden seiten). wir haben jedoch weiterhin auf der einen seite den betreiber der website, dem per se das WP:COI-problem anhaftet, und der nachwievor der einzige ist, der diesen link aufgenommen haben moechte. auf der anderen seite haben wir mehrere andere user, die die bisher verlinkten manuals nicht nur besser finden, sondern die noch keinen teil im droeppez-handbuch entdeckt haben, der den entsprechenden teilen der anderen handbuecher ueberlegen sei. auch die vom website-betreiber angefuehrte kuerze ueberzeugte niemanden, sondern wurde sogar die artikel wurden im gegenteil teilweise als zu kurz (mangelhaft) angesehen. da es an links im artikel nicht mangelt, sehe ich keinen grund, der fuer die aufnahme des links spricht. -- seth 23:24, 26. Mai 2011 (CEST)

Das stimmt so nicht. Wir haben einen, der mit guten Begründungen dafür ist, und das bin ich. Dann haben wir einen, der mit sehr subjektiven und relativ schwachen Begründung dagegen ist, und das bist Du. Und außer uns beiden sehe ich weder hier noch auf Deiner Diskussionsseite irgend jemanden, der sich legitim irgend ein Urteil leisten könnte. Vor allen Dingen haben es Fritzbruno und Netspy nicht nötig zu argumentieren, denn Du läßt ihnen die Manipulation dieser Diskussion ungestraft durchgehen, siehe die Versionsgeschichte. Ich wöllte auch mal unbequeme Wahrheiten und berechtigte Fragen einfach so wegmachen können. Ich erwarte hier auch keine demokratische Entscheidung, sondern eine technokratische. -- 87.170.140.64 09:06, 27. Mai 2011 (CEST)

Datentypen

Wertebereiche wären mal nett. Sind die genormt oder browserabhängig? --RokerHRO 15:11, 28. Mai 2011 (CEST)

Hmm, so viele Datentypen gibt's ja nicht, wo es sinnvoll ist, einen Wertebereich anzugeben. Der einzige numerische ist Number. Seine Werte sind laut ECMA 262 64Bit-IEEE-754-Floats. Steht auch schon im Artikel, wenn auch an einer etwas ungünstigen Stelle.

(Übrigens: Es gibt keinen Grund anzunehmen, Normierung und Browserabhängigkeit schlössen sich gegenseitig aus. Es geht beides gleichzeitig. :D )

--Daniel5Ko 01:32, 29. Mai 2011 (CEST)

node.js

beim überblick serversitiger javascript anwendungen fehlt node.js (nicht signierter Beitrag von 77.21.0.230 (Diskussion) 12:01, 1. Jun. 2011 (CEST))

Link auf englischsprachigen Wikipedia-Artikel fehlt

Wenn schon alle Quellen englischsprachige Artikel verweisen, kann man auch gleich den *längeren* englischen Wikipedia-JavaScript Artikel lesen.

2. Die Erklärung prototypbasierter Vererbung ist sehr *knapp*. Besteht die Hoffnung, daß Änderungen an diesem Abschnitt nicht rückgängig gemacht werden?

-- 80.132.159.172 16:48, 24. Aug. 2011 (CEST)

SelfHTML ist nicht englischsprachig, die Links auf entsprechende Artikel in anderssprachigen Wikis sind durchweg vorhanden. Also: wo genau siehst du ein Problem? --Fritzbruno 17:41, 24. Aug. 2011 (CEST)

---

Frage: Wieso gibt es so wenige deutschsprachige Links? Beispiel: http://www.fh-wedel.de/~si/seminare/ws07/Ausarbeitung/11.javascript/docs/informationhiding.html bzgl. Objektorientierung in JavaScript.

Wieso gibt es keine Links, die die prototypenbasierte Vererbung auf einem höheren Niveau darstellt?

Wieso wird nirgends erwähnt, was eine privilegierte Methode genau ist.

Wieso wird erwähnt, daß Methoden überschrieben werden können, dies aber nicht belegt oder definiert? In welchem Sinne wird hier "überschrieben" gemeint?

JavaScript hat sich enorm weiterentwickelt und dann helfen Links auf dieses Galileo-Buch nicht wirklich weiter.

Galileo erwähnt die prototypenbasierte Vererbung meines Wissens überhaupt nicht.

-- 80.132.164.17 16:11, 26. Aug. 2011 (CEST)

link ist jetzt drin. -- seth 23:55, 26. Aug. 2011 (CEST)

ECMAScript vs. JavaScript

Wieso gibt es eigentlich keinen seperaten Artikel für den ECMAScript-Standard? Das einfach zusammenzufassen finde ich inhaltlich falsch und verwirrend.

JavaScript und ECMAScript sind eben nicht identisch, sondern das Eine ein Dialekt des Anderen. Da es neben JS auch noch weitere Dialekte gibt (wie in der englischen Wikipedia nachzulesen ist), sollte es IMHO auch getrennte Artikel für den ECMAScript-Standard auf der einen und die wichtigsten Dialekte (JavaScript, ActionScript, JScript) auf der anderen Seite geben.

So wäre es dann auch deutlich einfacher zwischen der Entwicklung des Standards und der der Implementierungen zu unterscheiden und den Artikel überschaubar zu halten.

Martin Kraft 12:10, 30. Sep. 2011 (CEST)

Warum werden Closures nicht erwähnt

Das steht zwar in den meisten 0815-Webentwickler-Büchern auch nicht drinn, ist aber ein wichtiges Sprachfeature ohne das einige der bekannten Frameworks so nicht möglich wären.

Oh sorry habe es überlesen. Aber das Beispiel im Artikel ist völlig nichtssagend. (nicht signierter Beitrag von 84.164.148.143 (Diskussion) 21:25, 18. Dez. 2011 (CET))

Wenn du ein besseres hast wäre ich dir dankbar.--Fritzbruno 06:41, 19. Dez. 2011 (CET)

Ich werde bald einen kleinen Abschnitt dazuschreiben, habe nicht so viel erfahrung in Wiki-Ordnung und hoffe ihr könnt mich da ausbessern und verfeinern wo es geht. Bis die nächsten Tage. -- Aaron Diamantberg 19:08, 04. Apr. 2012 (CET) (ohne Benutzername signierter Beitrag von 77.80.17.141 (Diskussion))

dann schreib deinen Entwurf einfach hier auf die Diskussionsseite damit er erst einmal hier "verfeinert" werden kann. (Bitte verlinke hier nicht auf Facebook & Co.)--Fritzbruno (Diskussion) 20:34, 5. Apr. 2012 (CEST)

javascript al eigenständige sprache

sorry, aber irgendwie wird hier immer noch kein js beschrieben. javascript kommt von ki sprachen, d.h. scheme bzw lisp.

javascript funktioniert auch so und wird auch so programmiert, wie diese sprachen. javascript ist ein baum mit knoten. knoten sind variablen, die auch funktionen sein können.

programmiert wird javascript in dem der baum manipuliert wird und knoten entfernt, hinzugefügt bzw ersetzt werden.

es wird ein neuer knoten angelegt:

--- var myNode = {}; bzw var myNode = function(){}; ---

dann wird er gesetzt:

--- tree.anode.anotherernode.leaf = mynode. ---

oder ein knoten wird umgesetzt:

--- tree.anode.anothernode.thetargetenode.leaf = tree.anode.somewhere.sourcenode.leaf ---

so wird der baum den js darstellt ständig manipuliert und damit js mehr oder weniger selber verändert und wird entsprechend der änderungen weiter ausgeführt. javascript is implizit sebstmodifizierend.

explizit sei dazugesagt: ist mit baum nicht dom gemeint sondern javascript selber.

einzig das javascript schleifenkonstrukte und ähnliches hat sollte nicht dazu verleiten anzunehmen, die sprache wäre wie c mit einer abgewandelten syntax. es ist eine komplett andere sprache mit manchmal ähnlichen syntax, die wie oben dargestellt funktioniert. javascript ist ähnlicher mit lisp dialekt als c. bzw ein lisp um c syntax konstrukte erweitert.

das javascript nicht ecma ist und als sprache unabhängig vom einsatz im browser behandelt werden sollte hat schon jemand angemerkt. der häufigste einsatz ausgewachsener javascript programme ist in aufwendigen spielen(ist m.w die häufigst genutzte scripting sprache in professionellen spielen). in browsern kommt js zwar immer zum einsatz aber bis dato sind richtig ausgewachsene js programme im browser eher eine seltenheit. -- 84.57.61.148 20:14, 13. Jun. 2012 (CEST)

Variablen und Werte

Einwand: siehe zusammenfassungszeile http://de.wikipedia.org/w/index.php?title=JavaScript&diff=104541928&oldid=104541005 (nicht signierter Beitrag von 77.179.79.174 (Diskussion) 22:29, 18. Jun. 2012 (CEST))

gudn tach!

"For example, a variable is not required to have its type declared [...]" (ECMAScript Language Specification)

"The typeof operator returns a string indicating the type of the unevaluated operand. operand is the string, variable, keyword, or object for which the type is to be returned." (Client-Side JavaScript Reference, mozilla.org)

erklaerungen wie "Der Datentyp des Werts, den die Auswertung eines Ausdrucks e ergibt, lässt sich mit typeof e ermitteln." sind wesentlich umstaendlicher und auch unverstaendlicher (siehe WP:OMA) als "Der Datentyp einer Variablen v lässt sich mit typeof v ermitteln.".

ich werde deswegen jetzt den urspruenglichen stand wiederherstellen und bitte dich, von einem erneuten revert erst mal abzuesehen und stattdessen den verlauf der diskussion hier abzuwarten. -- seth 21:55, 19. Jun. 2012 (CEST)

Das zitat aus der spezifikation 262 stammt aus der informellen einleitung und handelt eher nicht von javascript-variablen. Im ganzen rest der spez. existiert das konzept "typ von variable" nicht.

Das zitat von mozilla.org ist falsch. "unevaluated" stimmt nicht mit dem ueberein, was im standard steht (11.4.3 The typeof Operator), typeof (5+5) ist legal, und der operand ist weder "string", "variable", "keyword", noch "object".

Korrektheit ist wichtiger als verstaendlichkeitsvorgaukelung durch treffen falscher aussagen.

Variablen aendern ihren typ nicht, und werte aendern ihren typ auch nicht. Erst wenn man diese begriffe ohne not sinnlos vermischt und zeitlich versetzt mit dem wort "variable" manchmal wert und manchmal variable meint, kann man zu der behauptung kommen, variablen würden ihren typ aendern. Diese letzte behauptung ist das schlimme missverstaendnis, welches man mit geeigneter wortwahl vermeiden kann. --77.179.89.196 22:38, 19. Jun. 2012 (CEST)

Noch ein gedanke, bzgl. oma-verstaendlichkeit. Sollte man das konzept "typ von variable" erfinden und definieren als "halt immer der typ des in der variablen enthaltenen wertes", dann ist "typ einer variable kann sich aendern" eine zwecklose verkomplizierung der aussage "beim schreiben in eine variable wird der vorher enthaltene wert ignoriert". --77.179.89.196 23:28, 19. Jun. 2012 (CEST)

gudn tach!

das zitat ist nicht falsch, sondern deiner meinung nach der inhalt. ;-p ich hatte den text uebrigens von https://developer.mozilla.org/en/JavaScript/Reference/Operators/typeof kopiert.

das mit der korrektheit (vs. pseudo-verstaendlichen, aber falschen aussagen) ist sicher richtig. aber die frage ist halt, was im kontext eine falsche aussage ist bzw. ob es falsch ist, vom datentyp einer variable zu sprechen. in diesem sinne moechte ich deiner these der verkomplizierten aussage widersprechen. beim +=-operator z.b. wird (im allgemeinen) der vorher enthaltene wert nicht ignoriert. dass variablen mit datentypen verknuepft sind und diese aendern koennen wird deutlicher anhand von funktionen wie settype (in php). denkbar ist sowas auch in javascript[2]. du wuerdest nun vermutlich entgegnen, dass nicht die variable ihren typ aendere, sondern nur der in der variablen enthaltene wert seinen typ aendere bzw. ein neuer wert eines anderen typs in der variablen gespeichert werde. im sprachgebrauch wird das aber eben einfach verkuerzt, und zwar ohne, dass dadurch falsche informationen transportiert werden. denn eine variable ist fest mit einem typ verknuepft, ob man nun den umweg ueber den wert der variablen geht oder sogar ueber die interne repraesentation im speicher ist in diesem kontext wurscht.

aber ich glaube auch, dass wir diese allgemeine frage hier gar nicht unbedingt zu klaeren brauchen. vielleicht finden wir fuer die beiden verbleibenden stellen, um die es noch geht,[3] bessere formulierungen.

zur ersten stelle (typeof): der gag an deinem vorschlag ist, dass das 'e' eine metasyntaktische variable und kein eigentlicher javascript-ausdruck ist (sondern einen solchen nur symbolisiert). das macht die sache imho etwas komplizierter als wenn man etwas enger im javascript-sprachsystem bleibt und einfach von "typeof(v) mit v einer js-variablen" spricht. da aber im weiteren verlauf des abschnittes auch nur von werten gesprochen wird, sehe ich ein, dass es sinnvoll ist, typeof auch eher damit in verbindung in der einleitung zu nennen. nach einigem gruebeln denke ich deshalb nun auch, dass deine formulierung da vielleicht die bessere war (und mir faellt keine noch bessere ein). bevor ich aber meinen revert revertiere, koennen wir vielleicht noch klaeren, was man mit der zweiten stelle macht:

bei der zweitenstelle (dyn. typ.): da halte ich die derzeitige formulierung fuer adaequat, allerdings ist fraglich, ob es den nachsatz "was manchmal zu fehlern bzw. unerwuenschten effekten fuehrt" braucht. imho ist der ueberfluessig, weil alle spracheigenheiten irgendwann irgendwie zu fehlern oder unerwuenschten effekten fuehren koennen, wenn man falsch damit umgeht. ich schlage deshalb vor, den zweiten nachsatz zu loeschen. die kurze erklaerung, was dyn. typ. grob ist, halte ich jedoch wie gesagt fuer sinnvoll. details kann ja jeder im verlinkten artikel nachlesen, der dann uebrigens auch von typen von variablen spricht. -- seth 11:43, 20. Jun. 2012 (CEST)

+= ist nicht blosses schreiben, sondern lesen gefolgt von schreiben. phps settype liest ebenfalls einfach einen wert und schreibt einen anderen, wie man z.b. an dem verwirrten kommentar von Chris Sullins 18-Apr-2010 11:59 sieht. Das javascript-settype ist abfall mit hoechst eingeschraenkter funktionalitaet (vr als string uebergeben und das muss eine globale variable sein???), das aber auch nur einen wert liest und dann einen wert schreibt.

(Ja, ich entgegne also genau das, was du erwartet hast). Das ist eben genau das, was es ist. Mit einer variablen ist kein typ verknuepft - jedenfalls nicht in anderer weise als in der, dass werte typen haben, und man variablenwerte auslesen kann. Gerade weil es in anderen sprachen durchaus moeglich und sinnvoll ist, tatsächlich typen an variablen zu haben, die unabhaengig von den werten sind, sollte man hier nicht die gefahr eingehen, dass die erwaehnung von typen von variablen in dieser richtung missverstanden wird. Benoetigt wird, wie gesagt, dieses konzept sowieso nicht und definiert ist es, etwa durch ECMA 262, auch nicht.

Man liest auch oft ein "mantra" (jetzt nicht unbedingt auf js bezogen, sondern etwa python, ruby, lisp, aber das modell ist ja bei allen das selbe), das wohl an C-programmierer gerichtet ist und lautet: "variables don't have types, values do". Wird wohl als wert betrachtet, andauernd wiederholt zu werden, um vorurteile und denkblockaden wegraeumen zu helfen.

(Nebenbemerkung: Unter "richtigen" informatikern, welche dynamische typen ueberhaupt nicht als typen ansehen, haben variablen in dynamischen sprachen sehr wohl einen typ, allerdings alle den selben (den man z.b. Any, oder Dynamic nennen koennte), siehe z.b. einleitung von kap. 18 "Dynamic Typing" von [4];  !)

Dass das e bei strenger auslegung nur ein bestimmter ausdruck war, und kein beliebiger, war mir auch aufgefallen, aber ich wollte es nicht noch seltsamer machen, als es so schon war...;)

Bzgl. ausdruck ggue wert: wenn ich "typeof <foo>" schreibe, und das als ausdruck in der sprache meine, dann ist foo eben noch kein wert, sondern auch erstmal ein ausdruck. Vielleicht ist das ohne ein echtes code-schnipsel besser, etwa "typeof ermittelt den typ (eines werts | seines operanden)"... --77.5.190.229 20:49, 20. Jun. 2012 (CEST)

gudn tach!

um es etwas abzukuerzen, gehe ich jetzt nur auf den schluss ein: ja, ich glaube ohne echten code-schnipsel waere das tatsaechlich besser. das ist eine gute idee.

nun gut, von mir aus kannst du es auch gerne direkt im artikel aendern. ich werd's dieses mal nicht revertieren. :-)

das grundsaetzliche thema "datentypen von variablen" waere evtl. mal eine diskussion auf portal:informatik wert. -- seth 22:26, 20. Jun. 2012 (CEST)

Abschnitt Datentypen

Ich bin über den Abschnitt zu Datentypen nicht wirklich froh. Das Verhalten des typeof-Operators und die spracheigenen Typen ohne strikte Unterscheidung zu vermischen ist keine gute Idee [5], instanceof wird übergangen, außerdem ist es falsch, dass sich "mit den vordefinierten Konstruktorfunktionen String(), Number() und Boolean() erzeugte Objekte [...] wie Werte der entsprechenden Datentypen" verhalten. Siehe !!new Boolean(false). Eher "ähnlich wie". Man müsste mal(tm) den Abschnitt klarer fassen. --84.153.56.75 20:08, 25. Jun. 2012 (CEST)

Das seh ich ähnlich. Da Variablen in JS ja (leider) überhaupt nicht typisiert werden können, ist diese ganze typeof-Geschichte eh ziemlich gurkig und gibt nur die primitivsten Basistypen noch dazu in der falschen Großkleinschreibung aus.

Strneg genommen sind auch diese sog. 'Konstruktorfunktionen' eigentlich gar keine (sie werden ja i.d.R. new aufgerufen) sondern eher ein Casting. --Martin Kraft (Diskussion) 20:53, 25. Jun. 2012 (CEST)

Verständlichkeit für Laien (bisher: "JavaScript - Artikel in der wiki")

Das versteht mal wieder kein Mensch.

Warum kann man nicht ganz einfach, ohne kryptisches Fach-Chinesisch beschreiben, was javascript macht, bzw., welche Gefahren sich dahinter verbergen? Warum man,auch unter Verlust der lustigen neuen internet-Welt, auf Java-script verzichten sollte? (nicht signierter Beitrag von Frau.mahlzahn (Diskussion | Beiträge) 02:19, 1. Nov. 2012 (CET))

Du findest den Artikel kryptisch; aber weißt ganz genau, wie man JavaScript mit zwei Sätzen abtun kann. --Parzi (Diskussion) 02:31, 1. Nov. 2012 (CET)

Eine recht eingeschränkte Sichtweise. JavaScript ist schließlich mehr als nur eine im Browser integrierte Sprache. Warum also sollte man generell darauf verzichten? Leider herrschen Meinungen wie Ihre noch in zu vielen Köpfen vor. JavaScript hat inzwischen jedoch mehr Anwendungsgebiete und ist nicht auf den Einsatz in Browsern beschränkt. Ein Paradebeispiel hierfür ist beispielsweise Nodes.js --Dutze (Diskussion) 12:30, 1. Nov. 2012 (CET)

Mal abgesehen davon wäre eine verkürzte Darstellung JavaScript == böse mit dem Neutralitätsgebot der Wikipedia schlicht unvereinbar. --Martin K. (Diskussion) 13:51, 3. Nov. 2012 (CET)

toll, Ihr habt nicht verstanden, was ich meine.--Frau.mahlzahn (Diskussion) 06:05, 13. Nov. 2012 (CET).

Nun rate mal, an wem das liegen könnte! --net (Diskussion) 08:26, 13. Nov. 2012 (CET)

Auch wenn Frau Mahlzahn Ihr Anliegen etwas plump vorträgt: Ich finde dass man zur Verständlichkeit zwei Dinge verbessern könnte.

• Den Einleitenden Absatz für Laien verständlich formulieren, erst danach auf die Charakteristika der Programmiersprache eingehen. Z.B. wie bei "Simple English"
• Den Punkt Sicherheit und Missbrauch zusammenfassen, um den Mythos vom "gefährlichen Javascript" zu entkräften, gleichzeitig aber auch die Rolle JS im Aufspüren von Browser-Sicherheitslücken etc. zu erklären.

PS: Frau Mahlzahn, was meinst du denn? --Jesus Presley (Diskussion) 15:21, 25. Nov. 2012 (CET)

Kasperletheater ;)

var maunz = function () {

  return (lebensZahl > 0) ? "miau" : "örks";

};
Nun, ich weiß ja nicht wie ihr das seht aber das ist mir doch eine Spur zu sehr Gekasper in einer Enzyklopädie. Sollten wir nicht ein etwas seriöses Beispiel finden können? -- Und bevor ich's vergesse: der mit dem "Mutantenfisch" muss wohl am Tag des Eintrags ebenfalls irgendwie zuviel bewusstseinserweiternde Ingredienzien geraucht haben ;)-andy 77.7.11.230 21:38, 31. Dez. 2012 (CET)

Funktionale Sprache?

Es kam gerade eine Rückmeldung, wieso der Artikel denn in der Kategorie "Funktionale Programmiersprache" sei (Spezial:Artikelrückmeldungen_v5/JavaScript#15752). Berechtigt, wie ich finde; JavaScript besitzt zwar (ähnlich wie Perl) Features wie Closures und so weiter, aber es ist dennoch meilenweit entfernt von tatsächlich funktionalen Sprachen wie Haskell oder Erlang, genauso wie Perls Objektorientierung nur schwerlich auf eine Stufe mit, sagen wir, Java gestellt werden kann (ich habe gerade nachgeschaut, Perl ist nicht in der Kategorie "Objektorientierte Programmiersprache"). Vielleicht sollte man den Artikel also aus der Kategorie entfernen - was meint Ihr? --Der Messer ^{meckern? - loben?} 22:05, 11. Feb. 2013 (CET)

Der Definition von Funktionale Programmiersprache folgend, ist JavaScript eine Programmiersprache, „die Sprachelemente zur Kombination und Transformation von Funktionen anbietet“ und gilt somit als funktional. Im Gegensatz zu Haskell ist sie jedoch nicht rein funktional, da auch andere Paradigmen unterstützt werden. --$TR8.$H00Tα ^{talk} 00:12, 12. Feb. 2013 (CET)

Anwendungsbereiche + Missbrauch

Hi, die Beispiele sind meiner Meinung nach ein bisschen seltsam, ich gehe mal von oben nach unten:

"Dynamische Manipulation von Webseiten über das Document Object Model" Tja das bezeichnet ungefähr alles, vielleicht wären da ein paar Beispiele, die der Anwender auch kennt, hilfreicher. Zum Beispiel modale Dialoge oder Lightboxes oder so schnacken.

"Banner oder Laufschriften" Ummm das war mal Flash und heute CSS3 und eigentlich schon immer Bullshit aber hat man dafür jemals flächendeckend Javascript eingesetzt?

"Mehrere Frames auf einmal wechseln oder die Seite aus dem Frameset befreien" Frames in 2013? Ist hoffentlich kein typischer Anwendungsbereich mehr ;

"Ungewolltes Schließen des Browserfensters" Geht nicht.

Gruß, --Courier New (Diskussion) 11:51, 6. Apr. 2013 (CEST)

Nur ein Beispiel: Frames werden massig zum Einbetten von Videos verwendet. Guck z.B. bei YouTube die Codevorschläge. Schliessen geht in manchen Browsern (z.B. Google Chrome) ohne Bestätigungsfenster, wenn keine History vorhanden ist: <html><body><script type="text/javascript">setTimeout("window.close();",4000);</script></body></html> Alauda (Diskussion) 16:16, 6. Apr. 2013 (CEST)

Frames werden bei der google-Bildersuche genutzt - das ist wohl nicht gerade selten. Für Laufschriften, zB. Börsenkurse oder News-Ticker, wird durchaus JavaScript verwendet. JavaScript-Banner-Wechsel-Programme sind zwar seltener geworden, sind aber noch nicht vöällig verschwunden. --Fritzbruno (Diskussion) 16:30, 6. Apr. 2013 (CEST)

Missbrauch + doch viele Webanwendungen betroffen

Viele aktuelle Webanwendungen, Player und Plugins werden mit JavaScript von dritten missbraucht, etwa per XSS (Codeeinschleusung) oder zum DoS. Scriptbeispiele als "Proof of Concept" findet man bei cxsecurity.com mit der Suche z.B. nach "Javascript overflow". Einige sehr alte funktionieren sogar (immer) noch. Kleines einfaches Beispiel Browser-DoS: http://cxsecurity.com/issue/WLB-2009070030 --84.167.138.113 23:41, 9. Jun. 2014 (CEST)

Abschnitt zu Traits und Mixins

Ich habe gerade die ausführlichen Ausführungen und Codebeispiele zum Thema Traits und Mixins verworfen, weil diese Pattern meiner Meinung nicht in den Abschnitt Sprachelemente gehören und zudem ihre Beschreibung (insbesondere die Codebeispiele) um ein vielfaches zu lang waren. Das hätte im Artikel nicht nur ein deutliches Ungleichgewicht erzeugt, sondern wäre auch stark richtung Tutorial gegangen - was die Wikipedia ja nicht sein sollte. Gerade Code-Beispile sollte man IMO so kurz und übersichtlich wie möglich halten.

Da es sich bei diesem Thema um einen interessante Alternative zur Vererbung handelt, könnte ich mir trotzdem vorstellen, sie in den zugehörigen Abschnitt zu erwähnen. Allerdings sollte man es dabei bei maximal einem Absatz belassen. --Martin K. (Diskussion) 11:53, 13. Apr. 2013 (CEST)

Typische Anwendungsgebiete

Da fehlen noch GUIs von Desktop Anwendungen.

Windows Vista/7 nutzt/nutzte (afaik) JS für seine Widgets.

KDE stellt gerade komplett die Widget Engine auf JS um (Anzeige ist rein JS, Logik dahinter in C++)

GNOMEs GNOME-Shell ist in JavaScript geschrieben (zum. die GUI, die Logik dahinter weiterhin in C).

Es gibt also in der Software Entwicklung immer öfters den Weg vor allem flexible GUIs in JavaScript zu schreiben und nurnoch die berechnende Logik dahinter (meistens) in C/C++ (nicht signierter Beitrag von 149.238.193.121 (Diskussion) 12:56, 28. Jun. 2013 (CEST))

Beeinflusst_von & Beeinflusste

Was soll dieser „Vandalismus“ wegen dieser zwei Abschnitte? Die gibt es bei fast allen Artikeln zu Programmiersprachen und die Information ist auch sinnvoll. Dass sich solche offensichtlichen Ähnlichkeiten nicht wirklich stichhaltig belegen lassen ist klar aber trotzdem verstößt das meiner Meinung nach keinesfalls gegen WP:BLG. --net (Diskussion) 15:00, 17. Aug. 2013 (CEST)

+1 Wobei es sicher auch möglich wäre für diese Feststellungen Quellen zu finden.. --Martin K. (Diskussion) 16:03, 17. Aug. 2013 (CEST)

Brauchbare Belege werden sich eher schlecht finden lassen, da die Entwickler/Erfinder wohl meist nicht tagebuchartig dokumentiert haben, wie und weshalb sie dies und das genau so implementiert haben. Die Ähnlichkeiten sind aber sehr offensichtlich und wenn wir in der WP jeden offensichtlichen Fakt belegen müssten, hätte jeder Artikel mehr Quellen als Inhalt. Wie bei allen Regeln in der WP gilt auch hier, dass man Augenmaß bewahren sollte. --net (Diskussion) 09:41, 18. Aug. 2013 (CEST)

Versionen?

Wenn ich mit folgender Datei auf JavaScript-Versionen teste, gibt es nie Versionen größer als 1.5. Angehängte Nullen (type="text/javascript1.5.0" etc.) gibt es auch nicht. Wie gehen diese praktischen Versionen mit der im Artikel gegebenen Versionierung Hand in Hand?

JavaScript-Test Nr. 3<br/>
<!-- RRZN-Skript Seite 54 -->
<script type="text/javascript">
<!--
  document.write("Teste auf JavaScript ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.1">
<!--
  document.write("Teste auf JavaScript 1.1 ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.2">
<!--
  document.write("Teste auf JavaScript 1.2 ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.3">
<!--
  document.write("Teste auf JavaScript 1.3 ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.4">
<!--
  document.write("Teste auf JavaScript 1.4 ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.5">
<!--
  document.write("Teste auf JavaScript 1.5 ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.6">
<!--
  document.write("Teste auf JavaScript 1.6 ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.7">
<!--
  document.write("Teste auf JavaScript 1.7 ... OK!<br/>")
//--></script>
<script type="text/javascript1.8">
<!--
  document.write("Teste auf JavaScript 1.8 ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.8.5">
<!--
  document.write("Teste auf JavaScript 1.8.5 ... OK!<br/>")
//-->
</script>
<script type="text/javascript1.9">
<!--
  document.write("Teste auf JavaScript 1.9 ... OK!<br/>")
//-->
</script>
<script type="text/javascript2.0">
<!--
  document.write("Teste auf JavaScript 2.0 ... OK!<br/>")
//-->
</script>

134.96.90.21 17:10, 21. Aug. 2013 (CEST)

Der Content-type ist in jeder JavaScript-Version text/javascript (ohne Versionsnummer). Wenn du testen willst, dann geht das normalerweise über das languages-Attribute, auch wenn das veraltet ist.

<script language="javascript1.6">var js_version="1.6"</script>

--net (Diskussion) 17:23, 21. Aug. 2013 (CEST)

Danke für den Hinweis; ich habe es ausprobiert und getestet: Das Verhalten von language ist genauso wie von type; Versionen bis 1.5 werden angezeigt, höhere nicht (Mozilla Firefox 23.0 und Konqueror 4.10.5). Wie hängt dies mit den Versionen, die im Artikel dargestellt sind, zusammen? 134.96.90.21 17:36, 21. Aug. 2013 (CEST)

P.S. Auch webhits.de kennt nur JavaScript-Versionen bis 1.5, siehe [6] 134.96.90.21 17:41, 21. Aug. 2013 (CEST)

Dein Beispiel mit type="" ist komplett falsch und language ist veraltet und wird nicht mehr unterstützt. --Gorlingor (Diskussion) 20:24, 21. Aug. 2013 (CEST)

Groß-Kleinschreibung von Typen

@PerfektesChaos: Ich würde Dich bitten einfach mal selbst in der Dokumentation nachzuschauen, bevor Du begründete und belegte Informationen zum zweiten Mal überschreibst. Das was typeof zurückliefert ist immer ein lowercase-String. Es ist daher weder eine vernüftige Referenz für die in den Sprachspezifikationen definierten Typen, noch kann man es einfach in einen < code >-Tag schreiben. Die Ausführung von number; erzeugt nämlich im Gegensatz zu Number; eine Fehlermeldung.

Da die Namen in den ECMA Language Specification genauso wie in allen wichtigen Dokumentationen (z.B. [7][8]) immer mit einem Großbuchstaben beginnen, sollten wir das auch. Ich werde die etablierte Schreibweise daher wieder im Artikel herstellen. // Martin K. (Diskussion) 14:37, 26. Sep. 2014 (CEST)

Bring hier bitte keine Verwirrung hinein.

• Wenn du es als Namen der drei Basistypen verwendest, dann kannst du Boolean, Number und String mit Großbuchstaben schreiben; jedoch nicht als <code> – das ist es nämlich nirgendwo nirgends nicht.
• Wenn es das Resultat von typeof sein soll, wie es die einleitende erste Zeile des Abschnitts Datentypen suggeriert, dann muss es Kleinschreibung sein, und dann und nur dann ist es auch<code>.
• Verwechsele es bitte nicht mit den Klassenfunktionen zu den Primitiva.
• Ich träume in ECMA. --PerfektesChaos 14:46, 26. Sep. 2014 (CEST)

Entschuldige, ich hatte tatsächlich überlesen, dass Du beim zweiten Mal umformuliert und nicht einfach nur revertiert hattest.

Bei Lichte betrachtet ist jedoch der gesamte Abschnitt JavaScript#Datentypen ein ziemlicher Murks, weil hier nicht die Daten-Typen, sonden die Funktion von typeof in epischer Breite beschrieben wird. Da typeof jedoch nur Mittel zum Zweck ist und zudem einige Eigenheiten an den Tag legt, die einem grundlegenden Sprachverständis eher im Wege stehen. Ich würde daher vorschlagen, den kompletten Abschnitt so umzubauen, dass typeof bestenfalls in einem abschließenden Satz erwähnt wird. // Martin K. (Diskussion) 15:06, 26. Sep. 2014 (CEST)

• Entschuldigung akzeptiert.
• Bitte beachte bei deinem weiteren Wirken, dass es bei den primitiven Typen drei Fälle gibt:
  1. Die Erwähnung des primitiven Typs, wie in der ECMA im Standard und laufenden Texts geschieht; korrekte Notation:

     Boolean

  2. Das Resultat von typeof – korrekte Notation:

     boolean

  3. Die Klassenfunktion, die das zugeordnete Objekt generiert:

     Boolean oder deutlicher Boolean()

• Es gibt sogar die Typen Null und Undefined, die jeweils nur einen einzigen Wert enthalten. Aber null ist leider kein Resultat von typeof.
• Dagegen liefern Funktionen zwar einen eigenen typeof, nämlich function, sind aber kein Typ im eigentlichen Sinn.
• Alles ziemlich verwirrend. Wenn du dort überarbeitest, würde ich eine tabellarische Darstellung aller Typen und typähnlicher Gebilde empfehlen.

LG --PerfektesChaos 15:32, 26. Sep. 2014 (CEST)

Da in JS alles ein Objekt ist (also auch die Funktionen) ist Function eigentlich doch auch ein ganz normaler Datentyp?! // Martin K. (Diskussion) 15:50, 26. Sep. 2014 (CEST)

Ich muss nochmal auf dieses Thema zurückkommen, da die Schreibweise an vielen Stellen im Artikel schlicht falsch ist:

• Wie oben schon verlinkt beginnen in allen relevanten Referenzen die Typnamen mit einem Großbuchstaben.
• Und auch Number oder String wäre in soweit korrekt, als dass es sich dabei um ausführbaren Code handelt (Nämlichen den aufruf der gleichnamigen Konstruktorfunktionen).

Sowas wie number oder string hingegen macht einfach keinen Sinn:

• Die Ausführung dieses „Codes“ führt lediglich zu einer Fehlermeldung: ReferenceError: string is not defined
• Da das, was type of zurückliefert ein String ist und kein Bezeichner, müsste da wenn überhaupt "number" oder "string" stehen. Was natürlich im Fließtext noch weniger Sinn macht.

Ich würde daher nochmal vorschlagen die Typbezeichnungen im Fließtextgrundsätzlich gemischt zu schreiben und die lowercas-Schreibweise nur dort zu benutzen, wo sie im Rahmen von type of angebracht ist. Und auch generell, sollten wir darauf achten, dass das was in < code > steht syntaktisch korrekter ausführbarer Code ist. Ich werd das jetzt malentsprechen anpassen. // Martin K. (Diskussion) 09:59, 26. Okt. 2014 (CET)

Ich empfahl weiter oben schon eine tabellarische Übersicht aller Typen, mitsamt null und undefined und den Konstruktorfunktionen (wo vorhanden) und der Doppelrolle der function und vor allem der Resultate von typeof. Anders wirst du Fälle wie den Wert null vom Typ Null mit dem typeof von object oder die Funktion vom Typ Object mit dem typeof von function niemandem verständlich rüberbringen. VG --PerfektesChaos 10:39, 26. Okt. 2014 (CET)

Mir ging es imkonkreten Fall auch eher um die generelle Schreibweise von Typ-Namen im ganzen Artikel – nicht nur um den Abschnitt Typisierung. // Martin K. (Diskussion) 10:57, 26. Okt. 2014 (CET)

Solange im zentral zuständigen Abschnitt nicht sauber durchdekliniert wurde zwischen Name, Konstruktorfunktion und typeof-Ergebnis, wird auch in den anderen Abschnitten niemand begreifen, was wann gemeint ist, und es immer wieder jemand auf etwas anderes umbauen. VG --PerfektesChaos 12:07, 26. Okt. 2014 (CET)

Benurzerdefinierte JS (vector.js bzw monobook.js) "spinnen"?

hallo, ich habe die Frage dazu hier gestellt, vielleicht lesen hier auch Leute mit. Es wäre schade, wenn das nicht mehr geht. Danke. --Brainswiffer (Disk) 17:28, 13. Mai 2017 (CEST)

Siehe oben: Diese Diskussionsseite dient dazu, Verbesserungen am Artikel JavaScript zu besprechen. --FriedhelmW (Diskussion) 17:48, 13. Mai 2017 (CEST)

Sorry, ich muss aber über eine Hilfeseite hierhergekommen sein :-) --Brainswiffer (Disk) 18:16, 13. Mai 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fehlläufer. // Martin K. (Diskussion) 14:54, 5. Mär. 2018 (CET)

Inoffizielles Logo

Das „inoffizielle Logo“ wird derzeit zentral von Wikidata als Logo-Eigenschaft für JavaScript definiert.

Wird sonst (zumindest in der deutschen Wikipedia) jeder unbequellte Scheiß entfernt, ist hier scheinbar ein „inoffiziell“ ausreichend. Was es natürlich nicht ist.

Wieso also wird das schwarzgelbe Logo in diesem Artikel verwendet? Ist »Chris Williams« jemand besonderes? Das Logo wird jedenfalls auch für http://jsconf.com/ verwendet. Ist es nun ein inoffizielles JavaScript-Logo, oder ist es eine Logovorlage für »JSConf™«?

Hier ein paar andere inoffizielle Logos:

• 
• Datei:Logo JS 2005.jpg
• 
• 
• 
• 
• 

Davon ernstgemeint ist höchstens das rechte Bild, denn bspw. in der englischen Wikipedia wird bei Programmiersprachen ohne Logo (wie ECMAScript/JavaScript) ein Quellcodeausschnitt nebst Dateiendung in der Infobox verwendet; das gibt es auch in der deutschen, etwa bei HTML. Das finde ich einen guten illustrativen Kompromiss gegenüber keinem Logo – ein selbstgemaltes und unbelegtes und inoffizielles Logo sollte jedenfalls außer Frage stehen. -- Gohnarch^░ 13:31, 24. Dez. 2014 (CET)

Volle Zustimmung. --Trustable (Diskussion) 14:22, 24. Dez. 2014 (CET)

Ok, also kein Logo. Das „rechte Bild“ halte ich jedoch auch für ungeeignet (es ist einfach ein Mimetype-Icon eines Icon-Sets … von einem Wikipedianer). Wenn es denn genehm ist würde ich eine solche bildliche Darstellung eines JavaScripts erstellen (analog zum genannten HTML und anderen Auszeichnungssprache)? Evtl. nützlich dafür wären inhaltliche Vorschläge. ↔ User: Perhelion 16:10, 28. Feb. 2016 (CET)

Objekte, „Private“ Eigenschaften, Otto muß sterben

Ich finde ein Beispiel ungeeignet, in dem Tiere getötet werden, nur um ein Element der Sprache zu verdeutlichen. Ich unterrichte JavaScript im Gymnasium und wurde durch eine Schülerin auf diesen Umstand aufmerksam gemacht. Es wird sich doch mitnichten ein neutraleres Beispiel finden lassen, wo Otto nicht sterben muß? Vielen Dank.

var neue_katze = function () {
    var lebensZahl = 7;
    var maunz = function () {
        return (lebensZahl > 0) ? "miau" : "örks";
    };

    // gibt neues objekt zurück
    return {
        toeten: function () {
            lebensZahl -= 1;
            alert(maunz());
        }
    };
};
var otto = neue_katze();
otto.toeten(); // miau

(nicht signierter Beitrag von 217.186.143.203 (Diskussion) 13:03, 30. Aug. 2015 (CEST))

Sei Mutig und schlag ein anderes Beispiel vor. -- HerrLock 15:06, 30. Aug. 2015 (CEST)

Codebeispiele um Semikolons ergänzen?

Einige der Codebeispiele nutzen die automatische Ergänzung fehlender Semikolons durch den JavaScript-Parser, wobei das aber nicht einheitlich gehandhabt wird. Da das Weglassen von Semikolons von der statischen Codeanalyse in der Regel bemängelt wird, schlage ich vor, einheitlich die Semikolons explizit anzugeben. Meinungen dazu? --Stefan Weil (Diskussion) 19:48, 28. Mai 2016 (CEST)

Ja, sehr gern, sollten natürlich vorbildlich sein.

Ich hab jetzt nicht reingeguckt, aber alle Klammern und Semikolonse und so sollten am Platz sein.

Wir präsentieren hier doch nicht das 1990er-Jahre-Gemurkse irgendwelcher „Webdesigner“ kurz vorm Abi.

Insbesondere sollte http://jshint.com/ in der härtesten Einstellung jeden Block absegnen.

LG --PerfektesChaos 21:11, 28. Mai 2016 (CEST)

JSHint ist jetzt zufrieden. --Stefan Weil (Diskussion) 22:14, 28. Mai 2016 (CEST)

Wurde in ECMAScript 6 nicht der Sprachkern um Klassendefinitionen erweitert? (Klassenlosigkeit)

Wurde in ECMAScript 6 nicht der Sprachkern um Klassendefinitionen erweitert? -> Ist JavaScript seit ES6 "klassenlos?"

Haut rein (nicht signierter Beitrag von 2A02:8071:238A:4100:12C:8CE5:68A7:655 (Diskussion) 02:13, 1. Jun. 2016 (CEST))

Das ist so nicht richtig, bzw. irreführend. Die Klassendefinition ist nur Syntaktischer Zucker und bringt keine neuen Funktionalitäten. JS ist nach wie vor Prototypen basiert. Ich schlage vor das "(bis ECMAScript 6)"aus der Einleitung zu entfernen und dafür die Klassensyntax unter Sprachelemente vorzustellen und dabei auch auf dieses wichtige Detail zu erwähnen. Hier die entsprechende Seite im MDN. --TorAc (Diskussion) 23:09, 10. Aug. 2017 (CEST)

Sehe ich genauso. Habe mal versucht, die Einleitung klarzustellen. Optimierungen meines Versuchs: gerne!

--JavaScriptKiddie (Diskussion) 08:33, 11. Aug. 2017 (CEST)

Vordefinierte Objekte

Muss es in der Passage

JavaScript kennt mehrere eingebaute Objekte, die von ECMAScript definiert werden.

• Das namenlose globale Objekt, das alle Variablen und Objekte enthält.
• Object als allgemeiner Prototyp, von dem alle Objekte abgeleitet sind.
• Function als Prototyp für Funktionen.

...

nicht besser heißen:

JavaScript kennt mehrere eingebaute Objekttypen, die von ECMAScript definiert werden

• Das namenlose globale Objekt, das alle Variablen und Objekte enthält.
• Object, wobei Object.protoype als allgemeiner Prototyp fungiert, von dem alle Objekte abgeleitet sind.

...

Natürlich kann man noch darauf hinweisen, dass ein „Objekttyp“ eigentlich eine Klasse ist. Wichtig erscheint mir aber, zwischen cl (===cl.prototype.constructor) und cl.prototype zu unterscheiden, wenn cl für eine Konstruktorfunktion wie Object, Array, ... steht. --JavaScriptKiddie (Diskussion) 09:01, 14. Mär. 2018 (CET)