4 ms·

Hey! Spec editor here. KV storage is being worked on in a standards body, the WICG. It has healthy cross-vendor collaboration, including Mozilla (who influence

Hey! Spec editor here. KV storage is being worked on in a standards body, the WICG. It has healthy cross-vendor collaboration, including Mozilla (who influenced the API design and naming significantly) and Microsoft (who encouraged us to work on it in the WICG and then eventually merge it into the IndexedDB standard, which they are one of the editors of). It also has a decent amount of collaboration from various web developers. I'd encourage you to check out the issue tracker and the minutes of the W3C TPAC standards meeting for more!

callahad 8y ago
Hi Domenic! First: I'm outside the edit window for the original post, but in hindsight it reads as more of an ad hominem than intended. My apologies. I don't mean to malign the technical aspects of KV Storage, nor WICG / TPAC / TC39 / etc. collaboration, but rather the specific positioning of KV Storage in the article. There's no acknowledgement of collaboration nor explanation of where this proposal sits in the standards process. In fact, it gives the opposite impression: - "the first one we're planning to ship" - "do we have to wait until all browsers support built-in module [...] no!" - "you can actually deploy your changes today!" - "Chrome 74+ users won't have to pay any extra download cost" That reads a lot like an Intent to Ship and counseling developers to begin relying on it, which feels wholly inappropriate given that the entire notion of having built-in modules at all is still a Stage 1 proposal. Similarly, I do not believe any vendor should claim an in-house implementation of their own proposal as being inherently part of "the Web." It may very well end up that way, but can we at least wait until the proposal hits Stage 3 before using that kind of language?
- domenicd 8y ago
  Hi callahad, I think there's some confusion about the standards venue this is taking place in. This work is being done in the WICG, at https://github.com/WICG/kv-storage https://github.com/WICG/kv-storage. The TC39 staging process, while relevant for any built-in modules TC39 may want to work on such as temporal, is not a blocker for web built-in modules. Just like web standards bodies and TC39 already collaborate on built-in globals, we're also collaborating with TC39 on built-in modules. Thus the links to the stage 1 proposal in the article and explainers. But in the end, KV storage is a web feature, and goes through the web standards process, which doesn't use the Ecma staging process. Instead, it uses the process others are discussing elsewhere on this thread: incubation, shipping to web users through early implementations or origin trials, eventually to stable, and then promotion to a standards body like the W3C or WHATWG. (In this case, to the W3C, as part of the IndexedDB specification.) Hope this helps!
  - danShumway 8y ago
    Just to be clear, is this article an intent to ship? That's the concern I have; not that it's going through the WICG, but that whatever process it's going through, this blog post sound like Google announcing user-facing shipment of a feature that hasn't finished its standardization process. We've already been through this before with Web Bluetooth and the Shadow DOM specification. Once Chrome turns a feature on for end users, it is effectively standardized -- it is very difficult to justify changing or evolving a spec once real sites on the actual web have already started to rely on it. Again, look at Shadow DOM as a good example of why this is a problem. I'd feel more comfortable about this process if there was some clarification that this is an intent to ship only behind a flag, or an intent to ship only to dev/beta versions of Chrome.
    - gsnedders 8y ago
      An intent-to-ship has to be sent to blink-dev, so per the Blink dev cycle this cannot be an I2S. There has however been an intent-to-experiment[0] and as the article says it'll be available as an origin trial in Chrome 74. (For those who don't know, origin trials are essentially an per-origin opt-in, time-limited way of shipping. It won't work by default, and in this case it won't work beyond Chrome 76.) [0]: https://groups.google.com/a/chromium.org/d/msg/blink-dev/sEwWEF80T4s/Nss9VxM3BAAJ https://groups.google.com/a/chromium.org/d/msg/blink-dev/sEw...
      - danShumway 8y ago
        Thanks. That makes me feel way better about this proposal. Intent to experiment is exactly where I would want a feature at this point in development to be -- gives normal people the ability to build things with it and figure out any pain points, but forces them not to use it in a production site quite yet.
    - philipwalton 8y ago
      Article author here, I probably should have been clearer in the article. I was trying to strike a balance between: - presenting what I believe to be a compelling and exciting possible future for the web (especially considering it has a viable polyfill story) - getting developers excited about this future and thinking about how it could integrate with existing tooling and: - Asking for feedback on the KV Storage and Import Maps APIs themselves. - Encouraging developer to experiment and/or sign up for the origin trial It's not an easy balance to strike, and in this case I probably should have emphasized more that this is still in the experimentation phase. I can update the article to make that more clear.

callahad 8y ago

Hi Domenic! First: I'm outside the edit window for the original post, but in hindsight it reads as more of an ad hominem than intended. My apologies. I don't mean to malign the technical aspects of KV Storage, nor WICG / TPAC / TC39 / etc. collaboration, but rather the specific positioning of KV Storage in the article. There's no acknowledgement of collaboration nor explanation of where this proposal sits in the standards process. In fact, it gives the opposite impression: - "the first one we're planning to ship" - "do we have to wait until all browsers support built-in module [...] no!" - "you can actually deploy your changes today!" - "Chrome 74+ users won't have to pay any extra download cost" That reads a lot like an Intent to Ship and counseling developers to begin relying on it, which feels wholly inappropriate given that the entire notion of having built-in modules at all is still a Stage 1 proposal. Similarly, I do not believe any vendor should claim an in-house implementation of their own proposal as being inherently part of "the Web." It may very well end up that way, but can we at least wait until the proposal hits Stage 3 before using that kind of language?

domenicd 8y ago
Hi callahad, I think there's some confusion about the standards venue this is taking place in. This work is being done in the WICG, at https://github.com/WICG/kv-storage https://github.com/WICG/kv-storage. The TC39 staging process, while relevant for any built-in modules TC39 may want to work on such as temporal, is not a blocker for web built-in modules. Just like web standards bodies and TC39 already collaborate on built-in globals, we're also collaborating with TC39 on built-in modules. Thus the links to the stage 1 proposal in the article and explainers. But in the end, KV storage is a web feature, and goes through the web standards process, which doesn't use the Ecma staging process. Instead, it uses the process others are discussing elsewhere on this thread: incubation, shipping to web users through early implementations or origin trials, eventually to stable, and then promotion to a standards body like the W3C or WHATWG. (In this case, to the W3C, as part of the IndexedDB specification.) Hope this helps!
- danShumway 8y ago
  Just to be clear, is this article an intent to ship? That's the concern I have; not that it's going through the WICG, but that whatever process it's going through, this blog post sound like Google announcing user-facing shipment of a feature that hasn't finished its standardization process. We've already been through this before with Web Bluetooth and the Shadow DOM specification. Once Chrome turns a feature on for end users, it is effectively standardized -- it is very difficult to justify changing or evolving a spec once real sites on the actual web have already started to rely on it. Again, look at Shadow DOM as a good example of why this is a problem. I'd feel more comfortable about this process if there was some clarification that this is an intent to ship only behind a flag, or an intent to ship only to dev/beta versions of Chrome.
  - gsnedders 8y ago
    An intent-to-ship has to be sent to blink-dev, so per the Blink dev cycle this cannot be an I2S. There has however been an intent-to-experiment[0] and as the article says it'll be available as an origin trial in Chrome 74. (For those who don't know, origin trials are essentially an per-origin opt-in, time-limited way of shipping. It won't work by default, and in this case it won't work beyond Chrome 76.) [0]: https://groups.google.com/a/chromium.org/d/msg/blink-dev/sEwWEF80T4s/Nss9VxM3BAAJ https://groups.google.com/a/chromium.org/d/msg/blink-dev/sEw...
    - danShumway 8y ago
      Thanks. That makes me feel way better about this proposal. Intent to experiment is exactly where I would want a feature at this point in development to be -- gives normal people the ability to build things with it and figure out any pain points, but forces them not to use it in a production site quite yet.
  - philipwalton 8y ago
    Article author here, I probably should have been clearer in the article. I was trying to strike a balance between: - presenting what I believe to be a compelling and exciting possible future for the web (especially considering it has a viable polyfill story) - getting developers excited about this future and thinking about how it could integrate with existing tooling and: - Asking for feedback on the KV Storage and Import Maps APIs themselves. - Encouraging developer to experiment and/or sign up for the origin trial It's not an easy balance to strike, and in this case I probably should have emphasized more that this is still in the experimentation phase. I can update the article to make that more clear.