What happens when an implementer is not in conformance with the controlling specification?

[ljharb]

Specifications don't "control", so the implementer would simply not be conforming with the spec. Generally, one files an issue with the implementer to notify them, and either the implementation will change to conform, the spec will change to match the implementation, or it will persist as a willful violation.

[guest271314]

I think the only way you can achieve the goals for Common Minimum API is to implement this yourself.

It is challenging enough just to let implementers of Web API know their source code is broken. Then once notified they can feign ignorance about technologies that use their gear, claim the specification for the Web API gives leeway to do or not do something, or just ignorethe notification altogether. When users who are banned from the implementers' feedback channels officially the challenge becomes twice as tedious. And so forth.

It doesn't take a bunch of people or resources to roll a JavaScript runtime circa 2023. You seem to know what you want, and have gotten this far by publishing your concerns. Make it happen and be done with the matter as to who is going to do what. Otherwise it's the same circular churn.

[ljharb]

I’m really not sure what you mean, but in all the arenas I’m privy to that info, less than 5 people have ever been banned for behavior over all time, so it’s not very common.

[guest271314]

You are basing things on numbers, which doesn't really mean anything. Of those 5 all 5 can locate bugs in your implementation that perhaps won't be addressed or fixed because of your biases against addressing bugs reported by banned users.

Counting numbers of users of an application is an ego trip, not based on technical capabilities claimed, tested, verified.

Anyway, Deno fetch(0 and Node.js fetch() behave wildly differently, so you're gonna have to address that technical fact for a common minum API.

I noticed you folks are referencing BackgroundFetch yet in your published draft all you have is fetch(). BackgroundFetch and fetch() are not identical.

[guest271314]

I don't think the maintainers of this actually test the JavaScript Web API's of the other stakeholders, if even their own gear.

You need independent testers of your proposals and existing Web API.

What I observe is Node.js and Deno maintainers are so engrossed in their own API's that they don;t even test their own gear, or even care if they think the "vast majority" of the users of their gear follow the basic, generic suggestions in their documentations, and venture no further.

The minute an individual statrts testing Node.js or Deno in applications that the maintainers of Node.js and Deno don't view as in the domain of "popular" packages or applications, they tend to just ignore the use cases.

You need people that will test you gear without any hint of brand loyalty, and give you the facts striaght up, without regard to maintainers concerns about "Popularity" or API usage metrics - just the code. Otherwise you will just be preaching to the choir you always have been and this proposal will be useless.

Good enough ain't good enough. You have to test. You can;t speculate about what other JavaScript runtimes are doing, nor trust their claims, and maintainers are too invested in their own gospels to think anything outside of their thinking is going on wirth going on.

You need folks that are going to tear your claims and gear to pieces, without rancor. Such as the case of Deno fetch() implementation supporting full duplex streaming, Node.js implementation of fetch() hasn't even been tested by its own Members to speak on full duplex streaming capabilities. Thus, nothing is common between the full duplex streaming Deno fetch() implementation and the Node.js fetch() implementation which doesn't even fetch() the resource or fulfill the Promise under certain conditions, for example, Node.js fetch() won't fetch() in an async function unless it is returned from the function. The problem is no Node.js Members have even bothered to test and reproduce that technical fact, so this goes into the unknown re

and either the implementation will change to conform, the spec will change to match the implementation, or it will persist as a willful violation.

as you can;t make a rational decision if you wilfully decide to not test your own gear, even the edge cases and applications.

[ronag]

What is your suggested solution to the problem you are presenting? Please remember that Node is developed by volunteers that do not get paid. In the case where Node development is funded, it's usually by some company or individual that has a specific need.

So unless you can help provide funding for someone to fix this problem or make some volunteers interested in resolving it in their spare time; I don't see what you are trying to achieve here.

Either way, what is the specification group supposed to do about non-conformity? This seems more like a problem to be raised directly with Node and not here.

[guest271314]

What is your suggested solution to the problem you are presenting?

I propose independent testers verify if a runtime is conformant with a specification or not.

Either way, what is the specification group supposed to do about non-conformity?

I don't think there is much you can do besides deny that a runtime is non-conformant.

When independent testers make the call that gets away from people patting their own back or plausible deniability for if a runtime is conformant or not.

Just like people volunteer for Node.js people in the field use Node.js and I'm sure are happy to test runtimes until they break to verify their conformance or not. It's easy enough for somebody representing Node.js to make claims that node is in conformance. Not easy when that chore is out of their hands.

[guest271314]

@ronag At the bare minimum everybody involved in this projects needs to test every runtime using the given API.

I don't think Node.js people are testing the same code in Deno, and probably vice versa. If this thinkg is to be folks needs to expand their testing regime to not just the runtime they are representing. Then they themselves will see the differences in implementations, and will be informed when somebody in the field brings up inconsistencies.

Right now this seems to be a vision, rather than a practical brick and mortar daily regime of testing the same code in different JavaScript runtimes.

Take Bun as an example. Bun's implementation of a server using ReadableStream does not stream unless non-specification, Bun-specific methods that are not found in WHATWG Streams are used https://github.com/oven-sh/bun/issues/1886#issuecomment-1615162853.

[guest271314]

So unless you can help provide funding for someone to fix this problem or make some volunteers interested in resolving it in their spare time; I don't see what you are trying to achieve here.

Sure. I can test and verify the veracity the claims of the runtimes involved.

I test various JavaScript engines and runtimes and am not brand loyal to any. I don't care if Node.js is doing it right or Deno is doing it right and have no qualms about notifying people when their gear is broken, which I know because I test until the gear breaks.

It is mathematically impossible for a system to verify the truth of it's own claims, therefore such testing and verification needs to be independent.

1. If a (logical or axiomatic formal) system is consistent, it cannot be complete.

2. The consistency of axioms cannot be proved within their own system.

• Kurt Gödel, Incompleteness Theorem, On Formally Undecidable Propositions of Principia Mathematica and Related Systems

[ronag]

Sure. I can test and verify the veracity the claims of the runtimes involved.

I think we already know that Node is not fully compliant. I don't think anyone disagrees with this. Then what?

If I understand correctly, you ask that Node remove any claims of full Web API and/or WinterCG conformity. Do you have any specific places where you would like this claim to be removed? I'm not aware of any such claim at the moment. Or maybe Node should be more explicit about what parts of the spec it's known to be non-compliant with?

[ronag]

FYI, the Node fetch implementation does test against WPT and volunteers do put some effort into making sure they pass. https://github.com/nodejs/undici/tree/main/test/wpt

[guest271314]

I'm saying that for this project because people are so vested in their own implementations that a page be created to display the results of independent testing of the given API, including descriptions of edge cases and use cases. Then you have empirical evidence as to which JavaScript runtime does what adjacent to each Web API Common Minimum API lists as being common to all stakeholders.

I'll put it this way.

Let's say you get rich selling a popular Web App, have a trust fund hippy, are a financier, a rock star, whatever, you got some money. You want to build your family's dream home. You hire sought after architechs and engineers to draw up your plans. That's your specification. You have a long way to go before you ever dwell in that home. You have to get a permit to build from the city or county. The city or county has to approve your plans (specification). You have to survey, make sure your property is not on a wetland or a protected animal lives in the tree where your plans map out the palatial drive way.

If the government approves your plans, then you have to excavate the land. Then survey again, just to make sure your pins and offsets are correct. If you don;t it can cost you a lot of money and time when a similarly wealthy neighbors say to the city, so-and-so new construction is over a property line. And their right. You have to demolish whatever you have so far and start again. After litigation and rescheduling.

Alright, your neighbors are cool. The general contractor you hired can now implement your specification. Excavate. Maybe you have good land, maybe you don't. That can change the plans. Set up forms for foundation.

Now the fun begins. At each stage of your project a city or county inspector inspects the work of the sub-contractors.

Imagine if the general contractor could inspect and sign off on the sub-contractors they hired, well, every inspection would pass!

That's not how it works though. An independent inspector must approve the foundation per the local ordinances and the plans - your specification.

An inspector must approve the plumbing, electrical, and all structural framing, etc.

The general contractor and the architect and the engineer don't get to inspect and pass the inspection of their own work.

No matter how popular your rock star songs are, how acclaimed you are internationally, or how much quiet money you got - your build will get inspected by governmental inspectors who are not supposed to be invested in your branding nor impressed with so-and-so architect and engineer.

People can spend a lot of money on non-top-drawer multi-million dollar homes, when they think they are getting top drawer.

That's what I mean by good enough ain't good enough. Some people ain't impressed by popularity. See it every day. So, what? You have to have somebody that is always looking at everything - because detail matters when you are at phase 1 of a multi-phase process.

And then there is V.I.F. on plans: Verify In the Field. That means an engineer or somebody has drawn up something that you, the professional builder, must verify in the field.

I think that's where we're at with this proposal.

So, since you folks are swamped volunteers what I suggest is that people who have posted on this repository who are not vested in any brand test the Web API's listed in your Draft and report and publish the results for each JavaScript runtime, so people don't get the idea that just because Node.js implements it's version of a specification.

Honest result for folks who are interested in this, which I would say is not the average user, rather users who actually test code. At least that's what one might perhaps mistakenly think. Until an individual posts complete steps to reproduce what happens for a use case of fetch(), and the alleged experts of that domain don't V.I.F. So, no attention to the details at phase 1 means you will probably be way off at stage N of the project.

[ljharb]

I'm afraid that's a profoundly poor analogy for software.

[guest271314]

How would you know unless you wrote code every day and were involved in multiple multi-million dollar projects building things for wealthy people?

Writing code every day is not the only thing I do. I might be involved at multiple projects during the day, performing primary research in the evening, writing a brief to file in federal court later in the evening, and testing more code before more research for clients. That's an average day.

People get wealthy and want exacting standards for their own forever home. They want top drawer. They pay for it, too.

It's the same principle in any discipline. You are as only good as your attention to detail.

The actual implementations that are supposed to be common are not common, they are wildly different, and that difference needs to be spelled out adjacent to the Web API: "Node.js does not support full duplex streaming using fetch() in some cases. Deno does support full duplex streaming using fetch(). The Fetch Standard does not specify full duplex streaming. See Fetch #1254.". That is attention to detail and honesty. Now we know where we are at.

[guest271314]

I'm afraid that's a profoundly poor analogy for software.

Funny.

I was involved in some work for a guy who said what he did, I said I was familiar, and wrote code every day after my other gigs. Wound up being involved in Intel chip testing for Mac. He said they (Apple) found the bugs, sometimes before the Intel folks, and were very involved with the process.

I can't say the same for Node.js folks.

So, yes, we in the field need to have Notes by your claims here when we have evidence Node.js Members don;t even test their own gear to verify the bug when reported by a user in the field.

[guest271314]

Thanks for the proposal-common-minimum-api. Keep up the good work.