3 ms·

first let me say i applaud you for experimenting and doing something unconventional - thoughts as i was reading this - ok, so we're programming via an AST vs

first let me say i applaud you for experimenting and doing something unconventional - thoughts as i was reading this - ok, so we're programming via an AST vs syntax I think this is interesting, however there's notable downsides - verbosity, dom bloat & debugging A potential upside to this is very odd but interesting meta programming capabilities, since the code should be able to inspect & modify itself fairly easily by inspecting the dom I am inclined to distrust the claim that this reduces complexity as most of the actions are mutation heavy directly to the dom, and the stack based programming is something i struggle to practical examples where it is a significant improvement to mainstream strategies

lassejansen 9mo ago
DOM bloat can certainly become a problem when adding lots of code in e.g. table rows. I added functions mainly to be able to move common code into a central place to minimize that problem. You certainly must get used to the stack based approach. I tried to make it more approachable by making stack lookups type based (automatic search for value with matching type) and by using type-prefixed commands, e.g. <request-send url="..."> // returns response <response-get-text> // looks up response on the stack and returns string <selection-set-text> // looks up string on the stack and writes it as text content to the current DOM element.
- dhamidi 9mo ago
  Maybe useful inspiration from TCL: there are many commands that define new variables, which makes modeling the stack unnecessary. For example: lappend responses [dict status 200 body ...] Appends a new dict to the list held in the variable responses, creating the variable if necessary. I can see that being an attribute: <request-send url="..." as="greeting" /> <response-text response="greeting" as="text" /> <selection-set-text text="text" />
  - lassejansen 9mo ago
    The main reason for using a stack was reducing verbosity because for short scripts using variables felt unnecessary when the type-prefix of the command already communicates the variable contents. But it could still be a good idea to have a shorter syntax for assigned variables. Accessing a variables works like this at the moment: <selection-set-text $text="varname"> Keeping the dollar syntax, setting the return value to a named variable could look like this: <response-get-text $="varname">

lassejansen 9mo ago

DOM bloat can certainly become a problem when adding lots of code in e.g. table rows. I added functions mainly to be able to move common code into a central place to minimize that problem. You certainly must get used to the stack based approach. I tried to make it more approachable by making stack lookups type based (automatic search for value with matching type) and by using type-prefixed commands, e.g. <request-send url="..."> // returns response <response-get-text> // looks up response on the stack and returns string <selection-set-text> // looks up string on the stack and writes it as text content to the current DOM element.

dhamidi 9mo ago
Maybe useful inspiration from TCL: there are many commands that define new variables, which makes modeling the stack unnecessary. For example: lappend responses [dict status 200 body ...] Appends a new dict to the list held in the variable responses, creating the variable if necessary. I can see that being an attribute: <request-send url="..." as="greeting" /> <response-text response="greeting" as="text" /> <selection-set-text text="text" />
- lassejansen 9mo ago
  The main reason for using a stack was reducing verbosity because for short scripts using variables felt unnecessary when the type-prefix of the command already communicates the variable contents. But it could still be a good idea to have a shorter syntax for assigned variables. Accessing a variables works like this at the moment: <selection-set-text $text="varname"> Keeping the dollar syntax, setting the return value to a named variable could look like this: <response-get-text $="varname">