darrinmn

Sure, companies are free to make their own choices based on their business incentives. But if you can create an account and be logged in without verifying an email address, then arguably the email address wasn't needed in the first place and you should just allow any type of username string. If the goal of your website is for email address to be the username, the you should confirm the user actually owns the email address they claim first - since anyone could lie and put a random email they don't own.

Yes but the exact quote is confusing as he specifically mentions email addresses (in bold text). I know the author mentions usernames elsewhere in the article and I agree with the author this isn't applicable to websites that allow username signup since anyone can pick any random string... But for email address signup, as the exact quote mentions, there is no additional context switching since you already need to confirm the email address regardless.

Are you saying your signup flow would automatically log the user in without confirming their email address (verify later)? I wouldn't suggest that for most websites as that would allow someone to signup with an email address they don't own.

For most websites transacting with potentially sensitive information, having an email sent to confirm you own the email address should already be part of the normal flow, so I'm not suggesting any extra step here. I was only suggesting an alternative email response in the situation you try to signup with an email that already exists. The normal happy path signup flow for a new account is not affected at all by my comment.

Not sure exactly what you mean? Are you referring to a purchase flow where you are buying something and also given the option to checkout as guest or signin/signup?

I am only speaking to the typical signup flow that anyone can access signed out without putting in any information besides email/pw. If you are in a purchase flow where valid credit card info is already entered and is going to result in actual purchase $$, you've already excluded bots/hackers who would be trying to brute force account enumeration. It would be totally fine to confirm the existence of an account in a web form in this situation as it is not a flow that can be easily brute forced for free with little effort or info needed (like a credit card).

What do you mean login? I'm talking about the signup flow. The signin flow would be consistent with what is discussed in the article "invalid username or pw".

> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address.

This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of that email address then receives an email - either 1) normal signup process, or 2) "did you just try to sign up? You already have a valid account for this email address."

This way you cannot tell via the signup web form alone whether an account exists or not. You need to have access to the email address.

It saddens me whenever a core web spec picks a sub-optimal solution purely because a 3rd party tool already picked the optimal one.

I find it ironic that the css "when/else" draft spec uses "if" for describing the conditional scenarios in plain english. As if the spec itself admits the syntax they are choosing is clearly sub-optimal.

The Vue community is not against JSX. I know many Vue devs that use it and it works great. Have you encountered any problems with vue+jsx/tsx?

The typescript support has immensely improved in vue3. The entire vue3 codebase is even written in typescript.

"our standups are growing and spend alot of time chatting / designing new features". So your standups are inefficient and your solution is to cancel them? Talk about a false equivalency. Fix your standups, dont cancel them.

Groups pick a team name for their projects, and they clearly picked ajacks as a play on "Ajax"... Possibly they also have 2 people named jack on the team.

Teams pick names for their group projects. There name is clearly ajacks, playing of of "Ajax"... And possibly they have 2 people on their team named jack.

yea, Vue had it in its core along time ago. Hence another downfall of react... you end up downloading tons of 3rd party packages that Vue gives you by default.

npm stats are slightly deceptive because Vue is huge in China. In China npm is very slow so most devs use mirrors to download their packages. so the * here is npm doesnt really include China, which is arguably Vue's biggest market.