Path to ES6, ES7?

[corbettbrasing1]

Is there current roadmap to upgrade the platform to ES6, or 7?   I know Helsinki upgraded it to ES5.

[xiaix]

Still ES5 in Madrid & New York... <sigh>

[Andreas R]

I'm of four minds on this (one more than usual, for me):

1. I understand the motivation to stay with older JS: Rhino just isn't up to snuff and if you promise ES2015 support you MUST guarantee it is complete. Rhino ES2015 support is not complete, and this adds a ton of extra support you need to manage as developers encounter Rhino wrinkles in attempts to port existing ES2015 libraries to the SN environment. SN doesn't want to be Rhino support as well as SN support, and at the very least, ES5 support is complete as can be. 

2. I understand the motivation to stay with Rhino. ServiceNow backcompat relies on very tight JavaScript/Java bindings, and Rhino is written in Java. It's sometimes amazing how tight a coupling we can get between our scripts and the underlying Java and I'm pretty thankful for that, actually. Switching to a more modern JSVM like V8 while maintaining the old bindings would be a pretty scary undertaking when you have so many enterprise customers and a big part of your sales pitch is uptime.

3. Sticking with Rhino keeps SN three curves behind the curve, and as others have mentioned, this makes you look ridiculous as a serious development environment, and that's keeping serious development efforts at arm's length. Doubling down on "innovations" with low/nocode doesn't help you at all here. Until you have cyclical flows with as rich an action API as anything anyone doing integrations can do with JS (fat chance), Flows are a red herring. As noble as SN's intentions are, most roads lead to procode for the foreseeable future. The very least you could do is give those saddled with serious programming labor on your platform as close to a modern work environment as possible. Hell, you can even spoof it by transpiling code before it gets passed to Rhino! I know, I do this myself with Babel in my background script replacement and tooling. That I have to do this myself makes ServiceNow look downright uninterested in bettering my workday. 

4. If you ARE sticking with Rhino, get real with it. Rhino supports let, const, arrow functions and destructuring, for me personally 90% of what I really miss in day to day scripting. And while you're at it, turn on E4X support to end our XMLDocument nightmares forever. Flip the switch you cowards! 

The clock is not only ticking, ServiceNow, the alarm is blaring at you and it has been for literally years. Take pro-code seriously or "braindrain" your community.

[corbettbrasing1]

I love your reply here.  I wonder...if the SN UI supported modern JS and then SN did the transpile through Babel...and they stayed on Rhino, but we didnt see that all we see is that now there is ES8 Support....if that would get us what we all want?

[Andreas R]

I already transpile with Babel in my SN tools and I know lots of people do the same. It is obvious to me that SN integrating a transpiler like Babel would solve this issue, though it does introduce a level of "indirection" with the script records not necessarily being a 1:1 reflection of the code as executed.

[Marco Moro]

I've created an Idea on the portal: Support for ECMAScript 2015 (ES6) or newer

Vote and comment on that idea so that the idea team takes care about that.