Minimum Common Web Platform API for Non-Browser EcmaScript-based runtimes
Hi, thanks for Quickjs!
Have you seen this effort to standardize non-browser JS runtimes: https://common-min-api.proposal.wintercg.org/ ?
Do you think it would make sense for Quickjs to implement (a subset of) the proposed minimal spec (e.g. the File interface) ?
Perhaps, as a user, that would make it easier to switch from and to Quickjs from another runtime
(As the author of a runtime which uses QuickJS) I think this is not the right place for it. QuickJS is to X what V8 is to Node for example. So QJS provides the JS engine, your runtime provides the web APIs.
I think TextEncoder/TextDecoder could be useful. These are already implemented in e.g. Duktape, which, just like QuickJS, also is "just the engine".
It's not part of ecma, is it?
I'd much rather see quickjs remain minimal... I build functionality like encoders as optional features in my wrapper lib.. winterjs does seem interesting...
It's not part of ecma, is it?
You will see TextEncoder and TextDecoder in the list at https://common-min-api.proposal.wintercg.org/.
That is not the ECMAScript standard.
Okay, that makes sense. https://github.com/saghul/txiki.js looks nice! It seems like you're aiming for Web Platform API compatibility. Amazon released https://github.com/awslabs/llrt which is also Quickjs-based but instead seems to aim more for Node.js compatibility.
I only realized now that https://common-min-api.proposal.wintercg.org/ is actually quite different from how things are done in Node.js today.
For Quickjs I was just wondering if it'd make sense to make the existing functionality present in in the std and os libraries compatible with Node.js or Wintercg, but then again I don't know how nicely they would map onto each other in practice.
Some very basic things like TextEncoder would definitely be nice though. UTF-8 encoding/decoding is currently accessible in Quickjs via the unescape(encodeURIComponent(s)) hack (see https://stackoverflow.com/questions/13356493/decode-utf-8-with-javascript/13691499#13691499)
I agree with the author that implementing web APIs is not something that makes sense in the JavaScript execution engine - which should be focused on implementing the TC39 ECMAScript standard.
Web APIs and other standard libraries (like the Node.js standard library) should be implemented on top of the JavaScript engine.
That said, it would be nice for the QuickJS documentation to point us to projects that build on top of QuickJS which provide support for web APIs and the Node.js standard library (or at least as much as can be supported without being backed by v8).