Echo JS 0.11.0

<~>
app_dev 1527 days ago. link parent 1 point ▲ ▼
Thanks!

That's a good solution you are doing as well. Interesting when I wrote this I had to test a wide range of browsers and learned that UC Browser (which is widely used in Asia) is using an old version of Chromium and has to be handled as well by a lot of sites.

Even hard than IE 11 is handling old versions of Safari on iOS. It’s not widely used anymore of course but if someone has a major site they still need to worry about it.

With you solution it’s great that you give a warning or alternative option for people with old browsers because it sucks for users if the site doesn’t work and gives no warning.

Replies

tracker1 1526 days ago. link 2 points ▲ ▼
Yeah... the preflight check should be a must... same for a <noscript> at load, which I don't do.  Anyone that has scripting disabled is likely to know what they're getting and why.  IIRC, iOS 11 (april/may 2017) is the break point for async and supports iPhone 6 and 5S I think.

Most of my work is internalized apps, but at this point even public facing it's probably a fair cutoff.  Killing the async/generator transforms is a pretty big improvement... I'd love to see a modern server that detects behaviors and pushes the mjs most likely to be requested from an initial starting point.

These days charting libraries are about the only thing too big imho that should be lazy loaded when needed.  I try to keep my app bundles under 500k, which includes styling and a layout images.  Larger than I'd like, but given the landscape reasonable for the effort.
app_dev 1525 days ago. link 2 points ▲ ▼
I agree. I haven't used <noscript> in a very long time. Seems like only bot traffic would browse the web without JS now days.

Here is a good article from 2018 when someone tried major sites with JS turned off.

https://www.smashingmagazine.com/2018/05/using-the-web-with-javascript-turned-off/

I have a few sites (including work sites that use CodeMirror for online code editing) and for those I lazy load since they are large but I to am finding that very few things need it (charts is a good example as I lazy loaded that on an app a few years ago).

For async/await I'm currently staying away except in node scripts or unless I build an app that fully requires modern JS (example web components). I even found issues with the `for ... of ...` with Babel previously so for now I avoid it with my React code that need to run in old browsers.

Here is an Example Web Component app I wrote that requires modern JS only.

https://www.dataformsjs.com/examples/places-demo-web.htm

Rather than worrying about polyfills it throws up a warning for old browsers. Then by only worry about new browsers I can really target the latest and greatest features, example, the source below uses 'element.querySelectorAll(selector + `:not(:defined)');` which to my knowledge will only work in modern browsers and can't be polyfilled.

https://github.com/dataformsjs/dataformsjs/blob/master/js/web-components/utils.js

export function componentsAreDefined(element, selector = '') {
    return new Promise(async (resolve) => {
        const undefinedComponents = element.querySelectorAll(selector + ':not(:defined)');
        if (undefinedComponents.length > 0) {
            const promises = [...undefinedComponents].map(
                c => window.customElements.whenDefined(c.getAttribute('is') || c.localName)
            );
            await Promise.all(promises);
        }
        resolve();
    });
}


https://github.com/dataformsjs/dataformsjs/blob/master/js/web-components/utils.js