Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimum Common Web Platform API for Non-Browser EcmaScript-based runtimes #233

Open
rmst opened this issue Feb 8, 2024 · 8 comments
Open

Comments

@rmst
Copy link

rmst commented Feb 8, 2024

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

@saghul
Copy link
Contributor

saghul commented Feb 8, 2024

(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.

@Emill
Copy link

Emill commented Feb 8, 2024

I think TextEncoder/TextDecoder could be useful. These are already implemented in e.g. Duktape, which, just like QuickJS, also is "just the engine".

@saghul
Copy link
Contributor

saghul commented Feb 8, 2024

It's not part of ecma, is it?

@andrieshiemstra
Copy link

I'd much rather see quickjs remain minimal... I build functionality like encoders as optional features in my wrapper lib.. winterjs does seem interesting...

@Emill
Copy link

Emill commented Feb 8, 2024

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/.

@saghul
Copy link
Contributor

saghul commented Feb 8, 2024

That is not the ECMAScript standard.

@rmst
Copy link
Author

rmst commented Feb 10, 2024

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)

@alshdavid
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants