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: ~~~js try { var self = await Promise.resolve("html"); } catch () { // kein await verfügbar } ~~~ Dies hier geht: ~~~js 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](https://modernizr.com/). _Rolf_ -- sumpsi - posui - obstruxi

Hallo klawischnigg, 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: ~~~js try { var self = await Promise.resolve("html"); } catch () { // kein await verfügbar } ~~~ Dies hier geht: ~~~js 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](https://modernizr.com/). _Rolf_ -- sumpsi - posui - obstruxi