The smooth animations in Gabriele Cirulli's version are due to this API: https://developer.mozilla.org/en/docs/Web/API/window.request...
They consist of a few lines of code.
Further, the animation code is only a miniscule fraction of that code base.
Further, the animation code is only a miniscule fraction of that code base.
I'll have to dig through the code again. The polish that the end product of the first version exhibited is well beyond that of any of the rewrites I've seen. To the point that it is, in fact, jarring. And makes it frustrating to read how much nicer the code looks in some of them.
Really brings home the point that intrinsic quality is nice, but pails in comparison to the final quality of the overall product. It isn't that I am convinced the sausage making process is always gross. Just that I have not seen that many examples where the clean versions are anything more than just sterilizations that have killed a lot of the original.
Regarding the point you brought up: you are conflating two issues. One is whether the UI is appealing, and the other whether the underlying code is of a high quality. The point of my article was merely to show how nicely the game logic can be expressed in Haskell, compared to many other languages.
Because, just using the app, I'd say the original app is much higher quality than this derivative. One I would consider playing for a bit, the other is just kind of neat.
If we are just going off how nicely the logic can be expressed, with no regard to the dirtiness of implementation, free text wins. A simple paragraph describing the game is much more understandable than even the haskel. Especially if you allow examples.
Edit: Also, I'm curious if you could reproduce the UI of the original with just a library in Haskel. That is, sure, most of the code is done though a library. Does that really change much? If so, you should be able to achieve the same fluid and pleasant UI with "just a library" in Haskel, right? (Genuine question.)
Feel free to use the UI as the sole measure of quality, but if that is your stance, you should probably seek a different audience.
But I'm not necessarily trying to make a claim that it can't be done in Haskel. More that I have not seen it done. You can claim that the final polish of the original is irrelevant, but I find that claim hard to believe. Especially since I have yet to see an example that has said polish.
Sadly, I don't know how you would really go about proving that one way or the other.
I'll hopefully have more to add to the conversation after I try this game in a language. At face value, I am not at all clear on how this will take 90 lines of javascript. That just seems extreme.
I'm not going to claim that the code alone is as "pretty" as the Haskel version, but I see no reason it should have exploded to be much larger. I may have to take a look at how other folks are doing this.
(Code is currently at https://github.com/taeric/2048-Explorations. Will try to prettify and publish the org file that accompanies it.)