I can't agree with this take. It's not lazy, it's a set of tradeoffs that didn't land the way OP would prefer, but that doesn't make it universally wrong.
> it's a set of tradeoffs that didn't land the way OP would prefer, but that doesn't make it universally wrong.
That's really the heart of the issue for me. There are users who are more concerned about privacy and owning their data who would prefer this trade-off. Also, indie developers who are working with constrained budgets may choose to architect with this limitation. I'm a big fan of looking at how we can design apps that put data back in the user's control. I think local storage is a really great technology to decentralise apps.
I really want to build apps that don't trap users. I'd like to have users stick with me because I provide value, not because I "own" their data. I also want to build free apps. And finally, I want to decrease the environmental footprint of my apps. Local storage is perfect for these goals, at least for some apps that don't absolutely need centralised storage.
I don't know how much I believe "a lot" for something at this complexity level. Wordle would need a server that stores 60 bytes of data for each user that has enabled sync, and would need to send and receive that data about 10 times a day.
This creates more friction, both to end users and for the dev. I likely would have never tried Wordle if I had to create an account first.
Most important is that there is no need at all to make an account first. You can stick a "make account" link under settings for the people that want it.
It definitely is some amount of dev work, but it's the kind of thing where you could make an acceptable version in a day or two. Especially if it just spits a secret code at you and you input that code into a different device. Password recovery isn't necessary. Privacy policy can be two sentences. Backups can be a daily rsync.