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

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?

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.