Hacker News Reader

> But I for one think an app that doesn't constantly send my every move to the server is actually a breath of fresh air.

I strongly agree. For me as a user, use of localStorage (and its ability to run 100% offline and even be loaded from a local path) makes Wordle particularly charming and usable.

It's also the ultimate in zero-trust architecture because there is no back end.

How often do you audit that the app hasn't changed to collect data? The idea LocalStorage-based apps are safe is silly if you're always loading them from a remote server.

> The idea LocalStorage-based apps are safe is silly if you're always loading them from a remote server.

This is true for any web page you load from a server in a browser.

My point is that Wordle's developer had to do almost no work to achieve a very high level of security. Literally the only things required are to (a) set up TLS correctly and (b) protect the app's static resources (and the server that's hosting them) from being compromised.

Depending on his choice of hosting provider, code repository, and build/deploy, those tasks may have been taken care of automatically.

I am pretty convinced that if Wordle added features that required talking to a server, it would make the overall experience worse, not better. It's easy to take for granted that you never see a loading spinner when playing the game, and that's largely because everything happens client-side.

To me, the real takeaway from the success of Wordle is that a lot of features that one might think are important, actually aren't in practice.

Wordle's stats would be easy enough to encode into a Base64 string that you could then copy and paste into a new one, or save in a text file as a backup... so if you're going to write something along those lines, consider doing that.

That could work though it's only a one time transfer (you can't continue playing on both devices unless you keep copying the encoded data).

One neat idea I like is using a GUID and having that act as a server key (vs an account) they you can copy the GUID, put it in a URL, have it transferred via QR code, etc. Of course that method then requires server storage.

LocalStorage serves important use-cases - you mentioned a few - but I‘be seen it used a bunch in web apps, where the user is already logged in, to persist setting. It was easier than adding an API to store a user‘s UI settings/state.

True. Not only easier but often times that user wants different settings on different machines (or even different browser profiles). What I want in my settings on my mobile device is not always the same as desktop especially when it comes to visual settings.

> some other way to tell the server that Device A and Device B are the same person

Browsers already have both user identity across multiple devices and ability to sync data. It just needs to be extended to cookies and localstorage.

The excellent cross-browser support of localStorage and the simplicity of the API should also be appreciated