Question SpeedScript & Javascript backtick conflict

[JamesBowen]

Problem:

In my webspeed html page I have embed JavaScript code. The JavaScript code includes backticks ( ` ) . In WebSpeed the backtick has a special purpose and so the webspeed code can't compile because of the conflicting javasctipt. As I understand it, the JavaScript language evolved to include the backtick in 2015.

<script>

const name = "James";
const role = "OpenEdge Developer";

const message = `Hello ${name}, your role is ${role}.`;

console.log(message);
</script>

Workaround:

My workaround solution is to substitute the backtick ` character with `chr(96)`.
This is ugly, but it's the only thing that works. I was hoping to use a tilde character to escape the back ticks i.e. ~` , but this did not work.

<script>

const name = "James";
const role = "OpenEdge Developer";

const message = `chr(96)`Hello ${name}, your role is ${role}.`chr(96)`;

console.log(message);
</script>

The other solution was to place the Javascript code into a separate .js file, but this seems like an overkill.

Is it worth perusing with Progress to create a solution?

 

[jdpjamesp]

My read is that PSC want Speedscript to go away. I could be wrong. But they've not really given Webspeed any real TLC lately and the compatibility handler for PASOE feels like a concession.

This is Claude's take on it
The fix I'd actually recommend for this case: don't fight the backtick — avoid it. Template literals are pure syntactic sugar; the same code works identically as plain string concatenation, which needs zero backticks:

const message = "Hello " + name + ", your role is " + role + ".";

No chr(96), no runtime substitution, valid in every JS engine, and WebSpeed never even sees a special character. For simple interpolation like your example, this is a straight drop-in replacement.


Where this gets harder is if you've got JS elsewhere that leans heavily on template literals (multi-line strings, tagged templates, third-party/minified code you don't control) — concatenating everything by hand stops being practical. For that case, I'd actually push back gently on "overkill" for the external .js file: it's not just a backtick workaround, it's the standard fix for this whole class of problem, because a static .js file never goes through WebSpeed's page preprocessor at all — so it's also immune to accidental collisions with the other three delimiter forms ({= =}, <%= %>, <!--WSE --&gt that modern JS, JSON, or CSS-in-JS could plausibly trip in the future. chr(96) stays a reasonable fallback for the odd one-off backtick you can't avoid, but as a page-wide strategy it's worth reserving for cases where externalizing genuinely isn't an option.


Sources:

Expression escapes

: Progress OpenEdge is the complete development platform for building dynamic multi-language applications for secure deployment across any platform, any mobile device, and any Cloud.

documentation.progress.com

Chapter 3 WebSpeed Preprocessing - FWD - Golden Code Redmine

Redmine

proj.goldencode.com

How to embed SpeedScript in HTML

: Progress OpenEdge is the complete development platform for building dynamic multi-language applications for secure deployment across any platform, any mobile device, and any Cloud.

documentation.progress.com

 

[JamesBowen]

Thanks James.

I agree, Progress has lost interest in WebSpeed for a very long time. The last WebSpeed documentation is 11.7. Nothing, on OE 12.x.

I'm trying to desperately to embrace the POSOE web transport, but is takes me ages to write anything and it's not always going to the be JSON output.

Unless I've missed something, I have not seen an example of how PASOE can using HTML templates for delivering HTML content. In the mean time I will continuing using embedded ScriptScript.