41–50 of 71 posts
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.
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.
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 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…
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.
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.
Perhaps localStorage could also be persisted/synced?
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.
Earlier quoted context omitted.
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 prett…
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.
> 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 localStorag…
> 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 localStorag…
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.
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 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.
Agreed. The alternative would have us creating accounts, server-side storage, and supporting all this. No way this could be free, without ads.
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.