Javascript

[richmond62]

https://forums.livecode.com/viewtopic.p ... 10#p234010

Since a long time, you've been able to run javascript in

xTalk

by simply calling it through

Code: Select all

do [javascript code] with "javascript"

This is also something that needs to be plugged both in the legacy IDE and any upcoming webTalk.

[tperry2x]

https://forums.livecode.com/viewtopic.p ... 10#p234010

Since a long time, you've been able to run javascript in

xTalk

by simply calling it through

Code: Select all

do [javascript code] with "javascript"

What works

• Standard ECMAScript 5 (ES5) and some ES6+: Basic JavaScript syntax, operators, control flow (if, while, for, etc.), math, strings, arrays, objects.

• Math functions, string manipulation, basic array operations.

• JSON parsing and stringifying: Useful for exchanging data between LiveCode and JavaScript.

• Safe expressions: You can evaluate simple expressions and get results back into LiveCode variables.

Key limitations

• No access to browser-specific APIs

• No access to window, document, DOM, fetch, alert, etc. (no access to the DOM is a deal breaker)

• You're not running in a full browser environment — it's not a browser.

• Limited JavaScript engine

• LiveCode uses a lightweight embedded JS engine.

• Some newer ES6+ features (like async/await, Promises, let/const, arrow functions) may not be supported, or behave inconsistently across platforms.

• No access to LiveCode variables or context inside JavaScript

• The JavaScript you run cannot access LiveCode variables or handlers directly.

• You have to manually pass values in and out (e.g., via do ... with ... or the result).

• Error handling is basic

• JS runtime errors may be returned in the result or as an empty string — debugging is awkward.

• Syntax errors or exceptions in JS don't always produce clear LiveCode errors.

• Security sandbox

• The JS engine is sandboxed — no file access, no network access, no system-level APIs.

• No DOM rendering

• Even if you return HTML from JS, it won’t render in a browser-like way unless you explicitly use a browser widget or external web view. Note: Browser widget is unsupported in Linux.

• Limited performance

• It’s fine for short scripts, but long-running or computationally intensive JS might slow down or hang LiveCode.

This is also something that needs to be plugged both in the legacy IDE and any upcoming webTalk.

Emphasis mine: webtalk is written in javascript, but I haven't implemented the 'do [script] with ["javascript"]'. It would be doable, but not the applescript version.

Workaround Techniques

• Exchange data via JSON:

Code: Select all

put "JSON.stringify({x: 1, y: 2})" into tJS
do tJS as "javascript"
put the result into tResult

• Run JavaScript in a browser widget for full DOM/API access if needed. (possible, but not for Linux)

• Use revExecuteJavaScript (in browser widgets only) for actual browser-context code execution.

[richmond62]

plugging the legacy IDE in webtalk

You misunderstand that one:

Plugging the possibility of using javascript inwith either the IDE or webTalk.

DOM

Document Object Model

I love the way people use acronyms assuming that everyone knows what they stand for . . .

https://youtu.be/KShnPYN-voI

MBP, MCP, BBG, SSE

[tperry2x]

plugging the legacy IDE in webtalk

You misunderstand that one:

Plugging the possibility of using javascript inwith either the IDE or webTalk.

Yes, I re-read your post and see what you mean now. webtalk (being itself created in javascript) has more access to everything in javascript than LC does. The LC version is very limited in what it can achieve. (as above)

[tperry2x]

Document Object Model
I love the way people use acronyms assuming that everyone knows what they stand for . . .

You asked, that's what it's called. The same as people don't often use the full phrase "Random Access Memory" - they use RAM instead.
I tried to detail all those points in english and non geek-speak as possible.

Sorry if you didn't read what you wanted to hear, that somehow the LC implementation of Javascript commands and functions is fully-formed, because it's not.

[tperry2x]

Anyway, worth mentioning too that it's:

Code: Select all

do "[javascript]" as "JavaScript"

(not 'with')

[richmond62]

Perhaps you should correct that "over there".

[tperry2x]

Perhaps you should correct that "over there".

There's not much point, they'd likely want to point me towards using 'create' / zavvi (whatever it's called) and not relying on the legacy IDE and engine... but just worth mentioning that the do [script] as [alternative language] is a handy feature, but not fully-featured (there are things you can still achieve with it if you work around the limitations).

As I've mentioned before though, I see little point in adding to anything 'over there' when we are striving to gain users 'over here' - and since we are barred from even mentioning this site 'over there', then why go out of our way to add any corrections?

This is partly the reason I've added specific conditions in my license agreement prohibiting use of my project by anyone affiliated with LC: they can do their thing, we can do ours. They've made that perfectly clear on multiple occasions that this is the way things are now.

[richmond62]

Personally I see no real harm keeping one foot in the door: but, then, I have not been quite so badly burnt as you have.

[tperry2x]

Personally I see no real harm keeping one foot in the door: but, then, I have not been quite so badly burnt as you have.

I'd say you have been moreso, with threats you received in the past. I haven't had any of that, but I have been told in no uncertain terms that no further help would be forthcoming.

[richmond62]

Yup: threats and so on . . .

Maybe I'm just a bit thicker-skinned than you are, or dafter: probably a bit of both.

[FourthWorld]

This is partly the reason I've added specific conditions in my license agreement prohibiting use of my project by anyone affiliated with LC: they can do their thing, we can do ours. They've made that perfectly clear on multiple occasions that this is the way things are now.

Which project did you use that license with?

[OpenXTalkPaul]

Some more clarifications I think are needed here:

As far was I know:
'Do tJSscript as javascript'
in LiveCode / OXT Community ONLY works in a web browser context, which effectively means the stack is running either in the Emscripten / (commercial edition) WASM engine, OR the stack is running in the Browser Widget (which could be either Webkit or CEF depending on the platform).

You absolutely CAN do two way communication between the Emscripten engine and the Bowser Engine it's running in, but some prep is needed as you have to set up the JS handlers you want to expose from the xTalk engine side.

You do that by setting the javascriptHandlers property.

When running in the Emscripten engine:
set the cJavascriptHandlers of this stack to pHanderList
(IRC the 'c' is important)

When running JS in the browser widget:
set the javascriptHandlers of widget to pHanderList

Previously (LC 6.7) with the Browser eXTernal you would use these two commands:
revBrowserAddJavaScriptHandler instanceID, handlerName
revBrowserRemoveJavaScriptHandler instanceID, handlerName

So if you go here:
https://openxtalk-org.github.io/OpenXTalk-Playground/
and paste 'put the script of this stack' into the 'message box'-like text area and then click the bottom-right button in the stack, it's JS that is passing the xTalk script into the Emscripten engine via the handler 'doXTscript' which was exposed to the JS side by setting the cJavascriptHandlers (see OpenStack handler). You can also see some other mixing in that stack script. JS needs to be passed as a string which can use double quotes which need to be 'escaped' by using xTalk 'entities' (constants "&quote&" ). That stack contains a bunch of examples of mixing JS and XTalk, including using HTML5 APIs and using an add-in JS library TinySynth.js triggering notes from script in the Piano Widget. There's examples of loading file from local disk (using fileReader API) and saving to disk in there as well.

You CAN do just about anything that you can do in the browser engine it's running in as far as that Browser Engine supports it. That includes manipulating DOM objects of the page it's running in (again examples in that web playground stack).

The problem with LC CE / OXT is that on Windows and Linux it uses a Chromium Embedded Framework (CEF) as the browser engine for the browser widget, which is now outdated but should still support ES5 / ES6. Another issue is that the build options they built CEF with doesn't include the whole shebang of what CEF can be built with support for (WebMIDI support for example), a source of frustration for some users (my self included), but still the bulk of CEF (circa 2021) is there (which adds a lot of bulk to the IDE). However when running on macOS/iOS the Browser Widget is using the OS provided WebKit as the browser engine and the Emscripten engine should run in any modern browser that supports HTML5 (which is why I was keen on trying to support the Emscripten engine build).

In ANY Extension Builder Widget a handler 'OnDo' can be added which enables users to send in sort-of arbitrary text. It's what the Browser Widget uses to accept 'do <javascript> in widget'.
I use that mechanism to allow for sending 'keydown pKey' to my 'OnScreenKeyboard Widget':
do "keydown' & pKey in widget "On Screen Keyboard"
which is then processed by its XB 'OnDo' handler.

OpenXION also has: do <JSscript> as Javascript, which I guess does whatever the JVM does with Javascript, but I haven't really played around with that. It also has 'do <script> as VBScript' (Windows only obviously) and 'do <script> as Python' (which I have tested with Python 3.x on macOS), and of course 'do <script> as AppleScript' on macOS.

[tperry2x]

Just to clarify, we were talking about in the LC / OXT legacy engine.
Not in emscripten or in a browser widget.
You can do very basic one-liner javascripts, or things which don't require extensive parsing and functions without a browser widget or anything. A bit like how you can also run applescripts too. (but again, only on MacOS).

(As I mentioned above in my reply, the browser widget does not work on Linux, however out of date that browser widget is now).

In the emscripten build, I know you can indeed use javascript, but that's a separate thing altogether. What we were on about was using the 'do as alternative language' function in the legacy IDE. Not with any browser widgets, not with the emscripten build, and not with any LCB extensions - but instead with the native legacy IDE alone.

Or at least, that's the entire gist of the OP as I took it to mean. If instead they did indeed mean also using the browser widget, then that's great except it only works on 2 out of 3 platforms, so it a bit of a moot point cross-platform-wise. Without using the browser widget it's very simplistic what you can run, and with the browser widget - there are still a lot of limitations. This is probably the entire reason why the emscripten build exists, but that itself is likely using depreciated APIs if we were to dig through it.

[tperry2x]

This is partly the reason I've added specific conditions in my license agreement prohibiting use of my project by anyone affiliated with LC: they can do their thing, we can do ours. They've made that perfectly clear on multiple occasions that this is the way things are now.

Which project did you use that license with?

Not any project here. The webtalk project specifically.
webtalk.tsites.co.uk

[FourthWorld]

This is partly the reason I've added specific conditions in my license agreement prohibiting use of my project by anyone affiliated with LC: they can do their thing, we can do ours. They've made that perfectly clear on multiple occasions that this is the way things are now.

Which project did you use that license with?

Not any project here. The webtalk project specifically.
webtalk.tsites.co.uk

Thank you. I like the two column format, very readable.

[OpenXTalkPaul]

Just to clarify, we were talking about in the LC / OXT legacy engine.
Not in emscripten or in a browser widget.
You can do very basic one-liner javascripts, or things which don't require extensive parsing and functions without a browser widget or anything. A bit like how you can also run applescripts too. (but again, only on MacOS).

In the emscripten build, I know you can indeed use javascript, but that's a separate thing altogether. What we were on about was using the 'do as alternative language' function in the legacy IDE. Not with any browser widgets, not with the emscripten build, and not with any LCB extensions - but instead with the native legacy IDE alone.

Is that so? IIRC, I tried that at one point, since Apple included JXA (Javascript for automation) along with AppleScript, as a 'OSA' type language I figured that might work, but I got the impression it does not. But maybe it requires newer versions than I tried?

(As I mentioned above in my reply, the browser widget does not work on Linux, however out of date that browser widget is now).

Well to be accurate, it does 'work' sort of, it just doesn't play well with modern window managers and GTK3/4 where it has off-screen render buffer to view port problems and keyboard focus issues. It's still includes a JS runtime in CEF and can still be useful for non-interactive-web things.

probably the entire reason why the emscripten build exists, but that itself is likely using depreciated APIs if we were to dig through it.

I think the reason is most likely the same reason that things like Heizer's LiveCard and SuperCard 'Roadster' were created back in the late 1990s, which is to deliver xTalk stack content via a web browser.

The Emscripten engine build instructions in the repo do call for a now rather old version of the Emscripten Dev Kit, but i'm not aware of any deprecated APIs it uses. I believe it should work fine on modern HTML5+ browsers that support web assembly and should continue to do so indefinitely, theoretically.

I'm off to test this theory of JS as an alternativeScripting language again...

[OpenXTalkPaul]

Let's test this assertion...

From the message box on macOS 11.7.10:

Code: Select all

put alternateLanguages()

Result:
applescript debugger -- Hmm where this came from? Probably from Pulsar, ScriptDebugger, or other dev tool I have installed.
applescript
javascript -- BINGO!
This is promising, I'm sure that this wasn't the result I got on earlier version I tried this with (probably on macOS 10.10.5).

Code: Select all

do "console.log('test');" as javascript ; put the result

Result: undefined -- which is actually GOOD because that's a Javascript error!
That must mean there's no console.log() method...

OK try super-simple then:

Code: Select all

do "'test'" as javascript ; put the result

Result:
"test"
AWESOME!
JSX does seem to work as alternateLanguage for scripting, at least on newer macOS it does.
Obviously just simply returning a string isn't a very useful thing but I'm definitely going to want to dig into this further.

[tperry2x]

Yes, I remember seeing it in the C++ engine source, so I knew it had support for very basic one-liners.
I will have to take the emscripten source apart at some point, as things like javascript 'keyboard.event' are depreciated.

Code: Select all

KeyboardEvent.keyCode, keyIdentifier

Code: Select all

document.addEventListener("keydown", function(event) {
  if (event.keyCode === 13) {
    console.log("Enter key was pressed");
  }
});

That was replaced with:

Code: Select all

document.addEventListener("keydown", function(event) {
  if (event.key === "Enter") {
    console.log("Enter key was pressed");
  }
});

(event.key instead of event.keyCode) -- doesn't sound like much, but little changes like this in browser support will cause things to break. That's why I'd be interested in looking through the entire emscripten source in it's most recent form.

[richmond62]

No 'buggers' on MacOS 12:
-

Screenshot 2025-05-10 at 11.44.32.png (36.79 KiB) Viewed 96 times

-
Not noticeably different on LC 963 CE:
-

Screenshot 2025-05-10 at 11.46.18.png (38.12 KiB) Viewed 95 times