
Ask HN: Why do most sites still not track state well? - DATACOMMANDER
I have a bit of frontend experience and a general understanding of how backends work, but I guess the &quot;glue&quot; layer between them must be more difficult than I think. Why is it that when I need to reset a password, or log in or out, the site that I&#x27;m interacting with is unable to handle even basic state? I&#x27;m not blocking cookies, so it can&#x27;t be that.<p>Can&#x27;t the page&#x2F;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&#x27;m brought back to where I was?<p>Password resets aren&#x27;t the only manifestation of this, but they&#x27;re the most obvious.
======
PaulHoule
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!)

~~~
DATACOMMANDER
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.

