Don't rely on LocalStorage
blog.jacobweisz.com
blog.jacobweisz.com
No... localStorage is popular because it allows you to persist state without requiring a server, opening up a whole lot of use cases that would normally require a login. With the tradeoff that you can't easily sync between machines and it can be cleared readily.
Calling it "lazy" seems bit unnecessarily confrontational. Of all the times I have used localStorage on my apps I can't say the reason was even once "laziness."
With that said, it would be nice to keep stats across instances on multiple devices. It adds either a lot of complicated edge cases or a lot of server calls (or both), though and it would need login or some other way to tell the server that Device A and Device B are the same person.
You also lose offline play.
A Progressive Web App would be nice. The best of both worlds. But guess what PWAs often use... localStorage, which I guess is lazy ;)
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.
Edit: fixed typo
Browsers already have both user identity across multiple devices and ability to sync data. It just needs to be extended to cookies and localstorage.
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.
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.
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.
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.
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.
> 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 have a hard time not seeing this as clickbait.
edit: correction thanks to a reply that corrected me about the author not having a game
I think small audiences also benefit from a server-side component, although ideally one that is also relatively small: With the example of high scores or seeing friends' progress, I wouldn't want to see the entire world's, but maybe share amongst a small group of friends or family. (This is what sharing to Twitter or Facebook largely emulates, in a very indirect way.)
[1] Aside: I briefly wondered if I should figure a way to shoehorn "Wordle" into the title if I was actually hoping to get some traction with this article, but I really think it would've moved away from the point then.
That is like insane argument.
Future owner should do due diligence and factor any issues in, NYT has a quick fix that will be there probably forever, but hey life goes on.
The use of localstorage here was absolutely fine - it puts the gameplay at the front and center.
This article is like an advertisement for useless cruft designed around monetizing a product, filled with things users fucking HATE, like forced signups and email spam.
I would have literally NEVER played it if it had required a signup, and it would had the dev taken the advice in this article.
My take away: This author is concerned primarily with his problems as a developer, and has not in any real way considered what users want, and why this product was successful. Further - he's using wordle as SEO to drive attention to his own pages. I find it off-putting at best, intentionally manipulative and insulting at worst.
No doubt localStorage has a few issues and drawbacks, but none of them really matter to the majority of users. No one expects persisted statistics across devices without logging in. No users care about the technical issues moving to a new domain. Using it for Wordle got the job done well and sold for a million bucks. Obviously localStorage was good enough for that, and probably for most other cases people use it for.
Social OAuth and passwordless email login (essentially one-time codes) are both pretty low-effort ways of managing auth without storing a lot of sensitive data or having to manage passwords.
Not for me, absolute deal-breaker. My fingers would find ctrl-w before the "Log in with Facebook!" modal finishes rendering.
I want to take it seriously but it's hard.
Hrm. But I don't have control of my data on a server. The person running the server does. There is currently no good way to satisfy both of these conditions on the web: control of my data, and access from all my devices.
But I also do not feel LocalStorage is really a good way to ensure you have control of your data: It's very unlikely you (or most anyone else) are auditing the code of a site to ensure it maintains your data locally, much less ensure that doesn't change over time.
There's nothing in this critique that doesn't also apply to hosted (server-based) storage.
If anything, it's harder to do those things with servers, because (a) if you the user are truly paranoid, it's trivial to throw a switch and make sure that no data is getting out—by shutting off your network connection entirely, whereas with server-based storage for user data the user has to do some form of whitelisting or blacklisting, and (b) it's pretty straightforward to get all your data at any given time, esp. since the localStorage API is well-defined, whereas if the application author had started with a server-based approach, it probably would have been a server under their control and not yours, which means your best shot involves either intercepting all communications from the beginning (instead of after the fact, once you realize you're interested in it) or doing the legwork to figure out the protocol and issue the appropriate request(s) to get all of it (rather than just a view), if that's even possible.
Overall, I don't think this post makes a very forceful argument that localStorage is bad, only that there might be a better experience for users if all the following conditions hold true:
1. they're playing across multiple devices
2. they're willing to take the time to connect to remote storage
3. the developer behind the app is sympathetic to the cause of data portability and/or user-controlled data, and is therefore willing to implement the necessary integration to enable #2
Failing that, a world where developers are defaulting to localStorage is still a much better state of affairs than what's typical of application authors today.
Durability and reliability are reasons enough!
- LocalStorage will silently drop concurrent writes sometimes. One of my first major projects at Notion was moving our client-side change queue from LocalStorage to IndexedDB because we found that localStorage would just… lose data. One of our engineers wrote a simple HTML page that wrote sequential data in a loop, and another thread read the data to verify it. We saw loss of 5% or more in some conditions.
- LocalStorage is treated as almost-ephemeral by the browser/OS. We found that under disk pressure, many engines will happily clear some or all of your LocalStorage keys. Browsers seem more reluctant to drop IndexedDB data.
- If you want any kind of “scan” over a bunch of data, or if you want to store larger/binary data, IndexedDB can get you better performance.
- Third party scripts like analytics, customer support chat, etc happily spray data into LocalStorage, and you end up competing with them for scarce quota. IndexedDB has better namespacing and budgeting - plus, if you use entirely IndexedDB, you can nuke LocalStorage to reclaim quota from those third parties.
I've been wondering whether IPFS might be a good answer to that - there is this, which supposedly works in the browser. https://github.com/ipfs/js-ipfs
Dump webrtc metadata onto ipfs, give the user the hash back as a "document key" (and maybe a password that was used to encrypt the webrtc metadata) to share with other people; they paste in the key, enter password, and tada, you have a multi user application backed by localstorage.
Of course this wouldn't survive a user changing IP (and perhaps other network attributes) but that might be an OK feature.
"If you want your stats proper and orderly, play the game only from your phone, buddy."
Perhaps localStorage could also be persisted/synced?