What would you change specifically? Adding an API call backed by servers / lambdas? The creator mentioned it costs in the tens of dollars per month to run wordle for 10s of millions of daily players. Having to run servers would not only add a ton of cost, but now be vulnerable to latency spikes, ddos, downtime.
Wordle scaled to 10s of millions in a few months, without any latency or downtime. Pretty elegant in my book.
I understand that the costs might be an issue, but this doesn't make the solution "elegant". This is the kind of code I wrote as an 8-year old in BASIC, like I mentioned elsewhere, and even my young self understood back then it wasn't a satisfying solution, I just didn't know how to hide secret literals.
I mean, I enjoy Wordle as much as the next person, but let's not make it into some engineering achievement when it's clearly not one.
I'd argue that it's not. Puzzles in the newspapers also don't hide secrets, the answers are on the next page or upside down. And for wordle, the vast majority of players don't even know the solutions can be found in the source (because they don't know what that means), and most of the ones who do know that don't look anyway because otherwise what's the point of playing.
Having the solutions viewable client side may not be engineering elegance, but in this case I do think it is product elegance.
Adding the DB or servers you mentioned would mean costs continue to increase with # of users, which would then create pressure to figure out how to make money off of wordle. Then comes logins, ads, or at the very least donation requests
Oh, you got me there! Definitely wouldn't want that to happen.
You make good points. It's true the solution to newspaper crosswords is usually on the same page, upside down.
Imagine not implementing blocking walls in Counter Strike, "just don't walk through walls, it would make the game less fun and why would you ruin the experience for yourself like that?".
This is a case where not hiding the word list was done because it was easier to implement Wordle this way. Engineering-wise, it's not elegant, it's a cop-out.
Client side dictionary isn’t a cop out at all. It’s a terrific solution for a single player game that helps keep the code base elegant.
Well, cheating is less important than in Counter Strike, but not entirely unimportant either. Playing Wordle has a social component.
I think this solution is neither elegant nor terrific. It's simply completely ignoring the problem and claiming that it doesn't matter anyway. I obviously disagree.
PS: when I was a kid, I learned programming on my C64 with BASIC. Like many kids, the first programs I wrote were "guess the thing" kind of games. Usually "guess the number", but occasionally "guess the word". Even back then I understood that hardcoding the word in the program listing was less than ideal, but I just didn't know how to do better. Let's say that 8-year old me would not have been positively impressed if told that Wordle had the "elegant" solution of storing the list of words in its source code.
It's just the default of "I decided not to tackle this problem because it's hard and not a priority for my design". This was also what I defaulted to with my C64 BASIC games when I was a kid, "I don't know how to hide this, so I won't".
...and it's trust model extends there too. It copies your "Achievements" into your paste buffer and you paste them to share. One could easily edit their results, but they'd be cheating themselves too. There's not need for technical restrictions on a player ruining their own satisfaction.
My wordle doesn't get worse from you cheating, but my game of CS sure would.
"I don't need to implement wall blocking, the player should just refrain from walking through walls". It's not elegant, it's lazy.
Single player games included cheatcodes hard-coded in them since forever. Those that didn't had "trainers" which fiddled with game memory with the same effect. Howver, invincibility and infinite ammo tend to ruin the game for most people.