61–70 of 71 posts
Earlier quoted context omitted.
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.
> 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…
> 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.
> 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…
> 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.
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.
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.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
> 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.
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.
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.
Earlier quoted context omitted.
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.
Sure, but the same caveats generally apply; cookies are limited to a single browser on a single device.
Earlier quoted context omitted.
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…
> 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.
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.
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.
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.