alt Hacker NewsGreat 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
Replies
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
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.
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.