Frage zum Wiki-Artikel „Grundlagen der Programmierung“

[Philip]

Liebe JavaScript-Experten,

zu dem Tutorial habe ich eine Rückfrage: Im Beispiel 9 wird eine Variable "zahl" definiert.

'use strict';
  var eingabe,
      ergebnis,
      zahl,
      text;
 
  function wurzelZiehen(zahl) {
      ergebnis = Math.sqrt(zahl);
      return ergebnis;
  }
 
  eingabe = prompt('Bitte geben Sie eine Zahl ein!', eingabe);
 
  ergebnis = wurzelZiehen(eingabe);
  text = 'Die Wurzel von '+ eingabe +' ist ' + ergebnis;
  document.write(text);

Wozu dient diese Variable im Beispiel? Wenn ich sie weglasse und "eingabe" für Math.sqrt einsetze, dann liefert die Funktion genau das gleiche Ergebnis.

'use strict';
            
            var eingabe,
                ergebnis,
                text;
            
            function wurzelZiehen() {
                ergebnis = Math.sqrt(eingabe);
                return ergebnis;
            }
            
            eingabe = prompt('Zahl eingeben');
            
            ergebnis = wurzelZiehen(eingabe);
            text = "Die Wurzel von " + eingabe + " ist " + ergebnis + "."
            
            document.write(text);

Danke. Euer Feedback würde mir als Anfänger sehr helfen, um das zu 100% zu verstehen. 😀 Philip

[j4nk3y]

Hey,

Wozu dient diese Variable im Beispiel?

Stimmt, sieht etwas überflüssig aus.

Bzw. im Beispiel ist sie notwendig um sie für die Funktion zu initialisieren.

Gruß
Jo

[dedlfix]

Tach!

Wozu dient diese Variable im Beispiel?

Stimmt, sieht etwas überflüssig aus.

Bzw. im Beispiel ist sie notwendig um sie für die Funktion zu initialisieren.

Nein, in der Funktion wird sie als Parameter übergeben und steht damit zur Verfügung. Der Parameter überlagert innerhalb der Funktion auch die globale Variable zahl. zahl ist global überflüssig.

Und auch im Beispiel 10 waren Fehler drin. Lokale Variablen global angelegt, Funktionsergebnis nicht genutzt, stattdessen globale Variablen verwendet.

Ich hab das mal korrigiert. Insgesamt ist das für meinen Geschmack noch zu geschwätzig, mit zu vielen Variablen. Aber um dem Anfänger die einzelnen Schritte zu zeigen, mag es geeignet sein.

dedlfix.

[TS]

Hello,

Nein, in der Funktion wird sie als Parameter übergeben und steht damit zur Verfügung. Der Parameter überlagert innerhalb der Funktion auch die globale Variable zahl. zahl ist global überflüssig.

Und auch im Beispiel 10 waren Fehler drin. Lokale Variablen global angelegt, Funktionsergebnis nicht genutzt, stattdessen globale Variablen verwendet.

Ich hab das mal korrigiert. Insgesamt ist das für meinen Geschmack noch zu geschwätzig, mit zu vielen Variablen. Aber um dem Anfänger die einzelnen Schritte zu zeigen, mag es geeignet sein.

Dann sollte aber gerade DAS, was nun nicht mehr drin ist, erläutert werden. Woher soll ein Anfänger sonst wissen, warum hier so verfahren wird und eben nicht, wie gelöscht?

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Dann sollte aber gerade DAS, was nun nicht mehr drin ist, erläutert werden. Woher soll ein Anfänger sonst wissen, warum hier so verfahren wird und eben nicht, wie gelöscht?

Das muss allgemein erläutert werden, wenn Scopes erklärt werden.

dedlfix.

[TS]

Hello,

Dann sollte aber gerade DAS, was nun nicht mehr drin ist, erläutert werden. Woher soll ein Anfänger sonst wissen, warum hier so verfahren wird und eben nicht, wie gelöscht?

Das muss allgemein erläutert werden, wenn Scopes erklärt werden.

Es könnte mMn anhand dieses kleinen Beispiels schon fast genau so übernommen werden, wie Janosch das hier gepostet hat.

Und dann in der üblichen rot, gelb, grün hinterlegten Art, damit der schnelle Leser nicht doch aus Versehen das falsche Beispiel nimmt.

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Das muss allgemein erläutert werden, wenn Scopes erklärt werden.

Es könnte mMn anhand dieses kleinen Beispiels schon fast genau so übernommen werden, wie Janosch das hier gepostet hat.

Und dann in der üblichen rot, gelb, grün hinterlegten Art, damit der schnelle Leser nicht doch aus Versehen das falsche Beispiel nimmt.

Artikel mit Tutorial-Charakter brauchen einen roten Faden. Es braucht also vielleicht ein paar Minuten, um die Information ordentlich zu adaptieren - und um das genauer zu erklären als ich das auf die Schnelle jetzt getan habe. Scopes werden wahrscheinlich an anderer Stelle schon sinnvoll abgehandelt, das war imho, worauf dedlfix rauswollte.

Grüße,

RIDER

[TS]

Hello,

Und dann in der üblichen rot, gelb, grün hinterlegten Art, damit der schnelle Leser nicht doch aus Versehen das falsche Beispiel nimmt.

Artikel mit Tutorial-Charakter brauchen einen roten Faden. Es braucht also vielleicht ein paar Minuten, um die Information ordentlich zu adaptieren - und um das genauer zu erklären als ich das auf die Schnelle jetzt getan habe. Scopes werden wahrscheinlich an anderer Stelle schon sinnvoll abgehandelt, das war imho, worauf dedlfix rauswollte.

Das habe ich wohl verstanden!

Das ganze Wiki wird aber, wenn "immer alles woanders erklärt" wird, zu theoretisch. Ich vertrete die Meinung, dass anhand dieses niedlichen kleinen Beispiels die praktische__Bedeutung von Gültigkeitsbereichen durchaus nochmal gezeigt werden kann. Und generell sollte man das bei anderen Dingen genauso hlaten. Die theoretischen Grundlagen müssen sich in den Beispielen ganz deutlich wiederfinden lassen, und meistens muss man dafür auch zeigen, wie man es FALSCH machen kann.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Das ganze Wiki wird aber, wenn "immer alles woanders erklärt" wird, zu theoretisch. Ich vertrete die Meinung, dass anhand dieses niedlichen kleinen Beispiels die praktische__Bedeutung von Gültigkeitsbereichen durchaus nochmal gezeigt werden kann.

Die ganze Seite ist ein Einsteigertutorial. Die "andere Stelle" wäre also lediglich ein paar Absätze weiter oben, wenn es um Variablen geht.

dedlfix.

[TS]

Hello,

Das ganze Wiki wird aber, wenn "immer alles woanders erklärt" wird, zu theoretisch. Ich vertrete die Meinung, dass anhand dieses niedlichen kleinen Beispiels die praktische__Bedeutung von Gültigkeitsbereichen durchaus nochmal gezeigt werden kann.

Die ganze Seite ist ein Einsteigertutorial. Die "andere Stelle" wäre also lediglich ein paar Absätze weiter oben, wenn es um Variablen geht.

Ok, das wird dann vielleicht reichen. Ich mag aber trotzdem immer gerne auch die bewusst falschen Beispiele mit Erklärung dazu, warum man es SO nicht machen soll.

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@dedlfix

Die ganze Seite ist ein Einsteigertutorial.

In einem Einsteigertutorial document.write() zu verwenden ist wohl auch nicht state of the art. Um an anderer Stelle dann zu sagen, dass man das nicht verwenden sollte?

LLAP 🖖

[dedlfix]

Tach!

In einem Einsteigertutorial document.write() zu verwenden ist wohl auch nicht state of the art. Um an anderer Stelle dann zu sagen, dass man das nicht verwenden sollte?

Wie lautet dein Vorschlag, der sowohl State of the Art als auch bewusst einfach gehalten ist?

dedlfix.

[JürgenB]

Hallo,

In einem Einsteigertutorial document.write() zu verwenden ist wohl auch nicht state of the art. Um an anderer Stelle dann zu sagen, dass man das nicht verwenden sollte?

Wie lautet dein Vorschlag, der sowohl State of the Art als auch bewusst einfach gehalten ist?

querySelector("output").innerHTML = ...;

und im HTML dann ein output-Element, und das Javascript am Ende des body.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

querySelector("output").innerHTML = ...;

Oder innerText.

Und dem output-Element eine ID verpassen und es per querySelector("#…") selektieren. (Es könnte ja mehrere output-Elemente geben.)

LLAP 🖖

[JürgenB]

Hallo Gunnar,

… (Es könnte ja mehrere output-Elemente geben.)

in einem möglichst einfachen Beispiel nicht 😉.

Gruß
Jürgen

[dedlfix]

Tach!

querySelector("output").innerHTML = ...;

Oder innerText.

Ihr denkt schon wieder zu komplex, scheint mir. Habt ihr euch mal angeschaut, welche Umgebung auf der Seite bereits vorliegt? Jedenfalls kein HTML. Wenn ihr nun damit anfangt, die Ausgabe in HTML bringen zu wollen, muss man da erstmal ein HTML-Dokument erstellen. Und dann kommt die nächste Anforderung, dieses statt einfach ebenfalls State of the Art zu gestalten, inklusive Mobile First und barrierefrei und vielleicht soll es auch noch ansprechend aussehen ... Da kommt man vom Hundersten ins Tausendste, und dabei sollen hier erstmal nur die Grundlagen des Programmierens vermittelt werden und nicht gleich alles auf einmal.

Mein Vorschlag würde eher in Richtung Console gehen. Das ist ein Werkzeug, das man als Javascript-Programmierer sowieso kennen sollte. Auch die alert()s wären Kandidaten für das Umschreiben nach console.log(). Man kann das alert() ja einmal zeigen und dann auf die Alternative hinweisen und umschwenken.

Vorgehen im Fehlerfall ist auch so eine Geschichte, die in Tutorials gern unterschlagen wird. Das könnte man da ebenfalls hinzufügen. Man baut einen Syntaxfehler ein, eine weiße Seite erscheint. Und dann die Console einführen, als das Werkzeug, das die Fehlermeldungen ausgibt und auch besser für Debug-Ausgaben geeignet ist.

dedlfix.

[Camping_RIDER]

Aloha ;)

Mein Vorschlag würde eher in Richtung Console gehen. Das ist ein Werkzeug, das man als Javascript-Programmierer sowieso kennen sollte. Auch die alert()s wären Kandidaten für das Umschreiben nach console.log(). Man kann das alert() ja einmal zeigen und dann auf die Alternative hinweisen und umschwenken.

Ja. Es bleibt allerdings zu bedenken, dass gerade die Tutorials vielleicht auch an einem Tablet nachvollzogen werden, das keine JavaScript-Konsole bietet. Just saying.

innerText und innerHTML als DOM-Methoden gehen über das Grundlagen-Tutorial hinaus, da haben @dedlfix und @Matthias Scharwies vollkommen recht.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

innerText und innerHTML als DOM-Methoden gehen über das Grundlagen-Tutorial hinaus, da haben @dedlfix und @Matthias Scharwies vollkommen recht.

Nein, das sehe ich nicht so.

Wie man eine Ausgabe auf eine Seite bekommt – und zwar ohne die Seite neu zu laden –, ist schon etwas Grundlegendes. Grundlegender als wie man eine Wurzel zieht.

LLAP 🖖

[dedlfix]

Tach!

Wie man eine Ausgabe auf eine Seite bekommt – und zwar ohne die Seite neu zu laden –, ist schon etwas Grundlegendes. Grundlegender als wie man eine Wurzel zieht.

In dem Fall läuft das Javascript nur beim Laden der Seite. Warum genau soll es dabei nicht die Ausgabe erzeugen? Und was konkret ist an document.write() falsch, es während des Seitenladens zu verwenden?

An welcher Stelle würdest du die Grenze ziehen, was Grundlagen in einem Programmieren-Lernen-Tutorial sind und was nicht?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

An welcher Stelle würdest du die Grenze ziehen, was Grundlagen in einem Programmieren-Lernen-Tutorial sind und was nicht?

Vordringlichste Aufgabe von JavaScript ist es, Interaktivität auf Webseiten zu bringen, also das DOM zu ändern.

Wie man eine Ausgabe in ein Element bekommt, gehört für mich zu den Grundlagen – noch vor if und for-Schleifen.

LLAP 🖖

PS: Zeichensetzung matters.

[Felix Riesterer]

Lieber Gunnar,

PS: Zeichensetzung matters.

Komm' Opa essen!

Liebe Grüße,

Felix Riesterer.

[Julius]

Hallo Felix,

PS: Zeichensetzung matters.

Komm' Opa essen!

Ich finde „meine“ Variante^[1] besser:

Korrekte Kommasetzung rettet Leben:
„Komm wir essen Opa!“

Gruß
Julius

---

---

1. Ausgedacht habe ich mir die natürlich nicht, die habe ich mir bestimmt irgendwo geklaut.. ↩︎

[Julius]

Hallo Gunnar,

Vordringlichste Aufgabe von JavaScript ist es, Interaktivität auf Webseiten zu bringen, also das DOM zu ändern.

Als ich mich erstmals mit JavaScript beschäftigt habe, war für mich die Bedeutung von JavaScript (aka ECMAScript) und DOM nicht klar. Ich habe ein bisschen gebraucht, um zu verstehen, dass JavaScript die Programmiersprache ist und das DOM die Schnittstelle zum Dokument (HTML / XML). Das nur so als Feedback eines JavaScript-Noobs 😉

PS: Zeichensetzung matters.

Sprache aber auch. Ich verwende deutsche Begriffe, wo es passende und etablierte gibt – einen Laptop würde ich nicht „Klapprechner“ nennen, weil ersteres etabliert ist. (something) matters würde ich nicht als etabliert bezeichnen, weil das ein Deutsch-Sprechender „im Deutsch-Modus“^[1] wahrscheinlich nicht erkennt.

Gruß
Julius

---

---

1. Wenn jemand mit mir in Sprache X kommuniziert und dann völlig unerwartet (!) Wörter aus Sprache Y verwendet, dann habe ich da oft Probleme. In dem Moment hätte ich gerne eine Art lang="xy" im Alltag... ↩︎

[Camping_RIDER]

Aloha ;)

Ich hab das mal korrigiert.

Hast du auch gleich das var innerhalb der Funktion eingesetzt gegen Seiteneffekte?

Insgesamt ist das für meinen Geschmack noch zu geschwätzig, mit zu vielen Variablen. Aber um dem Anfänger die einzelnen Schritte zu zeigen, mag es geeignet sein.

Wenn ich heute gegen Abend irgendwie die Zeit finde schau ich mal über den ganzen Artikel. Grad bei den Anfängersachen müssen wir exakt und unmissverständlich sein. Die vielen Variablen sind das eine, aber in einer Funktion globale Variablen zu verändern, die dann den Rückgabewert nochmal zugewiesen bekommen ist völlig absurd.

Grüße,

RIDER

[dedlfix]

Tach!

Ich hab das mal korrigiert.

Hast du auch gleich das var innerhalb der Funktion eingesetzt gegen Seiteneffekte?

Ich haben das auf Nebenwirkungsfreiheit umgestellt. (Seiteneffekt ist ein aus einer falschen wörtlichen Übersetzung entstandenes Wort, das es eigentlich nicht gibt.)

Insgesamt ist das für meinen Geschmack noch zu geschwätzig, mit zu vielen Variablen. Aber um dem Anfänger die einzelnen Schritte zu zeigen, mag es geeignet sein.

Wenn ich heute gegen Abend irgendwie die Zeit finde schau ich mal über den ganzen Artikel. Grad bei den Anfängersachen müssen wir exakt und unmissverständlich sein. Die vielen Variablen sind das eine, aber in einer Funktion globale Variablen zu verändern, die dann den Rückgabewert nochmal zugewiesen bekommen ist völlig absurd.

Das ist raus. Ich hab aber nur die Beispiele angeschaut und auch nur geprüft, dass der Erläuterungstext darunter noch konform ist.

dedlfix.

[Camping_RIDER]

Aloha ;)

Ich hab das mal korrigiert.

Hast du auch gleich das var innerhalb der Funktion eingesetzt gegen Seiteneffekte?

Ich haben das auf Nebenwirkungsfreiheit umgestellt. (Seiteneffekt ist ein aus einer falschen wörtlichen Übersetzung entstandenes Wort, das es eigentlich nicht gibt.)

Haste Recht 😉 und Danke 😀

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

In diesem Fall kannst du die Wurzel einer beliebigen Zahl ziehen:

'use strict';
  var eingabe,
      ergebnis,
      zahl,
      text;
 
  function wurzelZiehen(zahl) {
      ergebnis = Math.sqrt(zahl);
      return ergebnis;
  }
 

Du kannst also aufrufen: wurzelZiehen(4) und bekommst 2 als Ergebnis. zahl ist der Parameter der Funktion wurzelZiehen, der es dir ermöglicht, da einen beliebigen Wert einzusetzen.

Hier:

'use strict';
            
            var eingabe,
                ergebnis,
                text;
            
            function wurzelZiehen() {
                ergebnis = Math.sqrt(eingabe);
                return ergebnis;
            }
            

...Kannst du immer nur die Wurzel von der Zahl ziehen, die in eingabe gespeichert ist.

Für diese kleine Stück Code ist das gleich. Da könnte man sich sogar die Definition der Funktion sparen. Sobald du das an anderer Stelle aber nochmal brauchst, das wurzelZiehen, wird es relevant.

Aber mit einer Sache hast du Recht:

Die globale Variable zahl ist überflüssig und kann weg.

Ich bin im Moment nir am Tablet und kanns deshalb nicht recht selber machen, vielleicht kann @Matthias Scharwies oder ein anderer Beispiel-Admin das übernehmen, wenn er das hier sieht:

Der Code des Beispiels sollte mMn (wenn es nicht mit um einen Aspekt geht, der aus dem Posting hier nicht ersichtlich wird) lauten:

'use strict';
  var eingabe,
      ergebnis,
      text;
 
  function wurzelZiehen(zahl) {
      var ergebnis = Math.sqrt(zahl);
      return ergebnis;
  }
 
  eingabe = prompt('Bitte geben Sie eine Zahl ein!', eingabe);
 
  ergebnis = wurzelZiehen(eingabe);
  text = 'Die Wurzel von '+ eingabe +' ist ' + ergebnis;
  document.write(text);

zahl als Funktionsparameter hat bei den globalen Variablen nix verloren und ergebnis in der Funktion wurzelZiehen muss sich via Neudefinition im Funktionsscope vom globalen ergebnis unterscheiden, sonst gibts potenziell unerwünschte Seiteneffekte.

Grüße,

RIDER

[Matthias Scharwies]

Servus!

Aloha ;)

Aber mit einer Sache hast du Recht:

Die globale Variable zahl ist überflüssig und kann weg.

Ich bin im Moment nir am Tablet und kanns deshalb nicht recht selber machen, vielleicht kann @Matthias Scharwies oder ein anderer Beispiel-Admin das übernehmen, wenn er das hier sieht:

Leider Nein. Bin auch unterwegs und erst am Sonntagabend wieder daheim.

Generell geht's mir schon wieder gegen den Strich, dass jeder ein paar Verbesserungsvorschläge hat, wie man's anders machen sollte, ausser @dedlfix aber keiner gesehen hat, dass es hier erst mal um die Grundlagen geht. Das mit der Konsole ist ein guter Vorschlag, da gibts auch nen Artikel dazu, der aber nicht kontextualisiert ist.

Die Ausgabe mittels innerHTML oder textContent ist Thema des Nachfolgeartikel "Grundlagen des DOM".

Wer dieses Tutorial verbessern oder ein eigenes schreiben will, herzlich willkommen -es ist ein Wiki.

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

Ich bin im Moment nir am Tablet und kanns deshalb nicht recht selber machen, vielleicht kann @Matthias Scharwies oder ein anderer Beispiel-Admin das übernehmen, wenn er das hier sieht:

Leider Nein. Bin auch unterwegs und erst am Sonntagabend wieder daheim.

dedlfix hat es ja schon übernommen.

Generell geht's mir schon wieder gegen den Strich, dass jeder ein paar Verbesserungsvorschläge hat, wie man's anders machen sollte, ausser @dedlfix aber keiner gesehen hat, dass es hier erst mal um die Grundlagen geht.

Ich hab das auch gesehen 😉

Wer dieses Tutorial verbessern oder ein eigenes schreiben will, herzlich willkommen -es ist ein Wiki.

Das war mir zumindest von Anfang an klar 😉

Grüße,

RIDER

[Felix Riesterer]

Lieber Camping_RIDER,

Die globale Variable zahl ist überflüssig und kann weg.

und was ist mit document.write auf der Seite?

Ich bin im Moment nir am Tablet und kanns deshalb nicht recht selber machen,

Auf der Seite gehört so einiges geändert. Momentan habe ich dafür aber leider zu wenig Zeit. Eine sinnvolle Überarbeitung verwendet DOM-Methoden anstelle von document.write, nutzt Variablen nur wo notwendig, bedient sich des Scopes - und erklärt auch alles hübsch der Reihe nach. Daher ist das ein größeres Stück Arbeit, das ich erst in zwei Wochen angehen könnte. Es sei denn jemand ist schneller.

Liebe Grüße,

Felix Riesterer.

[Camping_RIDER]

Aloha ;)

Die globale Variable zahl ist überflüssig und kann weg.

und was ist mit document.write auf der Seite?

Das Eine ist eine Unzulänglichkeit im Code, die Verwirrung stiftet und ohne größere Nacharbeit einfach weggelassen werden kann.

Das Andere ist eine nicht-empfehlenswerte Methode zur Codeausgabe, die aber immerhin simpel ist und deren Weglassung oder Veränderung weitreichendere Folgen für die Strukturierung des Grundlagenartikels hat.

Kleine Änderungen kann ich auf die Schnelle machen. Für große Veränderungen oder Neufassungen fehlt mir - wie dir - die Zeit; und ich möchte sowas wie document.write nicht monieren^[1], ohne selber was dran tun zu können, weil sich @Matthias Scharwies sonst völlig zurecht fragt, warum eigentlich immer alle meckern und nie jemand was tut^[2].

Eine sinnvolle Überarbeitung [...ist...] ein größeres Stück Arbeit, das ich erst in zwei Wochen angehen könnte. Es sei denn jemand ist schneller.

Ich bin sicher, dass uns der Artikel nicht innerhalb der nächsten zwei Wochen wegläuft, so oder so 😉

Grüße,

RIDER

---

1. Ich weiß nichtmal ob ich document.write überhaupt monieren würde - für ein Anfängertutorial halte ich es für sinnvoll, einfache Mittel zu verwenden, und von den Genannten hat mich nur der mit der Konsole (einigermaßen) überzeugt, der bedeutet aber auch wieder Overhead für den Lernwilligen - auch wenn dieser Overhead an der Stelle sogar begründet ist. ↩︎

2. Bitte nicht persönlich nehmen, der Vorwurf ist nicht auf dich gemünzt; wir beide tun ja immer mal wieder was, wie es eben die Zeit erlaubt, du noch mehr als ich, und das ist mir bewusst - aber im Rundumschlag gegen alle Mitleser stimmt der Vorwurf ja trotzdem. ↩︎

[Rolf b]

Angesichts der Tatsache, dass "Grundlagen der Programmierung" direkt hinter dem Erstgebrauch von document.write darauf hinweist, dass man das eigentlich nicht so macht und auch gleich auf den Folgeartikel verlinkt, wo das richtige Vorgehen beschrieben ist, würde ich gegen document.write keine Einwände erheben.

Es ist ein Henne-Ei Problem. Wenn man gleich mit Ausgaben ins DOM anfangen will, muss man zunächst einmal die Basics des DOM API erklären. Dafür muss man aber auch ein bisschen über's Programmieren wissen. Und um einen Anfänger nicht zu überfordern, um Schritt für Schritt vorzugehen, muss man eins von beiden erstmal weglassen.

Natürlich könnte man auch so vorgehen, den Anfänger nicht in den Texteditor zu schicken, sondern ihn auf Experimentierseiten wie Codepen.io oder jsfiddle.net. Dort kann man ebenfalls mit Skripten experimentieren, nur das Debuggen fällt dort schwerer (bzw. man muss erklären, wie man im Debugger seinen Code und sein HTML findet). Und sie bieten auch gleich Syntax-Highlighting und Ansätze von syntaktischer Code-Ergänzung.

Man könnte dann ein Vorlagen-Fiddle bzw. einen Vorlagen-Pen bereitstellen, den der Lerner einfach nur aufrufen muss. Darin bringt man die nötigen Basics unter und der Anfänger kann sofort loslegen. Zum Beispiel sowas hier. Die "ausgeben" Funktion habe ich im HTML "versteckt", um den Script-Bereich freizuhalten, man könnte auch auf selfhtml.org ein kleines Script mit Helferlein hinterlegen und es als externe Ressource in das Fiddle hängen.

Ob es mit Frickl auch funktionierte, weiß ich nicht - wenn ich ein existierendes Frickl aufrufe und darin experimentiere, funktioniert so etliches nicht wie erwartet (z.B. ein output id="ausgabe" Element lässt sich im Script nicht mit document.getElementById("ausgabe") finden).

Rolf

[Matthias Scharwies]

Servus!

Man könnte dann ein Vorlagen-Fiddle bzw. einen Vorlagen-Pen bereitstellen, den der Lerner einfach nur aufrufen muss. Darin bringt man die nötigen Basics unter und der Anfänger kann sofort loslegen. Zum Beispiel sowas hier.

Ob es mit Frickl auch funktionierte, weiß ich nicht - wenn ich ein existierendes Frickl aufrufe und darin experimentiere, funktioniert so etliches nicht wie erwartet (z.B. ein output id="ausgabe" Element lässt sich im Script nicht mit document.getElementById("ausgabe") finden).

Hier ist Dein Beispiel im Wiki: SelfHTML Experimentierkasten

Das Frickl hat einige Eigenheiten. Einiges hab ich hier zusammengeschrieben: Hilfe:Artikel/Beispiele#Frickl

Die "ausgeben" Funktion habe ich im HTML "versteckt", um den Script-Bereich freizuhalten, ...

Das würde imho auch gehen, ich hab's trotzdem mal im Scriptbereich im head zusammengefasst.

...man könnte auch auf selfhtml.org ein kleines Script mit Helferlein hinterlegen und es als externe Ressource in das Fiddle hängen.

wär imho schon wieder zu kompliziert. Die Anfänger sollen doch sehen, was wie passiert.

Rolf

Herzliche Grüße

Matthias Scharwies

[Rolf b]

Ja, damit kann man experimentieren, aber diesen Aufbau halte ich für didaktisch ungünstig. Der Anfänger sollte einen sauberen Bereich haben, wo nichts steht außer seinem eigenen Skript. Dadurch kann sie oder er nichts an der Infrastruktur kaputtmachen. Das ist sicherlich nicht trivial. Ich hatte eben mal versucht, diesen Teil in einen eigenen Script-Block auszulagern, aber das wird von Frickl beim Öffnen wieder zu einem Block kombiniert.

Bei jsfiddle sorgt der Fiddle selbst für den Start über onLoad (sofern man nichts verstellt). Im Frickl ist diese Logik sichtbar und darf nicht beschädigt werden, sonst funkt nichts mehr. Sozusagen ein Experimentierkasten mit frei aufgebautem 240V-Netzteil. Man kann natürlich sagen, dass ein JS Programmierer lernen muss, diese Infrastruktur zu verstehen...

Ich baue das mal ein kleines bisschen um, um das Netzteil etwas vom Spielplatz zu isolieren.

Rolf

[Matthias Scharwies]

Servus!

Ja, damit kann man experimentieren, aber diesen Aufbau halte ich für didaktisch ungünstig. Der Anfänger sollte einen sauberen Bereich haben, wo nichts steht außer seinem eigenen Skript. Dadurch kann sie oder er nichts an der Infrastruktur kaputtmachen. Das ist sicherlich nicht trivial. Ich hatte eben mal versucht, diesen Teil in einen eigenen Script-Block auszulagern, aber das wird von Frickl beim Öffnen wieder zu einem Block kombiniert.

Bei jsfiddle sorgt der Fiddle selbst für den Start über onLoad (sofern man nichts verstellt). Im Frickl ist diese Logik sichtbar und darf nicht beschädigt werden, sonst funkt nichts mehr. Sozusagen ein Experimentierkasten mit frei aufgebautem 240V-Netzteil. Man kann natürlich sagen, dass ein JS Programmierer lernen muss, diese Infrastruktur zu verstehen...

Ich baue das mal ein kleines bisschen um, um das Netzteil etwas vom Spielplatz zu isolieren.

Schließ dich mal mit @Felix Riesterer kurz, der das Frickl entworfen hat.

Rolf

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Servus!

und was ist mit document.write auf der Seite?

Ich bin im Moment nir am Tablet und kanns deshalb nicht recht selber machen,

Auf der Seite gehört so einiges geändert.

@dedlfix @Rolf b Vielen Dank für Eure Korrekturen!

@Felix Riesterer Als ich vor 3 Jahren bei SelfHTML angefangen habe, war das da:

Grundlagen_der_Programmierung&oldid=15973

Dies war die Grundlage für die Trennung in Einführung in die Programmierlogik, den ich mit @Der-Dennis zusammen konzipiert habe, und den vorliegenden Artikel.

Ich habe die JavaScript/Tutorials so aufgebaut, dass in der linken Spalte die Grundlagen, die ihr so vermisst habt, stehen:

Grundlagen

• Einbindung in HTML
• Der strenge Modus (strict mode)
• Performance-Optimierung
• Debuggen für Anfänger

In der Einführung zu Grundlagen der Programmierung steht: "In diesem Tutorial soll es nicht um die Einbindung von JavaScript in HTML gehen, sondern zeigen, wie Sie einfache Programme erstellen. Der Artikel Programmierlogik behandelt die Grundlagen der Programmierung anhand eines Programmablaufplans."

Deshalb halte ich eine Ausgabe mit alert() oder document.write() hier für gerechtfertigt. Alles weitere wird im Einbindung-Artikel und im Grundlagen des DOM-Artikel, auf den mehrmals verwiesen wird, erklärt. Das sehen jetzt neben dedlfix und @Camping_RIDER wohl auch Rolf b so.

Was imho wirklich noch fehlt, wären:

• ein Tutorial, der anstatt die Konsolen-Methoden nur vorzustellen, das Debuggen anhand einer wirklichen Problemstellung erklärt.
• ein Tutorial, das Helferfunktionen zur dynamischen Erzeugung von Elementen vorstellt
• Grundlagen von Strings und Arrays
• Grundlagen der OOP

Dabei sollte man folgende Grundsätze berücksichtigen:

• ansprechende Themenstellung und Kontextualisierung
• didaktische Reduktion
• zeitliche Beschränkung (in der Schule 45/ 90 Minuten, im Wiki vielleicht nur 10 Abschnitte)

Während viele englische Artikel eine geschätzte Lesezeit von 2-15min erwähnen, werden unsere Tutorials immer länger, weil jeder noch dies und das hinzufügt. Hier sollten wir mehr mit Verlinkungen, evtl auch mit der Hauptartikel-Vorlage arbeiten.

{{Hauptartikel|JavaScript/Tutorials/anderer Artikel}}

Auch wenn es ein Wiki ist, an dem jeder Artikel nach Belieben ändern kann und darf, bitte ich doch meine Einteilung / Grundkonzept bei Euren Änderungen zu berücksichtigen.

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Servus!

@Felix Riesterer Als ich vor 3 Jahren bei SelfHTML angefangen habe, war das da:

[Grundlagen_der_Programmierung&oldid=15973](https://wiki.selfhtml.org/wiki/JavaScript/Tutorials/Einf%C3%BChrung)

Sorry, da ist mir der Link verrutscht:

richtig: Grundlagen_der_Programmierung&oldid=15973

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

In der Einführung zu Grundlagen der Programmierung steht: "In diesem Tutorial soll es nicht um die Einbindung von JavaScript in HTML gehen, sondern zeigen, wie Sie einfache Programme erstellen. […]"

Deshalb halte ich eine Ausgabe mit alert() oder document.write() hier für gerechtfertigt.

Das ist keine Begründung. Wie die Augabe auf den Bildschirm kommt, hat nichts mit Einbindung von JavaScript in HTML zu tun (dort geht es ums script-Element und dessen Plazierung).

Alles weitere wird im Einbindung-Artikel und im Grundlagen des DOM-Artikel, auf den mehrmals verwiesen wird, erklärt.

Das klingt wie „Wir zeigen euch erstmal, wie man ein Programm erstellt, so mit allem PiPAPo. Wozu man das dann verwenden kann, dat krieje mer nächstet Jahr.“

Wird hier das Pferd von hinten aufgezäumt‽

Was imho wirklich noch fehlt, wären:

Was in deiner Liste fehlt:

• Grundlagen sinnvollen JavaScripts, wo bspw. erklärt wird, dass man keine nicht-interaktiven Elemente als Zielelemente von click-Events verwenden darf, damit die Seite/Webapp für alle benutzbar ist.

Während viele englische Artikel eine geschätzte Lesezeit von 2-15min erwähnen, werden unsere Tutorials immer länger, weil jeder noch dies und das hinzufügt. […]

Auch wenn es ein Wiki ist, an dem jeder Artikel nach Belieben ändern kann und darf, bitte ich doch meine Einteilung / Grundkonzept bei Euren Änderungen zu berücksichtigen.

Dass ich ein Wiki, in dem jeder mitschreiben darf, für kein geeignetes Werkzeug halte, um vernünftige Tutorials zu verfassen, hatte ich damals schon im Tic-Tac-Toe-Thread thematisiert.

LLAP 🖖

[Tabellenkalk]

Hallo,

Dass ich ein Wiki, in dem jeder mitschreiben darf, für kein geeignetes Werkzeug halte, um vernünftige Tutorials zu verfassen, hatte ich damals schon im Tic-Tac-Toe-Thread thematisiert.

Was wäre denn für dich ein geeignetes Werkzeug, mit dem du Tutorials schreiben würdest?

@Christian Kruse: gibt es die Forensoftware her, ein weiteres Forum, neben SELF und Meta, anzulegen? Quasi ein Tutorial-Forum, in dem nur der TO antworten kann, um nach und nach das Tutorium zu erstellen?

Weiß nicht ob diese Idee was ist, kam mir hier grad so in den Sinn.

Gruß
Kalk

[Matthias Apsel]

Hallo Tabellenkalk,

@Christian Kruse: gibt es die Forensoftware her, ein weiteres Forum, neben SELF und Meta, anzulegen?

Ja.

Quasi ein Tutorial-Forum, in dem nur der TO antworten kann, um nach und nach das Tutorium zu erstellen?

Das verstehe ich nicht.

Bis demnächst
Matthias

[Tabellenkalk]

Hallo,

Quasi ein Tutorial-Forum, in dem nur der TO antworten kann, um nach und nach das Tutorium zu erstellen?

Das verstehe ich nicht.

Gunnar hat ein Problem damit, im Wiki Tutorials zu erstellen, weil(?) er meint, zuviele Köche das Tutorium zu Brei kochen würden, oder so.
Daher habe ich überlegt, was denn ein alternatives <del>Faktum</del>, äh Werkzeug wäre, und ob es mit Vorhandenem umsetzbar wäre.

Gruß
Kalk

[Matthias Apsel]

Hallo Tabellenkalk,

Gunnar hat ein Problem damit, im Wiki Tutorials zu erstellen, weil(?) er meint, zuviele Köche das Tutorium zu Brei kochen würden, oder so.

Das wäre aber auch nach dem Kochen immer noch möglich.

Daher habe ich überlegt, was denn ein alternatives <del>Faktum</del>, äh Werkzeug wäre, und ob es mit Vorhandenem umsetzbar wäre.

Am einfachsten wäre der eigene Benutzernamensraum im Wiki.

Bis demnächst
Matthias

[Tabellenkalk]

Hallo,

Am einfachsten wäre der eigene Benutzernamensraum im Wiki.

Das stimmt. Mal gucken, ob @Gunnar Bittersmann meine Frage beantwortet.

Gruß
Kalk

[Felix Riesterer]

Lieber Tabellenkalk,

Mal gucken, ob @Gunnar Bittersmann meine Frage beantwortet.

meiner Erfahrung nach wird er das nicht tun.

Liebe Grüße,

Felix Riesterer.

[Tabellenkalk]

Hallo,

Mal gucken, ob @Gunnar Bittersmann meine Frage beantwortet.

meiner Erfahrung nach wird er das nicht tun.

dasjadoof

Gruß
Kalk

[Matthias Scharwies]

Servus!

Gunnar hat ein Problem damit, im Wiki Tutorials zu erstellen, weil(?) er meint, zuviele Köche das Tutorium zu Brei kochen würden, oder so.
Daher habe ich überlegt, was denn ein alternatives <del>Faktum</del>, äh Werkzeug wäre, und ob es mit Vorhandenem umsetzbar wäre.

Der Self-Blog

Dort Geschriebenes kann nur vom Autor (und Matthias Apsel) verändert werden.

Kommentare können erstellt werden, müssen aber freigeschaltet werden.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Tabellenkalk

Dass ich ein Wiki, in dem jeder mitschreiben darf, für kein geeignetes Werkzeug halte, um vernünftige Tutorials zu verfassen, hatte ich damals schon im Tic-Tac-Toe-Thread thematisiert.

Was wäre denn für dich ein geeignetes Werkzeug, mit dem du Tutorials schreiben würdest?

Mit „Werkzeug“ habe ich wohl eine unglückliche Wortwahl getroffen; „Mittel“ wäre angebrachter. Fast dasselbe, doch ein kleiner, aber feiner Unterschied.

Der entscheidende Teil war nicht „Wiki“, sondern „in dem jeder mitschreiben darf“. Ob das nun als Wiki realisiert ist oder als Artikel auf Github, wo jeder Textänderungen reincommitten darf, ist hier irrelevant. (Wiki oder Github wären hier Werkzeuge.)

Ein Tutorial sollte einen roten Faden haben und stilistisch einheitlich sein. Bei einer Autorenschaft, wo jeder Wortfetzen von jemandem anderen stammen kann, ist das nicht gegeben.

Ich will keinesfalls sagen, dass sich andere nicht einbringen können sollten. Kollektives Brainstorming ist natürlich völlig OK und sinnvoll. Nur schreiben sollte es einer (oder wenige).

LLAP 🖖

[Camping_RIDER]

Aloha ;)

In der Einführung zu Grundlagen der Programmierung steht: "In diesem Tutorial soll es nicht um die Einbindung von JavaScript in HTML gehen, sondern zeigen, wie Sie einfache Programme erstellen. […]"

Deshalb halte ich eine Ausgabe mit alert() oder document.write() hier für gerechtfertigt.

Das ist keine Begründung. Wie die Augabe auf den Bildschirm kommt, hat nichts mit Einbindung von JavaScript in HTML zu tun (dort geht es ums script-Element und dessen Plazierung).

Vielleicht ist Einbindung an der Stelle das falsche Wort. Einbettung trifft es hier vielleicht eher.

Alles weitere wird im Einbindung-Artikel und im Grundlagen des DOM-Artikel, auf den mehrmals verwiesen wird, erklärt.

Das klingt wie „Wir zeigen euch erstmal, wie man ein Programm erstellt, so mit allem PiPAPo. Wozu man das dann verwenden kann, dat krieje mer nächstet Jahr.“

Wird hier das Pferd von hinten aufgezäumt‽

Überhaupt nicht. Es wurde schon mehrfach festgestellt, dass man sich für ein Anfängertutorial entscheiden muss, wo man anfängt, und was man in folgende Kapitel auslagert. Die Entscheidung, die Einbettung von JavaScript in den Kontext HTML inklusive DOM und Co. nicht im Anfängertutorial, sondern in einem nachfolgenden Artikel zu thematisieren und sich im Grundlagentutorial auf Syntax und grundlegende Sprachelemente zu beschränken ist vollkommen legitim.

Dass ich ein Wiki, in dem jeder mitschreiben darf, für kein geeignetes Werkzeug halte, um vernünftige Tutorials zu verfassen, hatte ich damals schon im Tic-Tac-Toe-Thread thematisiert.

Und im selben Thread hatten wir, meine ich, auch schon festgestellt, dass es unüberbrückbare Differenzen dahingehend gibt, wie umfangreich (nicht im Sinne von Textlänge, sondern im Sinn enthaltener neuer Konzepte und enthaltenen Lernstoffes) und motivierend ein Anfängertutorial zu sein hat 😉

Ich meine als eine persönliche Quintessenz dieser Diskussion im Kopf zu haben, dass du fachlich, vor allem, wenn es um Belange des Nutzers geht^[1], ein Experte bist, von dem man viel lernen kann, dass du aber auch kein guter Lehrer bist, weil dir einfach vorkommende Konzepte für Anfänger Schwierigkeiten darstellen, die du nicht siehst, und weil dir als Experte ein Streben nach Perfektion innewohnt, das mit einem Tutorial für blutige Anfänger überhaupt nicht vereinbar ist.

Als Lehrender muss man lernen, dass man je nach Stand der Lerner verschiedene Abstriche bewusst machen muss, auch an Dingen, die fachlich gesehen elementar erscheinen. Das ist eine Sichtweise, die nicht nur dir, sondern aus meiner persönlichen Erfahrung heraus auch der Mehrheit der Universitätsprofessoren sehr schwerfällt. Das mag bei den Universitätsprofessoren auch mit ein Sinn der Sache sein - darauf vertrauen, dass die Lerner intrinsisch motiviert sind und selbst ihren Lernfortschritt kontrollieren, und es ermöglicht eine sehr hohe Dichte von Stoff in kurzer Zeit.

Nun ist aber ein Tutorial kein adäquater Vergleich für eine Vorlesung. Ein Blog eines Web-Experten, der aus seiner Sicht heraus und ohne dabei zu sehr auf alle Leser eingehen zu wollen über ein Thema referiert, das ist das Äquivalent zur Vorlesung. Wo man von Experten lernen kann, indem man sie bei ihrem Tun und ihren Erläuterungen dazu beobachtet. Ein Tutorial ist sehr viel vergleichbarer mit Schulunterricht oder dem gängigen Tutorium, das von Studenten höherer Semester gehalten wird - hier setzt man die intrinsische Motivation nicht voraus, sondern man versucht, die Lerner mitzuziehen und selbst zu motivieren. Man macht fachliche Abstriche, zumindest zeitweise, und auch manchmal an grundlegenden Stellen, um sicherzustellen, dass alle Lerner auch mitkommen.

Ich würde nicht wollen, dass die von mir besuchten Tutorien von Professoren gehalten werden, die so sehr in fachlichen Sphären schweben, dass sie meine Bedürfnisse als Nicht-Wissender überhaupt nicht mehr nachvollziehen können. Vielleicht ist es mit dir als Experte und Perfektionist in Bezug auf Tutorials für Anfänger ähnlich gelagert. Ich würde mir nicht ohne Weiteres zutrauen, vor anderen mit fachlicher Ahnung so viel Bestand zu haben, dass ich irgendwo einen Vortrag halten würde. Zumindest nicht ohne extreme Vorbereitungszeit. Oder dass ich über Webentwicklung bloggen würde. Dir hingegen traue ich das sofort zu. Tust du ja auch. Dafür halte ich mich für sehr gut in der Lage, fachlichen Inhalt, den ich von Experten wie dir mitbekomme, so herunterzubrechen und zu portionieren, dass er für jeden verständlich ist. Vielleicht muss man einfach an manchen Stellen eingestehen, dass nicht jeder alles kann. 😉

Grüße,

RIDER

---

1. Ich ahne voraus, dass du genau an dieser Stelle ein großes Verlangen spüren wirst, mir zu widersprechen und zu sagen, dass es immer um die Belange des Nutzers geht. Genau das ist aber mit eine Manifestation des Problems. ↩︎

[Camping_RIDER]

Aloha ;)

Vielleicht muss man einfach an manchen Stellen eingestehen, dass nicht jeder alles kann. 😉

Ich möchte betonen, dass das kein „du hast keine Ahnung von Tutorials, also halt dich da raus“ sein soll. Ganz im Gegenteil. Wie Tutorien im Rahmen einer Vorlesung stattfinden sind auch Tutorials immer fest mit dem Expertenwissen verknüpft. Und es ist für uns, die wir mehr Vermittler als Experten sind, auch immer mal wieder ganz wichtig, von Experten auf die Füße getreten zu werden um Qualität zu halten und sicherzustellen, dass wir uns noch auf dem rechten Pfad in Richtung Expertenwissen befinden. Deshalb ist es gut und richtig, dass du immer wieder Tutorials für fachliche Unzulänglichkeiten kritisierst, um denen, die vermitteln, die Gelegenheit zu geben, innezuhalten und darüber zu reflektieren, ob die Art und Weise der Vermittlung geeignet gewählt war. Ich bin sicher, dass es diesen Anstoß braucht - ich bin aber auch sicher, dass ein Anstoß genügt, und dass man nach diesem Anstoß darauf vertrauen kann, dass die, die das mit der Vermittlung draufhaben, das dann auch richtig beurteilen. So wie eben auch bei Tutorien eine Form der Qualitätskontrolle durch den Professor stattfinden und wie eben auch bei Tutorien eine Art Weisungsbefugnis vorliegt, muss auch bei Tutorien die letzte Entscheidung darüber, wie eine geeignete Vermittlung aussieht, beim Tutor liegen.

Das ist ein schmaler Grat. Ich habe alle drei Fälle kennengelernt. Ich hatte gute Tutorien, die fachlichen Anspruch hatten und trotzdem in der Lage waren, den Stoff geeignet herunterzubrechen und schrittweise durchzunehmen. Ich hatte Tutorien, bei denen der Tutor schon so sehr auf der Expertenebene verankert war, dass er einfach überhaupt nicht zu mir durchgedrungen ist, weil er sich meine Schwierigkeiten gar nicht vorstellen konnte. Und ich hatte Tutorien, in denen ich nichts, aber auch gar nichts gelernt habe, weil der Tutor selbst viel zu wenig Ahnung hatte und sich viel zu wenig am fachlichen Stoff orientiert hat. Deshalb bin ich überzeugt davon, dass die Qualitätssicherung durch geeignete Innehalt-Signale durch Experten wichtig ist, aber auch nicht Überhand nehmen darf, weil sowohl bei Fehlen als auch bei übermäßiger Präsenz die Lernerfahrung stark eingeschränkt ist.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Es wurde schon mehrfach festgestellt, dass man sich für ein Anfängertutorial entscheiden muss, wo man anfängt, und was man in folgende Kapitel auslagert.

Natürlich.

Die Entscheidung, die Einbettung von JavaScript in den Kontext HTML inklusive DOM und Co. nicht im Anfängertutorial, sondern in einem nachfolgenden Artikel zu thematisieren und sich im Grundlagentutorial auf Syntax und grundlegende Sprachelemente zu beschränken ist vollkommen legitim.

Auch das. Es war aber auch nirgends die Rede davon, in dem Artikel das DOM zu thematisieren.

Es war die Rede davon, in den Codebeispielen nicht document.write(), sondern innerText zu verwenden – nicht mehr und nicht weniger.

Spräche denn was dagegen, es gleich richtig zu machen? IMHO nein, das ist nicht komplizierter.

LLAP 🖖

[Der-Dennis]

Hallo Matthias,

Dies war die Grundlage für die Trennung in Einführung in die Programmierlogik, den ich mit @Der-Dennis zusammen konzipiert habe, und den vorliegenden Artikel.

da fällt mir gerade ein, dass ich noch einen UML-Artikel schuldig bin. In den nächsten Wochen hab ich etwas Luft und werde mich daran setzen.

Ich habe die JavaScript/Tutorials so aufgebaut, dass in der linken Spalte die Grundlagen, die ihr so vermisst habt, stehen:

Grundlagen

• Einbindung in HTML
• Der strenge Modus (strict mode)
• Performance-Optimierung
• Debuggen für Anfänger

Top!

Deshalb halte ich eine Ausgabe mit alert() oder document.write() hier für gerechtfertigt.

Ich finde das auch nach wie vor ok. Es geht hier um absolute Anfänger, da sollte alles so einfach wie möglich gehalten werden. Sowas wie alert hat den Vorteil, dass man direkt etwas sieht. Auch wenn es Dinge wie die Konsole in der heutigen Form früher noch nicht gab, als ich angefangen hab, denke ich, dass mich das nur verwirrt hätte bzw. zu viel des Guten gewesen wäre. Dem Großteil dürfte das heute bestimmt noch ähnlich gehen.

Meiner Meinung nach muss man sich davon verabschieden, dass man etwas direkt nach allen Regeln der Kunst vermitteln kann. Der Grundsatz, dass Leute alles direkt richtig lernen sollen, ist zwar gut; in der Praxis funktioniert das aber nicht. Lernen findet insbesondere am Anfang normalerweise in kleinen Schritten statt. Da werden dann auch Umwege in Kauf genommen, einige Fehler muss jeder mal selbst gemacht haben und auch sonst gibt es viele Irrungen und Wirrungen. Ist doch ok, wenn es um das Lernen geht und am Ende eine neue Erkenntnis steht.

Nehmt als Beispiel die Layout-Tabellen: Klar, die sollten wir nicht in einem Tutorial verwenden, aber es spricht doch nichts dagegen, wenn ein Anfänger das mal ausprobiert. Das geht schnell, ist anschaulich und verständlich. Und wenn am Ende die Erkenntnis steht, dass es in HTML Elemente gibt, die aus Start- (und End-)Tags bestehen und Attribute beinhalten ist es doch auch gut. So könnte man bspw. dann auch hier im Forum vorgehen: Statt „Ach Du Sch****, meine Augen, mach das weg!“ kann man auch sagen: „Du hast also herausgefunden, dass es Elemente gibt und Browser ein Standardverhalten haben, wie sie diese anzeigen. Z.B. kann ich Sachen nebeneinander und untereinander anordnen. Gut, nächster Schritt: Die Elemente haben aber auch eine Semantik. Du solltest also Element XY nehmen. Bei dem Element zeigt der Browser anderes Verhalten, deshalb Flexbox...“ usw. Und am Ende hat er seinen Layouttabellen-Prototypen semantisch korrekt umgesetzt und wieder was gelernt.

Wir dürfen halt nicht vergessen, dass jeder mal bei vollständig Null angefangen hat. Und in Zusammenhang mit HTML ist die erste Erkenntnis, dass es paarweise auftretende Tags gibt. Und das erste Mal fällt man auf die Nase, wenn man ein Bild einbinden will… 😉

Was imho wirklich noch fehlt, wären:

• ein Tutorial, der anstatt die Konsolen-Methoden nur vorzustellen, das Debuggen anhand einer wirklichen Problemstellung erklärt.
• ein Tutorial, das Helferfunktionen zur dynamischen Erzeugung von Elementen vorstellt
• Grundlagen von Strings und Arrays
• Grundlagen der OOP

JavaScript ist nicht mein absoluter Favorit, aber zumindest für einen ersten Wurf zu Strings, Arrays, OOP sollte es reichen. Nach dem UML-Artikel kann ich da mitarbeiten.

Während viele englische Artikel eine geschätzte Lesezeit von 2-15min erwähnen, werden unsere Tutorials immer länger, weil jeder noch dies und das hinzufügt. Hier sollten wir mehr mit Verlinkungen, evtl auch mit der Hauptartikel-Vorlage arbeiten.

Ich finde auch und hab das schon mehrfach erwähnt, dass (mich eingeschlossen) viel mehr verlinkt werden sollte. Das ist das WWW! Nehmen wir das Beispiel von oben: Man kann grundsätzlich auch gerne DOM-Methoden verwenden. Da braucht es auch keine weitere Erklärung zu. Ein einfacher Link zu einem DOM-Tutorial ist ausreichend.

Außerdem denke ich auch, dass die Artikel oft zu lang werden, weil wir alles an Ort und Stelle nochmal erklären wollen. Außerdem haben wir viel zu viele „Beachten Sie“, Beschreibungen von Ausnahmen oder „Wenn-Dann-Sonst“-Konstruktionen. Ich denke vor allem – aber nicht nur – bei den Einsteiger-Tutorials müssen wir uns davon verabschieden, jede denkbare Möglichkeit für jeden potenziellen Anwendungsfall und jede Fehlermöglichkeit beschreiben zu wollen. Das werden wir erstens nie schaffen und zweitens sind die Artikel nachher so kompliziert, dass sie zwar völlig richtig sind, aber niemand mehr irgendwas versteht.

Gruß
Dennis

[Camping_RIDER]

Aloha ;)

Danke für deine Ausführungen. Ich bin fast vollständig bei dir.

Ich finde auch und hab das schon mehrfach erwähnt, dass (mich eingeschlossen) viel mehr verlinkt werden sollte. Das ist das WWW! Nehmen wir das Beispiel von oben: Man kann grundsätzlich auch gerne DOM-Methoden verwenden. Da braucht es auch keine weitere Erklärung zu. Ein einfacher Link zu einem DOM-Tutorial ist ausreichend.

Jein. Bei einem Artikel stimme ich dir völlig zu. Bei einem (Anfänger-)Tutorial ist Verlinkung mit Vorsicht zu benutzen - imho sollte in einem Tutorial nur das verlinkt werden, was als gegeben vorausgesetzt wird, als Referenz zum Nochmal-nachlesen. Konzepte, die nach eingehender Überlegung für mindestens einen gewissen Teil der Leser als „noch nicht gelernt“ oder „neu“ einzustufen sind, sollten nicht im Lauf des Tutorials verlinkt werden. Grund ist der, dass man in einem Tutorial den Leser mitnehmen möchte und eine Ablenkung zwischendrin nur dann sinnvoll ist, wenn sie einem „schnell nachlesen“ gleichkommt. Sobald eine Verlinkung geeignet ist, einem Leser Konzentration abzuverlangen, verliert er den Fokus auf das Tutorial und zäumt dann vielleicht tatsächlich das Pferd von hinten auf. Hier ist in Tutorials mMn Vorsicht und Augenmaß geboten. Viele Verlinkungen sind in Tutorials entweder am Anfang („Vorwissen, das zum Verständnis des Tutorials vorausgesetzt wird: …“) oder am Ende („Wenn Sie mehr über xyz erfahren sollen, lesen sie hier“) angebrachter als im Fließtext, einfach aufgrund didaktischer Gesichtspunkte.

Dass viel mehr Verlinkungen stattfinden sollten, damit hast du natürlich vollkommen Recht (nur eben nicht zwangsläufig im Verlauf der Tutorials).

Außerdem denke ich auch, dass die Artikel oft zu lang werden, weil wir alles an Ort und Stelle nochmal erklären wollen. Außerdem haben wir viel zu viele „Beachten Sie“, Beschreibungen von Ausnahmen oder „Wenn-Dann-Sonst“-Konstruktionen. Ich denke vor allem – aber nicht nur – bei den Einsteiger-Tutorials müssen wir uns davon verabschieden, jede denkbare Möglichkeit für jeden potenziellen Anwendungsfall und jede Fehlermöglichkeit beschreiben zu wollen. Das werden wir erstens nie schaffen und zweitens sind die Artikel nachher so kompliziert, dass sie zwar völlig richtig sind, aber niemand mehr irgendwas versteht.

Richtig. Die Devise sollte dann aber in die Richtung gehen, dass man gerade bei Anfängertutorials scharfe inhaltliche Grenzen ziehen sollte und lieber zwei Tutorials als ein langes produzieren sollte. Die dürfen dann ja auch gerne aufeinander als „Vorwissen“ bzw. „Weiterführendes“ verweisen.

Grüße,

RIDER

[Der-Dennis]

Hallo Camping_RIDER,

Ich finde auch und hab das schon mehrfach erwähnt, dass (mich eingeschlossen) viel mehr verlinkt werden sollte. Das ist das WWW! Nehmen wir das Beispiel von oben: Man kann grundsätzlich auch gerne DOM-Methoden verwenden. Da braucht es auch keine weitere Erklärung zu. Ein einfacher Link zu einem DOM-Tutorial ist ausreichend.

Jein. Bei einem Artikel stimme ich dir völlig zu. Bei einem (Anfänger-)Tutorial ist Verlinkung mit Vorsicht zu benutzen - imho sollte in einem Tutorial nur das verlinkt werden, was als gegeben vorausgesetzt wird, als Referenz zum Nochmal-nachlesen. Konzepte, die nach eingehender Überlegung für mindestens einen gewissen Teil der Leser als „noch nicht gelernt“ oder „neu“ einzustufen sind, sollten nicht im Lauf des Tutorials verlinkt werden.

ja, da hast Du vollkommen recht. Aber an der Stelle müssen wir aus meiner Sicht noch eine kleine Unterscheidung treffen, nämlich ob der Teil im Kontext des Tutorials relevant ist oder nicht. D.h. ob es ein Teil des Lernziels ist oder nicht. Möchte ich z.B. erklären was eine Schleife macht und nur genau eben das erklären, ist eine Ausgabe innerhalb der Schleife nebensächlich. Das braucht man an dieser Stelle (noch) nicht erklären, um zu vermitteln, wie eine Schleife funktioniert. Aus meiner Sicht ist dann eine reine Verlinkung und „an dieser Stelle einfach hinnehmen, dass es so ist; da drüben bzw. später erfährst Du mehr“ völlig ausreichend, da dies in diesem Zusammenhang und für die in diesem Kontext zu vermittelnden Inhalte nebensächlich ist.

Anders geht es insbesondere ganz am Anfang oft auch gar nicht, weil man immer wieder vor dem Henne-Ei-Dilemma steht. Manche Sachen bedingen sich einfach zu stark wechselseitig, als dass eine Entscheidung „erst das, dann das“ sinnvoll getroffen werden kann.

Im zweiten Fall, dass der Inhalt für den gerade vermittelten Aspekt elementar ist und noch nicht vorausgesetzt werden kann, stimme ich Dir natürlich vollkommen zu. Da ist eine Verlinkung nicht sinnvoll und stattdessen sollte die Thematik an Ort und Stelle behandelt werden.

Viele Verlinkungen sind in Tutorials entweder am Anfang („Vorwissen, das zum Verständnis des Tutorials vorausgesetzt wird: …“) oder am Ende („Wenn Sie mehr über xyz erfahren sollen, lesen sie hier“) angebrachter als im Fließtext, einfach aufgrund didaktischer Gesichtspunkte.

Stimme ich Dir auch vollständig zu. Wo es angebracht ist sollten wir dieses „Stilmittel“ häufiger anbringen.

Die Devise sollte dann aber in die Richtung gehen, dass man gerade bei Anfängertutorials scharfe inhaltliche Grenzen ziehen sollte und lieber zwei Tutorials als ein langes produzieren sollte. Die dürfen dann ja auch gerne aufeinander als „Vorwissen“ bzw. „Weiterführendes“ verweisen.

Sehe ich ebenfalls genauso. Da sind wir aber auf einem guten Weg und insbesondere @Matthias Scharwies zeigt das immer wieder. Er plädiert ja genau dafür, also immer nur ein sehr abgegrenztes Thema zu behandeln und aus meiner Sicht gelingt ihm das sehr gut. Ebenso wie die sinnvolle didaktische Reduktion und das herausarbeiten des eigentlichen Kerns des Themas, ohne etwas wichtiges zu vernachlässigen. Das ist halt eine Kunst für sich und man steht häufig vor einem Dilemma, was nun reingehört und was nicht.

Gruß
Dennis

[Camping_RIDER]

Aloha ;)

Aber an der Stelle müssen wir aus meiner Sicht noch eine kleine Unterscheidung treffen, nämlich ob der Teil im Kontext des Tutorials relevant ist oder nicht. D.h. ob es ein Teil des Lernziels ist oder nicht. Möchte ich z.B. erklären was eine Schleife macht und nur genau eben das erklären, ist eine Ausgabe innerhalb der Schleife nebensächlich. Das braucht man an dieser Stelle (noch) nicht erklären, um zu vermitteln, wie eine Schleife funktioniert. Aus meiner Sicht ist dann eine reine Verlinkung und „an dieser Stelle einfach hinnehmen, dass es so ist; da drüben bzw. später erfährst Du mehr“ völlig ausreichend, da dies in diesem Zusammenhang und für die in diesem Kontext zu vermittelnden Inhalte nebensächlich ist.

ACK.

Die Devise sollte dann aber in die Richtung gehen, dass man gerade bei Anfängertutorials scharfe inhaltliche Grenzen ziehen sollte und lieber zwei Tutorials als ein langes produzieren sollte. Die dürfen dann ja auch gerne aufeinander als „Vorwissen“ bzw. „Weiterführendes“ verweisen.

Sehe ich ebenfalls genauso. Da sind wir aber auf einem guten Weg und insbesondere @Matthias Scharwies zeigt das immer wieder. Er plädiert ja genau dafür, also immer nur ein sehr abgegrenztes Thema zu behandeln und aus meiner Sicht gelingt ihm das sehr gut.

Sehe ich genauso. Ich wollte auch mit keinem Wort die momentan geleistete Arbeit in Abrede stellen.

Grüße,

RIDER

[Der-Dennis]

Hallo Camping_RIDER,

Ich wollte auch mit keinem Wort die momentan geleistete Arbeit in Abrede stellen.

das hatte ich auch nicht so verstanden. Ich wollte an der Stelle nur gerne nochmal hervorheben, dass man sich meiner Meinung nach gut an Matthias orientieren kann, weil ihm die Gratwanderung ziemlich gut gelingt.

Gruß
Dennis

[Tabellenkalk]

Hallo,

Aber an der Stelle müssen wir aus meiner Sicht noch eine kleine Unterscheidung treffen, nämlich ob der Teil im Kontext des Tutorials relevant ist oder nicht. D.h. ob es ein Teil des Lernziels ist oder nicht.

ACK

Möchte ich z.B. erklären was eine Schleife macht und nur genau eben das erklären, ist eine Ausgabe innerhalb der Schleife nebensächlich. Das braucht man an dieser Stelle (noch) nicht erklären, um zu vermitteln, wie eine Schleife funktioniert.

IMHO ein unpassendes Bespiel. Eine Ausgabe ist so ziemlich das Grundlegendste beim Programmieren, geschätzte 99% aller Tutorials fangen mit „Hallo Welt!“, o.Ä. an. Sicher mag es Henne-Ei-Situationen geben, aber bei Schleife vs. Ausgabe ist es nicht der Fall.

Gruß
Kalk

[Der-Dennis]

Hallo Tabellenkalk,

Möchte ich z.B. erklären was eine Schleife macht und nur genau eben das erklären, ist eine Ausgabe innerhalb der Schleife nebensächlich. Das braucht man an dieser Stelle (noch) nicht erklären, um zu vermitteln, wie eine Schleife funktioniert.

IMHO ein unpassendes Bespiel. Eine Ausgabe ist so ziemlich das Grundlegendste beim Programmieren, geschätzte 99% aller Tutorials fangen mit „Hallo Welt!“, o.Ä. an. Sicher mag es Henne-Ei-Situationen geben, aber bei Schleife vs. Ausgabe ist es nicht der Fall.

das mit dem „Hallo Welt“ ist ja auch gut so. Aber über welche Ausgabe spreche ich jetzt hier? Alert, Konsole, DOM-Methoden, ...? Ich muss nicht gleich zu Anfang alle Ausgabeformen erklären. Ich wollte an der Stelle in dem Beitrag nur darauf hinaus, dass wenn ich mich an der Stelle dafür entscheide z.B. innerHtml als Ausgabeform zu verwenden und ich lediglich die Schleife erklären möchte, dann ist es ausreichend auf ein DOM-Tutorial zu verlinken. Ich muss an der Stelle nicht zuerst die Funktionsweise der gesamten DOM-Api erklären. Ich dachte das ging aus dem Kontext, aus dem Du das Zitat nahmst, sowie dem vorherigen Beitrag hervor.

Ist das so klarer, worauf ich hinaus wollte? Die Henne-Ei-Situationen wollte ich auch nicht auf die Schleife beziehen.

Gruß
Dennis

[Matthias Apsel]

Hallo Der-Dennis,

Nehmt als Beispiel die Layout-Tabellen: Klar, die sollten wir nicht in einem Tutorial verwenden, aber es spricht doch nichts dagegen, wenn ein Anfänger das mal ausprobiert. Das geht schnell, ist anschaulich und verständlich.

Das ist, denke ich ein schlechtes Beispiel. Eine Layout-Tabelle ist alles andere als intuitiv.

Bis demnächst
Matthias

[Der-Dennis]

Hallo Matthias,

Nehmt als Beispiel die Layout-Tabellen: [...] Das ist, denke ich ein schlechtes Beispiel.

ja, das ist sehr gut möglich.

Eine Layout-Tabelle ist alles andere als intuitiv.

Findest Du? Also ich kann mir schon gut vorstellen, dass man als Anfänger schnell auf die Idee kommt, sowas zu verwenden. Ich denke auch das viele hier im Forum – mich eingeschlossen – mal so angefangen haben. Das Konzept einer Tabelle dürfte wohl jedem, der mit dem Programmieren anfängt, bekannt sein. Und dann schaut man sich irgendeine bestehende Seite an und denkt „so ungefähr will ich das auch“. Und dann versucht man das für sich selbst zu strukturieren. Man sieht „ah, links eine Spalte, in der Mitte eine Spalte Hauptinhalt, rechts eine weitere Spalte“. Und von „Spalte“ kommt man schnell zur Tabelle, weil man Zeilen und Spalten zuerst mit einer Tabelle assoziiert. Dass es auch Spalten z.B. in Zeitungen gibt kommt einem dann erst später.

Ich will nicht sagen, dass das gut so ist. Und ich will auch niemanden ermutigen das so zu machen. Ich finde nur nicht, dass das so abwegig ist, am Anfang auf die Idee zu kommen. Man verwendet das, was man schon aus anderen Kontexten kennt und versucht das irgendwie zu übertragen und zu verwenden. Von Semantik oder so weiß man am Anfang im Normalfall ja noch nichts. Und dass man sich keine Gedanken darüber macht, dass eine Tabelle nur tabellarische Daten beinhalten sollte, kommt häufig auch davon, dass man es woanders nicht wirklich gelernt hat. Schau Dir z.B. mal viele Excel-Dokumente an (mit denen man wahrscheinlich vorher mal in Berührung gekommen ist): Da wird die Tabelle auch oft zum Layouten missbraucht, ohne dass einer meckert (z.B. da eine Überschrift mitten drin, oben rechts ein Logo, ...). Macht die Sache natürlich auch nicht besser.

Was alles aber nichts daran ändert, dass das wahrscheinlich ein blödes Beispiel ist, da gebe ich Dir recht.

Gruß
Dennis

[Matthias Apsel]

Hallo Der-Dennis,

Eine Layout-Tabelle ist alles andere als intuitiv.

z.B. da eine Überschrift mitten drin, oben rechts ein Logo, ...)

Eben. 😉

Bis demnächst
Matthias

[Der-Dennis]

Hallo Matthias,

Eine Layout-Tabelle ist alles andere als intuitiv.

z.B. da eine Überschrift mitten drin, oben rechts ein Logo, ...)

Eben. 😉

ja ja, schon gut :-) Ich schlage vor wir einigen uns auf ein Unentschieden ;-)

Gruß
Dennis

[Felix Riesterer]

Lieber Matthias,

@Felix Riesterer Als ich vor 3 Jahren bei SelfHTML angefangen habe, war das da:

Grundlagen_der_Programmierung&oldid=15973

das finde ich sogar gut! Es ist in aller Kürze ein Beispiel, wie man JavaScript im Kontext eines HTML-Dokumentes im Browser nutzen kann. Hier eine abgewandelte Version:

<!doctype html>
<html>
  <head>
    <title>JavaScript im Browser</title>
  </head>
  <body>
    <h1>JavaScript im Browser</h1>
    <p>Dieser Satz wird mit JavaScript … <script>document.write("zuende geführt.");</script></p>
  </body>
</html>

Dies war die Grundlage für die Trennung in Einführung in die Programmierlogik, den ich mit @Der-Dennis zusammen konzipiert habe, und den vorliegenden Artikel.

Für die meisten Anwendungsfälle dürfte dieses Beispiel von seiner Herangehensweise her nicht genügen. Da ist es tatsächlich wichtig, die Trennung der verschiedenen Technologien (Markup/Layout/Verhalten) zu thematisieren. Aber als „Erstkontakt“ mit JavaScript finde ich das Beispiel nicht (mehr) falsch. Natürlich wird man sehr schnell zu komplexeren Herangehensweisen überleiten, und zeigen, wie man nach dem vollständigen Laden das Dokument an den entsprechenden Stellen verändert - und ist prompt bei DOM-Methoden, Einbindung externer Script-Dateien im <head> und Asynchronem Verarbeiten. Da wir uns im Browser befinden (ich lasse node.js bewusst außen vor), ist das eine für Anfänger unvermeidliche Anfangshürde, die als Konzept erst einmal verarbeitet werden muss.

Und deshalb mag ich document.write auch in Anfänger-Tutorials nicht. Aber für einen „Erstkontakt“ finde ich es dann doch verschmerzbar, analog zu solchen Sachen in PHP:

<p>Dieser Satz wird mit PHP … <?php echo "zuende geführt."; ?></p>

Deshalb halte ich eine Ausgabe mit alert() oder document.write() hier für gerechtfertigt.

Ich stimme Dir zu (Stichwort „Erstkontakt“). Damit muss ich meinen ursprünglichen Einwand zurück nehmen.

• didaktische Reduktion

Eben. Das Komplexere gehört sicherlich an eine andere spätere Stelle.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

Und deshalb mag ich document.write auch in Anfänger-Tutorials nicht.

+1

Aber für einen „Erstkontakt“ finde ich es dann doch verschmerzbar

Verschmerzbar oder nicht, darüber will ich mir gar keine Gedanken machen, denn: ich finde es ganz einfach unnötig.

Anstatt

<p>Dieser Satz wird mit JavaScript … <script>document.write("zuende geführt.");</script></p>

kann man auch gleich schreiben

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

Das ist nicht wirklich komplizierter, es ist genauso ein JavaScript-Einzeiler.

Und das skaliert auch. Dass die beiden "ausgabe"-Dinger im HTML und im JavaScript irgendiwe zusammenhängen, sollte intuitiv ersichtlich sein. Wenn ein zweites Ausgabefeld gewünscht ist, dürfte auch ein Anfänger erkennen, was zu tun ist.

Es geht an der Stelle überhaupt nicht darum, das DOM zu erklären. Es geht darum, ein gutes Beispiel vorzumachen. Eins, wo man nicht gleich darauf wieder sagen muss: Jetzt haben wir’s so gemacht, ist aber blöd und jetzt lernen wir’s nochmal anders …

Stichwort „Erstkontakt“

… Man kann’s auch gleich richtig machen; Anfänger müssen gar nicht erst wissen, dass es so etwas wie document.write() überhaupt gibt.

LLAP 🖖

[TS]

Hello,

Anstatt

<p>Dieser Satz wird mit JavaScript … <script>document.write("zuende geführt.");</script></p>

kann man auch gleich schreiben

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

was aber leider nicht funktioniert.

schreibt man stattdessen aber

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe">?</span></p>

<script>document.querySelector("#ausgabe").innerHTML = "zuende geführt.";</script>

wird das Fragezeichen tatsächlich durch den Text ersetzt.

Was ist denn da eigentlich der Unterschied zu document.getElementById('ausgabe').innerHTML?

Liebe Grüße
Tom S.

[TS]

Hello,

Anstatt

<p>Dieser Satz wird mit JavaScript … <script>document.write("zuende geführt.");</script></p>

kann man auch gleich schreiben

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

was aber leider nicht funktioniert.

schreibt man stattdessen aber

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe">?</span></p>

<script>document.querySelector("#ausgabe").innerHTML = "zuende geführt.";</script>

wird das Fragezeichen tatsächlich durch den Text ersetzt.

Was ist denn da eigentlich der Unterschied zu document.getElementById('ausgabe').innerHTML?

Das verstehe ich jetzt nicht. Wo ist der Fehler in meinem Posting? Wieso -1?

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@TS

Das verstehe ich jetzt nicht. Wo ist der Fehler in meinem Posting? Wieso -1?

Dieselbe Frage stelle ich mir auch, und das gleich doppelt.

Zumindest du hast nun eine Antwort darauf.

LLAP 🖖

[Gunnar Bittersmann]

@@TS

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

was aber leider nicht funktioniert.

Was nicht funktioniert.

Mag sein, dass das in deiner Welt nicht funktioniert. In meiner tut es das.

In welcher Welt lebst du?

<script>document.querySelector("#ausgabe").innerHTML = "zuende geführt.";</script>

Was ist denn da eigentlich der Unterschied zu document.getElementById('ausgabe').innerHTML?

Dass beim einem querySelector(), beim anderen getElementById() verwendet wird.

Was genau willst du wissen?

Dass querySelector() universell einsetzbar ist und man nicht verschiedene Methoden zum Selektieren von Elementen im DOM braucht?

LLAP 🖖

[TS]

Hello,

was aber leider nicht funktioniert.

Was nicht funktioniert.

Oh, entschuldig bitte. Ich dachte, Du könntest sowohl (weiter-)lesen, als auch (weiter-)denken.
Nun hoffe ich aber, dass dein Screenreader wenigstens noch funktioniert. ;-P

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Oh, entschuldig bitte. Ich dachte, Du könntest sowohl (weiter-)lesen, als auch (weiter-)denken.

„Formuliere höflich und wertschätzend.“ Viel mehr muss ich dazu wohl nicht sagen.

Nun hoffe ich aber, dass dein Screenreader wenigstens noch funktioniert. ;-P

Diesen Zusammenhang verstehst wahrscheinlich nur du. Ich zumindest verstehe ihn nicht.

Grüße,

RIDER

[TS]

Hello,

„Formuliere höflich und wertschätzend.“ Viel mehr muss ich dazu wohl nicht sagen.

Fass Dir mal an deine eigene Nase!

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@TS

„Formuliere höflich und wertschätzend.“ Viel mehr muss ich dazu wohl nicht sagen.

Fass Dir mal an deine eigene Nase!

Häh?

LLAP 🖖

[Christian Kruse]

Hallo TS,

„Formuliere höflich und wertschätzend.“ Viel mehr muss ich dazu wohl nicht sagen.

Fass Dir mal an deine eigene Nase!

Wie bitte??

LG,
CK

[Camping_RIDER]

Aloha ;)

Dass querySelector() universell einsetzbar ist und man nicht verschiedene Methoden zum Selektieren von Elementen im DOM braucht?

Jein. Auch da braucht man manchmal querySelector() und manchmal querySelectorAll() 😉

Der wahre Vorteil liegt mMn darin, dass man (wie ich das neulich, als es um window.matchMedia() ging, auch schon angemerkt hatte), in JavaScript und CSS gleiche Syntax (in dem Fall zum selektieren) einsetzen kann und damit nicht mehr (oder nicht mehr so oft) umdenken oder umrechnen muss, was unter anderem Fehler vermeidet.

Wenn du das mit „nicht verschiedene Methoden zum Selektieren von Elementen im DOM brauchen“ meintest, dann umso besser, dann steht es jetzt zweimal in unterschiedlichen Worten da 😉

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Dass querySelector() universell einsetzbar ist und man nicht verschiedene Methoden zum Selektieren von Elementen im DOM braucht?

Jein. Auch da braucht man manchmal querySelector() und manchmal querySelectorAll() 😉

Grmpf, ich hätte „zum Selektieren eines Elements“ schreiben sollen. 😉

Der wahre Vorteil liegt mMn darin, dass man […] in JavaScript und CSS gleiche Syntax (in dem Fall zum selektieren) einsetzen kann

Ja, das auch.

Wenn du das mit „nicht verschiedene Methoden zum Selektieren von Elementen im DOM brauchen“ meintest, dann umso besser, dann steht es jetzt zweimal in unterschiedlichen Worten da 😉

Ich meinte allerdings den Teil vor der Klammer. Man braucht nicht getElementById(), getElementsByTagName(), getElementsByClassName() und und und, sondern nur noch querySelector() bzw. querySelectorAll().

LLAP 🖖

[Camping_RIDER]

Aloha ;)

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

was aber leider nicht funktioniert.

Ach ja?

Natürlich funktioniert das.

[Der Rest war irrelevant; verlesen - mea culpa.]

Grüße,

RIDER

[TS]

Hello,

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

was aber leider nicht funktioniert.

Ach ja?

Natürlich funktioniert das.

Ach nein!
In Firefox erst in der Version vom 02. Januar 2017. In denen davor, die ich jetzt testen konnte, rührt sich da nix. innerText wird nicht unterstützt, innerHTML sehr wohl.

Wenn ich das richtig sehe, ist es ausnahmsweise mal der IE (11) gewwesen, der querySelector als erster unterstützt hat. Leider weiß ich nicht, wie der das mit innerHTML und innerText gehalten hat. Ich habe keinen mehr.

Aber ich habe hier doch gelernt, dass man Sachen, die nur ein IE unterstützt, nicht verwenden soll ;-)

Ich empfinde euren "alle haben immer die neuesten Browser"-Hype als eine falsche Grundannahme.

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Ach ja?

Ja.

Ach nein!
In Firefox erst in der Version vom 02. Januar 2017. In denen davor, die ich jetzt testen konnte, rührt sich da nix. innerText wird nicht unterstützt, innerHTML sehr wohl.

innerText funktioniert in allen nennenswerten Browsern. Alte Versionen von Browsern, die in der Lage sind, sich automatisch upzudaten, sind vollkommen irrelevant.

Ich empfinde euren "alle haben immer die neuesten Browser"-Hype als eine falsche Grundannahme.

Nicht den neusten Browser zu haben wenn man ihn ohne Schwierigkeiten haben kann ist eine freiwillige Selbstverstümmelung, auf die nicht Rücksicht genommen werden sollte. Automatische Updates sind ein Opt-Out, und demnach muss jeder User, der diese ablehnt, auch selbst wissen, was er damit tut. Und mit den Konsequenzen leben.

Als es noch den IE8 unter XP gab, den man nicht mehr weiter updaten konnte, war es einigermaßen verständlich, darauf Rücksicht zu nehmen - wo der User keine Möglichkeit zum Update hat kann man ihm schlecht einen Vorwurf machen.

Seit der Abkündigung von IE8 und Windows XP ist auch der IE8 nicht mehr zu berücksichtigen.

Du kannst natürlich berücksichtigen, wen und was auch immer du willst. Aber Verständnis solltest du dafür nicht erwarten.

Grüße,

RIDER

[Rolf b]

Laut caniuse funktioniert innerText im Firefox seit #45 (08.03.2016). Am 2.1.17 gab's eigentlich gar keinen neuen Fuchs, die #50 ist vom November und #51 von Ende Januar. Oder sprichst Du von einer speziellen Plattform, Tom?

Die Alternative ist textContent, das zwar gewisse semantische Unterschiede beinhaltet, aber für den Zweck, einen Text in ein Ausgabelement zu setzen, den gleichen Zweck erfüllt. textContent wird von MS ab IE9 unterstützt.

Die Selbstverständlichkeit eines Auto-Update ist übrigens nicht gegeben. Wird ein Browser in einem Unternehmen mit zentraler Administration der Arbeitsplätze eingesetzt, aktualisierten sich die PCs nicht unbedingt selbst, sondern es gibt eine zentrale, releasegeführte Verteilung. Oder es gibt gar keine PCs, sondern Thin Clients und eine Terminal-Server Farm. Da kann ein Update sich schon mal ein halbes Jahr verzögern.

Rolf

[TS]

Hello,

Laut caniuse funktioniert innerText im Firefox seit #45 (08.03.2016). Am 2.1.17 gab's eigentlich gar keinen neuen Fuchs, die #50 ist vom November und #51 von Ende Januar. Oder sprichst Du von einer speziellen Plattform, Tom?

Das sollte 24.01.2017 heißen. Ist aber auch egal, wenn es seit V45 unterstützt wird.

Die Alternative ist textContent,

Danke, das scheint zuverlässiger zu funktionieren.
Irgendwo las ich mal. dass JavaScript keine Programmiersprache sei, sondern eine ständige Baustelle.

Wie kann ich eigentlich ermitteln, welche JavaScript-Version mein Script vor sich hat?

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Wie kann ich eigentlich ermitteln, welche JavaScript-Version mein Script vor sich hat?

Kann man vielleicht irgendwie, ist aber praktisch nicht weiter relevant, weil man daraus nicht entnehmen kann, welche Features nun konkret unterstützt werden und welche nicht. Man nimmt einfach Polyfills für Dinge, die noch ziemlich neu und keine nicht nachbaubaren Schlüsselwörter sind.

dedlfix.

[Camping_RIDER]

Aloha ;)

Irgendwo las ich mal. dass JavaScript keine Programmiersprache sei, sondern eine ständige Baustelle.

JavaScript ist zweifelsohne eine Programmiersprache.

Wie kann ich eigentlich ermitteln, welche JavaScript-Version mein Script vor sich hat?

??

Ich bin nicht sicher, aber ich glaube du sitzt hier Irrtümern auf. Erstens gibt es gar nicht so klar eine „JavaScript-Version“. Stattdessen gibt es Versionen des JavaScript zugrundeliegenden ECMAScript - hier gilt, dass Version 5 flächendeckend unterstützt wird (und das auch schon lange), Version 6 aber noch nicht vollständig.

Jetzt ist aber JavaScript ist nicht nur ECMAScript, sondern ECMAScript mit DOM, und die Probleme, mit denen man real zu tun hat, wenn es um die Unterstützung von JavaScript geht, liegen im Bereich des DOM, da einzelne DOM-Funktionen eben entweder unterstützt werden oder nicht. Hier gibt es die meisten Unterschiede im Browsersupport, und auch das DOM hat eigene Versionsnummern, die aber nichts über den Browsersupport aussagen.

Das bezieht sich aber auf die Version der Sprache, in der du deine Scripts verfasst. Du suchst, wenn ich dich richtig verstehe, nach einer Version der Javascript-Engine. Nur ist es so, dass es auch nicht die Javascript-Engine gibt, sondern wieder je Browser eigene, die eigenen Versionierungsschemata folgen.

Ich glaube nicht, dass es das, was du suchst, wirklich gibt.

Grüße,

RIDER

[Julius]

Hallo TS,

Irgendwo las ich mal. dass JavaScript keine Programmiersprache sei, sondern eine ständige Baustelle.

„Die einzige Konstante im Universum ist die Veränderung.“
Wir können uns eigentlich nur darüber freuen, dass sich etwas ändert und meist auch verbessert. Ich habe viel im Forums-Archiv und alten Aktuell-Artikeln gelesen und ekel mich regelrecht vor der Zeit von Tabellen-Layouts, Frames, Browserweichen und DHTML (statt einem Einzeiler ein Haufen if-elses für den Zugriff aufs Dokument). Gut, dass ich mich zur Zeit des beginnenden Niedergangs des IE noch nicht für Webentwicklung interessiert habe...

Wie kann ich eigentlich ermitteln, welche JavaScript-Version mein Script vor sich hat?

Version-Sniffing ist sowohl für den Nutzer als auch für den Entwickler eine schlechte Lösung – Nutzer mit Browsern mit unbekanntem Namen sitzen auf dem Trockenen und Entwickler müssen die verschieden Versionen und Features (sofern überhaupt möglich) zuordnen können.

Aber falls du rein aus Interesse fragst: schau mal unter JavaScript/Navigator ins Wiki.

Gruß
Julius

[Felix Riesterer]

Lieber Julius,

und ekel mich regelrecht vor der Zeit von Tabellen-Layouts, Frames, Browserweichen und DHTML (statt einem Einzeiler ein Haufen if-elses für den Zugriff aufs Dokument).

ja, das war in der Tat eklig. Und ja, gottseidank ist diese Zeit definitiv vorbei.

Gut, dass ich mich zur Zeit des beginnenden Niedergangs des IE noch nicht für Webentwicklung interessiert habe...

Ich schon. Und was war der IE 6 für ein unausrottbares Geschwür! Hoffentlich wird es mit WebAssembly nicht eine neue Büchse der Pandora geben.

Liebe Grüße,

Felix Riesterer.

[Julius]

N’ Abend Felix!

Gut, dass ich mich zur Zeit des beginnenden Niedergangs des IE noch nicht für Webentwicklung interessiert habe...

Ich schon. Und was war der IE 6 für ein unausrottbares Geschwür! Hoffentlich wird es mit WebAssembly nicht eine neue Büchse der Pandora geben.

Es soll ja nur eine Ergänzung darstellen (Zitat aus dem von dir verlinkten Artikel):

Es soll JavaScript nicht ersetzen, sondern ergänzen, und vor allem dort zum Einsatz kommen, wo hohe Performance erforderlich ist.

Außerdem kann (oder muss sogar) diese Programme in C++, Rust oder einer anderen kompilierbaren Sprache schreiben – ich könnte mir vorstellen, dass vielen Webentwicklern JavaScript reicht und die nicht noch C++ lernen wollen...

Gruß
Julius

[Felix Riesterer]

Lieber Julius,

Hoffentlich wird es mit WebAssembly nicht eine neue Büchse der Pandora geben.

Es soll ja nur eine Ergänzung darstellen (Zitat aus dem von dir verlinkten Artikel):

Die Frage, die sich mir stellt, ist diese: Wird dadurch der Browser nicht unnötigerweise noch unsicherer, als er das jetzt schon ist? Höhere Komplexität = mehr Möglichkeiten für konzeptionelle Fehler. Der aktuelle Grad an Komplexität ist schon jetzt durchaus beachtlich (einer der ersten Feuerfüchse brachte im Download als Windows-Setup.exe unter drei MB auf die Waage, heute am 06.03.2017 sind es 45MB für die 64bit-Plattform): WebAssembly, WebGL, Canvas, CSS-Animations usw. Für WebAssembly wird sicherlich (wieder) irgendeine Art IL verwendet, bei der es wieder sehr spannend wird, Malware als solche zu erkennen und zu entschärfen. Auch WebGL erlaubt das Schreiben von ausführbarem Code in die Shader-Prozessoren der Grafikkarte - welche spätestens seit dem AGP-Standard Zugriff auf den Hauptspeicher hat… eben Büchse der Pandora.

Liebe Grüße,

Felix Riesterer.

[Camping_RIDER]

Aloha ;)

Hoffentlich wird es mit WebAssembly nicht eine neue Büchse der Pandora geben.

Ohne euch unbedingt unterbrechen zu wollen: Ich glaube kaum, dass es seit der letzten Diskussion da neue Erkenntnisse gibt. Abwarten und nicht zu skeptisch sein ist nach wie vor die Devise, meiner Meinung nach.

Die Frage, die sich mir stellt, ist diese: Wird dadurch der Browser nicht unnötigerweise noch unsicherer, als er das jetzt schon ist? Höhere Komplexität = mehr Möglichkeiten für konzeptionelle Fehler.

„Wenn es danach geht, hätten wir nie mit dem Internet anfangen dürfen und alle bei unseren Amigas und Comodores bleiben müssen. Jede Weiterentwicklung birgt Komplexität und Potential für neue Sicherheitslücken. Die muss man dann halt finden und fixen.“

Für WebAssembly wird sicherlich (wieder) irgendeine Art IL verwendet, bei der es wieder sehr spannend wird, Malware als solche zu erkennen und zu entschärfen.

„Was die Sicherheit betrifft, ist WebAssembly so entworfen worden, dass die selben Zugriffs-Beschränkungen eingehalten werden müssen, die auch für JS gelten. Es ist der selbe Teil der JS-Engine, der bspw. den Dateisystem-Zugriff reguliert. Das ist der wesentliche Unterschied im Security-Modell von WASM und vorherigen Plugin-Lösungen. Es ist sogar ein explizit genannter Anwendungsfall, nicht-vertrauenswürdigen Code (serverseitig) gefahrlos auszuführen. Realisiert wird das über Sandboxing.“

Auch WebGL erlaubt das Schreiben von ausführbarem Code in die Shader-Prozessoren der Grafikkarte - welche spätestens seit dem AGP-Standard Zugriff auf den Hauptspeicher hat… eben Büchse der Pandora.

„Hier kommen gerade ein paar Mails von Leuten rein, die es besser/genauer wissen als ich. Die beiden Haupteinwände sind: a) man kann per WebGL nur GLSL hochladen, nicht binäre Shader, und b) die Grafikkarte kann nicht auf den kompletten Speicher im PC zugreifen, sondern nur auf die Bereiche, die der Treiber eingestellt hat. Soweit ich weiß ist das generell beides richtig.“

So what? 😉 Dinge schlechter reden als sie sind und widerlegte Argumente zu wiederholen bringt uns ja auch nicht weiter 😉 Einfach mal abwarten.

Grüße,

RIDER

[Julius]

Hallo Felix,

Der aktuelle Grad an Komplexität ist schon jetzt durchaus beachtlich (einer der ersten Feuerfüchse brachte im Download als Windows-Setup.exe unter drei MB auf die Waage, heute am 06.03.2017 sind es 45MB für die 64bit-Plattform): WebAssembly, WebGL, Canvas, CSS-Animations usw.

Heute sind aber auch der PDF-Betrachter, sowie – von den Funktionen her – Flash und Java-Plugin integriert, man hat mehr Arbeitsspeicher und benutzt den Browser für Web-Apps (bzw. könnte es machen) und nicht mehr nur für Webseiten. Mozilla arbeitet ja auch an Rust, um die Probleme bei der Programmierung von sicherer C-Software zu beheben.

Für WebAssembly wird sicherlich (wieder) irgendeine Art IL verwendet, bei der es wieder sehr spannend wird, Malware als solche zu erkennen und zu entschärfen.

Falls ich mich nicht irre, macht man das mit JavaScript bereits jetzt nicht wirklich: Adblocker (oder Privatssphärenschutz wie uBlock) arbeiten mit der Domain, unter der die Ressourcen liegen und nicht deren Inhalt.

Auch WebGL erlaubt das Schreiben von ausführbarem Code in die Shader-Prozessoren der Grafikkarte - welche spätestens seit dem AGP-Standard Zugriff auf den Hauptspeicher hat… eben Büchse der Pandora.

Dazu hat RIDER ja schon den letzten Absatz zitiert :-)

Gruß
Julius

[Felix Riesterer]

Lieber Julius,

Auch WebGL erlaubt das Schreiben von ausführbarem Code in die Shader-Prozessoren der Grafikkarte - welche spätestens seit dem AGP-Standard Zugriff auf den Hauptspeicher hat… eben Büchse der Pandora.

Dazu hat RIDER ja schon den letzten Absatz zitiert :-)

nein, den vorletzten. Und das finde ich wesentlich. Im letzten bleibt Fefe nämlich bei seiner Einschätzung. ;-)

Liebe Grüße,

Felix Riesterer.

[Camping_RIDER]

Aloha ;)

Auch WebGL erlaubt das Schreiben von ausführbarem Code in die Shader-Prozessoren der Grafikkarte - welche spätestens seit dem AGP-Standard Zugriff auf den Hauptspeicher hat… eben Büchse der Pandora.

Dazu hat RIDER ja schon den letzten Absatz zitiert :-)

nein, den vorletzten. Und das finde ich wesentlich. Im letzten bleibt Fefe nämlich bei seiner Einschätzung. ;-)

Da hast du Recht, der letzte Absatz ist aber auch ziemlich deutlich ein „Ihr-könntet-da-vielleicht-schon-Recht-haben-aber-wer-weiß-ob-die-Angaben-alle-so-stimmen-und-weil-es-möglich-wäre-dass-Hersteller-der-Versuchung-erliegen-bleibe-ich-trotzdem-skeptisch“-Mimimi 😉

Ich habe kein Problem mit einer gesunden Portion Skepsis und die ist sicher gerade bei solchen Dingen (IT-Sicherheit) auch angebracht, es gibt aber ein gewisses Level, an dem man aufhören muss zu hinterfragen und einfach mal davon ausgehen muss, dass der aktuelle Kenntnisstand auch so ist wie er kolportiert wird.

Einerseits ist es in der IT-Sicherheit so, dass man realistischerweise davon ausgehen muss, dass kein System absolut sicher ist. Demnach ist die reine Vermutung der Eventualität einer Sicherheitslücke per se mal nichts besonderes und sicher auch kein Grund, sich ablehnend gegenüber einer Technologie zu positionieren, solange die Indizien die Eventualität nicht zu einer erhärteten Vermutung werden lassen.

Andererseits sollte man, wenn man aus jeder Eventualität gleich eine Befürchtung konstruiert, am Besten gleich den Aluhut aufsetzen.

Maßvolle Skepsis ist eben ein schmaler Grat, der nur allzu leicht in Paranoia abdriftet. fefe befindet sich in seinem Blog immer mal wieder auf der einen und dann mal wieder auf der anderen Seite der Linie - was auch völlig in Ordnung sind, immerhin spiegelt er in seinem Blog eben einfach rücksichtslos seine Meinung wieder, ohne Gegenstimmen und ohne Anspruch auf Korrektheit. Als Diskussionsgrundlage kann man seine Einschätzungen dann aber auch nicht immer unreflektiert übernehmen 😉

Grüße,

RIDER

[dedlfix]

Tach!

immerhin spiegelt [Fefe] in seinem Blog eben einfach rücksichtslos seine Meinung wieder, ohne Gegenstimmen und ohne Anspruch auf Korrektheit. Als Diskussionsgrundlage kann man seine Einschätzungen dann aber auch nicht immer unreflektiert übernehmen 😉

Gegenstimmen sind aber gerade das was Fefe haben möchte, wie er selbst immer wieder betont. Das braucht er, um auch die Meinungen der Gegenseite in seine Betrachtungen einzubeziehen. (Nicht nur er, aber den meisten fehlt diese Einsicht.) Und oftmals bringt er genau diese Gegenstimmen auch als Zitat in seinem Blog. (Wobei viele davon auch nicht im zitierwüdigen Tonfall gehalten sein werden, vermute ich mal.) Natürlich kann er nicht immer warten, bis erst alle Gegenstimmen bei ihm eingetrudelt sind, ohne dass er vorher seine Meinung kundgetan hat.

dedlfix.

[dedlfix]

Tach!

Die Frage, die sich mir stellt, ist diese: Wird dadurch der Browser nicht unnötigerweise noch unsicherer, als er das jetzt schon ist?

Ja, aber das ist halt das Unvermeidliche daran, wenn man ein System haben möchte, das sehr vielen Anwendungsfällen gerecht werden soll, das als eierlegende Wollmilchsau konzipiert ist und in Zukunft auch noch weiterwachsen statt schrumpfen wird. Die Alternative dazu wären viele kleine Systeme (lies Programme), die auch nicht insgesamt gesehen weniger komplex und fehlerfreier werden. Hinzu kommt dann auch noch, dass diese Programme für mehrere Plattformen geschrieben werden müssen. Wieviel einfacher ist es doch, nur für den Browser entwickeln zu müssen (individuelle Zipperlein der Browser mal außer Betracht lassend). Damit dreht sich die Spirale weiter, bis sie irgendwann von einer anderen Technik abgelöst wird und von vorn beginnt.

dedlfix.

[Gunnar Bittersmann]

@@TS

In Firefox erst in der Version vom 02. Januar 2017.

Nein. Laut Can I use bereits seit Version 45 vom 8. März 2016.

In denen davor, die ich jetzt testen konnte, rührt sich da nix.

Wenn du ein Jahr später immer noch eine dermaßen alte Version zu laufen hast, bist du es, der in einer anderen Welt lebt.

Ich empfinde euren "alle haben immer die neuesten Browser"-Hype als eine falsche Grundannahme.

Da ist was dran. Aber bei Firefox und Chrome gibt es genau eine Version, auf die man Rücksicht nehmen muss: die gerade aktuelle.

LLAP 🖖

[dedlfix]

Tach!

Aber bei Firefox und Chrome gibt es genau eine Version, auf die man Rücksicht nehmen muss: die gerade aktuelle.

Das wären bei Firefox aber bis zu drei Versionen, die als aktuell definiert sind. Oder wie sind da sonst die ESR-Versionen einzusortieren?

dedlfix.

[Camping_RIDER]

Aloha ;)

Aber bei Firefox und Chrome gibt es genau eine Version, auf die man Rücksicht nehmen muss: die gerade aktuelle.

Das wären bei Firefox aber bis zu drei Versionen, die als aktuell definiert sind. Oder wie sind da sonst die ESR-Versionen einzusortieren?

Nun ja. Selbst wenn man das einbezieht gibt es keine aktuelle Firefox-Version, die innerText nicht anbietet - Firefox ESR 45.x (seit dem 7. Juni 2016 die älteste der als aktuell betrachtbaren Versionen) läuft ja auch auf Basis von Firefox 45, welches innerText-Unterstützung hatte.

Ob man ESR-Versionen jetzt als aktuell bezeichnen möchte weiß ich auch nicht. Zumindest lässt sich für die eine Rücksichtnahme begründen.

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

In Firefox erst in der Version vom 02. Januar 2017. In denen davor, die ich jetzt testen konnte, rührt sich da nix. innerText wird nicht unterstützt, innerHTML sehr wohl.

Übrigens liegst du auch damit falsch; gemäß den Informationen von caniuse unterstützt Firefox innerText seit Version 45, die am 8. März 2016 erschienen ist.

Das ist jetzt ein Jahr her. Man wird es selbst bei manuellen Updates wohl schaffen, den Browser innerhalb eines Jahres upzudaten. Alles andere ist grober Leichtsinn - Updates bringen nicht nur neue Features, sondern schließen immerhin auch Sicherheitslücken.

Grüße,

RIDER

[Rolf b]

LOL - das nenn ich mal Thread-Attention 😂

Ich war nur kurz nicht am PC bevor ich "Speichern" gedrückt habe, und schon hauen alle in die Versionsbresche.

Rolf

[Gunnar Bittersmann]

@@TS

Was ist denn da eigentlich der Unterschied
[von document.querySelector("#ausgabe").innerHTML]
zu document.getElementById('ausgabe').innerHTML?

Über einen Unterschied bin ich noch gestolpert:

<div id="42"></div>

document.getElementById('42'); // "<div id='42'></div>"

document.querySelector('#42'); // SyntaxError: '#42' is not a valid selector

Stimmt, das ist es nicht. Die 4 muss escapet werden:

document.querySelector('#\34 2'); // SyntaxError: '# 2' is not a valid selector

Häh? WTF? document.querySelector() erwartet als Argument einen Selektor, aber Escapes sind nicht erlaubt? Oder sind erlaubt, werden aber von Browsern nicht richtig aufgelöst?

Wie krieg ich das Element dann mit document.querySelector() angesprochen?

LLAP 🖖

[dedlfix]

Tach!

Stimmt, das ist es nicht. Die 4 muss escapet werden:

document.querySelector('#\34 2'); // SyntaxError: '# 2' is not a valid selector

Häh? WTF? document.querySelector() erwartet als Argument einen Selektor, aber Escapes sind nicht erlaubt? Oder sind erlaubt, werden aber von Browsern nicht richtig aufgelöst?

Kontextwechsel beachten! Der \ muss für Javascript mit noch einem solchen maskiert werden.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Kontextwechsel beachten! Der \ muss für Javascript mit noch einem solchen maskiert werden.

Kontextwaaas? ;-)

document.querySelector('#\\34 2'); // "<div id='42'></div>"

funzt. Danke.

LLAP 🖖

[Tabellenkalk]

Hallo,

Kontextwaaas? ;-)

Na, das Wort mit den zwei X

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

Kontextwaaas? ;-)

Na, das Wort mit den zwei X

Kontechstwexel. Ein X. Du hast dich verzählt.

LLAP 🖖

[Tabellenkalk]

Hallo,

Du hast dich verzählt.

Nö: Kontechstwexxel

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

Du hast dich verzählt.

Nö: Kontechstwexxel

Du willst mir ein Chs für ein U vormachen‽

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Wie krieg ich das Element dann mit document.querySelector() angesprochen?

Gar nicht. querySelector() erwartet einen selector string. Die Selektoren dieses Selector Strings sind definiert in Selectors Level 3, und dieses Dokument sagt, dass ein ID-Selektor eine # gefolgt von einem CSS-Identifier sein muss; und dieses Dokument sagt über CSS identifiers:

In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A0 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, two hyphens, or a hyphen followed by a digit.

Hervorhebung von mir.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

und dieses Dokument sagt über CSS identifiers:

In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A0 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, two hyphens, or a hyphen followed by a digit.

Hervorhebung von mir.

Eben deshalb muss die 4 ja escapet werden.

Wollen wir gemeinsam an jener Stelle weiterlesen?

Identifiers can also contain escaped characters and any ISO 10646 character as a numeric code (see next item). For instance, the identifier "B&W?" may be written as "B&W?" or "B\26 W\3F".

Hervorhebung von mir. 😜

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Eben deshalb muss die 4 ja escapet werden.

Ja gut, da habe ich nicht zuende gedacht. Nichts desto trotz: don't do this at home, kids!

LG,
CK

[Felix Riesterer]

Lieber Gunnar,

Verschmerzbar oder nicht, darüber will ich mir gar keine Gedanken machen,

das kannst Du Dir vielleicht leisten, aber Lehrkräfte, die Lernenden etwas beibringen möchten, können sich das nicht.

denn: ich finde es ganz einfach unnötig.

Das darfst Du. Du darfst (be)finden was immer Du willst. Aber Lernende empfinden, und manches überraschend anders, als in der Sache versierte Profis. Für die muss Dein Statement einfach nur anmaßend (lies: unnötig arrogant) klingen.

kann man auch gleich schreiben

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

Du erhöhst den Grad an Komplexität wesentlich! Du verwendest Markup, welches in meinem „Erstkontakt“-Beispiel nicht notwendig war (complexity++), um daraufhin DOM-Methoden zu bemühen, diesen aus Sicht des Neulings unnötigen Code-Bloat wieder erreichen (complexity++) und manipulieren (complexity++) zu können.

Das ist nicht wirklich komplizierter, es ist genauso ein JavaScript-Einzeiler.

Damit ist Dein Beispiel (hoffentlich sogar für Dich) nachweisbar um ein Mehrfaches komplexer.

Und das skaliert auch.

Wozu? Es ging um „Erstkontakt“, schon vergessen? Das Beispiel zeigt, dass man mit JavaScript innerhalb eines Dokumentes im Browser etwas „mit eigener Intelligenz“ einsetzen kann. Für mehr ist meiner Meinung nach document.write nicht geeignet. Die Frage nach Skalierung stellt sich erst dann, wenn man sinnvolle Beispiele erörtern möchte. Wir sind nicht in einem Tutorial, wir sind an einer Stelle, an der das Zusammenwirken von HTML und JavaScript als prinzipielle Möglichkeit erläutert wird!

Dass die beiden "ausgabe"-Dinger im HTML und im JavaScript irgendiwe zusammenhängen, sollte intuitiv ersichtlich sein.

Es ist bei Neulingen aber keinesfalls zu erwarten, dass es das auch tatsächlich ist.

Wenn ein zweites Ausgabefeld gewünscht ist, dürfte auch ein Anfänger erkennen, was zu tun ist.

Und wenn nicht? Wer sich mit HTML noch nicht genügend auskennt, also um die Universalattribute noch nicht weiß (wer braucht die schon, wenn die Schriftgröße mit <h1> bis <h6> eingestellt wird?), dem wird Dein Beispiel weniger sagen, als meines.

Es geht an der Stelle überhaupt nicht darum, das DOM zu erklären. Es geht darum, ein gutes Beispiel vorzumachen.

Nein, es geht darum zu zeigen, dass man eine Programmiersprache innerhalb des Dokumentes nutzen kann, nicht darum wie man das am sinnvollsten tut. Deshalb verwende ich ja auch gebetsmühlenartig den Begriff „Erstkontakt“. Aber wenn es um Tutorials geht, verbietest Du ja dem Lernenden seine wie auch immer verzerrten Perspektiven und lässt nur Deine als die allein gültige zu. Deshalb geraten wir in solchen Kontexten inhaltlich immer wieder aneinander.

Eins, wo man nicht gleich darauf wieder sagen muss: Jetzt haben wir’s so gemacht, ist aber blöd und jetzt lernen wir’s nochmal anders …

Warum nicht auf „historisches Überbleibsel“ plädieren und gut ist's? Das „Erstkontakt“-Beispiel ist tatsächlich so einfach, dass auch und gerade ein Anfänger erkennen muss, dass sich damit nicht viel erreichen lässt. Will man mehr und Raffinierteres, braucht man andere Herangehensweisen - und ist prompt bei den Tutorials.

Stichwort „Erstkontakt“

… Man kann’s auch gleich richtig machen;

Kann man das? Wie beurteilst Du in diesem Fall richtig und falsch? Welche Maßstäbe definierst Du (warum?) als dazu relevant? Nur um document.write zu vermeiden gleich die Komplexität vervierfachen? Wenn das Beispiel nur und ausschließlich zeigen soll, dass in einem HTML-Dokument im Browser eine Scriptsprache eingesetzt werden kann? Ist es da (nochmals: warum?) richtig, ein Mantra zu singen, das in genau diesem Kontext keine Relevanz für den beabsichtigten Erkenntnisgewinn hat?

Oder habe ich Dich schon wieder beim Missionieren erwischt?

Anfänger müssen gar nicht erst wissen, dass es so etwas wie document.write() überhaupt gibt.

Warum nicht? Und wozu listen wir es in der Doku? Und wenn Du (be)findest, dass Anfänger dieses nicht wissen brauchen, was brauchen sie statt dessen? DOM-Methoden? An dieser Stelle?

In meinem Englisch-Unterricht habe ich begonnen, gegen die Lehrwerke zu argumentieren und meinen Schülern den Begriff going-to future infrage zu stellen. Meine Argumentation ist, dass dieses Konstrukt keinesfalls ein grammatisches Tempus darstellt, sondern lediglich eine Redewendung, die hauptsächlich Absichten ausdrücken soll. Damit mag sie inhaltlich vielleicht Zukünftiges behandeln, ist aus grammatischer Sicht aber nichts anderes als ein present progressive. Spätestens bei Sätzen wie dem folgenden muss klar werden, dass es kein Tempus mit Futur-Charakter hat:

I was going to tell you, but you were already gone home.

Ebenso weigere ich mich die zweite Person plural als etwas anderes als eben Plural zu vermitteln. Auch wenn die zweite Person singular stilistisch ein Archaismus geworden ist, so ist sie nicht ungültig geworden. Man mag vielleicht damit argumentieren, dass sie mit der Pluralform ersetzt worden ist, aber das macht die Pluralform noch zu keinem Singular:

Hast thou spoken with him?
Have you spoken with him?

Was muss ein Anfänger wissen? Er muss wissen, wie er das Vermittelte einordnen muss. Und da ist es manchmal sinnvoll, mit halben Wahrheiten zu beginnen, damit man später das Wissen verfeinern kann. Aber das willst Du nicht wissen, da Du meinst, dass viel zu viele Selbstlerner auf halben Wege mit einem Tutorial aufhören und dann im beruflichen Umfeld mit diesem unfertigen Wissensstand Unheil anrichten.

Liebe Grüße,

Felix Riesterer.

[TS]

Hello Felix,

Stichwort „Erstkontakt“

… Man kann’s auch gleich richtig machen;

[•••]

Schade, mit deinem ausführlichen Posting nimmst Du mir den ganzen Spaß ;-)

Ich hätte mich gerne noch ein wenig mit den Richtimachern™️ auseinandergesetzt. Und während wir dann genüsslich gestritten hätten um die didaktischste Formulierung, hätte sich schon wieder die Browserversion geändert und "man macht das nicht mehr so", wie es da geschrieben steht.

Und wenn dann etwas nicht so funktioniert wie beschrieben, aber der Schüler dann schreibt: "wenn ich es aber so mache, dann erhalte ich die erwartete Ausgabe", darf der Lehrer keinesfalls intelligent genug sein, selber mal zu vergleichen, was der Schüler denn nun anders gemacht hat. Er muss nur stumpf rumblöken "funktioniert nicht" ist keine Fehlerbeschreibung.

Beispiele für Anfänger müssten mMn so oldfashioned (aber nicht ungültig) sein, dass sie garantiert funktionieren und nicht erst die Browserpredigt gehalten wird.

Liebe Grüße
Tom S.

[Felix Riesterer]

Lieber TS,

Schade, mit deinem ausführlichen Posting nimmst Du mir den ganzen Spaß ;-)

tut mir (aber nur ein bisschen) leid.

Ich hätte mich gerne noch ein wenig mit den Richtimachern™️ auseinandergesetzt. [...] Beispiele für Anfänger müssten mMn so oldfashioned (aber nicht ungültig) sein, dass sie garantiert funktionieren und nicht erst die Browserpredigt gehalten wird.

das geht für mich am Thema vorbei. Immerhin sind wir uns in einem Teilaspekt offensichtlich einig: Predigen um des Absolutheitsanspruches willen.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

denn: ich finde es ganz einfach unnötig.

Aber Lernende empfinden, und manches überraschend anders, als in der Sache versierte Profis. Für die muss Dein Statement einfach nur anmaßend (lies: unnötig arrogant) klingen.

Nein. Für die Lernenden klingt mein Statement gar nicht. Ich habe gar kein Statement für sie gemacht.

Mein Statement war für die Leserschaft dieses Threads, für die Autorenschaft des Artikels im Wiki.

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

Du erhöhst den Grad an Komplexität wesentlich! Du verwendest Markup, welches in meinem „Erstkontakt“-Beispiel nicht notwendig war

Es ist ein Element mehr da, was eindeutig als Ausgabe-Element gekennzeichnet ist. Das macht den Code eher noch besser lesbar. Erhöhte Komplexität? Nein. „Wesentlich“?? Ich bitte dich.

um daraufhin DOM-Methoden zu bemühen, diesen aus Sicht des Neulings unnötigen Code-Bloat wieder erreichen

Beides Einzeiler. document.write vs. document.querySelector('#ausgabe').innerText Code-„Bloat“?? Ich bitte dich.

und manipulieren

Manipulieren? Wie bitte?

Die einzige Manipulation, die ich hier sehe, ist, dass du die Meinung der Leserschaft über die Sinnhaftigkeit deiner Argument manipulierst. Einer war dir auf den Leim gegangen.

Wozu? Es ging um „Erstkontakt“, schon vergessen?

Der erste Eindruck ist oft der bleibende.

Wie oft taucht denn hier im Forum die Frage auf, warum nach document.write alles weg ist? So ein Grundlagentutorial sollte dafür sorgen, dass diese Frage nicht mehr auftaucht.

Dass die beiden "ausgabe"-Dinger im HTML und im JavaScript irgendiwe zusammenhängen, sollte intuitiv ersichtlich sein.

Es ist bei Neulingen aber keinesfalls zu erwarten, dass es das auch tatsächlich ist.

Ein Wort der deutschen Sprache, das zweimal im Code vorkommt – nicht zu erwarten, dass zwischen diesen beiden Stellen ein Zusammenhang erkannt wird?? Ich bitte dich.

Vermutlich hätte ich der Erkenntnis wegen wohl "Ausgabe" mit großem A schreiben müssen. Mein Fehler, ’tschuldigung.

Aber wenn es um Tutorials geht, verbietest Du ja dem Lernenden seine wie auch immer verzerrten Perspektiven und lässt nur Deine als die allein gültige zu.

Nein, ich bringe sachliche Argumente an. Und du??

Eins, wo man nicht gleich darauf wieder sagen muss: Jetzt haben wir’s so gemacht, ist aber blöd und jetzt lernen wir’s nochmal anders …

Warum nicht auf „historisches Überbleibsel“ plädieren und gut ist's?

Weil dieses historische Überbleibsel niemand braucht und es eher schädlich ist, s.o.

… Man kann’s auch gleich richtig machen;

Kann man das? Wie beurteilst Du in diesem Fall richtig und falsch? Welche Maßstäbe definierst Du (warum?) als dazu relevant?

Warum stellst du Fragen, die ich bereits beantwortet habe?

LLAP 🖖

[dedlfix]

Tach!

Beides Einzeiler. document.write vs. document.querySelector('#ausgabe').innerText Code-„Bloat“??

Man könnte in dem Artikel noch jede Menge mehr Code zu Einzeilern zusammenfassen. Einzeiler bedeutet jedoch nicht, dass etwas einfach oder einfach verständlich ist. Gerade bei solchen Verkettungen, bei denen eine Menge Zwischendinge entstehen, ist das nicht mehr so einzeilig einfach verständlich. Als Programmieranfänger muss man auch lernen, Probleme auf kleine Einheiten herunterzubrechen.

Man könnte schon das Tutorial auf die Verwendung eines vollständiges HTML-Dokuments umbauen, aber dann bleibt weiterhin das "Beachten Sie" übrig, nur mit anderem Text, der auf weiterführende Artikel verweist, und es kommen noch ein paar mehr solcher den Lesefluss unterbrechenden Hinweise hinzu, dass vieles vom Verwendeten an anderer Stelle erst erklärt wird.

Ich erinnere mich da grad eine eine Posting-Signatur, in der gesagt wurde, dass die Kunst der Perfektion nicht im Hinzufügen, sondern im Weglassen besteht …

Wie oft taucht denn hier im Forum die Frage auf, warum nach document.write alles weg ist? So ein Grundlagentutorial sollte dafür sorgen, dass diese Frage nicht mehr auftaucht.

Dann tauchen da eben andere Fragen auf. Zum Beispiel die, warum die Ausgabe nicht erfolgt. Vielleicht weil der Probleminhaber ein Konstrukt, das aufgrund seiner Komplexität noch nicht vollständig erläutert wird, falsch auf andere Anwendungsfälle zu übertragen versucht.

Ein Wort der deutschen Sprache, das zweimal im Code vorkommt – nicht zu erwarten, dass zwischen diesen beiden Stellen ein Zusammenhang erkannt wird??

Ich finde es immer wieder erstaunlich, wieviel ich selbst von den Dingen, die in einem Tutorial erwähnt wurden, dennoch vergesse. Oder die mir erst später klar werden. Nur weil etwas in vermeintlich einfacher Sprache dargelegt wurde, heißt das nicht automatisch, dass der Leser es sich merkt oder dass er es versteht und genauso berücksichtigt, wie es gemeint oder korrekt ist.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Beides Einzeiler. document.write vs. document.querySelector('#ausgabe').innerText Code-„Bloat“??

Einzeiler bedeutet jedoch nicht, dass etwas einfach oder einfach verständlich ist.

Natürlich nicht. Desöfteren ist das Gegenteil der Fall.

Genausowenig bedeutet Mehrzeiler erhöhte Komplexität.

Gerade bei solchen Verkettungen, bei denen eine Menge Zwischendinge entstehen, ist das nicht mehr so einzeilig einfach verständlich.

Mein Punkt ist (und war es von Anfang an): Der Leser muss document.querySelector('#ausgabe').innerText an der Stelle gar nicht weiter verstehen. Es muss lediglich nur verwenden.

Das Einzige, was er dabei verstehen muss, ist, dass das die Ausgabe auf dem Bildschirm erzeugt. Das ist nicht anders als bei document.write(). Die Zeichenkette ist ein paar Zeichen länger, aber das sollte in dem Zusammenhang irrelevant sein.

Wie oft taucht denn hier im Forum die Frage auf, warum nach document.write alles weg ist? So ein Grundlagentutorial sollte dafür sorgen, dass diese Frage nicht mehr auftaucht.

Dann tauchen da eben andere Fragen auf. Zum Beispiel die, warum die Ausgabe nicht erfolgt. Vielleicht weil der Probleminhaber ein Konstrukt, das aufgrund seiner Komplexität noch nicht vollständig erläutert wird, falsch auf andere Anwendungsfälle zu übertragen versucht.

Das ist ein Argument.

Mir tauchen dabei allerdings zu viele „Vielleichts“ auf. Das Problem mit document.write() ist real.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Mein Punkt ist (und war es von Anfang an): Der Leser muss document.querySelector('#ausgabe').innerText an der Stelle gar nicht weiter verstehen. Es muss lediglich nur verwenden.

Das beißt sich meiner Meinung nach sehr - erstens mit unserem Motto „Die Energie des Verstehens“, zweitens mit der Art und Weise, wie wir ansonsten Tutorial schreiben. Und ich halte es auch nicht für gut.

Das Einzige, was er dabei verstehen muss, ist, dass das die Ausgabe auf dem Bildschirm erzeugt. Das ist nicht anders als bei document.write(). Die Zeichenkette ist ein paar Zeichen länger, aber das sollte in dem Zusammenhang irrelevant sein.

Du weigerst dich offensichtlich, anzuerkennen, dass in diesen paar Zeichen mehr ein ganzer Haufen Konzepte versteckt ist - und es kann irgendwie nicht unser Ziel sein, Anfänger (auch nicht im ersten Kapitel) mit einem „nimm das mal so hin“ abzuspeisen. Wir möchten, dass die Leute, die zu uns kommen, verstehen. Wir möchten Sie dazu erziehen, Konzepte zu hinterfragen und eigene Entscheidungen zu treffen. Wir wollen nicht auch noch innerhalb des Anfängertutorial Fragen offen lassen.

Falls du meinen Worten keinen Glauben schenkst, so wie du es mit den Worten von Felix gehalten hast: Es gibt hier einen Thread der dir beweist, dass ein aufmerksamer Tutorial-Leser sich eben diese Gedanken doch macht. Auch dort gab es ein Konzept im Tutorial (window.prompt()), das einfach mit einem „das funktioniert so“ eingeführt wurde, ohne im Detail zu erläutern, was passiert. Mit der Folge, dass die Leser darüber stolpern und das dahinterstehende Konzept nicht zur Gänze erfassen. Das zum Prinzip zu erklären ist ein didaktischer Super-GAU. Und wenn es in diesem Thread nicht um das zweite Argument von prompt gegangen wäre, sondern um document.querySelector('#ausgabe').innerText, dann wäre ich damit nicht mit einem Satz so fertig geworden, dass der wissbegierige Leser mit der Erläuterung zufrieden ist, und dann wäre er nicht nur kurz dran hängen geblieben, sondern hätte eventuell aufgrund der auf ihn einprasselnden Komplexität den Rückzug angetreten.

Grüße,

RIDER

[JürgenB]

Hallo Janosch,

Mein Punkt ist (und war es von Anfang an): Der Leser muss document.querySelector('#ausgabe').innerText an der Stelle gar nicht weiter verstehen. Es muss lediglich nur verwenden.

Das beißt sich meiner Meinung nach sehr - erstens mit unserem Motto „Die Energie des Verstehens“, zweitens mit der Art und Weise, wie wir ansonsten Tutorial schreiben. Und ich halte es auch nicht für gut.

ich verstehe ehrlich gesagt nicht so ganz, warum ein "hingeworfenes" document.write einfacher oder didaktischer sein soll, als ein "hingeworfenes" document.querySelector('#ausgabe').innerText.

Den Satz aus dem Tutorial

Der Rechenweg wird in der Variablen text gespeichert und dann mit document.write ausgegeben.

musste man dann nur in

Der Rechenweg wird in der Variablen text gespeichert und dann mit document.querySelector('#ausgabe').innerText ausgegeben.

ändern und dann auf querySelector verlinken. Und das HTML-Grundgerüst sollte doch auch bekannt sein.

Und wenn querySelector nicht konsensfähig ist, nehmt alert, aber nicht document.write.

Gruß
Jürgen

[dedlfix]

Tach!

Und wenn querySelector nicht konsensfähig ist, nehmt alert, aber nicht document.write.

Ich denke, das könnte man als Kompromiss nehmen. alert() ist nicht schön, aber es ist bereits in anderen Beispielen verwendet worden und sollte auch wegen seiner Unschönheit eher zeigen, dass diese Ausgabe nur für den Zweck des Beispiels gewählt wurde. Nichtsdestotrotz kann man irgendwo einmalig anmerken, dass es noch weitere Arten gibt, wie Ergebnisse und andere Dinge in die Ausgabe kommen können, die Thema eines weiteren Tutorials sind, mit Verweis darauf. Das dürfte weder unüblich noch didaktisch großartig bedenklich sein.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Und wenn querySelector nicht konsensfähig ist, nehmt alert, aber nicht document.write.

Ich denke, das könnte man als Kompromiss nehmen. alert() ist nicht schön, aber es ist bereits in anderen Beispielen verwendet worden und sollte auch wegen seiner Unschönheit eher zeigen, dass diese Ausgabe nur für den Zweck des Beispiels gewählt wurde.

Das Zusammenspiel von HTML/DOM und JavaScript ganz aus einem Tutorial herauszuhalten, in dem es um Sprachgrundlagen von JavaScript wie if und for-Schleifen geht, klingt für mich nach einem Plan.

Wie war das mit dem Aufzeigen von Debugging? Wenn der Gebrauch des Entwicklerwerkzeugs schon erklärt wurde, könnte die Ausgabe auch mit console.log() erfolgen. Aber nur wenn.

LLAP 🖖

[dedlfix]

Tach!

Wie war das mit dem Aufzeigen von Debugging? Wenn der Gebrauch des Entwicklerwerkzeugs schon erklärt wurde, könnte die Ausgabe auch mit console.log() erfolgen. Aber nur wenn.

Das fehlt in dem Tutorial noch. Meiner Meinung nach, sollte das an einer sehr frühen Position behandelt werden, denn das ist bereits für die ersten Schritte wichtig. Nicht selten fangen die Lernenden gleich an, selbst zu probieren (zu wünschen wäre das jedenfalls), auch Dinge, die noch nicht behandelt wurden, die sie sich einfach so zusammenreimen, und dabei sind meist auch Fehler an der Tagesordnung. Wenn man dann bereits ein Werkzeug und dessen grundlegende Bedienung kennt, mit dem man Untersuchungen anstellen kann, hilft das sowohl für das Verständnis und auch eine Vorgehensweise kennenzulernen, die man ständig braucht, denn Fehler, die man debuggen muss, hat man immer wieder.

dedlfix.

[Camping_RIDER]

Aloha ;)

Wie war das mit dem Aufzeigen von Debugging? Wenn der Gebrauch des Entwicklerwerkzeugs schon erklärt wurde, könnte die Ausgabe auch mit console.log() erfolgen. Aber nur wenn.

Das fehlt in dem Tutorial noch. Meiner Meinung nach, sollte das an einer sehr frühen Position behandelt werden, denn das ist bereits für die ersten Schritte wichtig. Nicht selten fangen die Lernenden gleich an, selbst zu probieren (zu wünschen wäre das jedenfalls), auch Dinge, die noch nicht behandelt wurden, die sie sich einfach so zusammenreimen, und dabei sind meist auch Fehler an der Tagesordnung. Wenn man dann bereits ein Werkzeug und dessen grundlegende Bedienung kennt, mit dem man Untersuchungen anstellen kann, hilft das sowohl für das Verständnis und auch eine Vorgehensweise kennenzulernen, die man ständig braucht, denn Fehler, die man debuggen muss, hat man immer wieder.

Full ACK, aber: das erfordert dann im Zweifel einen neuen Artikel, dessen Struktur anders ist. In den Vorhandenen lässt sich das jedenfalls nicht so einfach verwursten, da muss man dann schon neu konzipieren.

Grüße,

RIDER

[Christian Kruse]

Hallo JürgenB,

Mein Punkt ist (und war es von Anfang an): Der Leser muss document.querySelector('#ausgabe').innerText an der Stelle gar nicht weiter verstehen. Es muss lediglich nur verwenden.

Das beißt sich meiner Meinung nach sehr - erstens mit unserem Motto „Die Energie des Verstehens“, zweitens mit der Art und Weise, wie wir ansonsten Tutorial schreiben. Und ich halte es auch nicht für gut.

ich verstehe ehrlich gesagt nicht so ganz, warum ein "hingeworfenes" document.write einfacher oder didaktischer sein soll, als ein "hingeworfenes" document.querySelector('#ausgabe').innerText.

ACK. Auch hinter document.write stehen eine Menge Konzepte, die erst verstanden werden müssen. Zuzüglich zu den vielen Problemen.

Und wenn querySelector nicht konsensfähig ist, nehmt alert, aber nicht document.write.

ACK.

LG,
CK

[Camping_RIDER]

Aloha ;)

Mein Punkt ist (und war es von Anfang an): Der Leser muss document.querySelector('#ausgabe').innerText an der Stelle gar nicht weiter verstehen. Es muss lediglich nur verwenden.

Das beißt sich meiner Meinung nach sehr - erstens mit unserem Motto „Die Energie des Verstehens“, zweitens mit der Art und Weise, wie wir ansonsten Tutorial schreiben. Und ich halte es auch nicht für gut.

ich verstehe ehrlich gesagt nicht so ganz, warum ein "hingeworfenes" document.write einfacher oder didaktischer sein soll, als ein "hingeworfenes" document.querySelector('#ausgabe').innerText.

document.write ist (wie window.alert) einfach ein Funktionsaufruf, dem das, was ausgegeben werden soll, mitgegeben wird. Sowohl document.write als auch window.alert sind dabei recht „sprechend“ („schreibe ins Dokument“, „melde im Fenster“). Das ist Kost, die sehr einfach zu schlucken und zu verdauen ist. (Übrigens console.log auch, aber da ist das Problem, dass man dann erstmal die Konsole einführen müsste, sich was für Lesegeräte ohne Konsole überlegen muss ...)

document.querySelector('#ausgabe').innerText = hat folgendes:

• ein kryptisches querySelector dessen Namensgebung man nur versteht, wenn man weiß, dass das Feature mal von jQuery übernommen wurde, und das nicht für sich spricht

• einen Funktionsaufruf mit einem Argument (das ist die einzige Komplexität, die sich die Methode mit den anderen genannten teilt)

• einen CSS-id-Selektor, der voraussetzt, dass man CSS vorher gelernt und verstanden hat, und, dass man versteht, dass man hier CSS-Syntax innerhalb von Javascript verwenden kann (ein eher neues Konzept)

• greift auf eine Eigenschaft eines Node zurück

• überschreibt diese Eigenschaft mit einem Wert was eine Reaktion des Browsers auslöst (man bedenke, dass das nicht trivial ist - in anderen Sprachen / Kontexten assoziiert man Funktionsaufrufe mit Reaktion, nicht Wertveränderungen!)

Den Satz aus dem Tutorial

Der Rechenweg wird in der Variablen text gespeichert und dann mit document.write ausgegeben.

musste man dann nur in

Der Rechenweg wird in der Variablen text gespeichert und dann mit document.querySelector('#ausgabe').innerText ausgegeben.

ändern und dann auf querySelector verlinken.

Nein, auf keinen Fall! Das durchbricht den Lesefluss und den Wissenserwerb nachhaltig. Der Artikel zu querySelector (der, stimme ich dir zu, verlinkt werden müsste, wenn man es verwendet) strotzt nur so von Dingen, die für den blutigen JS-Anfänger weit über sein Verständnis hinausgehen. Klickt er diesen Link aus Interesse an wird er unter ein Bombardement genommen, bei dem er nachher vielleicht nicht mehr weiß, wo er ursprünglich war. Kann sein, dass das übertrieben klingt, aber wenn das auch nur bei einem Leser passiert ist das schon zuviel. Wir reden hier vom grundlegendsten Grundlagenartikel überhaupt. Ein Artikel, der nichtmal...

Und das HTML-Grundgerüst sollte doch auch bekannt sein.

...HTML voraussetzt oder verwendet.

Und wenn querySelector nicht konsensfähig ist, nehmt alert, aber nicht document.write.

Interessanter Vorschlag. Was wären deiner Meinung nach die Vorteile von window.alert über document.write? In der Vergangenheit hat man mMn versucht, um alert einen möglichst großen Bogen zu machen. Aus gutem Grund, nämlich weil alert eine Seite inaktiv schaltet und sich in den Vordergrund drängt usw. usf. Auf den ersten Blick erkenne ich den Grund, warum das besser sein soll als document.write, nicht.

Jedenfalls ist window.alert für den Grundlagenartikel eine ernstzunehmendere Alternative für document.write als document.querySelector('#ausgabe').innerText = .

Grüße,

RIDER

[Christian Kruse]

Hallo Camping_RIDER,

document.write ist (wie window.alert) einfach ein Funktionsaufruf, dem das, was ausgegeben werden soll, mitgegeben wird. Sowohl document.write als auch window.alert sind dabei recht „sprechend“ („schreibe ins Dokument“, „melde im Fenster“). Das ist Kost, die sehr einfach zu schlucken und zu verdauen ist.

Erstens sind es keine „einfachen Funktionsaufrufe,” sondern komplexe Vorgänge, die viele Nebenwirkungen nach sich ziehen. Und zweitens muss ein Anfänger schon bereits so viel schlucken, dass er sich an einem querySelector nicht stören wird, sondern es einfach hinnehmen wird – tut er bei einem document.write ja auch.

(Übrigens console.log auch, aber da ist das Problem, dass man dann erstmal die Konsole > document.querySelector('#ausgabe').innerText = hat folgendes: […]

Das ist eine schlechte Argumentation. Einen ähnlichen Argumentationsbaum kann man auch für document.write aufbauen, dieses Konstrukt hat sehr viele Nebenwirkungen und der sichere Umgang damit setzt einiges an Wissen voraus. Dazu erscheint es mir albern anzunehmen, dass ein Anfänger Konstrukt a als Blackbox begreift aber Konstrukt b unbedingt im Detail verstehen möchte.

Außerdem kannst du mit hoher Wahrscheinlichkeit davon ausgehen, dass in der Fachwelt niemand ein Tutorial empfehlen geschweige denn verlinken wird, in dem die Verwendung von document.write – und sei es auch nur durch die Verwendung in Beispielen – propagiert wird. Ich würde es ganz sicher nicht tun.

Und wenn querySelector nicht konsensfähig ist, nehmt alert, aber nicht document.write.

Interessanter Vorschlag. Was wären deiner Meinung nach die Vorteile von window.alert über document.write?

alert erzeugt keine Sicherheitsprobleme, document.write dagegen sehr schnell? Die Verwendung von alert ist fragwürdig, die Verwendung von document.write ein absolutes no-go – es sei denn, man möchte sich lächerlich machen.

LG,
CK

[Camping_RIDER]

Aloha ;)

Interessanter Vorschlag. Was wären deiner Meinung nach die Vorteile von window.alert über document.write?

alert erzeugt keine Sicherheitsprobleme, document.write dagegen sehr schnell? Die Verwendung von alert ist fragwürdig, die Verwendung von document.write ein absolutes no-go – es sei denn, man möchte sich lächerlich machen.

Dann ist für mich window.alert das Mittel der Wahl. Aber immer noch nicht document.querySelector('#ausgabe').innerText = für das Anfängertutorial.

Das ist eine schlechte Argumentation. Einen ähnlichen Argumentationsbaum kann man auch für document.write aufbauen, dieses Konstrukt hat sehr viele Nebenwirkungen und der sichere Umgang damit setzt einiges an Wissen voraus.

Was document.write angeht hast du damit wahrscheinlich Recht. Wenn man document.querySelector('#ausgabe').innerText = mit window.alert vergleicht ist die Argumentation mMn immer noch valide. Es geht nämlich nicht darum, dass ein Anfänger...

Dazu erscheint es mir albern anzunehmen, dass ein Anfänger Konstrukt a als Blackbox begreift aber Konstrukt b unbedingt im Detail verstehen möchte.

...überhaupt ein Konstrukt als Blackbox begreifen soll, sondern vielmehr darum, dass es beim einen Konzept sehr schnell und einfach möglich ist, die Bestandteile des Aufrufs zu erläutern, und beim anderen nicht.

Ich habe niemanden davon freigesprochen, bei window.alert (oder bei document.write) etwas erläutern zu müssen - nur gibt es da an für den Anfänger im Befehl offensichtlichen Anknüpfungspunkten für Fragezeichen sehr viel weniger als bei document.querySelector('#ausgabe').innerText =.

Grüße,

RIDER

[JürgenB]

Hallo Janosch,

Interessanter Vorschlag. Was wären deiner Meinung nach die Vorteile von window.alert über document.write? In der Vergangenheit hat man mMn versucht, um alert einen möglichst großen Bogen zu machen. Aus gutem Grund, nämlich weil alert eine Seite inaktiv schaltet und sich in den Vordergrund drängt usw. usf. Auf den ersten Blick erkenne ich den Grund, warum das besser sein soll als document.write, nicht.

alert, prompt und confirm sind für den einfachen Dialog mit dem User gemacht. Z.B. nehme ich für Fehlermeldungen, die an den User gerichtet sind, auch schon mal alert. console.log richtet sich mMn an den Entwickler. Außerdem ist die Console nicht bei allen Browsern verfügbar.

Bei document.write müsste man den Anfänger möglichst früh vor dem unterschiedlichen Verhalten in und nach der Renderphase warnen.

Die einzige „Nebenwirkung“ von alert ist das schmucklose Aussehen. Das ist „Druck“ genug, um sich nach was anderem umzusehen.

Gruß
Jürgen

[Camping_RIDER]

Aloha ;)

alert, prompt und confirm sind für den einfachen Dialog mit dem User gemacht. Z.B. nehme ich für Fehlermeldungen, die an den User gerichtet sind, auch schon mal alert. console.log richtet sich mMn an den Entwickler. Außerdem ist die Console nicht bei allen Browsern verfügbar.

Bei document.write müsste man den Anfänger möglichst früh vor dem unterschiedlichen Verhalten in und nach der Renderphase warnen.

Akzeptiert^[1]. Dann gerne window.alert statt document.write.

Grüße,

RIDER

---

1. siehe auch die detailliertere Antwort an Christian. ↩︎

[Gunnar Bittersmann]

@@Camping_RIDER

Mein Punkt ist (und war es von Anfang an): Der Leser muss document.querySelector('#ausgabe').innerText an der Stelle gar nicht weiter verstehen. Es muss lediglich nur verwenden.

Das beißt sich meiner Meinung nach sehr - erstens mit unserem Motto „Die Energie des Verstehens“, zweitens mit der Art und Weise, wie wir ansonsten Tutorial schreiben. Und ich halte es auch nicht für gut.

Na, da haben wir doch was, worüber wir reden können.

Das Einzige, was er dabei verstehen muss, ist, dass das die Ausgabe auf dem Bildschirm erzeugt. Das ist nicht anders als bei document.write(). Die Zeichenkette ist ein paar Zeichen länger, aber das sollte in dem Zusammenhang irrelevant sein.

Du weigerst dich offensichtlich, anzuerkennen, dass in diesen paar Zeichen mehr ein ganzer Haufen Konzepte versteckt ist

Im Gegenteil. Ich erkenne das durchaus an. Mein Punkt ist ja gerade, dass der Haufen Konzepte an der Stelle auch versteckt bleiben soll.

und es kann irgendwie nicht unser Ziel sein, Anfänger (auch nicht im ersten Kapitel) mit einem „nimm das mal so hin“ abzuspeisen.

Zum einen wird das – egal womit du als Grundlagen anfängst – gar nicht anders gehen.

Zum anderen trifft das bei document.write() gleichermaßen zu. Deiner Argumentation folgend müsste man sonst ja erklären, das document ein Objekt ist, was das für ein spezielles Objekt ist und dass write() eine Methode ist, die man darauf anwenden kann.

Das will man natürlich an der Stelle ebensowenig wie erlären wie querySelector() und innerText. Und muss man auch nicht.

Es ist nur halt so, dass „nimm das mal so hin“ nicht zu wollen kein Argument für document.write() und gegen document.querySelector('#ausgabe').innerText wäre.

Wir möchten, dass die Leute, die zu uns kommen, verstehen. Wir möchten Sie dazu erziehen, Konzepte zu hinterfragen und eigene Entscheidungen zu treffen.

Gerne.

Wir wollen nicht auch noch innerhalb des Anfängertutorial Fragen offen lassen.

Ein Anfängertutorial wird immer Fragen offen lassen.

Falls du meinen Worten keinen Glauben schenkst, so wie du es mit den Worten von Felix gehalten hast: Es gibt hier einen Thread der dir beweist, dass ein aufmerksamer Tutorial-Leser sich eben diese Gedanken doch macht. Auch dort gab es ein Konzept im Tutorial (window.prompt()), das einfach mit einem „das funktioniert so“ eingeführt wurde, ohne im Detail zu erläutern, was passiert. Mit der Folge, dass die Leser darüber stolpern und das dahinterstehende Konzept nicht zur Gänze erfassen.

Ja, und? Ist doch völlig in Ordnung, dass Nachfragen, die über den Stoff eines Tutorials hinausgehen, im Forum gestellt werden.

Das kann auch bei document.write() geschehen. Nur dass es dann Gesprächsbedarf gibt, den man von vornherein vermeiden sollte.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Du weigerst dich offensichtlich, anzuerkennen, dass in diesen paar Zeichen mehr ein ganzer Haufen Konzepte versteckt ist

Im Gegenteil. Ich erkenne das durchaus an. Mein Punkt ist ja gerade, dass der Haufen Konzepte an der Stelle auch versteckt bleiben soll.

und es kann irgendwie nicht unser Ziel sein, Anfänger (auch nicht im ersten Kapitel) mit einem „nimm das mal so hin“ abzuspeisen.

Zum einen wird das – egal womit du als Grundlagen anfängst – gar nicht anders gehen.

Zum anderen trifft das bei document.write() gleichermaßen zu.

Nein. „Auch teilweise“, nicht „gleichermaßen“. Konzepte die versteckt bleiben ja, ein Haufen davon nein.

Deiner Argumentation folgend müsste man sonst ja erklären, das document ein Objekt ist,

Richtig, das könnte man sogar. Ist in einem Satz erledigt. Das ist das schöne an document, dass der Name eigentlich sehr selbsterklärend ist.

was das für ein spezielles Objekt ist

Nein, das ist nicht relevant an der Stelle.

und dass write() eine Methode ist, die man darauf anwenden kann.

Auch das lässt sich in einem Satz sagen, ohne, dass dabei irgendwas unklar bleibt.

Beispiel:

„Der Rechenweg wird in der Variablen text gespeichert und dann mit document.write(text) ausgegeben. Dabei ist document ein Objekt, das den Inhalt des Browserfensters (das „Dokument“) darstellt und write eine Methode des Objekts document, die bewirkt, dass der Text text ins Dokument geschrieben wird.“

Damit sind alle Konzepte ausreichend erklärt. Wenn Wert darauf gelegt wird, zu sagen, dass document.write nicht verwendet werden sollte, kann man noch ein

„Beachten Sie: `document.write hat gravierende Nachteile, wenn es nicht wie hier beim Aufruf der Seite direkt ausgeführt wird, weshalb man in der Praxis meist andere Ausgabemethoden verwendet.“

nachsetzen.

Das will man natürlich an der Stelle ebensowenig wie erlären wie querySelector() und innerText. Und muss man auch nicht.

Irrtum. Das kann man in aller Kürze erklären, querySelector und innerText nicht. Gründe habe ich im Detail hier genannt; die Konzepte sind einfach mehr und deutlich weniger eingängig.

Es ist nur halt so, dass „nimm das mal so hin“ nicht zu wollen kein Argument für document.write() und gegen document.querySelector('#ausgabe').innerText wäre.

„Nimm das mal so hin“ sollte gar nicht auftauchen. Da hast du Recht. Bei document.write (oder window.alert, wenn das lieber gesehen ist) lässt sich das „Nimm das mal so hin“ zügig auflösen ohne großartig Komplexität zu erzeugen („einfache“ (d.h. nicht hintereinanderausgeführte) Methodenaufrufe kommen im Tutorial ja sowieso vor, z.B. mit window.prompt - das Konzept ist also sowieso schon im Artikelfokus). Bei document.querySelector('#ausgabe').innerText muss man viel mehr erklären, und zwar abseits des eigentlichen Artikelfokus.

Wir wollen nicht auch noch innerhalb des Anfängertutorial Fragen offen lassen.

Ein Anfängertutorial wird immer Fragen offen lassen.

Richtig. Die Betonung meines Satzes war aber absichtlich auf innerhalb gelegt. Fragen dürfen offen bleiben, aber sie sollten so offen bleiben, dass man das Tutorial erst komplett verstehen und sich den Fragen danach widmen kann, nicht im Workflow während des Lesens.

Das ist übrigens etwas, was ich dem Vorlesungsskript, an dem ich gerade lerne, auch vorwerfen muss. Die ersten zwei Foliensätze wiesen so viele Konzepte auf, die nicht im Lesefluss erklärt wurden, dass ich ständig zu google greifen musste, um mir was noch einmal erklären zu lassen, was da so implizit verwendet wurde - und das hat meinen Lernfluss beträchtlich gestört, würde ich sagen.

Falls du meinen Worten keinen Glauben schenkst, so wie du es mit den Worten von Felix gehalten hast: Es gibt hier einen Thread der dir beweist, dass ein aufmerksamer Tutorial-Leser sich eben diese Gedanken doch macht. Auch dort gab es ein Konzept im Tutorial (window.prompt()), das einfach mit einem „das funktioniert so“ eingeführt wurde, ohne im Detail zu erläutern, was passiert. Mit der Folge, dass die Leser darüber stolpern und das dahinterstehende Konzept nicht zur Gänze erfassen.

Ja, und? Ist doch völlig in Ordnung, dass Nachfragen, die über den Stoff eines Tutorials hinausgehen, im Forum gestellt werden.

Das sollte aber nicht über den Stoff des Tutorials hinausgehen. Auch bei window.prompt gehört im Tutorial ein erklärender Halbsatz hin. „Der zweite, leere Parameter ermöglicht die Übergabe eines Defaultwerts.“

Wenn während dem Lesen und Verstehen das Forum geöffnet werden muss, um etwas nachzufragen, dann versagt das Tutorial. Das darf bei schwierigen Konzepten passieren, wenn alles dasteht und man Verständnisschwierigkeiten hat. Aber nicht bei einem Grundlagentutorial. Da stört es einfach den Workflow des Lerners.

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Nachdem ich inzwischen von window.alert als Alternative zu document.write überzeugt bin:

Beispiel:

„Der Rechenweg wird in der Variablen text gespeichert und dann mit document.write(text) ausgegeben. Dabei ist document ein Objekt, das den Inhalt des Browserfensters (das „Dokument“) darstellt und write eine Methode des Objekts document, die bewirkt, dass der Text text ins Dokument geschrieben wird.“

„Der Rechenweg wird in der Variablen text gespeichert und dann mit window.alert(text) ausgegeben. Dabei ist window ein Objekt, das den das Browserfensters darstellt und alert eine Methode des Objekts document, die bewirkt, dass der Benutzer eine Meldung angezeigt bekommt.“

Damit sind alle Konzepte ausreichend erklärt. Wenn Wert darauf gelegt wird, zu sagen, dass document.write nicht verwendet werden sollte, kann man noch ein

„Beachten Sie: `document.write hat gravierende Nachteile, wenn es nicht wie hier beim Aufruf der Seite direkt ausgeführt wird, weshalb man in der Praxis meist andere Ausgabemethoden verwendet.“

nachsetzen.

Damit sind alle Konzepte ausreichend erklärt. Wenn Wert darauf gelegt wird, zu sagen, dass window.alert nicht perfekt ist, kann man noch ein

„Beachten Sie: `window.alert hat ein paar Nachteile, allen voran, dass man das Aussehen der Meldung nicht verändern kann und, dass es eine Benutzerinteraktion erzwingt, weshalb man in der Praxis auf Webseiten oft andere Ausgabemethoden verwendet.“

nachsetzen.

Grüße,

RIDER

[JürgenB]

Hallo,

„Der Rechenweg wird in der Variablen text gespeichert und dann mit document.write(text) ausgegeben. Dabei ist document ein Objekt, das den Inhalt des Browserfensters (das „Dokument“) darstellt und write eine Methode des Objekts document, die bewirkt, dass der Text text ins Dokument geschrieben wird.“

„Der Rechenweg wird in der Variablen text gespeichert und dann mit window.alert(text) (korrigiert) ausgegeben. Dabei ist window ein Objekt, das den das Browserfensters darstellt und alert eine Methode des Objekts document, die bewirkt, dass der Benutzer eine Meldung angezeigt bekommt.“

das ist schon zu viel. Ein

„Der Rechenweg wird in der Variablen text gespeichert und dann mit window.alert(text) ausgegeben."

reicht. Mit so viel Text kann man ja auch ein querySelector einführen 😀

Gruß
Jürgen

[Camping_RIDER]

Aloha ;)

[Danke für die Korrektur, hab das mal ganz frech in den ursprünglichen Beitrag reineditiert.]

„Der Rechenweg wird in der Variablen text gespeichert und dann mit window.alert(text) ausgegeben."

reicht. Mit so viel Text kann man ja auch ein querySelector einführen 😀

„Der Rechenweg wird in der Variablen text gespeichert und dann mit window.alert(text) ausgegeben."

reicht, finde ich auch, ich empfinde

„Der Rechenweg wird in der Variablen text gespeichert und dann mit document.querySelector('#ausgabe').innerText = text ausgegeben."

als zu viel Text 😜

Spaß beiseite, eigentlich nervt mich die Diskussion. Offenbar gibt es eben unterschiedliche Standpunkte dazu, wie viel Blackbox okay ist und wie eine Blackbox verpackt zu sein hat.

Mich überkommt die Lust, der Diskussion ein Schnippchen zu schlagen und stattdessen einfach den Artikel zu schreiben, der die Konsole einführt und daran die Programmiergrundlagen erklärt 😝

Und hätte ich nicht morgen eine Prüfung zu funktionaler Programmierung und noch viel zu wenig Ahnung davon - ich würde es tun^[1].

Grüße,

RIDER

---

1. Wenn ich es irgendwie schaffe, tu ichs trotzdem - nur eben nicht mehr heute. ↩︎

[JürgenB]

Hallo,

Und hätte ich nicht morgen eine Prüfung zu funktionaler Programmierung und noch viel zu wenig Ahnung davon - ich würde es tun[^1].

sowas must du als Lehramtsstudent machen? Hast du als (Zweit-)Fach Informatik?

Gruß
Jürgen

[Christian Kruse]

Hallo JürgenB,

Und hätte ich nicht morgen eine Prüfung zu funktionaler Programmierung und noch viel zu wenig Ahnung davon - ich würde es tun[^1].

sowas hast du als Lehramtsstudent das Privileg machen zu dürfen? Hast du als (Zweit-)Fach Informatik?

Ich hab das mal für dich korrigiert ;-)

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

sowas hast du als Lehramtsstudent das Privileg machen zu dürfen? Hast du als (Zweit-)Fach Informatik?

Ich hab das mal für dich korrigiert ;-)

YMMD.

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

Und hätte ich nicht morgen eine Prüfung zu funktionaler Programmierung und noch viel zu wenig Ahnung davon - ich würde es tun[^1].

sowas must du als Lehramtsstudent machen? Hast du als (Zweit-)Fach Informatik?

Ich habe seit mittlerweile 4 vollen Semestern ein Studium zum Bachelor Informatik als Parallelstudium am Laufen (und bin damit fast fertig).

Wenn alles gut läuft (nicht 100% sicher) bin ich Ende April mit dem bisher noch fehlenden Staatsexamen in Mathe fertig mit dem Lehramtsstudium und dann fehlt mir für den Informatik Bachelor nur noch eine Vorlesung und die Bachelorarbeit, das kann ich dann also bis Sommer/Herbst abschließen, bevor ich Anfang des nächsten Jahres mit dem Lehramt ins Referendariat gehe.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Zum anderen trifft das bei document.write() gleichermaßen zu.

Nein. „Auch teilweise“, nicht „gleichermaßen“. Konzepte die versteckt bleiben ja, ein Haufen davon nein.

Hier geht es nicht um Quantität. Konzepte (egal wie viele), die versteckt bleiben und das auch bleiben sollten. Blackbox, wie CK sagte.

Deiner Argumentation folgend müsste man sonst ja erklären, das document ein Objekt ist,

Richtig, das könnte man sogar.

Nein. Nicht Thema dieses Tutorials.

und dass write() eine Methode ist, die man darauf anwenden kann.

Auch das lässt sich in einem Satz sagen, ohne, dass dabei irgendwas unklar bleibt.

Nicht Thema dieses Tutorials.

„Der Rechenweg wird in der Variablen text gespeichert und dann mit document.write(text) ausgegeben. Dabei ist document ein Objekt, das den Inhalt des Browserfensters (das „Dokument“) darstellt und write eine Methode des Objekts document, die bewirkt, dass der Text text ins Dokument geschrieben wird.“

Damit sind alle Konzepte ausreichend erklärt.

Nicht Thema dieses Tutorials.

Wenn Wert darauf gelegt wird, zu sagen, dass document.write nicht verwendet werden sollte, kann man noch ein

„Beachten Sie: `document.write hat gravierende Nachteile, wenn es nicht wie hier beim Aufruf der Seite direkt ausgeführt wird, weshalb man in der Praxis meist andere Ausgabemethoden verwendet.“

nachsetzen.

Etwas verwenden um gleich darauf zu sagen „Ich darf das, aber ihr nicht!“ – Nein.

Das will man natürlich an der Stelle ebensowenig wie erlären wie querySelector() und innerText. Und muss man auch nicht.

Irrtum. Das kann man in aller Kürze erklären, querySelector und innerText nicht.

Nicht Thema dieses Tutorials.

„Nimm das mal so hin“ sollte gar nicht auftauchen. Da hast du Recht.

Was willst du mir da in den Mund legen? Mein Punkt war, dass „Nimm das mal so hin“ in einem Tutorial auftauchen darf und auch auftauchen muss. (Das sollte freilich nicht explizit sein.)

Bei document.write (oder window.alert, wenn das lieber gesehen ist) […] - das Konzept ist also sowieso schon im Artikelfokus).

Nein. Nicht Thema dieses Tutorials.

Bei document.querySelector('#ausgabe').innerText muss man viel mehr erklären, und zwar abseits des eigentlichen Artikelfokus.

Ja. Nicht Thema dieses Tutorials.

Ein Anfängertutorial wird immer Fragen offen lassen.

Richtig. Die Betonung meines Satzes war aber absichtlich auf innerhalb gelegt. Fragen dürfen offen bleiben, aber sie sollten so offen bleiben, dass man das Tutorial erst komplett verstehen und sich den Fragen danach widmen kann, nicht im Workflow während des Lesens.

Man kann das Tutorial komplett verstehen ohne document.querySelector('#ausgabe').innerText zu hinterfragen. Blackbox. Und weder document noch querySelector() noch innerText sollten an dieser Stelle irgendwohin verlinkt sein und den Leser vom Thema dieses Tutorials abschweifen lassen.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Nein. „Auch teilweise“, nicht „gleichermaßen“. Konzepte die versteckt bleiben ja, ein Haufen davon nein.

Hier geht es nicht um Quantität. Konzepte (egal wie viele), die versteckt bleiben und das auch bleiben sollten. Blackbox, wie CK sagte.

Ich weiß nicht wie es dir geht, aber ich bin wissbegierig genug, um Blackboxen doof zu finden. Je mehr Konzepte und je offensichtlicher die Quantität, umso auffälliger und unbefriedigender die Blackbox.

In document.querySelector('#ausgabe').innerText = stecken ganz viele kryptische Sachen drin, deren logischer Sinn sich mir als Anfänger überhaupt nicht erschließt.

Wenn das meine Blackbox ist fühlt sich die Blackbox an wie Voodoo.

In window.alert denke ich mir als Anfänger „aha, es geht um ein Fenster und um alert, hm, was bedeutet alert noch gleich, irgendwas mit Alarm“ und dann steht im Folgesatz: „damit wird im Browserfenster eine Meldung ausgegeben“ und dann passt das völlig zu meiner Erwartung.

Dann habe ich immer noch nicht verstanden, was ein Objekt ist, was eine Methode ist, was ein Parameter ist, was der Punkt da soll, was der Browser intern damit tut ... also habe ich weiterhin eine Blackbox.

Aber diese Blackbox fühlt sich nicht an wie Voodoo, sondern sie tut, was ich instinktiv von ihr erwarte und weil da keinerlei kognitive Dissonanz drinsteckt (ganz anders als bei Begriffen wie „querySelector“ und „innerHTML“) kann ich die Blackbox auch als Wissbegieriger ganz einfach hinnehmen.

… Nicht Thema dieses Tutorials. … Nicht Thema dieses Tutorials. … Nicht Thema dieses Tutorials. … Nicht Thema dieses Tutorials. … Nein. Nicht Thema dieses Tutorials. … Ja. Nicht Thema dieses Tutorials.

Unsere Einschätzung, was Thema dieses Tutorials ist, geht offenbar stark auseinander. Da im Tutorial noch an anderer Stelle das Schema <OBJEKT>.<METHODE>(<PARAMETER>) verwendet wird (window.prompt, Math.sqrt, zahl.toFixed) halte ich eine solche wie die genannte Zusatzerläuterung sehr wohl für Thema dieses Tutorials - man kann das jetzt doof finden oder nicht, dass diese Sachen vorkommen, aber sie kommen nunmal vor und dann gehören sie auch zumindest kurz erläutert. In einem Anfängertutorial sollte das Standard sein.

Ein Anfängertutorial sollte in sich schlüssige Erklärungen bieten (selbst wenn sie nicht in allen Aspekten formal korrekt sein sollten) und innerhalb des Lernflusses keine Fragen aufwerfen. So wie man eben auch in der Schule das Rechnen mit den Zahlen von 1-10 lernt, ohne was von den Peano-Axiomen zu wissen und ohne zu wissen, dass die Zahlen von 1-10 natürliche Zahlen sind. Blackboxen dürfen vorkommen, Auslassungen dürfen vorkommen, aber sie dürfen nicht offensichtlich sein, sie dürfen keine kognitive Dissonanz erzeugen und die gewählte (nicht notwendigerweise fachlich vollständige) Erläuterung muss in sich schlüssig sein.

Das ist, was ein Tutorial von einem Fachtext unterscheidet. Und Schulunterricht / Tutorium von Vorlesung.

„Nimm das mal so hin“ sollte gar nicht auftauchen. Da hast du Recht.

Was willst du mir da in den Mund legen? Mein Punkt war, dass „Nimm das mal so hin“ in einem Tutorial auftauchen darf und auch auftauchen muss. (Das sollte freilich nicht explizit sein.)

Nicht nur „nicht explizit“, sondern „gar nicht wahrnehmbar“, also „gar nicht“. Ansonsten sind wir schon wieder weg vom Anfängertutorial.

Man kann das Tutorial komplett verstehen ohne document.querySelector('#ausgabe').innerText zu hinterfragen. Blackbox.

Nein. Nicht einfach „Blackbox“. Eine „Blackbox“ ist ein Stilmittel, das man mit Bedacht verwenden muss, und zwar so, dass es dem Lerner nicht störend auffällt. Warum das im einen Fall gegeben ist und im Anderen nicht habe ich oben schon erläutert.

Und weder document noch querySelector() noch innerText sollten an dieser Stelle irgendwohin verlinkt sein und den Leser vom Thema dieses Tutorials abschweifen lassen.

Vollkommen richtig. Das Tutorial muss aber so sein, dass der Leser diese Verlinkungen auch nicht vermisst. Deshalb darf eine Blackbox nicht stark auffallen oder stören.

Grüße,

RIDER

[Christian Kruse]

Hallo Camping_RIDER,

Ich weiß nicht wie es dir geht, aber ich bin wissbegierig genug, um Blackboxen doof zu finden. Je mehr Konzepte und je offensichtlicher die Quantität, umso auffälliger und unbefriedigender die Blackbox.

Blackboxen nimmt man als Lernender immer hin, zwangsläufig. Erst im Laufe des Lernprozesses werden aus den Blackboxen irgendwann transparente Boxen. Ein natürlicher Teil des Lernprozesses, den ich gerade erst bei Entdecken einer neuen Liebe erneut durchlaufen habe.

In document.querySelector('#ausgabe').innerText = stecken ganz viele kryptische Sachen drin, deren logischer Sinn sich mir als Anfänger überhaupt nicht erschließt.

Wenn das meine Blackbox ist fühlt sich die Blackbox an wie Voodoo.

In window.alert denke ich mir als Anfänger „aha, es geht um ein Fenster und um alert, hm, was bedeutet alert noch gleich, irgendwas mit Alarm“ und dann steht im Folgesatz: „damit wird im Browserfenster eine Meldung ausgegeben“ und dann passt das völlig zu meiner Erwartung.

Ich verstehe dein Argument hier nicht. Ist dir querySelector().innerText zu schlecht lesbar? Darüber kann man streiten, immerhin ist innerText auch ein sehr sprechender Name. Aber falls nicht, jo mei, dann kapsele das halt in eine Funktion zeigeText("foo").

Aber diese Blackbox fühlt sich nicht an wie Voodoo, sondern sie tut, was ich instinktiv von ihr erwarte und weil da keinerlei kognitive Dissonanz drinsteckt (ganz anders als bei Begriffen wie „querySelector“ und „innerHTML“) kann ich die Blackbox auch als Wissbegieriger ganz einfach hinnehmen.

Ich glaube, dass das eine ziemlich einseitige Wahrnehmung ist.

LG,
CK

[Camping_RIDER]

Aloha ;)

Ist dir querySelector().innerText zu schlecht lesbar?

Ja, im Sinne von nicht sehr intuitiv verständlich.

Darüber kann man streiten, immerhin ist innerText auch ein sehr sprechender Name.

Ja, aber vielleicht bin ich dann schon über den querySelector gestolpert. Oder über den CSS-Selektor, den ich da als String übergeben muss, oder …

Aber falls nicht, jo mei, dann kapsele das halt in eine Funktion zeigeText("foo").

Das würde einige meiner Argumente entschärfen, richtig, Problem dabei: Es hat eigene Nachteile - zum Beispiel ist der Lerner dann von meiner Ausführumgebung abhängig und kann das bei mir gelernte Wissen nicht unabhängig verwenden. Das empfinde ich als ausreichend negatives Argument, um das nicht in Erwägung zu ziehen, solange mit window.alert("foo") ein - visuell gesehen - nur in einer Kleinigkeit (der Punkt) komplexeres Konstrukt zur Verfügung steht, das nicht von meiner Ausführumgebung abhängt.

Aber diese Blackbox fühlt sich nicht an wie Voodoo, sondern sie tut, was ich instinktiv von ihr erwarte und weil da keinerlei kognitive Dissonanz drinsteckt (ganz anders als bei Begriffen wie „querySelector“ und „innerHTML“) kann ich die Blackbox auch als Wissbegieriger ganz einfach hinnehmen.

Ich glaube, dass das eine ziemlich einseitige Wahrnehmung ist.

Das wäre möglich, aber es entspricht nun mal meiner Wahrnehmung. Und wie immer kann sich keiner von uns vorstellen, dass seine Wahrnehmung nicht der der Allgemeinheit entspricht, weil das einfach menschlich ist 😉

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Ich weiß nicht wie es dir geht, aber ich bin wissbegierig genug, um Blackboxen doof zu finden. Je mehr Konzepte und je offensichtlicher die Quantität, umso auffälliger und unbefriedigender die Blackbox.

Blackboxen nimmt man als Lernender immer hin, zwangsläufig. Erst im Laufe des Lernprozesses werden aus den Blackboxen irgendwann transparente Boxen. Ein natürlicher Teil des Lernprozesses, den ich gerade erst bei Entdecken einer neuen Liebe erneut durchlaufen habe.

Da hast du Recht, aber ich weiß aus meiner Erfahrung (die nicht unbedingt mit der Erfahrung Anderer übereinstimmen muss), dass ich Blackboxen nur ungern akzeptiere, selbst wenn ich es muss, und am Liebsten ist es mir und am wenigsten anstrengend finde ich es dann, wenn sie mir nicht vollständig schleierhaft sind, sondern ich ihren Sinn (wenn auch nicht ihre Wirkungsweise) intuitiv erfassen kann.

YMMV.

Grüße,

RIDER

[Matthias Apsel]

Hallo Christian Kruse,

Blackboxen nimmt man als Lernender immer hin, zwangsläufig. Erst im Laufe des Lernprozesses werden aus den Blackboxen irgendwann transparente Boxen.

Sagen wir so: Die Opazität nimmt ab. Man kann etwa wunderbar mithilfe des bestimmten Integrals Flächeninhalte berechnen, ohne den Integralbegriff wirklich verstanden zu haben. (Und es ist trotzdem mehr, als bloßes schematisches Anwenden)

Ein natürlicher Teil des Lernprozesses, den ich gerade erst bei Entdecken einer neuen Liebe erneut durchlaufen habe.

Dein neues Lebenselixir?

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Blackboxen nimmt man als Lernender immer hin, zwangsläufig. Erst im Laufe des Lernprozesses werden aus den Blackboxen irgendwann transparente Boxen.

Sagen wir so: Die Opazität nimmt ab. Man kann etwa wunderbar mithilfe des bestimmten Integrals Flächeninhalte berechnen, ohne den Integralbegriff wirklich verstanden zu haben. (Und es ist trotzdem mehr, als bloßes schematisches Anwenden)

Das, denke ich, ist eine Wesensfrage. Ich z.B. habe durchaus Spaß daran, Blackboxen zu verstehen.

Ein natürlicher Teil des Lernprozesses, den ich gerade erst bei Entdecken einer neuen Liebe erneut durchlaufen habe.

Dein neues Lebenselixir?

Richtig, sozusagen der Jungbrunnen^[1].

Aber mal im Ernst, das Erlang-Ökosystem ist ja schon lange eins meiner Faibles. Ich habe eine Zeit lang sehr viel Erlang geschrieben, hatte aber leider keinen praktischen Anwendungsfall dafür. Das hat sich mit Elixir gleich doppelt geändert, sowohl im Job als auch im Hobby-Bereich 😍

LG,
CK

---

1. elixir fountain, you get it? Get it? ↩︎

[Gunnar Bittersmann]

@@Christian Kruse

Ein natürlicher Teil des Lernprozesses, den ich gerade erst bei Entdecken einer neuen Liebe erneut durchlaufen habe.

Neuer Hund oder neue Frau?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Ein natürlicher Teil des Lernprozesses, den ich gerade erst bei Entdecken einer neuen Liebe erneut durchlaufen habe.

Neuer Hund oder neue Frau?

Inwiefern hätten ein neuer Hund oder eine neue Frage (beides trifft nicht zu) einen Lernprozess meinerseits nach sich gezogen? 😂

Nein, es betrifft Elixir.

LG,
CK

[Gunnar Bittersmann]

@@Camping_RIDER

Ich weiß nicht wie es dir geht, aber ich bin wissbegierig genug, um Blackboxen doof zu finden.

Hängt stark vom Thema ab. Maches interessiert micht näher, anderes will ich gar nicht genauer wissen.

In document.querySelector('#ausgabe').innerText = stecken ganz viele kryptische Sachen drin, deren logischer Sinn sich mir als Anfänger überhaupt nicht erschließt.

Von mir aus ein Satz à la „Durch document.querySelector('#ausgabe').innerText = gelangt die Ausgabe in das Element mit der ID „ausgabe“.

Ein Anfängertutorial sollte in sich schlüssige Erklärungen bieten (selbst wenn sie nicht in allen Aspekten formal korrekt sein sollten) und innerhalb des Lernflusses keine Fragen aufwerfen. […]

Das ist, was ein Tutorial von einem Fachtext unterscheidet.

Den Unterschied verstehe ich nicht so richtig. Ein Fachtest sollte nicht in sich schlüssige Erklärungen bieten und innerhalb des Lernflusses keine Fragen aufwerfen?

Mein Punkt war, dass „Nimm das mal so hin“ in einem Tutorial auftauchen darf und auch auftauchen muss. (Das sollte freilich nicht explizit sein.)

Nicht nur „nicht explizit“, sondern „gar nicht wahrnehmbar“

So war’s gemeint.

also „gar nicht“.

Hm.

Und weder document noch querySelector() noch innerText sollten an dieser Stelle irgendwohin verlinkt sein und den Leser vom Thema dieses Tutorials abschweifen lassen.

Vollkommen richtig. Das Tutorial muss aber so sein, dass der Leser diese Verlinkungen auch nicht vermisst.

Obiger Satz.

Und falls jemand doch so wissbegierig ist wie du, kann sie die Suchmaschine ihrer Wahl ja mit den Begriffen füttern. Dann sollte ihr auch klar sein, dass sie den Pfad des Tutorials bewusst verlässt.

Deshalb darf eine Blackbox nicht stark auffallen oder stören.

Das ist das Konzept einer Blackbox: Ein in sich geschlossenes System, von dem man das nach außen sichtbare Verhalten (Eingabe, Ausgabe) kennt.

Wenn eine Blackbox stört, ist sie nicht richtig abgeschlossen oder nicht richtig black.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Deshalb darf eine Blackbox nicht stark auffallen oder stören.

Das ist das Konzept einer Blackbox: Ein in sich geschlossenes System, von dem man das nach außen sichtbare Verhalten (Eingabe, Ausgabe) kennt.

Wenn eine Blackbox stört, ist sie nicht richtig abgeschlossen oder nicht richtig black.

Vielleicht ist das mit das Problem. Vielleicht ist sie nicht richtig black.

In document.querySelector('#ausgabe').innerText = text stecken ganz viele Dinge drin, die ich (als Anfänger) zwar nicht verstehe, die ich aber auch nicht als black sehen kann, weil sie ja doch irgendwo zu mir sprechen.

Ähnliches gilt natürlich für window.alert(text), aber da kann ich mit einem kurzen Satz die Dinge, die nicht richtig black sehen kann transparent machen, während die Dinge daran, die schon black sind (Funktionsweise, was bedeutet der Punkt, wie reagiert der Browser) black bleiben.

Auch bei document.querySelector('#ausgabe').innerText = text gibt es Dinge, die sind black und Dinge, die sind nicht so black. Im Gegensatz zu window.alert(text) sind der Dinge, die *nicht so * black sind, hier relativ viele, die man nicht einfach alle transparent machen kann, ohne zu sehr abzuschweifen.

Vielleicht ist mein Punkt so verständlicher?

Grüße,

RIDER

[Matthias Apsel]

Hallo Felix Riesterer,

Ich bin an dieser Stelle eher bei Gunnar als bei dir.

<p>Dieser Satz wird mit JavaScript … <span id="ausgabe"></span></p>

<script>document.querySelector("#ausgabe").innerText = "zuende geführt.";</script>

Die Lernenden bekommen ein auch für komplexere Situationen zuverlässig funktionierendes und stabiles Konzept in die Hand.

Sie lernen:

• JS und HTML sind aufeinander angewiesen
• kennzeichne im HTML die Elemente, die verändert werden sollen
• such dir, wenn es soweit ist, das gewünschte Element heraus
• mach was mit diesem Element

Das ist bei document.write nicht gewährleistet.

Bis demnächst
Matthias

[Der-Dennis]

Hallo Matthias,

was die Frage querySelector vs. document.write betrifft bin ich völlig Eurer Meinung.

Ich bin nur der Ansicht, dass das hier die falsche Fragestellung ist. Ich denke das ist auch das, worauf Felix mit dem Begriff „Erstkontakt“ versucht hinzuweisen. Bei der Intention, die der Artikel verfolgt, ist querySelector einfach zu viel. Im Artikel sollte eigentlich überhaupt kein HTML vorkommen, wenn ich die Zielsetzung richtig verstanden habe.

Man darf meiner Meinung nach gerne die Sinnhaftigkeit der Zielsetzung bzw. den ganzen Artikel hinterfragen. Da jetzt aber einfach HTML hinzuzufügen verändert das Ziel (wie ich es verstanden habe) so grundlegend, dass in dem Fall gleich ein komplett neuer Artikel geschrieben werden kann.

Gruß
Dennis

[Matthias Apsel]

Hallo Der-Dennis,

Man darf meiner Meinung nach gerne die Sinnhaftigkeit der Zielsetzung bzw. den ganzen Artikel hinterfragen. Da jetzt aber einfach HTML hinzuzufügen verändert das Ziel (wie ich es verstanden habe) so grundlegend, dass in dem Fall gleich ein komplett neuer Artikel geschrieben werden kann.

Der Artikel beginnt mit Hello World. Ohne HTML. Ich finde ihn gelungen und auch brauchbar, so wie er jetzt ist. Trotz document.write. Aber da der gesamte Artikel auch komplett ohne HTML auskommt, ist das auch in Ordnung so. Mein Beitrag bezieht sich nicht auf den bestehenden Artikel.

<strong class="übertreibung">Leider kommt durch solcherart Diskussionen nicht ein einziges neues Wort ins Wiki</strong> und dass @Matthias Scharwies überhaupt noch die Motivation findet, weiter zu machen, ist bewundernswert.

Bis demnächst
Matthias

[Der-Dennis]

Hallo Matthias,

Ich finde ihn gelungen und auch brauchbar, so wie er jetzt ist.

entschuldige bitte, da habe ich dann Dein Posting missinterpretiert. Hatte mich schon gewundert. Da sind wir uns dann ja einig. Danke für die Klarstellung.

Gruß
Dennis

[Camping_RIDER]

Aloha ;)

<strong class="übertreibung">Leider kommt durch solcherart Diskussionen nicht ein einziges neues Wort ins Wiki</strong> und dass @Matthias Scharwies überhaupt noch die Motivation findet, weiter zu machen, ist bewundernswert.

Naja, die Diskussion war gut und sinnvoll - eine Weile lang. Solange wie sie es ist trägt sie eher zu meiner Motivation bei, mich mit dem Wiki auseinanderzusetzen, was gut und sinnvoll ist.

Aber du hast Recht, sie ist inzwischen abgeglitten und wird von unterschiedlichen Akteuren in ganz unterschiedliche Richtungen geritten - und das bindet nur Zeit und Kraft. Vor allem auch für @Matthias Scharwies, der wie kein Anderer Zeit und Kraft in den vorliegenden Artikel gesteckt hat und bei sowas schätzungsweise immer befürchten muss, dass seine Arbeit unter den Stiefeln irgendeiner Marschrichtung im Staub landet. Was sicher weder fair noch angemessen ist.

Vorschlag: Mein Eindruck sagt, dass eigentlich jeder Gelegenheit hatte, seinen Standpunkt ausreichend darzustellen. Einen Konsens werden wir hier (im Forum, sofern keine irgendwie moderierte Diskussion mit klarem Fokus stattfindet) sowieso nicht finden. Wer ernsthaft Interesse daran hat, sich für seine Marschrichtung einzusetzen, mag einen eigenen Artikel schreiben (wer sagt, dass es nur ein Anfängertutorial geben darf?) oder in Absprache mit Matthias Scharwies den Bestehenden in Details verbessern. Und wir schließen diesen Thread hier - oder zumindest die Stränge, die sich um das Wiki-Thema drehen.

Grüße,

RIDER

[Der-Dennis]

Hallo Camping_RIDER,

ich stimme Dir zu.

Da ich aber nicht hoffe jetzt Stein des Anstoßes gewesen zu sein, noch eine kurze Anmerkung:

Wer ernsthaft Interesse daran hat, sich für seine Marschrichtung einzusetzen, mag einen eigenen Artikel schreiben

Würde ich einen Artikel zu dem Thema schreiben wollen, würde ich den Artikel von Matthias kopieren.

Gruß
Dennis

[Gunnar Bittersmann]

@@Camping_RIDER

Wer ernsthaft Interesse daran hat, sich für seine Marschrichtung einzusetzen, mag einen eigenen Artikel schreiben (wer sagt, dass es nur ein Anfängertutorial geben darf?)

Falsche Frage. Es gibt bereits unzählige Anfängertutorials da draußen im Web.

Die Frage ist, ob das Anfängertutorial im SELFHTML-Wiki etwas ist, was man Anfängern empfehlen kann, oder etwas, vor dem man abraten muss.

LLAP 🖖

PS: Du meintest nicht, dass es mehrere Tutorials zu einunddemselben Thema im SELFHTML-Wiki geben kann, oder?

[Camping_RIDER]

Aloha ;)

PS: Du meintest nicht, dass es mehrere Tutorials zu einunddemselben Thema im SELFHTML-Wiki geben kann, oder?

Doch, das meinte ich. Es ist ein Wiki. Bei Artikeln zu Elementen gilt das Highlander-Prinzip, da gibt es ein klar umrissenes Lemma und das ist dann dort (und nur dort) zu beschreiben. Bei Tutorials (Artikel, die einem roten Faden folgen) ist das so nicht unbedingt der Fall. Da kann es sehr wohl zwei Tutorials geben, die denselben Inhalt auf unterschiedliche Art und Weise vermitteln.

Wenn beide Tutorials eine ähnliche Qualität und nur einen unterschiedlichen Ansatz haben, können sie beide stehenbleiben.

Wenn eins der Tutorials qualitativ spürbar hochwertiger ist als das andere wird selbiges irgendwann in der Versenkung verschwinden.

Und selbst wenn es nicht gewünscht ist, zwei Tutorials zu einem Thema zu haben: Wenn ein neues Tutorial im Benutzernamensraum entsteht und fertig wird kann man dann anhand der fertigen Tutorials vergleichen, welches geeigneter ist und sich dann entweder für eins entscheiden oder sich die Kirschen zusammenpicken und an einem neuen roten Faden verpacken.

Alles andere führt zu dem, was zurecht so sehr frustrierend ist: Es wird nur am Bestehenden rumgemäkelt, ohne selbst tätig zu werden. Und ja, auch eine komplette Überarbeitung des Artikels muss erstmal im Benutzernamensraum stattfinden, bevor sie dann den alten Artikel ersetzen kann.

Egal wie: Wenn man konstruktiv tätig werden will muss man einen Artikel schreiben!!! (Vollkommen egal, ob der dann komplett neu entsteht oder ob man sich den alten rüberkopiert, entkernt, und neu füllt.)

Ich bin sicher, dass die Lust für diejenigen, die den alten Artikel unter Zeit- und Krafteinsatz geschrieben haben, über Änderungen oder eine Ersetzung zu diskutieren, sehr viel größer ist, wenn sie sehen, dass sich das Gegenüber auch mit ähnlichem Einsatz eingebracht hat.

Grüße,

RIDER

[Matthias Scharwies]

Servus!

Aloha ;)

Egal wie: Wenn man konstruktiv tätig werden will muss man einen Artikel schreiben!!! (Vollkommen egal, ob der dann komplett neu entsteht oder ob man sich den alten rüberkopiert, entkernt, und neu füllt.)

Ich bin sicher, dass die Lust für diejenigen, die den alten Artikel unter Zeit- und Krafteinsatz geschrieben haben, über Änderungen oder eine Ersetzung zu diskutieren, sehr viel größer ist, wenn sie sehen, dass sich das Gegenüber auch mit ähnlichem Einsatz eingebracht hat.

Full Ack!

Was imho wirklich noch fehlt, wären:

• ein Tutorial, der anstatt die Konsolen-Methoden nur vorzustellen, das Debuggen anhand einer wirklichen Problemstellung erklärt.
• ein Tutorial, das Helferfunktionen zur dynamischen Erzeugung von Elementen vorstellt
• Grundlagen von Strings und Arrays
• Grundlagen der OOP

Ich arbeit grad an einem Tutorial zu Ereignisverarbeitung und Webseiten-Interaktion ...

... und die Reaktion im Forum ist leider wie immer 😟

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

Egal wie: Wenn man konstruktiv tätig werden will muss man einen Artikel schreiben!!! (Vollkommen egal, ob der dann komplett neu entsteht oder ob man sich den alten rüberkopiert, entkernt, und neu füllt.)

Ich bin sicher, dass die Lust für diejenigen, die den alten Artikel unter Zeit- und Krafteinsatz geschrieben haben, über Änderungen oder eine Ersetzung zu diskutieren, sehr viel größer ist, wenn sie sehen, dass sich das Gegenüber auch mit ähnlichem Einsatz eingebracht hat.

Full Ack!

Mich freut, dass ich damit deinen Nerv treffe. Es frustriert mich immer wieder, daran zu denken, wie du (und die anderen, die im Wiki regelmäßig tätig sind) sich abrackern, und auch wenn ich die Sichtweise der hier diskutierenden gut verstehe (ich zähle ja selbst mit dazu) bin ich immer in großer Sorge, dass euch sowas die Luft aus den Segeln nimmt, weil nicht von jeder Seite aus immer (ich will mich da nicht ausnehmen) genug Wertschätzung^[1] im Urteil über die Wiki-Artikel mitschwingt.

Was imho wirklich noch fehlt, wären:

• ein Tutorial, der anstatt die Konsolen-Methoden nur vorzustellen, das Debuggen anhand einer wirklichen Problemstellung erklärt.
• ein Tutorial, das Helferfunktionen zur dynamischen Erzeugung von Elementen vorstellt
• Grundlagen von Strings und Arrays
• Grundlagen der OOP

Ich arbeit grad an einem Tutorial zu Ereignisverarbeitung und Webseiten-Interaktion ...

... und die Reaktion im Forum ist leider wie immer 😟

Ich habe das schon gesehen. Ich weiß nicht wieso das so ist, aber auf solche Nachfragen fällt mir regelmäßig keine wirkliche Antwort ein 😟 so gehts mir leider immer wieder (das war neulich bei window.matchMedia schon ähnlich) - ich würde gerne helfen, ich hab aber irgendwie keinen rechten geistigen Einstiegspunkt, an den ich mich da hinklemmen könnte, und alles was mir zum Thema durch den Kopf geht fühlt sich irgendwie nicht recht auf die Fragestellung passend an.

Grüße,

RIDER

---

1. Wertschätzung und Kritik schließen sich ja gegenseitig nicht aus - es ist nicht notwendig, einen Artikel in aller Form gut zu finden, um das darinsteckende Maß an Arbeit zu respektieren. ↩︎

[dedlfix]

Tach!

... und die Reaktion im Forum ist leider wie immer 😟

Ich habe das schon gesehen. Ich weiß nicht wieso das so ist, aber auf solche Nachfragen fällt mir regelmäßig keine wirkliche Antwort ein 😟 so gehts mir leider immer wieder (das war neulich bei window.matchMedia schon ähnlich) - ich würde gerne helfen, ich hab aber irgendwie keinen rechten geistigen Einstiegspunkt, an den ich mich da hinklemmen könnte, und alles was mir zum Thema durch den Kopf geht fühlt sich irgendwie nicht recht auf die Fragestellung passend an.

Das geht mir ähnlich. Ich habe mich aber trotzdem mal bemüht, und hoffe, dass ich am Ende noch die Kurve gefunden habe, und nicht wie am Anfang meiner Antwortformulierung ziemlich am Thema vorbei geantwortet.

dedlfix.

[Gunnar Bittersmann]

@@Camping_RIDER

PS: Du meintest nicht, dass es mehrere Tutorials zu einunddemselben Thema im SELFHTML-Wiki geben kann, oder?

Doch, das meinte ich. Es ist ein Wiki. […] Da kann es sehr wohl zwei Tutorials geben, die denselben Inhalt auf unterschiedliche Art und Weise vermitteln.

Ein Nutzer auf der Suche nach einem Tutorial kommt zu SELFHTML.

SELFHTML so: „Mit einem Tutorial für dich können wir nicht dienen. Wir haben sogar mehrere!1elf.

Welches davon du lesen sollst? Können wir dir nicht sagen. Such dir eins aus. Oder lies alle.“

Welches wird der arme Mensch wohl lesen?

Meine Vermutung: gar keins. Er geht woanders hin, wo er eine Antwort auf seine Frage bekommt.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Du hast dich offensichtlich entschlossen, den größten Teil meines Postings zu ignorieren und dich auf die Teilaussage eingeschossen, die du kritisieren kannst. Schade. Da wäre noch so viel mehr Substanz in meiner Aussage gewesen.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Du hast dich offensichtlich entschlossen, den größten Teil meines Postings zu ignorieren und dich auf die Teilaussage eingeschossen, die du kritisieren kannst. Schade. Da wäre noch so viel mehr Substanz in meiner Aussage gewesen.

Du hast dich offensichtlich entschlossen, mein Posting ganz zu ignorieren. Schade.

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

Deine Reaktionen auf Kritik an Deinen Äußerungen wirken auf mich kindisch, wenn nicht gar trollig:

Falsche Frage.

Wie kannst Du es Dir erlauben, das so pauschal allgemein zu formulieren? Es ist aus Deiner Sicht eine falsche Fragestellung. Aber eben zunächst einmal nur aus Deiner. Daher wirkt die pauschalisierte Formulierung "falsche Frage" arrogant, uneinsichtig und trollend, weil sie nicht Konsens-orientiert, sondern "nur ich habe recht"-artig formuliert ist.

Es gibt bereits unzählige Anfängertutorials da draußen im Web.

Was soll das für ein Argument sein? Uns interessiert in erster Linie, dass wir hier im Wiki gute Inhalte haben. Da ist dieses Dein Argument auch wieder kontra-produktiv, da es implizit die Notwendigkeit für noch mehr Anfängertutorials infrage stellt. Warum nur tust Du das?

Die Frage ist,

Nein, Deine Frage ist. Du solltest schreiben "aus meiner Sicht stellt sich eher/stattdessen die Frage". Tust Du das nicht, setzt Du Dich durch diese absolute Formulierung über die anderen Poster. Vielleicht hast Du eine fachliche Qualifikation in Sachen Frontend-Entwicklung, die vielleicht sogar um Welten höher ist, als das, was andere hier anzubieten haben, aber vielleicht geht es in diesem Teil des Threads nicht mehr um das, was durch Deine Qualifikation abgedeckt ist, sondern um einen menschlichen Aspekt, bei dem es schwierig bis unmöglich ist, Deinen Absolutheitsanspruch aufrecht zu erhalten. Da halte ich es in besoderer Weise für angebracht, dass Du vor Dir selbst zugibst, Dich vielleicht auf unsicheren Terrain zu bewegen und vielleicht schneller zu irren, als Du annimmst. Diese Bescheidenheit vermisse ich hier, weshalb ich Dir aktives Trollen vorwerfen muss.

ob das Anfängertutorial im SELFHTML-Wiki etwas ist, was man Anfängern empfehlen kann, oder etwas, vor dem man abraten muss.

Das finde ich besonders perfide von Dir. Hier wird öffentlich darum gerungen, gute Tutorials zu schreiben, indem die natürlich begrenzte Sicht des jeweiligen Autors durch Diskussionen erweitert wird, damit am Ende empfehlenswerte Inhalte entstehen. Dein Wirken war in diesem Bereich ausschließlich ein Kritisieren an vorhandenem Inhalt, ein Verlinken von Twitter-Quellen anderer Apologeten, das ein oder andere CodePen-Beispiel, aber keinesfalls ein eigenes Tutorial oder gar ein Feature-Blogartikel. Dabei musstest Du sogar so weit gehen und die Nützlichkeit Deines Kritisierens anzumerken und als aktive (aber indirekte) Mitarbeit am jeweils diskutierten Tutorial anzumahnen. In der oben bereits kritisierten Art und Weise muss das aber gelegentlich wie ein Rumstänkern um des Rechthabens willen wirken, anstatt konstruktiver Mitgestaltung.

Wenn Du ein Tutorial also nicht Deinen Maßstäben gerecht findest, dann ziehst Du es auf Twitter durch den Kakao und rätst anderen davon ab, es zu lesen/befolgen/nutzen? Trollt da etwa ein eingeschnapptes Kind?

PS: Du meintest nicht, dass es mehrere Tutorials zu einunddemselben Thema im SELFHTML-Wiki geben kann, oder?

Du weißt, was das Wiki bieten soll? Du kennst die idealistische Ausrichtung des Projektes SELFHTML? Was soll dann dieses Rumgetrolle im PS?

Als Mensch kann ich Dich gut leiden und schätze Dich bei den SELF-Treffen immer wieder auf's neue. Aber Deine Formulierungen hier im Forum ärgern mich. Und das ist alles nicht neu.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

Wie kannst Du es Dir erlauben, das so pauschal allgemein zu formulieren? Es ist aus Deiner Sicht eine falsche Fragestellung.

Natürlich gebe ich in meinen Postings meine Sicht der Dinge wieder. Das ist in einem Forum nun mal so.

Daher wirkt die pauschalisierte Formulierung "falsche Frage" arrogant, uneinsichtig und trollend

Wie kannst Du es Dir erlauben, das so pauschal allgemein zu formulieren? Es wirkt aus Deiner Sicht arrogant, uneinsichtig und trollend.

Du erkennst, dass du haargenau dasselbe tust was du mir vorwirfst?

Ersteres finde ich OK, zweiteres dann unangebracht.

Und wenn du willst, dass ich dein Posting zuende lese und ernstnehme, wäre es besser, darauf zu verzichten, mich in die Troll-Ecke zu stellen.

LLAP 🖖

[Gunnar Bittersmann]

@@Matthias Apsel

dass @Matthias Scharwies überhaupt noch die Motivation findet, weiter zu machen, ist bewundernswert.

Dass ich überhaupt noch die Motivation finde, mich mit dem Wiki auseinanderzusetzen, aber auch. 😈

LLAP 🖖

[Camping_RIDER]

Aloha ;)

dass @Matthias Scharwies überhaupt noch die Motivation findet, weiter zu machen, ist bewundernswert.

Dass ich überhaupt noch die Motivation finde, mich mit dem Wiki auseinanderzusetzen, aber auch. 😈

Vielleicht solltest du einfach nochmal meinen Ratschlag in Erwägung ziehen und deine Kritik mit Begründung vorbringen, auf dass sie gehört wird, und es dann aber auch irgendwann dabei beruhen lassen, falls sie gehört, aber verworfen wurde.

Oder du könntest dich, wenn dir wirklich daran gelegen ist, etwas zu verändern, mal an einem Perspektivwechsel versuchen, zum Beispiel indem du das direkte Gespräch (nicht-öffentlich) mit der Gegenseite suchst, um sie dir erläutern zu lassen. Die kurze Aussprache wegen Tic-Tac-Toe, die Felix und du am Selftreffen hattet, habe ich als konstruktiv und brückenschlagend in Erinnerung. Ich könnte mir vorstellen, dass es dann Kompromissmöglichkeiten gibt.

Das was im Moment bei mir rüberkommt ist aber mehr der Eindruck, dass du eben nicht versuchst die Gegenseite zu verstehen, während du deinen Standpunkt wiederholst. Dir sollte beispielsweise klar sein, dass Felix nicht im Sinn hat, dich zu trollen. Das Komplexitäts-Argument so einfach abzutun wie du es tust ist ein Zeichen dafür, dass du es nicht ernst nimmst und auch nicht verstehen willst. Das ist äußerst schade, weil man so nicht auf einen grünen Zweig kommt.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Das Komplexitäts-Argument so einfach abzutun wie du es tust ist ein Zeichen dafür, dass du es nicht ernst nimmst und auch nicht verstehen willst.

Das ist Unsinn. Ich habe mich mit dem Komplexitäts-Argument auseinandergesetzt und – denke ich – widerlegt. Felix hat da eine Komplexität konstruiert, die überhaupt nicht da ist.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Das Komplexitäts-Argument so einfach abzutun wie du es tust ist ein Zeichen dafür, dass du es nicht ernst nimmst und auch nicht verstehen willst.

Das ist Unsinn. Ich habe mich mit dem Komplexitäts-Argument auseinandergesetzt und – denke ich – widerlegt. Felix hat da eine Komplexität konstruiert, die überhaupt nicht da ist.

…oder du siehst sie nur nicht, weil du dich nicht ausreichend darauf eingelassen hast. So zumindest ist meine Wahrnehmung. Vielleicht siehst du sie auch deshalb nicht, weil du sie gar nicht sehen kannst - weil dein Fokus einfach ein Anderer ist als der des Lernenden. Ich kann es nicht beurteilen. Ich sehe nur, dass deine Wahrnehmung hier von meiner Wahrnehmung deutlich (!) abweicht.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Das Komplexitäts-Argument so einfach abzutun wie du es tust ist ein Zeichen dafür, dass du es nicht ernst nimmst und auch nicht verstehen willst.

Das ist Unsinn. Ich habe mich mit dem Komplexitäts-Argument auseinandergesetzt und – denke ich – widerlegt. Felix hat da eine Komplexität konstruiert, die überhaupt nicht da ist.

…oder du siehst sie nur nicht, weil du dich nicht ausreichend darauf eingelassen hast.

Oder weil sie schlicht und einfach nicht da ist.

Ich lasse mich immer wieder auf deine Postings ein und trotzdem das ist nicht ausreichend‽

Wenn man deinen Standpunkt nicht übernimmt, liegt das daran, dass man nicht genügend darüber nachgedacht hat?

Nun sind ja noch CK und JürgenB aufgetaucht … Haben die auch nicht genügend nachgedacht?

LLAP 🖖

[JürgenB]

Hallo,

Nun sind ja noch CK und JürgenB aufgetaucht … Haben die auch nicht genügend nachgedacht?

wobei ich da weniger dogmatisch bin. document.write hat für mich in einem Anfängertutorial nichts zu suchen. Das ist ein Profiwerkzeug. Ich kann aber damit leben, wenn Javascript ohne html mit alert verwendet wird.

Besser fände ich, wenn man kurz darauf hinweist, das clientseitiges Javascript ohne html nicht sinnvoll ist und dann am Anfang ganz kurz die html-Grundstruktur zeigt, und erwähnt, das man mit document.querySelector("output").innerText den Inhalt des ersten output-Elements verändern kann.

Aber da ich kein Tutorialschreiber bin, überlasse ich den Autoren die Entscheidung und beschränke mich auf Anregungen.

Felix's Meinung, die Schüler langsam an das Thema heranzuführen und auf dem Weg zur reinen Lehre auch kleine „Fehler“ zu akzeptieren, hat den Vorteil, die Schüler nicht zu schnell abzuhängen. Die, die dann aber doch vorzeitig aussteigen, gehen dann aber mit unvollständigem Halbwissen.

Das kann bei Gunnars Idee, sofort und nur die reine Lehre zu vermitteln, egal wie „kompliziert“ sie ist, nicht passieren. Aber es werden bestimmt mehr Schüler verloren.

Gruß
Jürgen

[Julius]

Hallo Jürgen,

Besser fände ich, wenn man kurz darauf hinweist, das clientseitiges Javascript ohne html nicht sinnvoll ist […]

Im „SELFHTML-Kontext“ ist das korrekt, allerdings kann man JavaScript auch in PDFs benutzen (obwohl das afaik nur der Acrobat Reader unterstützt und ich für interaktive Dinge doch lieber auf Webtechnologien setze...).

Felix's Meinung, die Schüler langsam an das Thema heranzuführen und auf dem Weg zur reinen Lehre auch kleine „Fehler“ zu akzeptieren, hat den Vorteil, die Schüler nicht zu schnell abzuhängen.

Das funktioniert auch am besten. Programmieren gelernt habe ich nicht mit einer C-Einführung, die mir gefühlt seitenweise erklärt, was Literale und Operatoren sind, sondern mit einer Einführung in PHP, die sagt, was man konkret machen muss, um was zu erreichen – also eher die spielerische, learning-by-doing Ebene, die durch Erfolgserlebnisse motiviert. Man sieht, was geht und wird dadurch ermuntert, mehr zu lernen und sich dann auch irgendwann die Doku anzusehen und die Theorie zu verstehen. Die Theorie kann man dann auch besser verstehen, weil man sich Beispiele bauen kann. Man muss halt nur aufpassen, dass die Lernenden nicht etwas grundsätzlich unsicheres machen (z. B. include($_GET['page']);) und selber wissen, dass sie derzeit nur die Spitze des Eisbergs kennen und da noch mehr ist (weiterführende, nicht vorauszusetzende Erklärungen).

Zu diesen „Fehlern“ eine kleine Anekdote aus meiner Schulzeit:
Im Chemie-Unterricht der 10. Klasse fragte ein Schüler den Lehrer, warum wir denn das Bohr’sche Atommodell lernen würden, wenn es doch falsch sei – wir hatten vorher die Grenzen des Modells behandelt, glaube ich. Daraufhin erwiderte der Lehrer, dass es ja ein die Wirklichkeit vereinfachendes Modell sei, das die Dinge, die wir behandeln, ausreichend erklären würde und es damit seinen Sinn erfüllt hätte.

Gruß
Julius

[Camping_RIDER]

Aloha ;)

Ich lasse mich immer wieder auf deine Postings ein und trotzdem das ist nicht ausreichend‽

Wenn man deinen Standpunkt nicht übernimmt, liegt das daran, dass man nicht genügend darüber nachgedacht hat?

Ich achte darauf, meine Meinung zu vertreten und dabei immer wieder einzuräumen, dass ich falsch liegen kann. Wenn ich das Gefühl habe, dass sie nicht verstanden wurde (zum Beispiel, weil du sie aus meiner Sicht sehr schnell abtust), erkläre ich sie nochmal.

Nicht, um Recht zu behalten. Sondern um einen Konsens zu erringen, den es nur geben kann, wenn der jeweils Andere versteht, was man sagen möchte. Solange ich nicht sicher bin, dass ich verstanden wurde und dass einfach eine andere Auffassung bei vergleichbarer Wahrnehmung herrscht, verfolge ich den Weg, Konsens zu suchen.

Vielleicht ist es ein Fehler, dass ich das so nachdrücklich verfolge.

Nun sind ja noch CK und JürgenB aufgetaucht … Haben die auch nicht genügend nachgedacht?

Ich hatte sowohl bei Jürgen als auch bei CK das Gefühl, mit meinen Erklärungen nicht auf taube Ohren zu stoßen, sondern Verständnis für meine Sichtweise zu erlangen, obwohl wir nach wie vor unterschiedlicher Meinung sind. Du kannst das nachlesen; ich habe mich in den betreffenden Teilthreads damit abgefunden, dass eben unterschiedliche Ansichten bestehen.

Umso mehr betrübt und trifft mich dein grundloser, personifizierter Vorwurf.

Ich sehe von dir sehr oft, dass du deine Meinung sowohl sprachlich als auch im gesamten Kommunikationsverhalten sehr vehement und unbarmherzig vertrittst, oft auch ohne Rücksicht auf Verluste. Gleichzeitig kommt es nicht sehr oft vor, dass du, wenn du dann doch mal eher falsch liegst, die eigene Fehlbarkeit eingestehst.

Zum Glück denke ich dich persönlich genug zu kennen, um zu wissen, dass das nicht daran liegt, dass du die eigene Fehlbarkeit nicht anerkennst. Würde ich dich nicht kennen und nur dein Postingverhalten beurteilen, müsste ich dir das glatt unterstellen. Ich bin froh, dass es nicht so ist.

In meinen Postings liegt alles mögliche, aber kein absoluter Wahrheitsanspruch, noch ein Wille, um jeden Preis Recht zu behalten. Mir das immer wieder aufs Neue zu unterstellen obwohl ich immer wieder deutlich das Gegenteil zeige und viele der „Indizien“ dafür auf bloßem Unverständnis meiner eigentlichen Motivation beruhen zeugt nicht gerade von Höflichkeit und Wertschätzung. Vor allem unter Kollegen.

RIDER over and out.

[Gunnar Bittersmann]

@@Camping_RIDER

Ich achte darauf, meine Meinung zu vertreten und dabei immer wieder einzuräumen, dass ich falsch liegen kann. Wenn ich das Gefühl habe, dass sie nicht verstanden wurde (zum Beispiel, weil du sie aus meiner Sicht sehr schnell abtust), erkläre ich sie nochmal.

Ebendas hab ich in diesem Thread ebenfalls getan. (Deshalb zog sich die Diskussion mit dir so lange hin.)

Ich hatte sowohl bei Jürgen als auch bei CK das Gefühl, mit meinen Erklärungen nicht auf taube Ohren zu stoßen, sondern Verständnis für meine Sichtweise zu erlangen

Wie jetzt, bei mir nicht‽ Ich bin auf deine Erklärungen eingegangen – immer und immer wieder. Dass diese meine Meinung darüber, dass document.write im Tutorial nichts zu suchen hat, nicht geändert haben, lag daran, dass deine Erklärungen in meinen Augen im Laufe der Zeit nicht richtiger wurden.

Umso mehr betrübt und trifft mich dein grundloser, personifizierter Vorwurf.

Da es keinen solchen gab, besteht kein Grund, Trübsal zu blasen.

Gleichzeitig kommt es nicht sehr oft vor, dass du, wenn du dann doch mal eher falsch liegst, die eigene Fehlbarkeit eingestehst.

Sogar hier in diesem Thread.

LLAP 🖖

[Gunnar Bittersmann]

@@Felix Riesterer

Dank Felix kennen wir nun endlich den genauen Wert der Komplexität x.

Du erhöhst den Grad an Komplexität wesentlich! Du verwendest Markup, welches in meinem „Erstkontakt“-Beispiel nicht notwendig war (complexity++), um daraufhin DOM-Methoden zu bemühen, diesen aus Sicht des Neulings unnötigen Code-Bloat wieder erreichen (complexity++) und manipulieren (complexity++) zu können.

[…] gleich die Komplexität vervierfachen?

Es gilt also: x + 3 = 4x, folglich x = 1.

Da müssen wir ja keine Angst haben, das Komplexität exponentiell wachsen könnte: x exp(αt) = 1.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

x = 1.

Da müssen wir ja keine Angst haben, das Komplexität exponentiell wachsen könnte: x exp(αt) = 1.

Oops, das kommt davon, wenn man LaTeX vermeidet. Nicht 1 ist die Basis, sondern e. Bei $$x,\mathrm e^{\alpha t}$$ wäre mir das noch aufgefallen.

1. Wir müssen doch Angst haben.
2. Mathe ist zu komplex für mich. (Zumindest am Montagmorgen.)

LLAP 🖖

[JürgenB]

Hallo,

ich möchte mich Gunnars Meinung ausdrücklich anschließen. document.write sollte man von Anfängern wegen der Nebenwirkungen fernhalten.

Gruß
Jürgen

[Der-Dennis]

Hallo Jürgen,

siehe bitte auch hier.

Gruß
Dennis