85
edits
Building with Parenscript and Preact: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 66: | Line 66: | ||
Once the game was working properly, I wanted to include a win screen kind of like the original Solitaire which had the bouncing trailing cards. Since I had GSAP at my disposal to do all sorts of transforms, I made it so the cards get into big sine waves on the top and bottom of the page, and a "You win!" pops up in the middle. I think it looks pretty cool, and only took a few lines of code. | Once the game was working properly, I wanted to include a win screen kind of like the original Solitaire which had the bouncing trailing cards. Since I had GSAP at my disposal to do all sorts of transforms, I made it so the cards get into big sine waves on the top and bottom of the page, and a "You win!" pops up in the middle. I think it looks pretty cool, and only took a few lines of code. | ||
[[File:winscreen3.gif]] | |||
I will say this about React, the restrictions it puts on you are annoying, but once you've wired up the animations and stuff properly, everything just kind of magically works. I added an undo/redo feature which keeps track of the previous state whenever you perform a <code>set-board-state</code> and the cards perfectly float into place and the columns perfectly expand/contract according to my rules... very nice. You can even undo out of the win screen and it all reverts back properly, and back in again if you redo. | I will say this about React, the restrictions it puts on you are annoying, but once you've wired up the animations and stuff properly, everything just kind of magically works. I added an undo/redo feature which keeps track of the previous state whenever you perform a <code>set-board-state</code> and the cards perfectly float into place and the columns perfectly expand/contract according to my rules... very nice. You can even undo out of the win screen and it all reverts back properly, and back in again if you redo. | ||
| Line 97: | Line 97: | ||
<blockquote class="templatequote"> | <blockquote class="templatequote"> | ||
Its bad! You can't say (apply #'+ (list 1 2 3)). Its the thinnest, most brittle veneer on top of JS and it makes all sorts of implications that it can't keep | Its bad! You can't say (apply #'+ (list 1 2 3)). Its the thinnest, most brittle veneer on top of JS and it makes all sorts of implications that it can't keep<br> | ||
[https://old.reddit.com/r/lisp/comments/ccrjvl/in_which_domains_and_where_does_parenscript_find/etubhei/ —commonslip] | [https://old.reddit.com/r/lisp/comments/ccrjvl/in_which_domains_and_where_does_parenscript_find/etubhei/ —commonslip] | ||
</blockquote> | </blockquote> | ||
Parenscript is fundamentally flawed. It's a super-lightweight papering-over of JavaScript, and you become aware of that harsh reality immediately. It makes an attempt to look like the surface syntax of Common Lisp while maintaining none of its semantics, so you kind of have to juggle in your mind the JavaScript you want to get, the Parenscript you have to write, and the Common Lisp that would do something else if executed as CL. It's especially odd since JS has no cons cells, and Parenscript doesn't try to provide them-- <code>(cons 1 nil)</code> just becomes <code>cons(1, null);</code>. So it looks superficially a lot like CL, but isn't like it semantically at all. On top of that, Parenscript has a few bugs: it will just miscompile things sometimes, specifically its <code>loop</code> construct, and it has a bad habit of not declaring variables when you use <code>let</code>, which doesn't work in <code>use strict"</code> mode. | Parenscript is fundamentally flawed. It's a super-lightweight papering-over of JavaScript, and you become aware of that harsh reality immediately. It makes an attempt to look like the surface syntax of Common Lisp while maintaining none of its semantics, so you kind of have to juggle in your mind the JavaScript you want to get, the Parenscript you have to write, and the Common Lisp that would do something else if executed as CL. It's especially odd since JS has no cons cells, and Parenscript doesn't try to provide them-- <code>(cons 1 nil)</code> just becomes <code>cons(1, null);</code>. So it looks superficially a lot like CL, but isn't like it semantically at all. On top of that, Parenscript has a few bugs: it will just miscompile things sometimes, specifically its <code>loop</code> construct, and it has a bad habit of not declaring variables when you use <code>let</code>, which doesn't work in <code>use strict"</code> mode. | ||
| Line 107: | Line 105: | ||
= Conclusion = | = Conclusion = | ||
One thing I've always thought about macros in Common Lisp is that you often don't need them because the language is already so rich on its own. A lot of the times I find myself wanting to use a macro is when I'm using other | One thing I've always thought about macros in Common Lisp is that you often don't need them because the language is already so rich on its own. A lot of the times I find myself wanting to use a macro is when I'm using other languages that don't have them. In this case, worlds collide since the actual implementation language is pretty spartan, but it can be extended with the full power of Lisp. Which means that usually when I'd wish for macros I'd sigh wistfully and start copy-pasting, but now I can actually have them. It's pretty cool, and combined with JavaScript's dynamic nature, and my home-grown interactive development environment, it does feel kinda like you're writing Lisp... until the illusion is inevitably broken by semantic differences. But I actually do like it a lot anyway, it's a lot more fun than writing straight JS, that's for sure. | ||