Hacker News Reader

Comment by danShumway | Hacker News Reader

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.

View on HN

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.

It's got to be frustrating to write something like this up and immediately see people jump to, "Google is taking over the world again."

To be clear, this looks really promising. I particularly like the way that import maps are polyfilled. I kind of wish standard modules were flat-out required to be imported in versioned form, since that would open the door to better API versioning on the web in general, but... whatever, that's what the standards process is for, and it looks like that's something people are at least already talking about.

But the unfortunate side of things is that because of Chrome's history, it's really easy to read posts like this as, "here's a new thing, and btw we're shipping it tomorrow." That's not your fault, it's just what the environment is like right now.

> All your users should benefit from better performance, and Chrome 74+ users won't have to pay any extra download cost.

To me that sounds like, "post Chrome 74, we will have this feature turned on for production sites." If that's not the intent, and Chrome isn't planning to turn this feature on early, then I'm much more excited about the proposal.

It seems a bit unfortunate to quote a sentence out of context and then misinterpret it like that. Let's expand the quote by one sentence:

> If your site currently uses localStorage, you should try switching to the KV Storage API, and if you sign up for the KV Storage origin trial, you can actually deploy your changes today! All your users should benefit from better performance, and Chrome 74+ users won't have to pay any extra download cost.

I'm not sure what that extra sentence changes. I would still (and in fact, did when I read the release) interpret both sentences together as, "you can enable this today via an origin trial, and in Chrome 74+ it'll be enabled permanently." I certainly wouldn't read it as, "you should sign up for an origin trial and then provide us with feedback so we can continue to evolve the spec."

I realize that to no small degree that's my own fault for not understanding the specifics of origin trials, but how many people reading this article already understand origin trials?

I don't want to derail things -- I just wanted to get clarification that this wasn't going to be HTML imports again. At the end of the day, I don't care how the announcement is worded as long as it's not actually being shipped in the next release as on by default for every site. The spec itself looks really interesting and I'm excited to see it develop.

I've updated the article to emphasize that this is indeed something we're experimenting with, and explain a bit more how built-in modules go through the standards process (in general and in Chrome).

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/sEw...

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.

Reply on news.ycombinator.com