Echo JS 0.11.0

<~>

tracker1 1514 days ago. link 2 points
Very cool... My hope is that eventually the browser's JS engine will add a jsx pragma directive that will allow you to specify your jsx translation in the browser + js.

That said, I've all but dropped legacy (IE11) support and break at anything that doesn't support async functions .

    // index.precheck.js
    try {
      eval('(function() { async _ => _; })();');
    } catch (e) {
      window.location.replace('/legacy.html');
    }

With the above precheck in place, I have my main index.js generated via the following babel configuration...  It specifically excludes the async/generator transforms which are freaky huge... without them, my bundles are a decent size.

    // .babelrc
    {
      "presets": [
        [
          "@babel/preset-env",
          {
            "modules": false,
            "useBuiltIns": "usage",
            "targets": {
              "browsers": "> 5%"
            },
            "exclude": [
              "transform-async-to-generator",
              "transform-regenerator"
            ]
          }
        ],
        "@babel/preset-react"
      ],
      "env": {
        "test": {
          "plugins": [
            [
              "@babel/plugin-transform-modules-commonjs",
              {
                "allowTopLevelThis": true
              }
            ],
            [
              "babel-plugin-dynamic-import-node",
              {
                "noInterop": true
              }
            ]
          ]
        }
      }
    }
app_dev 1514 days ago. link 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.
tracker1 1513 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 1512 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
app_dev 1515 days ago. link 1 point
Hello World Demo:

https://www.dataformsjs.com/examples/hello-world/en/react.htm

Why?

It's a fast way to include React on any web page and build apps with using a build process or large dependencies. Simply use React with JSX in a page or site and include needed CDN or JavaScript links.

How?

It compiles JSX directly to JS for modern browsers and downloads Polyfills and Babel Standalone for IE and other old browsers.

Doesn’t Babel Standalone do this already?

Yes, however when Babel Standalone is used in a Browser it is intended for prototyping. This script is intended for production use. Originally I used Babel Standalone for all React demos on the site however it takes a lot of memory and causes a delay of many seconds when viewing pages from a mobile device. Once I created this script memory was reduced up to 5x and content renders almost instantly now.