Ask HN: Why do most sites still not track state well?
2 comments
I built a user management system circa 2001 that kept state across login and other events using the method you suggest. It even could save POST contents around a login.
I used it for a few web sites that cumulatively had 500,000+ members, open sourced it, didn't get any interest from anyone else. My system was mostly written in PHP, but the actual cookie handling module could be coded up in about 50 lines of code and I ported it to Perl, Java, Cold Fusion and a few other languages.
My viewpoint at the time was that user management was the central service behind a "portal" web site, that is, you would log into Yahoo once and what bound it all together was they you had one login. In contrast to "PHPNuke" which was one huge application that had half-baked implementations of different services, you could pick best of breed applications and tie them into the auth system.
At the time there was a lot of code reuse in terms of applications (WordPress) and there were a few proto-frameworks like Struts, but Ruby-on-Rails was the first web framework that was transformational.
User management libraries didn't catch on until federated login came along.
I think today people are often ignorant and wouldn't care a bit about user experience if somebody wasn't threatening that something awful was going to happen if their site wasn't accessible. Half of the job of the W3C is normalizing deviance by not standing up against the pop-in windows that harass you everywhere on the web the same way those shoes you saw on Zappos five years ago are still following you around.
On the other hand, my priorities have always been different from other people. I've never bolted pagination onto a user interface after the fact. I have tried to parallelize something without chunking the work (to reduce overhead so it actually speeds up) but that was a n00b mistake 20 years ago -- people write these blog posts where they make it sound like Actors or some other shiny new thing is the key thing and no, you'll have to chunk no matter how you do it. (e.g. is more fundamental!)
I used it for a few web sites that cumulatively had 500,000+ members, open sourced it, didn't get any interest from anyone else. My system was mostly written in PHP, but the actual cookie handling module could be coded up in about 50 lines of code and I ported it to Perl, Java, Cold Fusion and a few other languages.
My viewpoint at the time was that user management was the central service behind a "portal" web site, that is, you would log into Yahoo once and what bound it all together was they you had one login. In contrast to "PHPNuke" which was one huge application that had half-baked implementations of different services, you could pick best of breed applications and tie them into the auth system.
At the time there was a lot of code reuse in terms of applications (WordPress) and there were a few proto-frameworks like Struts, but Ruby-on-Rails was the first web framework that was transformational.
User management libraries didn't catch on until federated login came along.
I think today people are often ignorant and wouldn't care a bit about user experience if somebody wasn't threatening that something awful was going to happen if their site wasn't accessible. Half of the job of the W3C is normalizing deviance by not standing up against the pop-in windows that harass you everywhere on the web the same way those shoes you saw on Zappos five years ago are still following you around.
On the other hand, my priorities have always been different from other people. I've never bolted pagination onto a user interface after the fact. I have tried to parallelize something without chunking the work (to reduce overhead so it actually speeds up) but that was a n00b mistake 20 years ago -- people write these blog posts where they make it sound like Actors or some other shiny new thing is the key thing and no, you'll have to chunk no matter how you do it. (e.g. is more fundamental!)
Thanks for the great response. If I understand you, the problem is that this sort of state handling works at a low(ish?) level, and the frameworks that most people use nowadays didn’t prioritize it, so in order to do it properly you’d have to write custom code at a lower level of abstraction than most devs are comfortable with? Basically, it was handled poorly in libraries that are now universally used? Please correct me if I’m wrong.
Can't the page/endpoint that I left in order to reset my password be encoded into the password-reset URL, so that after my password has been reset I'm brought back to where I was?
Password resets aren't the only manifestation of this, but they're the most obvious.