Design Meeting 2021-08-05

[kitsonk]

• Update on deno_graph
  • was discussed the previous week as part of Q3 roadmap review, but @kitsonk gave a further update on progress, well on track.
  • Discussion about whether import map should be pulled into deno_graph or not, as those consuming it would want to have support for import maps. The functionality is abstracted out as the Resolver trait, but there is no implementation.
  • Decision was to wait until the integration of deno_graph into CLI occurs.
  • Next step was integration into deno_doc.
• Service Workers, do we actually need them? (Implement the Service Worker API #5957)
  • Discussion around what they are actually good for as part of Deno. There is no compelling use case that they solve, and to implement compliant service workers is complicated and full of challenges that would need to be solved.
  • Note, this does not mean that the Cache and CacheStorage APIs are un-needed or unwanted. They were implemented as part of service workers and are critical to service workers, but they aren't isolated to service workers in the web platform.
  • Decision the core team is not opposed to service workers, but there is no compelling use case we can see. If someone had a use case and wanted to contribute it to Deno we wouldn't oppose it, though we caution any implementors that there be dragons.
• Quota Management and StorageManager API (Implement quota management and StorageManager API #11525)
  • Discussed that all browsers have a non-user facing quota manager. How they implement it varies from browser to browser.
  • Quota Management is an internal API that enables other user facing features. The StorageManager API gives a user some view into storage and capacity management to better manage their workloads.
  • Discussed that DENO_DIR is unbounded in size and we need to do something eventually there.
  • There is nothing currently broken that this would fix, but if we were to add CacheStorage or IndexedDB it starts to become a problem.
  • @ry concerned about expending effort on something that doesn't actually fix anything that is broken or doesn't deliver a direct user feature. Is this pre-mature optimisation?
  • Action to have a breakout meeting once people have better context and have done more research.
• Plan for deprecating std/http and std/ws (https://github.com/denoland/deno_std/discussions/1034)
  • @kitsonk is concerned that the proposal is just another abstraction and API we have to support. It isn't compatible with std/http as it exists.
  • It is trivial to implement.
  • @ry wondered what would happen with oak since native HTTP was stabilised, @kitsonk indicated it would just start using native.
  • Action determine how someone would change a std/http application to work with the new std abstraction. If it is change a couple lines, great, if it is more complicated, what value does a new abstraction bring?
• Enable Deno APIs by default in Workers (feat: Enable Deno APIs by default in Workers #8178)
  • Ultimately it is a mistake we made with 1.0.
  • It was not until Deno 1.4 that workers could access the Deno namespace and only with an explicit flag.
  • Changing it before 2.0 is likely to cause strange and exotic regressions in code, because of the way permissions interact with workers, and code that might be expecting to run in an environment without the Deno namespace actually seeing it, and then trying to do something, but not having the right permissions would break.
  • Decision it is not burdensome to pass deno: true in the worker options, because type: "module" already has to be passed in Deno, and the risk of breaking changes for little to no value for the user isn't worth the risk, but we would like to correct the mistake for Deno 2.0.
• REPL --eval flag (deno repl --eval flag #11317)
  • Python has this and it's nice
  • Really solves the problem of having a specific, easily repeatable, REPL context to work with
  • Action progress forward, though specific semantics to debate.

[nayeemrmn]

Plan for deprecating std/http and std/ws (RFC: std/http built on the native HTTP server deno_std#1034)

• @kitsonk is concerned that the proposal is just another abstraction and API we have to support. It isn't compatible with std/http as it exists.

I agree with this, regarding the serve() function proposed in https://github.com/denoland/deno_std/discussions/1034. I think an ideal set of choices for users to have would be to either use the built-in async iterator API or jump straight to something higher level like oak. Having an in-between which is basically a callback-based version of the built-in API doesn't offer significant value and becomes another thing to choose from.

I have a notion that async iterators should be preferred for simple request event streams, while a callback-based API becomes justified precisely at the level of abstraction where something like middleware is introduced. If you agree then Deno and std should limit their recommended options accordingly; avoid wrappers like serve(listener: Deno.Listener, handler: HttpHandler) in std until we want to explore routing or middleware along with it.

[lucacasonato]

Having an in-between which is basically a callback-based version of the built-in API doesn't offer significant value and becomes another thing to choose from.

The value it provides is that the footgun of awaiting in a for await loop goes away, and errors can be handled correctly.