Hacker News new | past | comments | ask | show | jobs | submit login
Don't rely on LocalStorage (jacobweisz.com)
28 points by ocdtrekkie 4 months ago | hide | past | favorite | 68 comments



> LocalStorage is popular for web apps because it is lazy

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


> 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.


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.


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.


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


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.


Well said - much more succinctly put than my own response.

> 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.


Agreed. The alternative would have us creating accounts, server-side storage, and supporting all this. No way this could be free, without ads.


Yes, exactly. Having to have the backend infrastructure adds a lot of costs. For some of my apps that I've been building with local storage, I've considered adding a paid sync feature in the future if I ever launch anything that gets a lot of usage and there is the demand for it.

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.


> Having to have the backend infrastructure adds a lot of costs.

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.


But you also need: * Account creation * Password recovery * Backups * Privacy policy

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.


Well, I was specifically replying to infrastructure costs. But I can address non-infrastructure costs too.

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.


I kinda got the feeling that this article was mainly written to take advantage of the Wordle hype. Overall I didn't get much of substance and I felt that the main takeaway was disingenuous to what the goals of the developer were. As if it's always wrong to use local storage. I'm sure the developer knew the limitations of using local storage. And it definitely rubbed me the wrong way when the author called it "lazy" to use local storage. Probably because I've recently gotten really into building apps that put data back in users' control and also trying to reduce the environmental impact of my apps. Local storage is really great for this, and often the apps I'm building it's totally acceptable to not have your data follow you everywhere. At the very least, that is often what I'm doing intentionally. Does that make me lazy? I don't think so. In fact, I find it challenging to architect apps this way because I"m used to the traditional client/server model, which there are way more examples of and feels like the default.

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


The author does not have their own game and isn't promoting anything. Except that LocalStorage makes the author very sad.


Oh, you're totally right. I don't know how I misunderstood that sandstorm platform as being their game. Thanks for the correction!


The author makes some decent points about localStorage generally, but I think really misses the point on what makes Wordle so successful and endearing. It was built as a side project for a very small audience and just happened to have massive, organic growth. If Josh Wardle had thought about all of these described use cases in advance, there's a much higher chance that it never would have gotten off the ground as a side project. Additionally, the massive growth would have presented much harder (or at least much more expensive) scaling challenges, whereas with it being entirely client-side it is much easier and cheaper to scale to millions of users.


I admit focusing on Wordle here may be a popularity hack for this article[1] (though it is also what brought writing it to mind), as obviously Josh Wardle wasn't expecting the results he got. Though I do really hope the New York Times integrates cross-device play at some point... they already have an account system, after all.

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.


So that's where the name came from. Makes you wonder how much such a simple thing as a last name impacted their life.


Regarding Wordle specifically, this allowed Josh Wardle to make the app a simple webpage with no backend necessary beyond serving the page itself. Is there something that allows someone like him to do that aside from LocalStorage?


I believe he could have used Cookies instead of LocalStorage. The data he's keeping seems simple enough. It has the same issues the author is talking about, but it should work.


Can client-side code set the cookies themselves? I was under the impression cookies were a HTTP-level thing.


Yes. `document.cookie`


Sure, but the same caveats generally apply; cookies are limited to a single browser on a single device.


Fair enough. I was more interested in identifying other ways of technically achieving the goal of local storage than solving the authors complaint.


Yes, IndexedDB.


Seems like this article misses one critical point. Part of the wordle attraction was the friction free ability to play. Click on a link, type in a 5 letter word and you are playing. I suspect it would not have gained popularity anywhere near as quickly if step #1 was create an account.


I see it as one should not use local storage because some future owner (which might never happen) could have issues with your solution.

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.


So much this!

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.


This article is a brilliant example of one of my favorite phrases: "Perfect is the enemy of good."

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.


Sure you won't be able to see all of your friend's stats in one nice looking UI, but I doubt that has bothered anyone tremendously. If anything, what you perceive to be crutch actually encourages people to share their result 1-1 with their friends in whatever chat apps they please. That to me, is a feature, not a bug.


Yeah, keeping stat sharing outside of the app serves as user-generated marketing. I think that counts more as a feature for the dev than the user, though.


I can see this being a win-win. I actually started chatting more frequently with people I hadn't chatted more often with because of Wordle. We're basically bonding over Wordle.


I'm aware of the drawbacks of localStorage. I accept them every time I use them. But it has advantages too. I'm not going to stop relying on it because sometimes, it is the right answer.


How can they migrate it to server without requiring login? The best part is that you don't need to create any user for playing. Accessing data between devices requires some form of auth.


I would assume almost all daily users of Wordle would consider having to have an account in exchange for persistent, cross-device statistics a worthy trade-off. And presumably a well-designed app could even abuse LocalStorage for anonymous play, and include a mechanism to hand off and save your data, should you wish to, via a login.

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.


Are those statistics actually interesting to many users? I barely noticed the move to NYTimes because I'm mostly just interested in playing the game once a day, sometimes sharing the result.


This might be one of those weird gamification things... but I don't think I'd care about my stats if they weren't there. But since they are, I don't want to mess them up by playing on multiple devices?


You can take my 100% win-loss ratio from my cold dead hands, I cherish my stats.


Didn't even know it's there...


> I would assume almost all daily users of Wordle would consider having to have an account in exchange for persistent, cross-device statistics a worthy trade-off

Not for me, absolute deal-breaker. My fingers would find ctrl-w before the "Log in with Facebook!" modal finishes rendering.


To be fair, I think you're probably right. But, that doesn't make the article any more right to me. The argument wasn't that local storage is no longer a good choice, but that it's always a bad choice. Or at least that's how it comes across to me.


Many auth providers allow anonymous auth, which creates a UID that can be used to store and secure data. Only later the customer can link that account with another identity provider (e.g. socail, email/password). This gives the low-friction benefits of local storage and the flexibility of cloud storage.


I have found firebase to be a pretty good provider if you want something to get going quickly with. There are lots of others too, but it's probably got one of the more generous free tiers. But something to beware of is potential lock-in and loss of user privacy. Also, some of the free tiers are pretty generous, but then they hit a cliff and it can be expensive quickly. That could be a bad thing if you want to build a free app that goes viral. Also, not all of the providers also provide the cloud storage, so you might have to build/pay for that. Lots of drawbacks to this design choice that would not be suitable for a high user, free app run by an indie developer.


> You see, the first time I tried Wordle was on my tablet. But suddenly, I wanted to give Wordle a shot on my phone... and I realized those treasured statistics wouldn't be there.

I want to take it seriously but it's hard.


> Ultimately, people should have control of their data, and they should have access to their data from all of their devices. Whether that is running their own or renting someone else's, that ultimately means the correct place to store web app data is on a server.

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.


I specifically refer to self-hosting here, which does satisfy both of those conditions. (There is arguably still a lot of stress to making self-hosting a better experience for non-technical users, and unfortunately large tech companies are very motivated to maintain a paradigm opposed to self-hosting.)

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.


> 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.


I bet even now, long after the NYT’s check has cleared, Josh is filled with a deep sense of regret over his decision to use LocalStorage. It keeps him up, long into the night. What could have been…


He knows, deep down, that he is a fraud. He used a mechanism built into the browser instead of building some big-brain distributed system with Kubernetes and stuff. Just like a fraud would do.


“LocalStorage is lazy” and “server storage is more fun” are not good reasons to avoid localStorage.

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 think there's some opportunity, if this doesn't already exist, to make some decentralized (WebRTC, with centralized fallback) way of synchronizing localStorage across multiple devices with a pre-shared key. A drop-in script would add functionality to show and scan a QR code or enter a 12 word phrase. It could even be a userscript running without the web app developer's involvement at all. A lot of hoopla for a word game, but could be quite handy in more scenarios.


I've been thinking about this for a localstorage based app that I'm tinkering around with. You can do webrtc without a STUN server, but it requires exchanging a chunk of ugly metadata with another person.

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.


Counterpoint: if you shouldn't write a 'for fun' game without architecting it to withstand super-viral success, a lot of people won't write them at all.


Use of localStorage and no back end was arguably what enabled Wordle to withstand super-viral success despite it being merely a side project.


This just sounds like a Sandstorm issue/side-effect. Of course randomizing hostnames is going to break things that rely on the underpinnings of the web. I don't think a third-party tool failing to provide additional functionality beyond what the developer intended is reason to entirely dismiss core web functionality like LocalStorage.


I imagine Khaby Lame sitting at a desk, a laptop, a tablet, a printed out sandstorm logo and a phone next to him. He puts the laptop, logo and tablet away, grabs the phone and points at it several times, his facial expression saying:

"If you want your stats proper and orderly, play the game only from your phone, buddy."


There's definitely a real problem to be solved here. Offline persistence is by far one of the weakest parts of the web platform. It's definitely tricky to make secure, but I'd love to see more innovation in this area.


Browsers already persist and sync saved passwords and browser history to back-end accounts.

Perhaps localStorage could also be persisted/synced?


This is one of the big missing pieces of the web development puzzle. It would be quite nice if the browsers handled sync & backup of local data. Would be even better if came with SQL access.


I should write a story about how I avoided using local storage for a few years assuming all sorts of things and wished I hadn’t…


Imho Wordle is better suited for the pick-up-and-go approach vs needing to login.


Meh




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: