Is this repository concerned with only Node.js and Deno - not QuickJS, txiki.js, Bun?

[guest271314]

What is the end-goal of this repository? What does a deliverable look like?

[crabmusket]

Per the readme,

The idea behind the Minimum Common API is to document the minimal collection of Web Platform APIs that ought to be implemented by Web-interoperable runtimes.

So, I imagine a deliverable from this group would look like this by without the massive "unofficial draft" watermark.

[guest271314]

Right,

to be implemented by Web-interoperable runtimes.

That is why I do not understand why this #33 was closed.

That "Web-interoperable runtimes." needs specificity. Currently that phrase can be interpreted narrowly or broadly, depending on who is doing the interpreting.

[ljharb]

It seems like it needs to be interpreted by the runtimes themselves. If QuickJS, for example, plans to be web-interoperable, they would say so. If they haven't, then they likely aren't.

[guest271314]

It seems like it needs to be interpreted by the runtimes themselves. If QuickJS, for example, plans to be web-interoperable, they would say so. If they haven't, then they likely aren't.

Have you asked?

If you are taking the lead in the goal, then you must be pro-active in asking potential stakeholders what their interests are, if those parties are interested in participating in your group. Have you performed due diligence to ask maintainers of JavaScript runtimes other than V8-based Node.js and Deno if they are interested in your work?

For example one of the proposed specification items is Fetch. HTTPS.

How is Fetch implementation per any specification emanatating from going to be tested?

With different servers?

If there is to be true interoperability the proof would be in a design that is made by the participants and works on all implementations the same.

Note, you have never actually defined "web-interoperability" in your explainer.

[JakeChampion]

A runtime can use the web-platform-tests for conformation, which is what we do for the Fastly js-compute-runtime project and it's web implementations such as fetch.

For example, here are our current test results -- https://github.com/fastly/js-compute-runtime/tree/main/tests/wpt-harness/expectations

[guest271314]

What is Fastly js-compute? A JavaScript runtime itself?

[guest271314]

@JakeChampion My interest here is literally a minimal JavaScript runtime that is also capable of having a built-in HTTP Web server, and interoperability of JavaScript and Web API's. That is how I got here. Node.js and Deno do not provide a means to start with an application written in JavaScript then use that source code to build the JavaScript engine necessarily to only execute that code - and do nothing else. Not carry around V8 in C++ or Rust while not using a bulk of the predisposed built-ins and in the case of Nodes.js - a package manager, too. That is how I interpret "web-interoperability". W begin with the code and scale from there, not begin with V8 - without the ability to remove unnecessary functionality for a minimal runtime before we build.

QuickJS provides a minimal JavaScript runtime, is not shipped with an HTTPS server to use for local development - so we do not have to make requests to the "cloud" to test.

[JakeChampion]

What is Fastly js-compute? A JavaScript runtime itself?
Yes, built on top of Spidermonkey and using web APIs.

https://js-compute-reference-docs.edgecompute.app/

[crabmusket]

That "Web-interoperable runtimes." needs specificity.

My interest here is literally a minimal JavaScript runtime

I don't claim to speak for the WinterCG project or any of its members, I'm just a random passerby, but it seems clear to me you're asking in the wrong place. WinterCG's website and this repo clearly state they're trying to produce specifications. This is not a new runtime. On the other issue you linked to, it was stated that building an HTTP server is out of scope for WinterCG.

QuickJS provides a minimal JavaScript runtime, is not shipped with an HTTPS server to use for local development - so we do not have to make requests to the "cloud" to test.

It sounds like you should be petitioning QuickJS to add a server, or starting that project yourself. If you, or someone, did do that, you could choose to be compatible with whatever standard WinterCG decides to produce around web servers.

I can't see any current part of the WinterCG docs suggesting they have a spec for web servers, and I don't know if they intend to produce one, but even if they did, the result would be a spec, not an implementation.

[guest271314]

@crabmusket

I can't see any current part of the WinterCG docs suggesting they have a spec for web servers, and I don't know if they intend to produce one, but even if they did, the result would be a spec, not an implementation.

To what end?

How do you even verify an implementation is in compliance with Fetch standard without using the same server code?

Yes, what you linked to includes servers, this includes an HTTPS server when we are talking about Fetch

The ultimate goal of the group is to promote runtimes supporting a comprehensive unified API surface that JavaScript developers can rely on regardless of the runtime they are using: be it browsers, servers, embedded applications, or edge runtimes.

[JakeChampion]

How do you even verify an implementation is in compliance with Fetch standard without using the same server code?

By using the web-platform-tests which already exist to test for conformance - https://web-platform-tests.org/

[guest271314]

@JakeChampion Using what server code?

[guest271314]

What is Fastly js-compute? A JavaScript runtime itself?
Yes, built on top of Spidermonkey and using web APIs.

https://js-compute-reference-docs.edgecompute.app/

If I am reading this correctly js-compute just makes requests to an external server API?

[guest271314]

@JakeChampion At js-compute-runtime-cli.js in js-compute-runtime-1.3.4 downloaded .zip file there is

#!/usr/bin/env node

which is an assumption that node executable is installed globally. I don't normally install node, deno, bun, tjs, or qjs executables locally or globally. I fetch the nightly or lastest build, and in the case of Node.js, get rid of everything else in the nightly download, and run the JavaScript engine from that directory.

So Fastly js-compute depends on node being installed in PATH.

If I am missing something about js-compute based on making external requests to Fastly kindly direct me to the documentation where I can use js-compute runtime locally without relying on Node.js or Deno being installed or using either executable to run js-compute or the server code which is being used to test "Web-interoperable runtimes.".

In other words, you can't use Node.js to test Node.js runtime.

Interoperability from my vantage, is not making an assumption that node is installed and will be used to perform an programmatically agnostic task just to use js-compute.