While PlayCanvas is actively developed, the JavaScript API feels very old fashioned, especially sharing everything in the global namespace. It really needs modernizing.
I appreciate that changing the API is not a simple thing to do, but as the years go by, and modern APIs become standard, it feels more and more jarring to go back to PlayCanvas.
Babylon JS has a similar issue, but they have begun modernizing the API (in time for Babylon 6).
PIXI JS recently began releasing multiple versions of their library (using the mjs extension to distinguish modern modules from old school ones).
PlayCanvas will need to go through its own modernization process at some point, and it seems counterproductive to do that later if it could be done sooner.
I looked for a roadmap, but the newest one I found was from 2021, so I’d be grateful if anyone could shine any light on PlayCanvas’ plans for the future (specifically regarding the JS API, and ES6 support).
What do you find with the API that requires modernization?
The engine itself supports ES6 and is written in ES6 with module support and can build to .mjs. It’s also recently being refactored to support treeshaking when used directly.
The Editor however is behind the curve where the scripts default to an ES5 style although we have developers like @LeXXik using ES6 code in the Editor directly now that most modern browsers support it.
@yaustar - Sorry that I didn’t see your reply sooner.
I only have experience with the editor, so was really just commenting on that. It honestly felt abandoned.
The code feels ancient without module support. I either have to wrap every script in a giant IIFE, like back in the day, or just let everything spill into the global namespace.
When I looked through the docs, they seemed to be in the exact same state as they were in years earlier, when I last looked at them. It all just seems stale and unloved.
So if you are using engine only, you have module support without us needing to change the API.
There are some areas that are still a bit problematic from a typing POV such as asset.resource returning any resource type so that would need to be casted or hinted at with JS Docs. That is unlikely to change due to backwards compatibility unless we move to PlayCanvas 2.0.
The other side is more complicated unfortunately, the Editor is a bit ‘stuck’ on using the older style of JS programming. For us to adopt a more modern JS workflow where modules are used and using a bundler like Webpack/rollup will require significant work that we haven’t committed to unfortunately.
I know that some developers have take to using ES6 classes to improve code completion in the Code Editor itself.
Some other developers have decided to have the code outside of PlayCanvas, build using Webpack/roll up and upload the built JS file to PlayCanvas Editor via REST API or playcanvas-sync. This is not straightforward due to having to keep 2 version control systems in sync. We are looking to help make this easier in the future though to help.
The scriptTypes system is going to be largest pain point and my mean a Script v3 is needed as they are still in ES5 style hence the docs have changed little in the example code.