Should we slow down deprecation/removal to support the usage in browsers?

[kt3k]

We deprecated and removed readableStreamFromIterable in std/streams because Deno implemented ReadableStream.from in v1.35, which overlaps with readableStreamFromIterable.

However the above removal affected the user who uses readableStreamFromIterable in Web browsers (Note: ReadableStream.from is not yet available in browsers except firefox). See #3579 (comment) )

Should we slow down our deprecation/removal pace to better support such use cases? (Especially 'removal')

[kt3k]

I think it makes sense to keep some APIs only for supporting browsers because we support and promote Fresh for web app development, and it encourages the mixed style of server-side and client-side programming.

[lino-levan]

I feel like there's almost an opportunity for a /std/shim which contains these "moved" APIs (and has room for other possible shims). Just a thought.

[kt3k]

Do you mean we should provide ReadableStream.from shim in std/shim?

[lino-levan]

That was my feeling, yes. We could also not do shims and tell people to look for more well-known solutions (corejs), but I'm not really too sure about that. It feels like shims for semi-modern (post IE) runtimes could be useful.

[lino-levan]

We could just provide some ponyfills if needed. I'm kind of swaying back and forth on this one. The docs should be really clear what method to use instead in modern runtimes.

[jollytoad]

My specific use case was for shunting some server-side Deno code into a ServiceWorker, it would certainly be handy if std provider something like the suggested std/shim, ReadableStream.from and URLPattern are two good polyfill candidates for this. I'd be happy to help contribute to this effort if it was agreed upon as a path forward.

[iuioiua]

I like the idea of a polyfill until sufficient browser support for a particular API exists. I think it should have the following properties:

• Be identical to the upcoming API, as much as possible, including type signature, behaviour and name.

  // streams/readable_stream_from.ts
  function readableStreamFrom<R>(asyncIterable: AsyncIterable<R> | Iterable<R | PromiseLike<R>>): ReadableStream<R>

• Declare that the function is for client-side code while browser support is pending and that the native equivalent is recommended outside of that use case.

[iuioiua]

Alternatively, we now have a Deprecation Policy, which has an answer for these use cases - use an older pinned version of the Standard Library. Should we be happy with that answer or provide polyfills? My concern is that we can get carried away with polyfills and start to compete with other libraries, such as core-js, which I don't think we should do.

[kt3k]

Closing as we decided on the deprecation policy.

@lino-levan Please open a new issue if you still feel strongly about std/shim idea.

[jollytoad]

It may also be helpful in deprecation notices to provide links to third-party polyfills. To at least confirm there is a polyfill before deprecation.

[iuioiua]

Yeah, that might be a good idea too.

[lino-levan]

@lino-levan Please open a new issue if you still feel strongly about std/shim idea.

I think I've more or less decided that the deno standard library should be focused on providing support for deno programs. We really do not want to get into the headache that is polyfills. Community projects are much better for that imo. I think it would be cool if someone put the std ponyfills into something like /x/shim.

Pinning to an old version of std seems reasonable to me.