Browser console shows XHR warning due to fengari-web using synchronous requests (?)

[rdw-software]

Displayed warning:

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help http://xhr.spec.whatwg.org/

This occurs right after loading fengari, no matter what I do in my actual program. I'm not sure if synchronous requests are needed. I'd expect all requests to be async as that is the default value, so the warning is a bit confusing.

Don't synchronous requests reduce responsiveness? Or doesn't that apply to how fengari works? (Not that performance is a major concern for me)

[giann]

require will make synchronous requests so that it keeps the same semantic as in regular Lua.
To avoid that you can either remove the require and load that script with a <script> tag or use fengari-loader with webpack which will package your scripts into a single file.

[daurnimator]

In general, you need a way to get your module into package.preload or package.loaded so that require doesn't need to blocking-ly fetch it. fengari-web does this for you, but you can do it yourself if you want.

[rdw-software]

I see, thanks! The only require I'm using is

js = require "js"

as written in the README for fengari-interop. Can I access the JS API in another way without using require? I'm already loading fengari-web via <script> tag in the loader (html webpage), but I need to access those functions inside of the Lua scripts that make up the actual app :)

[giann]

If you're using fengari-web, fengari-interop should already be loaded for you.

[rdw-software]

I have to admit, I totally forgot to check back. After looking into it again, it appears that dofile exhibits the same behaviour. I use a lot of calls to dofile to load modules dynamically.

For what it's worth, I couldn't care less if the loading is blocking in the context of my app (which isn't a website). However, if mainstream browsers eventually remove support for this, I would have to fix it in a rush, so I'd rather get rid of the warning now and be done with it.

Is there any way around it that will still allow me to access the Lua tables loaded in the typical fashion, ideally without adding unneeded complexity? I'd rather not load everything in JS and have to deal with more interoperability issues than absolutely necessary.

[shakna-israel]

I've just seen one approach, using a coroutine to wrap the promise, over here.

Would either that, or relying on await/fetch, be a possible way to shift this issue?

XHR has already started dying, and there's a likelihood it will continue to disappear.

[daurnimator]

I've just seen one approach, using a coroutine to wrap the promise, over here.

That seems very roundabout way of doing things:

• why create the script element when they could just load() themselves?
• why litter the global namespace?
• if you use async on the script tag it will be non-synchronous if that's what you want. But note that then then's few guarantees on when it might run (the default of non-async is to allow usage of old JS apis/practices like document.write)

[shakna-israel]

The primary need is because load currently relies on a deprecated browser feature, synchronous XHR, that is beginning to see pieces of it removed. There is an effort to making sure that somewhere in the future, those requests are blocked altogether.

I'm not saying everything here is a good idea. But something is sort of needed, before fengari-web starts to break on various browsers. Using a coroutine to work around JS' need to be async with absolutely everything, is one approach that seems viable.

[daurnimator]

The primary need is because load currently relies on a deprecated browser feature, synchronous XHR, that is beginning to see pieces of it removed. T

load is a lua/fengari function that fengari-web uses to implement the script tags themselves.
https://www.lua.org/manual/5.3/manual.html#pdf-load