If I remember, in addition to VBS support, DOpus uses the JScript engine built in OS. For WSH, Microsoft still uses JScript 5.7 feature set by default for backward compatibility. This is equivalent to ES3 released in 2000. This language has evolved a lot with significant updates since then and most of the web dev already use ES6 released in 2015. Some web dev could be surprised if they use their ES6 or even ES5 skills in their JScript in Dopus, facing weird bugs.
I think, it would be simpler for scripters to be able to always use the last released EcmaScript version, the one they are used to and because those versions are more powerful. If DOpus came with a built-in Node.js, scripters could use ES5 with no effort and most of the ES6 important features.
Other languages
What about Python and C#? The first one is often used in software as the default scripting language (ComicRack, etc.). The second one is used in some other software like Unity 3D. The goal is supporting those languages without the user needs to install Python or else.
Final words
I Hope to see those improvements in future to encourage more user to write more scripts without facing oddity of the old WSH engine.
But would you agree, there are very few topics where people complain about STRING.startsWith() does not work or that managing property attributes seems broken? My impression is, that 99,9% of users don't know what ES iterations are out there and where the exact difference is between JScript and ES6 and so they probably don't miss much.
For the ES6-Gurus, some things can be hooked into the aged JScript engine with the polyfills available at mozilla or stackoverflow. I must say, I get along with JScript quite well. ES6 does not really open a whole new world, it's easier to use here and there and there are some nice modern approaches built into it, but you can still write nice code with ES3.
For some reason, DO does not seem to attract a whole lot of programmers, you'd see more scripts where you scratch your head because things are done on a really advanced level. This let's me doubt there is much sense in supporting C# anytime soon. It's not a scripting environment either.
Currently, most of DOs new scripting features are yet to be explored by the world and me, hu? o) So, adding another universe of possibilities probably does not help encouraging people to write more stuff. And if you take a look at the scripts forum, many of what gets uploaded are one trick ponies which reside without any maintenance or update. The latter is understandable, because updating and writing short documentations leaves the fun-sector - it's becoming work. o)
If you ask me, I'd go for supporting powershell next - at least for inline button scripts. It would fit the needs of most people much better than offering another advanced C# api. Another thing is examples and short "how to use"-snippets directly in the script-objects documentation. The current reference is nice and you can't do without, but it's quite short-worded and requires a lot of knowledge to be helpful on it's own. That's my impression - I at least struggle from time to time and need to lookup code from existing scripts to be able to get on and if you don't know where to look, well then it's hard. o)
The current reference is nice and you can't do without, but it's quite short-worded and requires a lot of knowledge to be helpful on it's own. That's my impression - I at least struggle from time to time and need to lookup code from existing scripts to be able to get on and if you don't know where to look, well then it's hard. o)
I agree with that.
For the rest, I tend to have another way of thinking. I remember to have been frustrated with the current JScript based on ES3 (don't ask me why, I can't remember).
Python is popular, I guess. Maybe among the people from Linux world though but it can attract some people to write script.
A built-in script store as VScode or other code editor provide would be an appeal. If scripts are more integrated with built-in update support, etc. It can only be better and again attract more people to write and maintain scripts.
Some kind of Script-Store for easier access is a nice idea, I doubt that the devs have time to do something like that though. Who's going to maintain the backend for it? Justifying the required efforts to built this is probably not easy, but I would agree, it would allow easier access to all the scripting stuff..
Such a thing does not necessarily need to be built into DO, so anyone could give it a go?! hint.. o)
ps: That mysterious has been removed from the thread it seems. I don't mind! o)