Most concretely, the codebase needs a rewrite to modern ES2018 form, and the missing Processing 3 API classes and functions need to be implemented, and due to modern CSP, the way parsed scripts get injected also needs a changeover.

I started this over on https://github.com/Pomax/processingjs-es7 but that stalled last year because I was too busy, if you want to team up and help get that to a parity-with-current-pjs then that would be fantastic. It's fairly far along, but there's still plenty of work left before it can be called on par with even current Pjs.

(The rewrite is also missing basically any kind of test harness to verify the objects and functions behave correctly - while the current version has a slew of those, they really need to be rewritten to use a modern test framework, e.g. something like jest for unit testing and testcafe for render testing)

I will go over the repository this weekend.

I would definitely like to work on something outside of my own style of programming and certainly would love to work on this.

awesome, feel free to reach out to me by email, or through IRC (the processingjs channel on the mozilla irc server used to be the place where all us devs would coordinate, it's a bit of a ghost town atm but it's still an IRC channel so it works just fine for chats =)

Digging in now.

Just spit balling.

Looking into the Processing 3.0 JavaScript export mode.
Maybe contact them and find out what the stable bits of that are and if it can be used in a build chain.
Is it already used in the build chain in any way?

Maybe can export their tests do they have tests !?!? ooooo man

Then was this ever considered for the interpreter?
https://github.com/zaach/jison/wiki/ProjectsUsingJison
Though I love being able to mix the JS and Java code like a reckless animal and Jison would probably break that it would add a lot of people to the project quickly.

We used to use quite a few of their tests, but the idea behind Pjs is "if you run syntactically correct code that runs in Processing, it should do the same using Processing.js, barring technological impossibilities" (e.g. sync file loading, thread sleeping, etc). A fair number of Processing tests also test for things that are java specific, so running those would be unnecessary for Pjs, and sometimes even counterproductive as JS uses a different internal data model that allows things that fail hardcore on java to pass just fine, and as intended, in JS. The crucial part is having tests that confirm parity between the Processing 3 API and a rewritten Processing.js with support for that API.

If you want to completely rewrite the parser, that's cool, but I'd recommend only doing that if you know you can get it done in a relatively short amount of time (e.g, a few days tops): there is already a parser right now that works well enough to get sketches parsed, loaded, and running into the browser so getting the call library support up to parity with Processing 3 is far more important than replacing a working parser with another working parser.