That's so ugly it hurts to look at.

Why is there so much empty space? The visual design is attrocious, the columns are just randomly placed without any thought, margins or symmetry.

It looks like it's incomplete? There are now visual guidelines to separate elements, it's hard to read and it looks like it's missing something.

My work has us call a helpdesk which verifies our ID (based off the number we're calling from and other info) then gives us a one-time password to reset all our login info

Solutions that work for a corporate application where all the staff know each other are unlikely to be feasible for a publicly available application with thousands of users all over the world

This is something of a hybrid. There will be both general public users as well as staff. So for staff, we could just call them or walk down the hall and verify them but the public accounts are what I'm trying to cover (and, ideally, the staff would just use the same method as the public).

Figure if an attacker attempts the 'forgot password' method, it's assumed they have access to the users email.

Yep, that's part of the current posture. If MFA is enabled on the account, then a valid TOTP code is required to complete the password reset after they use the one-time email token. The only threat vector there is if the attacker has full access to the user's phone (and thus their email and auth app) but I'm not sure if there's a sane way to account for that. It may also be overkill to try to account for that scenario in this project. So we're assuming the user's device is properly secured (PIN, biometrics, password, etc).

If you are offering TOTP only,

Presently, yes, but we're looking to eventually support WebAuthn

or otherwise an OTP sent via SMS with a short expiration time

We're trying to avoid 3rd party services, so something like Twilio isn't really an option (nor Duo, etc). We're also trying to store the minimum amount of personal info, and currently there is no reason for us to require the user's phone number (though staff can add it if they want it to show up as a method of contact). OTP via SMS is also considered insecure, so that's another reason I'm looking at other methods.

"backup codes" of valid OTPs that the user needs to keep safe and is obtained when first enrolling in MFA

I did consider adding that to the onboarding but I have my doubts if people will actually keep them safe or even keep them at all. It's definitely an option, though I'd prefer to not rely on it.

So for technical, human, and logistical reasons, I'm down to the following options to reset the MFA:

1. User must contact a staff member during business hours to verify themselves. Most secure, least convenient.
2. Setup security questions/answers and require those after the user receives an email token (separate from the password reset token). Moderately secure, less convenient, and requires us to store more personal information than I'd prefer.
3. Similar to #2 except provide their current password and a short-term temporary token that was emailed to them when they click "Lost my MFA Device". Most convenient, doesn't require unnecessary personal info, possibly least secure of the 3. Note that password resets require both email token and valid TOTP token, so passwords cannot be reset without MFA.

I'm leaning toward #3 unless there's a compelling reason not to.

There's a really nice high level overview of TOP/MFA by OWASP

They say:

There is no definitive "best way" to do this, and what is appropriate will vary hugely based on the security of the application, and also the level of control over the users. Solutions that work for a corporate application where all the staff know each other are unlikely to be feasible for a publicly available application with thousands of users all over the world. Every recovery method has its own advantages and disadvantages, and these need to be evaluated in the context of the application.

Some suggestions of possible methods include:

• Providing the user with a number of single-use recovery codes when they first setup MFA.
• Requiring the user to setup multiple types of MFA (such as a digital certificate, OTP core and phone number for SMS), so that they are unlikely to lose access to all of them at once.
• Mailing a one-use recovery code (or new hardware token) to the user's registered address.
• Requiring the user contact the support team and having a rigorous process in place to verify their identity.
• Requiring another trusted user to vouch for them.

The most important thing I think is, the MFA reset should have a different method and flow than the password reset option. Figure if an attacker attempts the 'forgot password' method, it's assumed they have access to the users email. Therefore, you don't want to send a 'reset MFA' in the same manner. The password recovery flow should be separate to the MFA recovery flow by using some form of out-of-band verification such as sending a password reset link within a "forgotten password email" containing a randomly generated and unique token that allows the user to reset the password only. The MFA recovery flow should work in a different manner. If you are offering TOTP only, I suggest offering a fallback method in place such as a list of "backup codes" of valid OTPs that the user needs to keep safe, and is obtained when first enrolling in MFA, or otherwise an OTP sent via SMS with a short expiration time. Ask for the TOTP while entering a new password. The reset link would be useless for the attacker.

I thought about generating a list of backup codes during the onboarding process but ruled it out because I know for a fact that people will not hold on to them.

That's why I'm leaning more toward, and soliciting feedback for, some method of automated recovery (email token + TOTP for password resets, email token + password for MFA resets, etc). I'm trying to also avoid using security questions but haven't closed that door entirely.

Have you thought about TOPT recovery codes?

When a user activates totp you show a list of 6-8 codes they can use to access the account. Just make sure the recovery code only works one time.

Came here to say the same thing but for SVG

This is my favorite web dev blog, his grid and flex tutorials are amazing with all those interactive examples.

No I don't accept the counter argument as an argument. People who care shouldn't jump through hoops to get what they deserve.

And the visual clutter is way too little to care.

Go for the fun, but your issue is a non issue. I use Zola (built with Rust) and it is very very fast. A full build of ~200 pages takes ~2s and in dev mode, changes are reflected almost instantly.

Targeting sub 1s build times seems like the wrong optimisation. If you write your content in markdown you can just preview it in a browser with ~1ms latency, because you don't need no fancy build system to do that. When you've written your post, put it in the site data structure, hit build, and go make a coffee.

If your objective is to put content on the internet, this will be more than enough. If it is instead to create The Most Perfectest Website Framework Ever, then unfortunately Spring Boot already exists 😏

The article obviously picks vector loaders as better, except in certain specific cases (or for very small loaders). I usually stick with SVG > PNG > JPG when dealing with graphics for the web.

I always do it. Getting thrown into another website forces you to switch context entirely, and also is a privacy and security right of the user to know they are going to be moved somewhere else.

Was a bit embarrassed when showing a prototype using Temporal last month and the provided computer's Chrome turned out not recent enough to support it, so for this one API I'll wait for one more year before considering it ready.

Check against Can I Use, all of the APIs, except for the following are supported by major browsers:

• Synchronous Clipboard API only Safari has full support, the rest have partial
• Temporal only currently supported in Chrome and Firefox

Are those APIs supported by all major browsers or is it Chrome(-ium) only? Even if those are supported, it will mean the users may need to update their browser to use the site (but maybe the support is implemented long ago and that's not much of an issue)

I see you answer that question for most of proposed APIs, but for some of them support is fragmented and/or present since 2025 and even 2026 for one. But at least it's not a single browser vendor lock

I do like it when they’re styled differently. Not on all sites, but on an article based site, yeah.

I mean both. But while I understand that there is for now not a lot of alternatives for web scripting, there is a lot of backend languages which makes backend javascript even worse.

The fact that people even bring javascript as the backend is a bit crazy to me.

To clarify do you mean replacing JavaScript just on the backend? This article is about using JavaScript on the front end.

Anything else, basically. There's not a lot of languages that are currently used and much worse.

My preference would lean towards something like Nim, probably, but I'm definitely not the best one to answer that. But javascript and its whole ecosystem is rotten (I mean, that's sort of the reason the article exists here) and it is just not fit to make anything. The fact that people even bring javascript as the backend is a bit crazy to me.

I'm intrigued, what would you replace it with?

I mean, it's good, but what needs to be replaced is javascript.

There was a time where you really needed Javascript and the Javascript you needed did not exist yet so you actually needed Flash.

If all your site did was display static content or maybe POST to a php back-end, sure, JS was optional. But if you wanted a website to do anything, or look like more than a jumped-up Word document, then JS was your only sane option until maybe 2011. And even then the Javascript you needed was actually jQuery.

(psssttt... If you are scrolling billions of rows you've done UX wrong, regardless of performance)