[FEATURE REQUEST] Properly fail on missing required features

[glondu]

Is your feature request related to a problem? Please describe.

My application stopped working for a user after a js_of_ocaml upgrade. This user has an old iPhone (ISTR 8, released in 2017) with iOS 16.7.5, and is using the built-in Safari. I have no idea how to debug this.

Out of curiosity, I tried said application in Firefox ESR 45.9.0 in an old Debian 9.0.1 LiveCD (released in 2017) and I see the same behaviour. Looking at the JavaScript console, the problem seems to be due to the use of ES6 classes, which is a recent new "feature".

Unrelatedly, code generated by js_of_ocaml unconditionally uses TextDecoder, which is not supported in quickjs.

Describe the solution you'd like

I am not against using new JavaScript features, but the situations described above are very frustrating. It would be nice if js_of_ocaml-generated code could (auto-)detect features before using them. I don't know how feasible it is, though.

Describe alternatives you've considered

Maybe an alternative solution could be to provide a stub that would probe required features from the runtime at loading time and somehow expose the missing ones so that the application has a chance to give a meaningful error message to the user.

[hhugo]

There have been many modernization lately.
The use of optional chaining (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining) will probably be an issue as well.

Have you considered using https://babeljs.io/ ? Documenting this process could be a useful addition to the doc (in case specific config is need to process js_of_ocaml programs).

I am not against using new JavaScript features, but the situations described above are very frustrating. It would be nice if js_of_ocaml-generated code could (auto-)detect features before using them. I don't know how feasible it is, though.

Detecting feature availability before use and fallback to another implementation inside jsoo feels like too much to maintain.

Maybe an alternative solution could be to provide a stub that would probe required features from the runtime at loading time and somehow expose the missing ones so that the application has a chance to give a meaningful error message to the user.

That doesn't work for new syntax, such as optional chaining.
For the case of TextEncoder,/TextDecoder it should be easy to include a polyfill. That said, I don't want to include this in default runtime. I would expect babeljs to be able to provide such polyfill.

Regarding quickjs, we could consider supporting if you think it makes sense. Feel free to contribute PR with a new CI job. Long term, the way to go might be to add support in quickjs. After a quick search, maybe support has been added to a fork already nginx/njs@447d66d

[glondu]

Have you considered using https://babeljs.io/ ?

I didn't know about this. A quick test with my app breaks on modern browsers. This needs further investigation, but looks like a good lead. Thanks!

Documenting this process could be a useful addition to the doc (in case specific config is need to process js_of_ocaml programs).

Sure.

Detecting feature availability before use and fallback to another implementation inside jsoo feels like too much to maintain.

I understand.

Regarding quickjs, we could consider supporting if you think it makes sense.

I think it makes sense to use javascript outside of the web, e.g. see the node ecosystem. However, node is a nightmare to port to a new architecture, and effectively has not been ported to e.g. hurd (and it doesn't look worth it to spend time doing so)... that's why I consider quickjs. Moreover, its embeddability is appealing.

BTW, the same applies to wasm, and wasm_of_ocaml seems too tied to the web at the moment... (but that could be the subject of its own issue)

[hhugo]

BTW, the same applies to wasm, and wasm_of_ocaml seems too tied to the web at the moment... (but that could be the subject of its own issue)

#1831 should help

[hhugo]

A quick test with my app breaks on modern browsers. This needs further investigation, but looks like a good lead. Thanks!

It might be because the result of babel needs to be "bundled" to resolve require/import.
I've just opened #2216 to test workflow.

[glondu]

It turns out the breakage is due to an "Uncaught InternalError: too much recursion" appearing with the transpiled bundle.

My code probably relies on tail recursion working. Is it possible the way they are handled in js_of_ocaml is incompatible with babeljs?

[hhugo]

It turns out the breakage is due to an "Uncaught InternalError: too much recursion" appearing with the transpiled bundle.

My code probably relies on tail recursion working. Is it possible the way they are handled in js_of_ocaml is incompatible with babeljs?

You're saying that a working jsoo program no longer works after going through babel ? What babel config did you use ?

Also, regarding the original report, can you mention the last working version for your usecase .

[glondu]

You're saying that a working jsoo program no longer works after going through babel ?

This is correct.

After further investigation, the "too much recursion" error happens inside a function that is written in CPS style (hence doing many tail calls), and when the input size is bigger than a (not so big) threshold... This is not the first time I face issues with CPS style in jsoo context! I don't know how feasible it would be to warn on unoptimized tail calls in jsoo itself, it would help in debugging this kind of situations.

I rewrote the offending function without using CPS, and it works.

What babel config did you use ?

I used the config and pipeline from #2216

Also, regarding the original report, can you mention the last working version for your usecase .

Difficult to say... I don't have access to the problematic device (nor its owner).

[hhugo]

@glondu, can you test #2229 for quickjs support ?

[hhugo]

I've merged #2216.