#863: ServiceWorker static routing API

Visit on Github.

Opened Jun 19, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of ServiceWorker static routing API.

This API allows developers to configure the routing, and allows them to offload simple things ServiceWorkers do. If the condition matches, the navigation happens without starting ServiceWorkers or executing JavaScript, which allows web pages to avoid performance penalties due to ServiceWorker interceptions.

  • Explainer¹ (minimally containing user needs and example code): url
  • User research: it is a well-studied phenomenon that faster sites are better for users, but we have not conducted any user studies specifically on this feature.
  • Security and Privacy self-review²: url
  • GitHub repo (if you prefer feedback filed there): url (proposed to move to WICG)
  • Primary contacts (and their relationship to the specification):
    • Yoshisato Yanagisawa (@yoshisatoyanagisawa), Google
    • Shunya Shishido (@sisidovski), Google
  • Organization/project driving the design: Google Chrome
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): W3C Service Workers Working Group
  • The group where standardization of this work is intended to be done ("unknown" if not known): W3C Service Workers Working Group
  • Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/w3c/ServiceWorker/issues/1373
  • Major unresolved issues with or opposition to this design: Maybe no as far as I took a glance at https://github.com/w3c/ServiceWorker/issues/1373
  • This work is being funded by: Google

You should also know that...

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Discussed Aug 28, 2023 (See Github)

Max: I looked at this. The use case - is trying to solve the problem that sometimes some JS - not necessary to run all the JS using the SW - bypass the SW in some cases. So they designed this static routing API. The question I have - looking at their descritpion - uses a mechanism that is not stable yet. https://github.com/WebKit/standards-positions/issues/206 : comment that it builds on URLPattern but this hasn't been standardized..

Dan: no progress on the Mozilla standards position https://github.com/mozilla/standards-positions/issues/828

Dan: It's going to Origin Trial according to the Explainer...

Yves: I think URL pattern is a version of Regexp where most of the expeisnve things are removed....

Dan: Service Worker Scope Pattern Matching also made use of URLPattern...

Dan: I think it's concerning that something like URLPattern that is being used as a building block is still not "stable" or is sitting in WICG instead of having been brought forward...

Dan: feels like they have to have a plan for standardization of URL Pattern

max to leave comment

Comment by @maxpassion Aug 30, 2023 (See Github)

Hi @yoshisatoyanagisawa, We had a discussion in our breakout C meeting this week. One concern is that this proposal uses URLPattern but URLPattern has not been standardized. Is there any update on this?

Comment by @yoshisatoyanagisawa Aug 31, 2023 (See Github)

Thank you for reviewing our proposal! @domenic @wanderview Do you know the current URLPattern status?

Comment by @domenic Aug 31, 2023 (See Github)

URLPattern is fully specified. It's true that it hasn't moved to a standards organization, but that's due to other browsers choosing not to implement, which isn't something we can speak to; you'd have to ask representatives of other browsers about their plans in that area.

Discussed Sep 4, 2023 (See Github)

Dan: Some discussion... URLPattern is spec'd in a CG but not a standard due to other browsers not implementing. Doesn't sound like there's a technical issue with it.. Anne said they'd be supportive of it if the venue was resolved

Yves: position from other browser vendors is clear

<blockquote> Hi @domenic - thanks for that clarification. As with a number of other current reviews, in that case, I'd like to express concerns that we are building new capabilities on top of shaky ground – that is, existing specifications that do not have consensus and do not have multiple implementations across multiple browsers.

Further to that, we have another open review, Compression Dictionary Transport which also makes use of "URL Patterns" but does not appear to reference the URLPattern spec.

Could there be an option here to work together to specify static routing without relying on URLPattern, or to specify a fall-back?

Alternatively, is there a way forward to bring URLPattern forward for standardization that could unblock multiple implementations?

</blockquote>
Comment by @torgo Sep 5, 2023 (See Github)

Hi @domenic - thanks for that clarification. As with a number of other current reviews, in that case, I'd like to express concerns that we are building new capabilities on top of shaky ground – that is, existing specifications that do not have consensus and do not have multiple implementations across multiple browsers.

Further to that, we have another open review, Compression Dictionary Transport which also makes use of "URL Patterns" but does not appear to reference the URLPattern spec.

Could there be an option here to work together to specify static routing without relying on URLPattern, or to specify a fall-back?

Alternatively, is there a way forward to bring URLPattern forward for standardization that could unblock multiple implementations?

Comment by @domenic Sep 5, 2023 (See Github)

Could there be an option here to work together to specify static routing without relying on URLPattern, or to specify a fall-back?

I don't think it's a good idea to invent a second URL pattern syntax for routing on the web platform, and you need some sort of syntax for specifying URL patterns if you're to statically give a pattern for which URLs are routed...

Further to that, we have another open review, Compression Dictionary Transport which also makes use of "URL Patterns" but does not appear to reference the URLPattern spec.

Thanks for highlighting this! We will work to ensure that feature uses the platform's common URL pattern syntax which is designed in the URL pattern spec. I filed https://github.com/WICG/compression-dictionary-transport/issues/48, but it looks like this is already under discussion in https://github.com/WICG/compression-dictionary-transport/issues/42.

Alternatively, is there a way forward to bring URLPattern forward for standardization that could unblock multiple implementations?

Again, I think there's nothing blocking this besides the other implementations' interest. Chrome has done everything we can by laying out a full specification, web platform tests suite, and so on. The "way forward" is for another implementation to support standardization, and that's not something the Chrome team has control over. I'd really encourage the TAG to bring these concerns up with the other engines directly, instead of the current approach (which I see across multiple reviews) of asking Chrome team members for information on the future plans of other companies.

Comment by @kenchris Sep 5, 2023 (See Github)

URLPattern is quite popular judging from our polyfill https://www.npmjs.com/package/urlpattern-polyfill which has 3.5M weekly downloads. It is also implemented in Deno https://deno.land/api@v1.36.4?s=URLPattern

Comment by @torgo Sep 11, 2023 (See Github)

I'd really encourage the TAG to bring these concerns up with the other engines directly, instead of the current approach (which I see across multiple reviews) of asking Chrome team members for information on the future plans of other companies.

@domenic I think you know it's not the TAG's job to sell Google's vision of the web to other browser makers. Having said that, we are trying to drive cross-platform consensus around topics such as Powerful APIs and Web Privacy - I suggest you attend those sessions at this week's TPAC plenary to learn more.

Discussed Oct 9, 2023 (See Github)

Max: No response from comment... We gave them the comment that there is no standardization for URLPattern. They gave some feedback...

Dan: I don't think it's appropriate for the TAG to go chasing other browser vendors on behalf of Google... My propoosal is to close this with "satisfied with concerns" - the concerns being that this is built on top of a spec that is not being standardized anywhere... The design is fine and considering that as Ken said on sep 5, there's a polyfill available...

<blockquote> We're going to go ahead and close this with "satisfied with concerns" - we're happy with the overall design but we remain concerned about URLPattern's status on the standards track. Considering there seems to be a [way forward for standardization](https://github.com/WebKit/standards-positions/issues/61#issuecomment-1527486428), we'd encourage you to pursue that path. </blockquote>

closed with satisfied with concerns

Comment by @torgo Oct 10, 2023 (See Github)

We're going to go ahead and close this with "satisfied with concerns" - we're happy with the overall design but we remain concerned about URLPattern's status on the standards track. Considering there seems to be a way forward for standardization, we'd encourage you to pursue that path.

Comment by @chrishtr Nov 10, 2023 (See Github)

Considering there seems to be a way forward for standardization, we'd encourage you to pursue that path.

FYI the URL Pattern spec is now at the WHATWG and Webkit is positive on this proposal.