Call me naïve, but routing in a single page application is just not that hard of a problem. At the core it's about having a piece of state¹ (your active route) which determines which part of the app you want to render–something you can do with a switch statement². On top of that, you want to synchronize that state to the page URL³.

Doing it yourself requires more boilerplate code, no question about it. But it's not that much code tbh (not very complex either), and you get back control over that important piece of state, which otherwise remains opaque and difficult to work with–i.e., its "shape" is pre-determined by the routing library you use. For example, react-router doesn't support parallel routes.

¹ https://github.com/superegodev/superego/blob/main/packages/a...

² https://github.com/superegodev/superego/blob/main/packages/a...

³ https://github.com/superegodev/superego/blob/main/packages/a...

I agree with the other two comments, surely almost every frontend webdev has implemented a router in their career unless they never strayed from the major frameworks. It's really not a complicated thing to have to build. I'm not one to look a gift horse in the mouth but I don't see why we're being given this one.

Unfortunately cases like here in the article are an example of why URLPattern had enormous push back during development. It's not the worst thing in the world to run three or four patterns one after another. But generally, doing a linear search for the right pattern doesn't scale well at all! If there's a dozen routes, running pattern after pattern is probably not ideal!

We can look at Hono routers, for example. Which has a bunch of different examples, most of which will one-shot a bunch of patterns at once. RegExpRouter, TrieRouter. There's good write-ups for the tradeoffs across them. But they all take a bunch of routes up front, and combine them into a single matcher, attempting to re-use work across patterns. https://hono.dev/docs/concepts/routers

Really good we have URLPattern, but this is the anti-use-case, that almost convinced folks not to make URLPattern at all.

> Another thing- should we be building a router with web components? Eh... maybe not? Lit seems to think (it would be helpful and useful)[1]. But there are a lot of considerations you have to handle with your own implementation that framework routers have already solved. Web components also add another level of security you need to be aware of.

The Lit Labs router isn't a web component. It's a Lit reactive controller that lets you define a router separately from a component, but attach it to a component so that the component updates when routes change. So we're saying don't make your router a web component (ie `<my-route path="...">`

Also there isn't another level of security web components. They're implemented in script just like a router. Script running in a page can do all kinds of things.

[1]: https://www.npmjs.com/package/@lit-labs/router