←back to thread

Windows NT on 600MHz machine opens apps instantly. What happened?

(twitter.com)
752 points dceddia | 1 comments | 23 Jun 23 14:02 UTC | HN request time: 0.212s | source
Show context
verall ◴[23 Jun 23 14:36 UTC] No.36447353[source]▶
A lot of people are bringing up Wirth's law or other things, but I want to get more specific.

Has anyone else noticed how bad sign-on redirect flows have gotten in the past ~5 years?

It used to be you clicked sign in, and then you were redirected to a login page. Now I typically see my browser go through 4+ redirects, stuck at a white screen for 10-60 seconds.

I'm a systems C++ developer and I know nothing about webdev. Can someone _please_ fill me in on what's going on here and how every single website has this new slowness?

replies(16): >>36447462 #>>36447463 #>>36447473 #>>36447749 #>>36447944 #>>36448057 #>>36448342 #>>36448778 #>>36448926 #>>36448930 #>>36449089 #>>36449478 #>>36450517 #>>36450908 #>>36453785 #>>36460900 #
billyjobob ◴[23 Jun 23 15:00 UTC] No.36447749[source]▶
A lot of sites now don't even a "sign in" now. You only have a large "sign up" button, which you have to click, and then in very small text at the bottom of the sign up screen find the link for "already have an account?"
replies(6): >>36447938 #>>36447967 #>>36448629 #>>36448826 #>>36449810 #>>36453286 #
cpeterso ◴[23 Jun 23 16:08 UTC] No.36448826[source]▶
Web UX designers need to find some alternative button label that users understand means both “Sign up” and “Sign in”. The site will know if your email address has an account and should then be asked does a password. Though users will still complain that the login process requires two steps: entering a username and then the backend determining whether to next serve a password or registration form.
replies(2): >>36450944 #>>36478151 #
guntars ◴[23 Jun 23 19:06 UTC] No.36450944[source]▶
Needing a bunch of JavaScript to make it work, which will get bungled by the devs and break it for people using password managers, making the thing even worse. Login is such a common pattern that it should be just handled by the browser.
replies(1): >>36452406 #
cpeterso ◴[23 Jun 23 21:30 UTC] No.36452406[source]▶
Good point. It's unfortunate that HTTP Auth never become popular. I don't know if that was because the browser support or UX was bad or if web developers wanted more control over their sites' login flow or user information required.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica...

replies(1): >>36461961 #
1. efreak ◴[24 Jun 23 19:34 UTC] No.36461961[source]▶
The problem is that you have a few options:

1. send in plain text with http basic auth. Over https this isn't a problem, but https was expensive). This is sent on every request. 2. Use digest. This is also sent on every request, and also requires actual processing, at which point you might as well go for 4 so it looks nice. 3. Use certificates. Nobody does this on the pubic web. The only website I've ever used certificates was whatever certificate site predated let's encrypt, can't remember the name at the moment, and as someone who doesn't use client certificates it was a huge pain (blame that on the browsers though) 4. Use a form on the website with a session token, and you get control over the UI including error messages and styling. Much more user-friendly. You can trivially prevent the user from (easily) sending requests with pain text passwords by only showing sensitive pages like login over https. The user can't bookmark or share a URL with a password embedded in it. You can request more information than just username and password (Bank: do you want to see your checking account or savings account? Forum: go back to previous page or to homepage? SSO-ish (DayForce): what's the name of the org you're signing into?)