Welche JavaScript Version???

[pl]

Mahlzeit ;)

Hier würde ich gerne die Version prüfen bzw. ersteinmal feststellen. Ist ja in anderen PL's nicht unüblich und ganz einfach, die Frage ist wie in JS?

MfG

[1unitedpower]

Hier würde ich gerne die Version prüfen bzw. ersteinmal feststellen. Ist ja in anderen PL's nicht unüblich und ganz einfach, die Frage ist wie in JS?

Welche Version denn? Die des EcmaScript-Standards, die der Browser-Engine oder doch die Version einer bestimmten API, wie zum Beispiel XMLHttpRequest?

Aber für all diese Versionsnummern gibt es keine sinnvollen Anwendungsfälle, abgesehen von statistischen Erhebungen. Viel eher möchtest du vermutlich eine Feature-Erkennung machen. Um zum Beispiel zu prüfen, ob du addEventListener für AJAX-Anragen benutzen kannst, kannst du folgenden Test benutzen:

if ('addEventListener' in XMLHttpRequest.prototype) {
   // feature vorhanden
} else {
   // feature nicht vorhanden
}

Modernizr ist eine umfangreiche Bibliothek zur Feature-Erkennung. Darauf aufbauend gibt es auch Libraries, die fehlende Features direkt nachrüsten, zum Beispiel webshims. Damit kannst du dich auf deine eigentlichen Problemdomäne konzentrieren, während andere dafür sorgen, dass deine Anwendung auch crossbrowser-kompatibel ist. Das soll nicht heißen, dass du selber keine Browsertests mehr durchführen musst.

[pl]

Hier würde ich gerne die Version prüfen bzw. ersteinmal feststellen. Ist ja in anderen PL's nicht unüblich und ganz einfach, die Frage ist wie in JS?

Welche Version denn? Die des EcmaScript-Standards, die der Browser-Engine oder doch die Version einer bestimmten API, wie zum Beispiel XMLHttpRequest?

Nicht nur APIs auch allg. Code. Bspw. funktioniert var [name, vname] = fullname.split(/,/); mit Sicherheit erst ab einer bestimmten JS-Version -- Darum gehts mir.

MfG

[1unitedpower]

Hier würde ich gerne die Version prüfen bzw. ersteinmal feststellen. Ist ja in anderen PL's nicht unüblich und ganz einfach, die Frage ist wie in JS?

Welche Version denn? Die des EcmaScript-Standards, die der Browser-Engine oder doch die Version einer bestimmten API, wie zum Beispiel XMLHttpRequest?

Nicht nur APIs auch allg. Code. Bspw. funktioniert var [name, vname] = fullname.split(/,/); mit Sicherheit erst ab einer bestimmten JS-Version -- Darum gehts mir.

Auch das kannst du mit einer Feature-Abfrage herausfinden:

try {
   eval('var [a,b] = [1,2];');
   console.log('Destructuring is supported');
} catch (e) {
   console.log('Destructuring is not supported');
}

Die Frage ist, was fängst du damit nun an? Meine Empfehlung ist, du benutzt einen Transpiler, wie TypeScript oder Babel. Dann kannst du in deinem Code Destructuring benutzen, aber der resultierende JavaScript-Code muss es nicht und läuft daher auch in veralteten Browsern.

[pl]

Hier würde ich gerne die Version prüfen bzw. ersteinmal feststellen. Ist ja in anderen PL's nicht unüblich und ganz einfach, die Frage ist wie in JS?

Welche Version denn? Die des EcmaScript-Standards, die der Browser-Engine oder doch die Version einer bestimmten API, wie zum Beispiel XMLHttpRequest?

Nicht nur APIs auch allg. Code. Bspw. funktioniert var [name, vname] = fullname.split(/,/); mit Sicherheit erst ab einer bestimmten JS-Version -- Darum gehts mir.

Auch das kannst du mit einer Feature-Abfrage herausfinden:

Ja, ist schon klar, die Suchmaschine liefert mir haufenweise sowas. Mir ist es nur völlig unverständlich, warum es in JS nicht möglich ist, ein bestimmtes Release/Version zu prüfen bzw. einzufordern. Schönen Sonntag.

[1unitedpower]

Ja, ist schon klar, die Suchmaschine liefert mir haufenweise sowas. Mir ist es nur völlig unverständlich, warum es in JS nicht möglich ist, ein bestimmtes Release/Version zu prüfen bzw. einzufordern.

Kannst du schon, zum Beispiel mit window.navigator.appVersion. Aber diese Versionsangabe verrät dir nicht, welche JavaScript-Features tatsächlich unterstützt werden. Du kannst daraus für dein Beispiel mit Destructuring-Assignments keine Handlungs-Alternative ableiten, sowie es mit dem Feature-Test geht.

[pl]

Ja, ist schon klar, die Suchmaschine liefert mir haufenweise sowas. Mir ist es nur völlig unverständlich, warum es in JS nicht möglich ist, ein bestimmtes Release/Version zu prüfen bzw. einzufordern.

Kannst du schon, zum Beispiel mit window.navigator.appVersion.

Na. Wenn da mal nicht ein Versionskontrollsystem dahinter steckt!

[pl]

Hier würde ich gerne die Version prüfen bzw. ersteinmal feststellen. Ist ja in anderen PL's nicht unüblich und ganz einfach, die Frage ist wie in JS?

Welche Version denn? Die des EcmaScript-Standards, die der Browser-Engine oder doch die Version einer bestimmten API, wie zum Beispiel XMLHttpRequest?

Aber für all diese Versionsnummern gibt es keine sinnvollen Anwendungsfälle,

Oh doch! der Sinn von

use 5.010; # nur ein Beispiel

besteht eben darin, dem Anwender klar zu machen, dass es im gesamten Code soviele Änderungen gegenüber früheren Versionen gibt, dass eine bestimmte Version des Interpreters sichergestellt sein muss. Da geht es eben nicht nur um einzelne Klassen, Interfaces oder API's.

Womit auch sichergestellt ist, dass sich der Interpreter selbst um eine ordentliche Fehlerbehandlung sowie Fehlermeldung kümmert und eben nicht der Entwickler.

In Fakt sollte idealerweise und beispielsweise bei einem "use JavaScript 1.9"; der Browser spontan reagieren, dem Anwender eine hübsche Meldung zeigen und die weitere Verarbeitung von JS-Code abbrechen.

MfG

[Christian Kruse]

Hallo pl,

Aber für all diese Versionsnummern gibt es keine sinnvollen Anwendungsfälle,

Oh doch! der Sinn von

use 5.010; # nur ein Beispiel

Du vergleichst Äpfel mit Birnen.

Wer sich Perl installiert, ist versiert genug um zu verstehen, was ein Versions-Update von Perl nach sich ziehen mag und wie er es umsetzen kann. Das gilt nicht für Browser.

Mal abgesehen davon, dass es für JS nicht den einen Interpreter gibt, sondern diverse Interpreter. Auf Anhieb fallen mir da etwa V8, Nitro, SpiderMonkey, JaegerMonkey und Chakra ein. Und die werden nicht nur in einer Variante, sondern in verschiedenen Varianten benutzt.

In Fakt sollte idealerweise und beispielsweise bei einem "use JavaScript 1.9"; der Browser spontan reagieren, dem Anwender eine hübsche Meldung zeigen und die weitere Verarbeitung von JS-Code abbrechen.

Und was soll das bringen? Der User wird nur merken „geht nicht.” Verstehen, was da schief läuft, wird er nicht. Und das wird dazu führen, dass es keiner einsetzt, denn es könnte den User verschrecken. Siehe XHTML, das hat auch keiner als XML ausgeliefert, aus genau diesem Grund. Wozu also einbauen?

LG,
CK

[pl]

Hallo pl,

Aber für all diese Versionsnummern gibt es keine sinnvollen Anwendungsfälle,

Oh doch! der Sinn von

use 5.010; # nur ein Beispiel

Du vergleichst Äpfel mit Birnen.

Wer Perl entwickelt weiß genau mit welcher Version, warum sollte das ein JS-Entwickler nicht wissen?

Wer sich Perl installiert, ist versiert genug um zu verstehen, was ein Versions-Update von Perl nach sich ziehen mag und wie er es umsetzen kann. Das gilt nicht für Browser.

Mal abgesehen davon, dass es für JS nicht den einen Interpreter gibt, sondern diverse Interpreter. Auf Anhieb fallen mir da etwa V8, Nitro, SpiderMonkey, JaegerMonkey und Chakra ein. Und die werden nicht nur in einer Variante, sondern in verschiedenen Varianten benutzt.

In Fakt sollte idealerweise und beispielsweise bei einem "use JavaScript 1.9"; der Browser spontan reagieren, dem Anwender eine hübsche Meldung zeigen und die weitere Verarbeitung von JS-Code abbrechen.

Und was soll das bringen?

Es nimmt dem Entwickler die Arbeit ab, das ist der eigentliche Sinn und auch eine Frage der Garantie bzw. Gewährleistung. Das ist doch für Dich alles nichts Neues oder?

Der User wird nur merken „geht nicht.” Verstehen, was da schief läuft, wird er nicht.

Doch: Wenn der Browser eine verständliche Meldung ausgibt wird das jeder User verstehen.

MfG

[Matthias Apsel]

Hallo pl,

Der User wird nur merken „geht nicht.” Verstehen, was da schief läuft, wird er nicht.

Doch: Wenn der Browser eine verständliche Meldung ausgibt wird das jeder User verstehen.

Nein. Er wird vielleicht die Worte verstehen, aber nicht ihren Inhalt. Viele wissen nicht, dass es JavaScript überhaupt gibt. Gefühlt 98% aller Fehlermeldungen werden nicht gelesen.

Wenn man auf Nachfrage bekommt „Da stand was.“ muss man oft schon zufrieden sein.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Wenn man auf Nachfrage bekommt „Da stand was.“ muss man oft schon zufrieden sein.

Haha, ja ;-) „Was stand denn in dem Popup?” „Welches Popup?” „Da muss doch eine Fehlermeldung gekommen sein?” „Nein, da war keine!” „Zeig mal” klick, klick „Da ist doch die Fehlermeldung?” „Oh, das hab ich gar nicht gesehen”

LG,
CK

[pl]

hi,

Der User wird nur merken „geht nicht.” Verstehen, was da schief läuft, wird er nicht.

Doch: Wenn der Browser eine verständliche Meldung ausgibt wird das jeder User verstehen.

Nein. Er wird vielleicht die Worte verstehen, aber nicht ihren Inhalt. Viele wissen nicht, dass es JavaScript überhaupt gibt. Gefühlt 98% aller Fehlermeldungen werden nicht gelesen.

Eigentlich gehts hier um den Sinn einer Versionskontrolle -- die in JavaScript wohl für immer im Verborgenen bleiben soll, aus welchen Gründen auch immer.

Wenn man auf Nachfrage bekommt „Da stand was.“ muss man oft schon zufrieden sein.

Wir sollten den Usern ein bischen mehr Intelligenz zutrauen. Ganz bestimmt will er nicht eine Anwendung die nur ein bischen geht und in manchen Features nicht sondern eine Anwendung die 100%ig funktioniert. Zumindest ist solch ein Verhalten beim Kauf einer Software vorherrschend. Und siehe da, auf der Packung stehen die Requirements, also dass was außer einem PC sonst noch so erforderlich ist zur Gewährleistung.

So denke ich, dass einer der die Software haben+anwenden will, auch imstande dazu ist, die Voraussetzungen dafür zu schaffen. All solche Dinge stehen und fallen mit einer Versionskontrolle. Also um ehrlich zu sein, ich verstehe Eure Argumente nicht die darauf hinauslaufen, den Sinn einer Versionskontrolle betreff JavaScript in Frage zu stellen.

In der Entwicklung gibt es keinen Stillstand es dauert höchstens länger.

MfG

[dedlfix]

Tach!

Eigentlich gehts hier um den Sinn einer Versionskontrolle -- die in JavaScript wohl für immer im Verborgenen bleiben soll, aus welchen Gründen auch immer.

Versionskontrolle ist ein Begriff mit anderer Bedeutung, als du sie hier verwendest. Versionsprüfung möchtest du haben, und die bekommst du praktisch nicht, so wie du sie haben möchtest, weil die Javascript-Welt in den Browsern anders tickt als die Welt herkömmlicher Programmierumgebungen.

Wir sollten den Usern ein bischen mehr Intelligenz zutrauen. Ganz bestimmt will er nicht eine Anwendung die nur ein bischen geht und in manchen Features nicht sondern eine Anwendung die 100%ig funktioniert. Zumindest ist solch ein Verhalten beim Kauf einer Software vorherrschend. Und siehe da, auf der Packung stehen die Requirements, also dass was außer einem PC sonst noch so erforderlich ist zur Gewährleistung.

Dann musst du exakt festlegen, in welchem Browser und welcher Version deine Anwendung läuft. Es gibt zwar Versionsstände von Javascript, aber die sind nur theoretisch von Interesse. Praktisch obliegt es dem Hersteller des Browsers, welche konkreten Features er nun implementiert hat oder nicht. Deshalb liefert eine Versionsnummer keine weiteren Erkenntnisse. Stattdessen hat man Feature-Detection und Polyfills (Nachbau für (noch) nicht vorhandene Features) erfunden. Das ist das übliche Vorgehen, um eine Interoperabilität der Anwendung sicherzustellen.

So denke ich, dass einer der die Software haben+anwenden will, auch imstande dazu ist, die Voraussetzungen dafür zu schaffen. All solche Dinge stehen und fallen mit einer Versionskontrolle.

Nein, du lieferst die Polyfills mit für die Features, von denen du annimmst oder weißt, dass sie in der Ablaufumgebung nicht zur Verfügung stehen. Polyfills findet man zusammen mit der Information, welche Browsers Unterstützung für eine bestimmte Funktion anbieten, zum Beispiel im MDN (Mozilla Developer Network). Ich suche dazu üblicherweise nach "mdn funktionsname".

dedlfix.

[JürgenB]

Hallo,

willst du denn die Javascripte an den Seitenbetreiber oder an den Seitenbesucher verkaufen?

Für die Kontrolle sind der Entwickler und der Seitenbetreiber verantwortlich, den Seitenbesucher interessiern solche Details nicht.

Gruß
Jürgen

[Rolf b]

Wir sollten den Usern ein bischen mehr Intelligenz zutrauen.

Ich spreche dem Gros meiner Usern keineswegs Intelligenz ab. Sonst wären sie in meinem Unternehmen nicht arbeitsfähig.

Aber technisches Verständnis, das gibt's selten. Und wenn ein Programm sich nicht wie erwartet verhält, dann halten die allerwenigsten inne, lesen die Fehlermeldung und denken darüber nach. Statt dessen wird kurz geflucht, die Fehlermeldung ungelesen weggeklickt, irgendwie versucht weiterzuwurschteln und wenn dann der vierte Folgefehler gekommen ist, DANN rufen sie den Helpdesk an und melden diesen Folgefehler. Als Support liest man dann die zentrale DB mit dem Fehlerlog und sieht die Ursache. Wenn man sie fragt, warum sie nicht beim ersten Fehler innegehalten haben, kommt gerne die Antwort "Ich muss meinen Vorgang fertigbekommen, ich habe für so einen Blödsinn keine Zeit".

Ist leider nicht erfunden. Die Kollegen sitzen mit fachbezogenen Scheuklappen da und denken nur an ihr Arbeitssoll.

Rolf

[Christian Kruse]

Hallo pl,

Wer Perl entwickelt weiß genau mit welcher Version, warum sollte das ein JS-Entwickler nicht wissen?

Weil das Web so nicht funktioniert. Der Browser ist kein Server, du hast keine Kontrolle über die andere Seite. Das ist für dich doch nichts Neues, oder?

Und was soll das bringen?

Es nimmt dem Entwickler die Arbeit ab, […]

Und wälzt sie auf den User ab. Nicht besonders sinnig. Und selbst Entwickler reden ja schon von einer „dependency hell,” das sollte dir zu denken geben.

das ist der eigentliche Sinn und auch eine Frage der Garantie bzw. Gewährleistung. Das ist doch für Dich alles nichts Neues oder?

Doch, diese Betrachtungsweise ist neu für mich. Das musst du ausführen, was soll das mit Gewährleistung zu tun haben?

Der User wird nur merken „geht nicht.” Verstehen, was da schief läuft, wird er nicht.

Doch: Wenn der Browser eine verständliche Meldung ausgibt wird das jeder User verstehen.

I lol'd irl. Entweder du hast nie etwas mit Usern zu tun oder du bist unfassbar naiv. Fehlermeldungen werden entweder gelesen und nicht verstanden oder einfach weg geklickt.

LG,
CK

[Orlok]

Hallo Christian

Und was soll das bringen? Der User wird nur merken „geht nicht.” Verstehen, was da schief läuft, wird er nicht. Und das wird dazu führen, dass es keiner einsetzt, denn es könnte den User verschrecken.

Abgesehen davon, würde ein solcher early exit auch dem Ziel entgegenstehen, möglichst vielen Benutzern eine möglichst gute Nutzungserfahrung zukommen zu lassen, wenn wir unterstellen, dass dies der Zweck des Einsatzes von JavaScript ist. Sprich, warum sollte man auf die gesamte Funktionalität verzichten, wenn tatsächlich vielleicht nur ein paar wenige Features nicht unterstützt werden?

Viele Grüße,

Orlok

[Christian Kruse]

Hallo Orlok,

Abgesehen davon, würde ein solcher early exit

Du kannst inzwischen auch einfach {: @en} schreiben ;-)

auch dem Ziel entgegenstehen, möglichst vielen Benutzern eine möglichst gute Nutzungserfahrung zukommen zu lassen, wenn wir unterstellen, dass dies der Zweck des Einsatzes von JavaScript ist.

Ja, du hast recht, das habe ich vergessen zu erwähnen. Danke.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

Abgesehen davon, würde ein solcher early exit

Du kannst inzwischen auch einfach {: @en} schreiben ;-)

Zumal {: .lang="en"} falsch ist, weil es zu <foo class="lang="en""> gerendert wird.

Bis demnächst
Matthias