That question is so open ended I’m surprised half the letters haven’t drifted off! But in all seriousness it depends what exactly you are trying to do. To make a major and questionable generalisation if you are doing anything that is exceedingly time sensitive or involves crossing the max/js barrier very frequently then you might want to re-think your approach. However if you’re not experiencing any problems then you’re probably fine to keep on going in javascript. It’s very good for some things like patcher scripting and it is quite a nice step up to learning java or C if you’re coming from a non-programming background. Do you have any specific issues you are running in to? Or are you just worried about future developments?

I could be wrong about this, so someone please correct me if I am, but I think everything running through js ends up in the deferred que in Max6. This makes triggering events by running a call through js less than timing-accurate. Array manipulation is incredibly handy, but you might want to send the manipulated arrays out to [coll], and then trigger the data via [metro] (e.g.) so that things happen immediately.

I tend to use js these days for UI and scripting inside patchers (it’s great for that!), but leave all the heavy lifting to native Max objects, java, or gen~. Resultant values can always be fed to pattrs, whose value can be retrieved in the js using this.patcher.getnamed(‘whatever’).getvalueof().

However, if your input to or output from javascript is already deferred, you won’t gain anything by avoiding js.