The justification for this approach is that this extends the capabilities of the browser in new and innovative ways. And, indeed, there is a grain of truth in that assertion, and the argument is not entirely without merit.
To regain the expected behavior, the user is required to cut-and-paste the URL from the new window back into their original browser window. This is a significant annoyance at best, and a drain on system resources and user patience otherwise.
This arrogant attitude is made even MORE obvious when the web-developer decides that certain features of the browser need to be disabled.
Why in the world do users put up with such a thing?
(And, indeed, they may not; I have not heard of anyone complaining of this in a long time, so perhaps it is becoming less of an issue these days.)
A developer may choose to push some of the computation from the server to the client. The computation is for the client's benefit, and the server is presumably busy, so reducing the load on the server and increasing the load on the client can make sense. Of course, since the computation is beind done with a scripting language, the actual amount of work increases, but that's a cost paid for by the client.
Given the habit of pushing computation to the client, it then becomes very easy to push verification and validation tasks to the client, using the same justification. And it's here that a developer's laziness transmutes into stupidity.
The very justification for pushing this logic to the client side means that there's pressure to remove it from the server side. If performance is a little slow, that's an easy thing to remove to lighten the load. If not by the original developer, then by a junior programmer who's been tasked with speeding up the production server.
Additionally, the check will be done in two places, which might well lead to the checks getting out of sync. (I've seen this happen, with overlapping ranges. The test cases passed, but some input fields were limited to exactly one value.)
Once client-side verification and validation have become established procedures, it's then only a small step to client-side authentication. If the security folks go nuts at the idea of client-side validation, they just give up at this stage, and stand back and laugh.
"That would never happen," you say, "even an idiot who doesn't understand why client-side validation is bad would recogonize that client-side authentication is stupid."
You'd be wrong.
So what's the real problem?
How to get where we should be from where we are pretty much falls out of the problem list. Solve the problems in an intelligent way, and we're golden, right?
The original version of the essay was much shorter and more a result of frustration. As you can see, I've moderated my position somewhat over time, mostly from discussion in the #kernel-panic IRC channel on freenode.
Find me there to help me refine my position, add examples, or otherwise improve this essay.