You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Is this repository concerned with only Node.js and Deno - not QuickJS, txiki.js, Bun? #37
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.
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.
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.
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.
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.
@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.
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.
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 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.
Activity
crabmusket commentedon Feb 11, 2023
Per the readme,
So, I imagine a deliverable from this group would look like this by without the massive "unofficial draft" watermark.
guest271314 commentedon Feb 11, 2023
Right,
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 commentedon Feb 11, 2023
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 commentedon Feb 11, 2023
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
Fetchimplementation 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 commentedon Feb 11, 2023
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 commentedon Feb 11, 2023
What is Fastly js-compute? A JavaScript runtime itself?
guest271314 commentedon Feb 11, 2023
@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 commentedon Feb 11, 2023
https://js-compute-reference-docs.edgecompute.app/
crabmusket commentedon Feb 11, 2023
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.
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 commentedon Feb 11, 2023
@crabmusket
To what end?
How do you even verify an implementation is in compliance with
Fetchstandard without using the same server code?Yes, what you linked to includes servers, this includes an HTTPS server when we are talking about
FetchJakeChampion commentedon Feb 11, 2023
By using the web-platform-tests which already exist to test for conformance - https://web-platform-tests.org/
guest271314 commentedon Feb 11, 2023
@JakeChampion Using what server code?
guest271314 commentedon Feb 11, 2023
If I am reading this correctly js-compute just makes requests to an external server API?
guest271314 commentedon Feb 12, 2023
@JakeChampion At js-compute-runtime-cli.js in js-compute-runtime-1.3.4 downloaded .zip file there is
which is an assumption that
nodeexecutable is installed globally. I don't normally installnode,deno,bun,tjs, orqjsexecutables 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
nodebeing installed inPATH.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
nodeis installed and will be used to perform an programmatically agnostic task just to use js-compute.