klawischnigg: Javascript-Abfrage, ob Browser "async function" beherrscht

Hi there,

kennt jemand eine Möglichkeit mit Javascript abzufragen, ob ein Browser asynchrone Funktionen beherrscht? (Ich weiß, das sollten sie eigentlich seit 5 Jahren alle tun, aber ich hab's leider manchmal mit echt alten Geräten zu tun)

akzeptierte Antworten

  1. Hallo klawischnigg,

    das geht wohl nur auf die dreckige Art.

    let hasAsync = true;
    
    try {
      eval('async () => {}');
    } catch (e) {
      if (e instanceof SyntaxError) {
        hasAsync = false;
      }
      else {
        throw e;
      }
    }
    

    Freundliche Grüße,
    Christian Kruse

    1. Hi there,

      das geht wohl nur auf die dreckige Art.

      Sch***egal, hier vergibt niemand Haltungsnoten...😉

      let hasAsync = true;
      
      try {
        eval('async () => {}');
      } catch (e) {
        if (e instanceof SyntaxError) {
          hasAsync = false;
        }
        else {
          throw e;
        }
      }
      

      super, danke, auf das Werfen der Exception hätt' ich eigentlich selbst kommen können😉, vermutlich dachte ich auch, daß man irgendwie eleganter erledigen könnte...

      1. Hallo klawischnigg,

        eleganter

        Wie lange machst Du schon Javascript? Eigentlich solltest Du wissen, dass Javascript und Eleganz sich gegenseitig ausschließen 😉

        Rolf

        --
        sumpsi - posui - obstruxi
        1. Hi there,

          eleganter

          Wie lange machst Du schon Javascript?

          Viel zu lange. Eigentlich könnt' ich eh schon in Pension gehen (oder Rente, wie Ihr das nennt). Leider betreib' ich für das Überleben einen ziemlich hohen Aufwand...😉

          Eigentlich solltest Du wissen, dass Javascript und Eleganz sich gegenseitig ausschließen 😉

          Ja eh, aber wer so wie ich gelegentlich an das Gute im Menschen glaubt, der glaubt halt auch gelegentlich an das Gute in Javascript...

  2. Hallo klawischnigg,

    Edit: Scheiße, das kommt davon wenn man zuviel drumrum schreibt...

    welche Geschmacksrichtung? Nackige Promises oder async/await Schlüsselwörter?

    Na gut - nackige Promises sind simpel, da würdest Du wohl nicht fragen, aber der IE kennt auch die nicht.

    Für Promises gibt's Polyfills, davon solltest Du eins einbauen.

    async/await ist schwieriger. Dieser Code läuft auf dem IE gar nicht erst an, sondern bricht vor Scriptstart mit Syntaxterror ab:

    try {
       var self = await Promise.resolve("html");
    }
    catch () {
       // kein await verfügbar
    }
    

    Dies hier geht:

    try {
       var klawi = eval("async () => 42;");
    }
    catch (err) {
       console.log("oh boy...");
    }
    

    Mit var, nicht let, sonst bricht Dir ein IE vor 11 das Script ab, bevor Du Fragen stellen kannst. Du musst testen, eine async-Funktion zu erzeugen (was auch eine Pfeilfunktion sein kann, weil die aus einem älteren Standard sein können). Einen await zu testen bringt nichts, weil ein eval("await Promise.resolve('foo')") in jedem Browser verreckt, mit der Meldung, dass await nur in async-Funktionen erlaubt ist.

    Der Syntax-Error führt jedenfalls zum Werfen einer Exception durch eval und das kannst Du einfangen. Und ein Brauser, der bei diesem eval keinen Syntaxterror macht, der kann beides. Zwangsläufig, ohne Promises kein async.

    Ich will nicht ausschließen, dass ein IE 4 oder so sich auf andere Weise über diesem Code erbricht; der IE11 wirft jedenfalls (im W3C Tryit) den Syntax Error, und auch in der IE5 Emulation bemerkt er den Fehler.

    Frage ist nur, ob Du zwei Codebasen pflegen willst. Eine mit async/await, und eine mit promise.then(). async/await sind Syntaxzucker für Promises, du hast zwar als Entwickler Vorteile, aber bei der Ausführung keine neuen Möglichkeiten (vielleicht abgesehen von asynchronen Iteratoren oder ähnlich esoterischem Gedöns).

    Vermutlich ist es nur sinnvoll, einen Basissatz an Scriptsupport zu bauen, der auch in 2011-er Browsern läuft, und die volle Dröhnung an Komfort dann anzubieten, wenn Du auch die volle Dröhnung an Sprachfeatures hast.

    Oder Du programmierst Typescript und generierst zwei Codebasen. Eine für "aktuelle Browser", und eine für "Stone Age Browser". Ich wette, dass Typescript da ein fertiges Feature für den Fallback mitbringt. Aldernatief gips immer noch Modernizr.

    Rolf

    --
    sumpsi - posui - obstruxi
    1. Hi there,

      welche Geschmacksrichtung? Nackige Promises oder async/await Schlüsselwörter?

      Letzteres.

      async/await ist schwieriger. Dieser Code läuft auf dem IE gar nicht erst an, sondern bricht vor Scriptstart mit Syntaxterror ab:

      Der IE ist mir sowas von wurscht. Wer den verwendet ist selbst schuld. Wenn sogar die Mirkosaft von der Verwendung abrät, dann wer ich mir deswegen keine grauen Haare wachsen lassen. Es geht mir eher um die Chrome-Browser etc., die auf bestimmten älteren (hüstel) Betriebssystemen nicht mehr supportet werden und daher auch nicht upgedatet werden können. Wir reden hier von Version 52 oder so, die 2016 released wurde.

      Ich will nicht ausschließen, dass ein IE 4 oder so sich auf andere Weise über diesem Code erbricht;

      Der war gut...😉, das dürfte so um 1997 gewesen sein, wenn ich mich recht erinnere.

      Frage ist nur, ob Du zwei Codebasen pflegen willst. Eine mit async/await, und eine mit promise.then().

      Eher nicht.

      Oder Du programmierst Typescript und generierst zwei Codebasen. Eine für "aktuelle Browser", und eine für "Stone Age Browser". Ich wette, dass Typescript da ein fertiges Feature für den Fallback mitbringt. Aldernatief gips immer noch Modernizr.

      Ja, danke für die Tipps, dieses Modernizer-Zeugs kannte ich noch nicht. Für das, was ich vorhabe resp. wofür ich das brauche tue ich mir das defintiv nicht an. Es geht im Prinzip nur um das Warten auf eine Eingabe, und Browser, "die nicht warten können", die werden einfach mit "prompt" gefüttert und gut isses. Was nichts daran ändert, daß ich anyway wieder was gelernt habe...😉