Don't you get bored with spending many years learning and becoming advanced or an expert in a system paradigm (like different hosting systems), a programming language (i.e. Perl), or a framework (pick your JS framework), only to have it completely obsoleted a few years later? And then in a job interview, when you try to sell yourself on your wisdom as expert on thing X, new to Y, they dismiss you because the 25 year old has been using Y since its release three years ago?

And when you're in an existing company, stuck in thing X, knowing that it's obsolete, and the people doing the latest Y that's hot in the job market are in another department and jealously guard access to Y projects?

How about when you go to interview, and you not ONLY have to know Y, but the Leetcode from 15 years ago?

So maybe I've given you another alternative to 'it has to be power, there's no other rational reason to go into management'.

Here's a gentler one: if you want to build big things, involving many people, you need to be in management.

Do you enjoy brick laying and calculating angles around doorways? You're the engineer. Do you want to be the architect hiring engineers, working with project managers, and assessing the budget while worrying about approvals? They're different types of work, and it's not about 'power' like you are suggesting. Autonomy and decision-making power are more the 'power' engineers often don't get (unless they are lucky, very very smart or in a small startup-like environment).

In my opinion it is obvious and should be uncontroversial that some environmental regulations work and are great and should if anything be reinforced, while other environmental regulations do more harm than good and need to be reigned in or eliminated.

Turning "environmental regulation" into a unified bloc that must be either supported or opposed in totality is a manipulative political maneuver and it should be forcefully rejected.

Regulations are not people, and they don't have rights. It is fair and reasonable to demand that environmental regulation justify its existence with hard, scientifically verifiable data or else get chopped. Clearly, banning leaded gasoline has that kind of justification, and therefore I'm strongly in favor of maintaining that ban and extending it wherever it isn't in place yet. The same reasonable standard should be applied to other regulations across the board.

While is a cool idea on its own, I don't get why they try to reinvent it as a new system. We've got swagger, openapi, graphql and many other systems that already describe the APIs. They mostly include documentation too. Why not just expose those for the same effect? (If I was cynical, I'd guess Vercel wanting a proprietary thing of their own just for less portability)

This you? https://flow-control.dev/

Author here. I agree that the having the code editable in my repo is nice!

But the fact that it just wraps another dependency (Radix) kind of defeats the purpose for me.

100% agreed on CSS being the right approach here! I’ve been using CSS hacks to style radio buttons for ages before we had good CSS support and never even considered recreating it in JS

I think xpath is cool too!

If wxpath can help revive some of that excitement, then I consider my project a success.

As for your question, while wxpath does extend the xpath syntax, `/map` is not one of its additions, nor is it a html map element.

XPath 3.1 introduced first-class maps (and arrays) (https://www.w3.org/TR/xpath-31/#id-maps), and `/map` is the syntax to create said structure. It's an awesome feature that's especially useful for quickly delivering JSON-like objects.