jsPsych can sometimes be restrictive for more complicated designs, but the next version of jsPsych is going to fix much of this. IMO the advantage is a consistent API for interacting with data and experiment timelines so I don't have to think about that as much, leaving me time to do other things. - ThreadSky

courtneybhilton.bsky.social • 257 days ago

jsPsych can sometimes be restrictive for more complicated designs, but the next version of jsPsych is going to fix much of this.

IMO the advantage is a consistent API for interacting with data and experiment timelines so I don't have to think about that as much, leaving me time to do other things.

Comments

courtneybhilton.bsky.social•257 days ago

In the 'Tone Guesser' experiment above, basically all of what you see and hear is my own vanilla js code, but still it is very useful to package up my code as a jsPsych plugin to inherit all its methods etc for dealing with data and integrating into an experiment timeline

courtneybhilton.bsky.social•257 days ago

Once timelines become more flexible in the next major version I don't see any downside for more advanced users, since you can inject as much of your own code, or build your own plugins as needed for more advanced functionality while still getting all the benefits of what jsPsych takes care of

mehr.nz•257 days ago

This thread is also a nice demonstration of how different features of an environment are important for entirely different reasons

joshdeleeuw.bsky.social•257 days ago

I think the restrictiveness that advanced users sometimes feel is more of a developer experience fault on my end than an actual restrictiveness. I've yet to encounter something that couldn't be implemented. (Which is not to say that it is a good idea to use it for every project!)

courtneybhilton.bsky.social•256 days ago

What I mean by restrictive is more to do with cases requiring modifying the timeline on the fly. Trying to get around that is possible although can be a bit clunky, in my experience. Although this is probably only a fairly rare requirement

joshdeleeuw.bsky.social•256 days ago

Yeah, totally in agreement! "Possible but clunky" is not a great developer experience 😅

fredcallaway.bsky.social•255 days ago

Thanks for all the discussion! In case it’s useful, here are some things I found clunky :
- logic that works across trials (like step designs)
- reactive elements that stay on screen across multiple trials
- composing elements of plugins (eg interactive instructions that use parts of the main task)

fredcallaway.bsky.social•255 days ago

These all *can* be done by defining a bunch of plugins that draw on a “library” of general code, maybe using timeline variables, etc… but functions and variables just feel more natural (and are much easier to implement and debug in my experience)

joshdeleeuw.bsky.social•257 days ago

And along the lines of "consistent API" I think a related advantage is something analogous to an advantage of the tidyverse in R. If you have a consistent way to construct an analysis pipeline then you can build tools that interact easily, without needing centralized development.

mehr.nz•257 days ago

Maybe we should consider some documentation laying out advantages/disadvantages for advanced users as part of the 'ecosystem development' stuff

Comments

Posting Rules

Reply