Alas, also has mis-use. You don't want to linearly parse urls, as a router! Addition was controversial because folks anticipated mis-use like this.
https://news.ycombinator.com/item?id=46043318
It would take a very large number of routes before linear search would become a noticeable performance problem.
At that point, you’d probably be splitting the router itself into multiple client bundles, with something at the root to quickly match the URL with a bundle of routes (maybe a hash table on the first URL segment, or even a trie).
This URLPattern library and linear search would still be a reasonable choice for implementing each individual route bundle. And in practice, just do it the naive way until it actually becomes a problem.
Can you talk more about this… I was under the impression that was the EXPLICIT reason [1] why it was added in the first place or did I misread your comment?
Hono for example has a RegExpRouter and a TrieRouter, both of which seek for a matching route from amid multiple options. URL Patterns, plural!
They also have a linear search router, which they even say could have wins in some cases. But for relatively complex apps, with lots of possible sub-routes, the idea of running theonesr search feels so bad to me.
I just tried to match a URL against about a hundred patterns of various types (thanks to Claude code), expecting it to be a non-issue.
A hundred regex tests, for example, is generally very fast. A quick Python script made them run in 0.85ms. A hundred Flask router tests is 2.64ms.
So I had no reason to think this API would be slow. Surely matching a URL is a subset of generalized regexes and can only be fast? And given that routing is not an activity you do a lot, why would it matter anyway?
But the performances were atrocious: it took 8 seconds to resolve the worst-case scenario on Firefox, and it locked the entire browser UI.
Ok, note to self, stay away from the URL Pattern API.
For what it's worth, quite a lot of libraries don't use NFA/DFA style regexes and instead use something like PCRE, which aren't not necessarily linear in the worst case. I'd hope that URL pattern matching wouldn't need recursive backtracking or whatever, but probably quite a lot of the time people use libraries with the less performance implementations they're not intending to use those features either, so it probably wouldn't be the first time anyone accidentally make their matching way slower from this if that's what happened here.
In the near future I fear there may be laws about “LLMing while drunk” after enough rogue LLM agents vibe coded while drunk cause widespread havoc. You know folks harassing exs or trying to hack military depos to get a tank.
Yes but usually the routing is done as part of a library so the developers are unlikely to interact with the API themselves. It will just affect the internals of their routing library. Those libraries already have their own implementation of similar stuff.
Overall I dislike the shift away from a URL as a language-agnostic string primitive to some weird convoluted object which is limited to specific use cases.
URL literally stands for Universal Resource Locator... A string is Universal. It can be passed around easily between processes, it can be easily stored in a database, it can be easily shared online, it can be easily passed to an LLM... URLs were supported by LLMs before LLMs even existed! You've got to appreciate that!
This class they call URL is actually not a URL at all, it's more like a bound URLParser or URLExtractor.
A URL is a string that's a fact. Even ask Google; "is a URL a string?" it will say yes.
The idea of a URL instance as a language-specific construct is a bad idea. It's one of the reasons why many people don't like Java.
[EDIT] I don't dislike this API though it initially triggered my Java PTSD as I mistakenly thought it built on TOP of the URL instance. It actually takes things in the opposite direction as I initially understood; it's moving back towards URLs as string primitives which is what I advocate for. I do hope we don't end up adding too much more complexity related to URL handling though.
I was aware of the first part though I foolishly assumed by the name that it was designed specifically to work with the existing URL object. I then experienced a bout of Java PTSD.
Upon further analysis of the full API, it's not as bad as I initially thought.
My initial reaction was kind of surface-level eye-rolling "Oh no, don't tell me they managed to find a way to make URL parsing even more complicated than it needs to be."
But in a way, this is almost an attempt at rolling back the previous complexity introduced by the URL instance and acknowledging the utility of the URL as a string primitive.
It is additional complexity but I guess at least it might prevent the need for additional future complexity.
Great tool. So glad we have something!
Alas, also has mis-use. You don't want to linearly parse urls, as a router! Addition was controversial because folks anticipated mis-use like this. https://news.ycombinator.com/item?id=46043318
It would take a very large number of routes before linear search would become a noticeable performance problem.
At that point, you’d probably be splitting the router itself into multiple client bundles, with something at the root to quickly match the URL with a bundle of routes (maybe a hash table on the first URL segment, or even a trie).
This URLPattern library and linear search would still be a reasonable choice for implementing each individual route bundle. And in practice, just do it the naive way until it actually becomes a problem.
Can you talk more about this… I was under the impression that was the EXPLICIT reason [1] why it was added in the first place or did I misread your comment?
It’s also something the Lit team uses like here: https://www.npmjs.com/package/@lit-labs/router
I think maybe we are just debating the data structure the hold the patterns? Like it should be a trie rather than say a Set or Map.
[1] https://developer.chrome.com/docs/web-platform/urlpattern
Hono for example has a RegExpRouter and a TrieRouter, both of which seek for a matching route from amid multiple options. URL Patterns, plural!
They also have a linear search router, which they even say could have wins in some cases. But for relatively complex apps, with lots of possible sub-routes, the idea of running theonesr search feels so bad to me.
https://hono.dev/docs/concepts/routers
I just tried to match a URL against about a hundred patterns of various types (thanks to Claude code), expecting it to be a non-issue.
A hundred regex tests, for example, is generally very fast. A quick Python script made them run in 0.85ms. A hundred Flask router tests is 2.64ms.
So I had no reason to think this API would be slow. Surely matching a URL is a subset of generalized regexes and can only be fast? And given that routing is not an activity you do a lot, why would it matter anyway?
But the performances were atrocious: it took 8 seconds to resolve the worst-case scenario on Firefox, and it locked the entire browser UI.
Ok, note to self, stay away from the URL Pattern API.
For what it's worth, quite a lot of libraries don't use NFA/DFA style regexes and instead use something like PCRE, which aren't not necessarily linear in the worst case. I'd hope that URL pattern matching wouldn't need recursive backtracking or whatever, but probably quite a lot of the time people use libraries with the less performance implementations they're not intending to use those features either, so it probably wouldn't be the first time anyone accidentally make their matching way slower from this if that's what happened here.
...Eight seconds for a hundred matches? What does your code look like?
My bad, I should not read AI generated code while drunk at a xmas party. That's the total run time for 10000 iterations.
Average time for 100 tests is hence 0.8 ms. Completely normal, and absolutely acceptable, especially for an operation as rare as routing.
Letting my previous comment as-is for historical purposes. And to remind myself I'm a dumbass.
In the near future I fear there may be laws about “LLMing while drunk” after enough rogue LLM agents vibe coded while drunk cause widespread havoc. You know folks harassing exs or trying to hack military depos to get a tank.
Actually that’d be a fun sci-fi book.
> Note: This feature is available in Web Workers.
... is _also_ available in Web Workers, or _only_ available in Web Workers?
Also
At first glance it seems like this API would be more useful on the server side to do URL routing. What are the use cases for it on the client side?
routing in SPAs
Yes but usually the routing is done as part of a library so the developers are unlikely to interact with the API themselves. It will just affect the internals of their routing library. Those libraries already have their own implementation of similar stuff.
I don't like this API.
Overall I dislike the shift away from a URL as a language-agnostic string primitive to some weird convoluted object which is limited to specific use cases.
URL literally stands for Universal Resource Locator... A string is Universal. It can be passed around easily between processes, it can be easily stored in a database, it can be easily shared online, it can be easily passed to an LLM... URLs were supported by LLMs before LLMs even existed! You've got to appreciate that!
This class they call URL is actually not a URL at all, it's more like a bound URLParser or URLExtractor.
A URL is a string that's a fact. Even ask Google; "is a URL a string?" it will say yes.
The idea of a URL instance as a language-specific construct is a bad idea. It's one of the reasons why many people don't like Java.
[EDIT] I don't dislike this API though it initially triggered my Java PTSD as I mistakenly thought it built on TOP of the URL instance. It actually takes things in the opposite direction as I initially understood; it's moving back towards URLs as string primitives which is what I advocate for. I do hope we don't end up adding too much more complexity related to URL handling though.
The class isn’t called URL, it’s called URLPattern. Because it represents a pattern that URLs can be matched against.
I was aware of the first part though I foolishly assumed by the name that it was designed specifically to work with the existing URL object. I then experienced a bout of Java PTSD.
Upon further analysis of the full API, it's not as bad as I initially thought.
My initial reaction was kind of surface-level eye-rolling "Oh no, don't tell me they managed to find a way to make URL parsing even more complicated than it needs to be."
But in a way, this is almost an attempt at rolling back the previous complexity introduced by the URL instance and acknowledging the utility of the URL as a string primitive.
It is additional complexity but I guess at least it might prevent the need for additional future complexity.
I hope that's the idea.