which parts of this proposal are intl?

[zbraniecki]

The unit conversion API seems like a non-intl, cheap to implement user land solvable problem. As such I struggle to justify it being proposed to extend the surface of the standard API. And if most will disagree on the value, I'd argue it should be non-intl proposal. My concern is that this part is in intl proposal because it feels easier to get it into spec via this channel, rather than because this is the right space for it.

The intl part is cross locale conversion. I can see that being a potential API (human hight units between en-US and en-GB). I'd recommend scoping this proposal within ecma402 down to just that operation.

Separately I'd like to see an analysis of that operation being common, and costly to implement in user land.

[younies]

I totally understand that the Locale-aware units conversion is the most Intl part of this proposal, However:

1. We could not have the locale units conversion without implementing Units Conversion and Complex Units Conversion (at least internally).
2. Many users need the conversion and the translation of the unit. For example, In the fitness app, I want to show the units in Arabic, Hebrew or French languages and also the users can convert those units.

Therefore, I think having those Units Conversion tools is needed and related to Intl.

[zbraniecki]

We could not have the locale units conversion without implementing Units Conversion and Complex Units Conversion (at least internally).

We could not have ListFormatter with Array/List, but that doesn't mean Array/List should be specified in Intl.

Many users need the conversion and the translation of the unit. For example, In the fitness app, I want to show the units in Arabic, Hebrew or French languages and also the users can convert those units.

I don't understand how is it a justification to standardize it. Yes, "many users" need "many things" and millions of developers develop millions of apps. We shoudn't add everything and a kitchen sink to standard API because of that. What's special about it? What's hard to implement as a library?

[Jamesernator]

We shoudn't add everything and a kitchen sink to standard API because of that

Why not? Other languages see lots of use of their standard libraries which are often much larger than JS's.

Like we shouldn't be going too far in the direction of say PHP which has random bizarrely specific API bindings (like all those thin C wrappers for weirdly specific libraries), however incredibly common operations should absolutely become part of the language (or at least standardized Web APIs like URL or similar).

One simple reason for this is that any library that needs to be done in userland, is something that ultimately needs to be shipped, parsed and loaded into any runtime that will utilize it. In cases where huge amounts of people are basically shipping the exact same thing it makes sense to add that as a standard part of the library.

Also, unlike other a lot of other languages, JS at the very least has a fairly high bar for inclusion in the standard library, rather than just adding what the engine developers feel is neccessary, inclusion of general APIs in the standard library tends to be based more so on what is already popular in the community. (i.e. array.flatMap, or Object.fromEntries).

[zbraniecki]

Why not?

The list of reasons is very long, but I'm not sure if it is documented well in any place. Your question makes me realize that it should.

Generally speaking there is an (exponentially) increasing cost of growing the API, and for stdlib the cost is much greater. And then for the Web Standard the cost is much greater yet.

Every single piece of API has to be maintained, in case of the Web basically "forever". Every future piece of API has to be aligned and consistent with it, or risk growing API inconsistency. Every piece of web API has to be implemented by every implementation which increases the barrier to entry. Every bug becomes "forever". Every mistake petrifies.

In result, there's a strong set of reasons to push absolutely everything possible further away from stdlib, toward the edges. Whatever possible should be implemented as a library.

Only when library solution is not feasible, should we consider extending API surface.

One simple reason for this is that any library that needs to be done in userland, is something that ultimately needs to be shipped, parsed and loaded into any runtime that will utilize it. In cases where huge amounts of people are basically shipping the exact same thing it makes sense to add that as a standard part of the library.

Correct. So the balance we're trying to strike is - what percent of web sessions will use such API? Is it high enough to justify shipping it and maintaining in every single browser (+ all the cost I described above)?

however incredibly common operations should absolutely become part of the language

And what is "incredibly common"? How do you measure it? If we can claim that there's a functionality that is incredibly commonly needed, then yes, we should consider including it in stdlib. One way to measure it is to develop it as a library and see it becoming incredibly popular. A great example of such story is jQuery which triggered W3C to develop querySelector and a number of other methods because jQuery, in fact, became incredibly popular.

Can you make the same claim about unit conversions? That there's a library that has 5 million downloads per week, and is integrated in, say, 8/10 top sites? or 30/50?

The second issue that you should think about is that the actual "need" is subjective. There are more than 10 million js developers. Each one of them needs something for their current project. What one sees as "absolutely critical", the other 9 million will never need.

If we keep adding everything that everyone asks for, we'll end up with unmaintainable mess. So we have to select. And as we select, we need to be careful not to pick what loudest, or most demanding people ask for, because that would lead to API design by yelling.

Instead, we're looking for things that are very costly to be implemented as libraries, have large scale value to large portion of the audience and have been battle-tested as libraries (so that we know that API design of choice is the right one - we have zero room for API design mistakes).

I question whether this proposal meets any of the criteria. It seems rather easy to develop as a library,

There seem to be a number of libraries - https://www.npmjs.com/package/convert-units - https://www.npmjs.com/package/js-quantities - https://www.npmjs.com/package/unit-converter - all of them moderately popular, all of them with vastly diverging APIs, and none of them seem to be blocked due to anything that stdlib needs to unlock.

Finally, on top of all of it, this proposal is conflating multiple different areas, which, even if all criteria were met, should be handled in different areas of the spec.

HTH