WASM wrapper

[tperry2x]

Off the back of the bit-rot topic, I've been looking into Paul's WASM suggestion.
Digging a bit deeper into it: (this is from Gemini, and Deepseek - so take it with a pinch of salt as it may not be correct).

1. Running WebAssembly Offline in a Browser

• WebAssembly modules (.wasm files) can be loaded and executed entirely within a web page, using JavaScript.

• If the web page is stored locally (file:// protocol) or served from a local web server (e.g., using Python's http.server or Node.js), it will work without an internet connection.

• Browsers like Chrome, Firefox, Edge, and Safari support WebAssembly natively.

2. Running WebAssembly Locally Without a Browser

• Wasmtime: A lightweight Wasm runtime for running .wasm files on desktops.

• WasmEdge: Optimized for IoT and cloud applications but works locally too.

• Wasmer: A runtime that allows running WebAssembly programs like native executables.

• WASI (WebAssembly System Interface): Provides system calls to WebAssembly, allowing it to run outside the browser with access to files, environment variables, and networking.

(I'd never heard of any of those suggestions, so I'm off to check them out).
The 'AI' algorithms go on to say:

Key Considerations

• No Internet Required: As long as the necessary .wasm file and JavaScript loader are available, execution is completely offline.

• Local Storage: WebAssembly can access IndexedDB, localStorage, or File API in a browser for persistence.

• Performance: Near-native speeds, making it a good choice for local applications.

Emphasis mine. 'Near-native speeds' which means slower. I wonder how much slower?

[OpenXTalkPaul]

Emphasis mine. 'Near-native speeds' which means slower. I wonder how much slower?

I think it would be slowed down by the amount of time to interpret the wasm bytecode into to native machine code, so I imagine that it is very similar to Java. Of course there are strategies like just in time / ahead of time compiling to mitigate delays. If you've ever tried the wasm port of Audacity sound editor (or similar desktop to web asm ported app), it's definitely usably fast once it's loaded.

The AI response seems pretty accurate to me from what I've read about these while researching the Emscripten engine.

I'm going to try to recompile the Emscripten engine to .wasm as soon as I have time to do the Emscripten SDK install and setting up stuff. LC team already did that port (post open-source), so we know that it's doable, and compiling .wasm should just be a compiler option.

[FourthWorld]

...compiling .wasm should just be a compiler option.

Checking the WASM output box is the easy part.

Rewriting all of the engine's OS calls is apparently daunting.

Note the date:
https://livecode.com/livecode-to-html5/#project

$395k + a decade of additional payroll burn and they're still ironing it out.

Emscripten is very popular, but usually for discrete functions. I've not come across any other project attempting to use it to bring an entire event-driven GUI into the confines of a browser window, let alone one as complex as an xTalk.


One last envisioning of another way:

Porting the xTalk object model to HTML/CSS is tedious but not difficult.

Translating the scripting into something that can run in the browser's only scripting language used to be prohibitively hard, until Dan pointed the way with his transpiler.

An Emscripten-based port requires downloading the translated LC engine just to render the first page.

A truly native web port uses the browser engine that's already there.

Cheaper to deliver, faster to load and run.

[OpenXTalkPaul]

...compiling .wasm should just be a compiler option.

Checking the WASM output box is the easy part.

Rewriting all of the engine's OS calls is apparently daunting.

Many of the important Engine's OS calls have already been ported to work in web environment, some very easy to 'port' functionality (such as revSpeak for one example that has an equivalent HTML5 API, was bothered with.

That's the reason why I started that OXT Playground webstack, to see if I could add some of that missing features using xTalk<>JS and Web APIs, turns out it was pretty easy to add a few things here and there when I had some free time. Enabling 'speak' (no 'rev', back to it's traditional name) with Web Speech API was an obvious low hanging fruit, pretty easy to wrap that in a an xTalk 'speak' command. As was getting the prefered 'darkMode' from JS/DOM.

If you're talking about running JS & wasm in a desktop GUI app, take a close look at what Electron (and other wrappers) offer. Electron comes with batteries included, already facilitates things like creating individual windows, file system access, shell() access, Node.js, etc.

Note the date:
https://livecode.com/livecode-to-html5/#project

$395k + a decade of additional payroll burn and they're still ironing it out.

If you check the other forum, the various complaints, a lot from HH in bug reports and such, you'll see a lot of discontent about the amount of work (or lack thereof) that was done on the Emscripten engine.

Emscripten is very popular, but usually for discrete functions. I've not come across any other project attempting to use it to bring an entire event-driven GUI into the confines of a browser window, let alone one as complex as an xTalk.

Emscripten asm.js or wasm? Maybe you aren't looking hard enough.
https://github.com/nepx/halfix
https://wavacity.com
https://medium.com/@addyosmani/photosho ... d70954365a
https://probablykam.github.io/Mario64webgl/
I could go on.

Porting the xTalk object model to HTML/CSS is tedious but not difficult.

I'm all for doing that, I do not like CSS but I'll suck it up and work with it.

Translating the scripting into something that can run in the browser's only scripting language used to be prohibitively hard, until Dan pointed the way with his transpiler.

Yes Dan did it brilliantly, although not the only one to do HyperCard web

[FourthWorld]

The Photoshop port is impressive. Adobe is one of the wealthiest software companies in history. It would be useful to learn how much that cost them.

[OpenXTalkPaul]

The Photoshop port is impressive. Adobe is one of the wealthiest software companies in history. It would be useful to learn how much that cost them.

It probably depends on what language the source is written in. But certainly there's open source projects that have compile some GUI apps to wasm (like that Audacity port is a good, useful example), and library support is getting better (slowly), so it's not like it necessarily requires a big budget.

This morning I installed Emscripten Dev Kit (after having to update / reinstall XCode stuff) on macOS (via Homebrew formula), interesting how some of it's dependencies already sync up with the pre-built binaries / linux engine dependencies:

==> Installing dependencies for emscripten: node, libpng, freetype, fontconfig, libunistring, gettext, meson, glib, util-macros, xorgproto, libxau, libxdmcp, xcb-proto, libxcb, xtrans, libx11, libxext, libxrender, pixman, cairo, gobject-introspection, harfbuzz, zstd, little-cms2, openjdk and yuicompressor

[OpenXTalkPaul]

I think the best approach would be a combination of xTalk<>JS+DOM transpiling and HTML5/Web APIs and wasm modules for anything else.
By "for anything else", I mean things like some of the Musical Synthesizers I've used within a browser (have you tried the functioning 'Piano Widget' I put into the OXT Web Playground? https://openxtalk-org.github.io/OpenXTalk-Playground/) some that use JS and Web Audio API and others that are like C++ code compiled to wasm modules.

I just now arrived at the realization that compilers themselves can be compiled to wasm:
https://github.com/soedirgo/llvm-wasm
https://github.com/jprendes/emception live demo here: https://jprendes.github.io/emception/

[richmond62]

I really wish I could begin to understand what you are writing about as it sounds both fascinating and important.

Any chance of a simplified explanation for 'bottom feeders' like myself?

[tperry2x]

I will feed anyone reading this back to this topic (in the hope that it might be read).
Having all these ideas about potentially:

• putting things in a WASM wrapper (so you can use web technologies on the desktop)

• using javascript DOM element inspecting (which would help you when formatting and saving elements back to file)

• using wrappers to also run compilers in (negating the need for a full dev environment to be installed each time)

• using C++ extensions and transpilers to convert between one language to another (on-the-fly / behind the scenes)

all very good and interesting, however without some working examples and demos of this actually functioning - it's all just empty speculation, with nothing to actually show for it.

As an aside, speaking of Adobe:
Since the later stages of CS6 where they moved to a subscription model, rather than site license / solely device licenses, they have been raking in cash. Have you seen the subscription costs, with no nod towards discounts for education. That's been going on for the last 12+ years - plenty of time for Adobe to store up any funds it needs, and enough to keep their investors/shareholders/bean-counters happy too. Make no mistake, Adobe's end users have paid for this move to the web a few times over. But that's why the growing discontent in the Adobe forums. Nobody there is a fan of the licensing, they subscribe to it much the same as people who might also subscribe to Microsoft365: because "it's industry standard", and there's a knee-jerk reaction to divert from any well trodden software path into alternatives available (because it requires effort). And so it persists.

[richmond62]

Well that is slightly better.

Although if I had a pound for every time I had either heard or read 'potential' I'd be a millionaire.

[tperry2x]

Well that is slightly better.

Although if I had a pound for every time I had either heard or read 'potential' I'd be a millionaire.

Yeah, it's all just BS until someone shows a working example of what it can do (putting it bluntly).

[OpenXTalkPaul]

Well that is slightly better.

Although if I had a pound for every time I had either heard or read 'potential' I'd be a millionaire.

Yeah, it's all just BS until someone shows a working example of what it can do (putting it bluntly).

I don't understand this comment, we have working examples, maybe not the best, but working.

Screen Shot 2025-03-02 at 11.28.26 AM.png (97.06 KiB) Viewed 20477 times

Sorry about the grammar error.

This is the ASM.js (wasm predecessor) compiled engine right here:
https://openxtalk-org.github.io/OpenXTalk-Playground/
And that engine has since been compiled to wasm 'over there
If you want I can share the example Electron app wrapper I made on macOS, I tested using the Emscripten engine with it.
Then there's a lot of non-xTalk engine examples of wasm.

using javascript DOM element inspecting (which would help you when formatting and saving elements back to file)

Exaclty, not just inspecting the page/environment that the Browser engine is running on (although that is important obviously), I'm interested in creating and manipulating the DOM objects from xTalk, for example: create button "My New Button" should create a button tacked onto the page / 'stack', and also generate any relevant messages up the message hierarchy to a main event loop, the 'newButton' message in this example.

To try to simplify what I'm talking about with wasm ...

- WebAssembly conceptually is a lot like Java but Oracle corp doesn't own it. Wasm is assembly language / intermediary bytecode for a virtual computer, a generic VM.

- Code written in C/C++, like our MC>RR>LC>OXT engine AND various free open-source libraries needed to make the engine work like FreeType, and Cairo drawing library, can be compiled to this virtual machine assembly language and then can be run something that supports that virtual machine. It's he same 'Write Once Run Anywhere' (WORA) concept of Java/JVM. Code can be compiled to this VM's ASM 'bytecode' so that program can run as quickly as possible while still not being tied to a specific platform or CPU architecture. It's still not 'native' machine code, but it is much closer to that than 'higher level' languages like C/C++, Js, xTalk, etc.

- Modern web browsers engines support asm.js (Javascript 'polyfill' version can work on older browser engines) and smaller/faster wasm compiled modules. It is also possible to run.wasm modules without the web on desktop computers (no internet required to run), much like JAVA .jar files.

- The Emscripten OXT engine, used here: https://openxtalk-org.github.io/OpenXTalk-Playground/ is the asm.js javascript build of the Engine. It has since recompliled that engine to smaller/faster .wasm bytecode module 'over there' with which is NOT covered by the GPLv3 open source license that governs OXT, so we can't use that without a subscription.

- We may however recompile the community engine to .wasm ourselves. Mark Wielder has said was able to do that, although I have not seen a .wasm compiled module from this. In the building guides doc the recommended environment for bulding the engine with Emscipten is Linux, but Emscripten developer kit can be installed on other platforms.

I thought that I had Emscripten developer kit yesterday, but macOS 11/ Big Sur is too old for the current Homebrew formula for building the Emcripten Developer Kit. It never completed because XCode command line tools for macOS 11 is missing functions the newer build depends on. It's probably time to update the OS on this old laptop that I use for tinkering.

Then there's a different approach, used in HyperCard Simulator, ViperCard, others where there is a 'transpiling' of some sort of on-the-fly conversion of xTalk to JavaScript. JavaScript, and now WASM too, are the only languages that are 'native' to web platform. This could be done 'on the fly', but is going to yeild better results if the conversion can be done ahead of time.

I think it would be best to use a hybrid combination of xTalk -> JS transpiling method as demonstrated by the great working example we have in Dan's HyperCard Sim (there has been other projects similar to that, such as ViperCard), along with HTML5 / Web APIs (text-to-speech, geolocation, joystick support, etc.) and if helpful use compiled .wasm modules too if, for example, we want to use some chart making desktop library that's already been compiled to web assenbly.

I hope that helps make sense for anyone reading this thread.

[OpenXTalkPaul]

Dan's HC Simulator on the other hand does not use any WebAssembly at all, it's like an HyperTalk translator/wrapper around Javascript / HTML.

HC sim has some good examples in a few different things.

It can create new 'stacks' which are 'virtual windows' (again there is no concept of a 'window manager' inside browser context). These are actually custom HTML elements. You can save 'stack' out to an html file where you can see that its parts ( 'scriptObjects' to use the LCB term) are created as html elements.

if you then paste into that saved 'stack' html page Dan's approx. 300kb transpiling HyperTalk interpreter you have a functional 'standalone' in that the stack / page can then be run inside modern browsers engines with nothing else needed.

Other resources such as images or sounds can either be linked to a URL of a file, or the can be embedded into the page as data URLs, which are simply base64 encoded binary data as URL/string. HC sim has some image files on its server that match those included in HyperCard & mac OS 6/7 Toolbox, while the HyperCard sounds such as 'boing' have been embedded as Data URLs.

[tperry2x]

A lot of it is probably because I don't use github. Yes, it's my own fault, but to go digging for stuff is quite tedious (and error-prone). That's not a jibe at anyone - just that I don't actually know what I'm looking for, because I don't know it exists in the first place (if that makes sense). Having a webpage with - "Here's a test version which will work on your desktop, no internet required, and will show off the latest web-savvy technologies"... and "here's a version that is a HTML5/Javascript/CSS implementation" etc, - that would give people a starting block and a clear view of the status of things (in my opinion). As I say, a lot of this is probably my own fault as I can't see the wood-for-the-trees in Github, so a clear HTML page listing of what's available would help I think.

[OpenXTalkPaul]

"here's a version that is a HTML5/Javascript/CSS implementation" etc, - that would give people a starting block and a clear view of the status of things (in my opinion).

Browsers usually have a Developer tools built into them, where you can see the files / resources used by a page, and download them.
This is a really good start:
https://www.tsites.co.uk/otherstuff/hyp ... index.html
I can see that it's basically some of the same stuff from HyperCard Sim.

Screen Shot 2025-03-02 at 2.29.01 PM.png (132.16 KiB) Viewed 20467 times

I used Safari's Web Dev Menu to download all of the pieces that make up HC sim including the black & white HyperCard Icons and put them into a Fork of Dan's GitHub repo, which did not include those, so that I could look at how he built it and tinker around with it. I didn't need to use github (but GitHub is certainly a valuable resource IMO), I put it there for anyone else who may be interested in using running it 'offline'. Download that whole repo and it should work offline, except for the importer php script.
https://github.com/PaulMcClernan/hyperc ... k-uploader

I hosted my modified version of the HC sim with for testing some edits to it here: https://openxtalk.org//WebStacks/simulator.html

Here's an example 'standalone' Stack/HTML file with the script.js 'engine' included https://openxtalk.org//WebStacks/HC3PlusPlus.html

[OpenXTalkPaul]

This is going just slightly off-topic for "wasm", since web assembly doesn't necessarily need to be involved in interpreting xTalk script, but...

Here's what the Electron macOS .app wrapper looks like with the OXT Emscripten engine included (relevant files highlighted in orange):

Screen Shot 2025-03-02 at 4.04.22 PM.png (104.75 KiB) Viewed 20443 times

That 184 Mb large Electron Framework.framework includes the Chomium browser engine, but it also enables 'Desktop' things like direct file system access, creating app menus, creating new windows, running shell scripts, etc.

Next I downloaded your example starter xtalk interpreter page/js files and replaced the OXT web playground files with those files and it's now a different 'app' no XCode involved.

Screen Shot 2025-03-02 at 4.55.09 PM.png (286.09 KiB) Viewed 20440 times

[tperry2x]

That's good, but I do have to ask as to the 'why' regarding the need for a WASM wrapper. I'd hoped that the WASM wrapper would obscure the HTML and Javascript from prying eyes, however if you can just right-click > show package contents, it's not much (any) of a defence.

When you can simply open the html page in a browser, and the browser itself is our 'app' for doing everything - I'm perhaps missing the point, but I don't see the need for the wrapper.

Plus, the example above makes it non-cross-platform (mac-only) which kind of defeats the point of doing a browser-based version?

It's all very clever having it in a wrapper - so it resembles a Mac-App, but that detracts from the cross-platform aspect of it. I don't even know if it would be possible to obfuscate html and javascript (and still have it functioning properly), so the only way to do that (as mentioned elsewhere) is to cover it with a restrictive license.

[OpenXTalkPaul]

That's good, but I do have to ask as to the 'why' regarding the need for a WASM wrapper. I'd hoped that the WASM wrapper would obscure the HTML and Javascript from prying eyes, however if you can just right-click > show package contents, it's not much (any) of a defence.

Personally I'm not looking for a defense against being open source, but I think what you want is for the xTalk interpreter to be compiled to wasm byte code module or some other mechanism to make it less human readable than HTML/Javascript. This is what the Emscripten engine is (but still has JS mixed in, not .wasm byte-code ). I believe there's a variety of languages that can be compiled to .wasm, C++ for example (which is what the Enscripten port is, but it's old asm.js format)

I think your best defense against intellectual property theft if you're worried about that is going to be attaching a copyright notice and license agreement to your work. If using Javascript you could 'minify' Javascript, which is removing line breaks, unused white spaces, etc. so that's less readable (and potentially significantly smaller). But as far as I know, every webpage/webapp on the internet can be inspected, and even WebAssembly is readable as far as assembly code is 'readable' (so if you're a human compiler). Even for compiled 'native' binaries there are decompiler/disassemblers. I did a disassembly of the Android standalone engine .jar in OXT using a Java disassembler, just to look at it (but I don't know enough Java to make much sense of a lot of it, and I'm sure its using Android APIs which I'm also not very familiar with).

When you can simply open the html page in a browser, and the browser itself is our 'app' for doing everything - I'm perhaps missing the point, but I don't see the need for the wrapper.

Can the browser create a new custom menu bar or 'system tray' item? Can the browser directly read files in some folder on your local drive (not a web cache) without user initiated (or simulated) interaction? Can a web page run shell scripts? Node modules, stuff like react-native or how about foreign code libraries? Can a web page communicate with another web page (or inter process communication), or launch a sub process or slave-app?
A web page can not do all of the things a desktop app can do, at least not in the same way, and that's by design/for security reasons (sandboxing). That's why Electron and similar wrappers were created, to enable Javascript/Web graphics to be used to build desktop apps.

Benefits:
Native Features: Access to system-specific features like file system, notifications, and hardware capabilities.

Offline Functionality: Ability to design apps that can work even when not connected to the internet.

Improved User Experience: A more seamless experience for users who can launch the app directly from their desktop.

Offline...the wrapped in Electron .app loaded offline from M.2 SSD that HyperTalk interpreter loads instantly for me.

Of course I'm not at all against running a stack in a regular web browser if a native thing or system APIs sorts of things are not needed, or if a web-app-to-native-app wrapper is not available for a given platform.

Plus, the example above makes it non-cross-platform (mac-only) which kind of defeats the point of doing a browser-based version?

It's all very clever having it in a wrapper - so it resembles a Mac-App, but that detracts from the cross-platform aspect of it.

Electron (and NW.js and others like them ) is available for Mac, Linux, Windows. Chromium has been ported to various platforms so I'm sure there could be wrapper apps for OSes like Haiku or whatever. Many mobile apps already are just thin wrappers around web apps. It should look native to Linux for UI elements when running the Linux Electron app version, same for Windows version. There will be some things that are platform specific, same as there already is in OXT engine. Like for example you there is a JS interface to control the 'Dock' Icon/menu in the Mac version, that obviously wouldn't do anything on Windows were there is no 'Dock'.

I don't even know if it would be possible to obfuscate html and javascript (and still have it functioning properly), so the only way to do that (as mentioned elsewhere) is to cover it with a restrictive license.

With HTML and Javascript traditionally being an interpreted scripting language (just like xTalk script) it is going to be readable by people who dig into the app and know enough javascript and enough about transpiling, BNF, etc. to understand what it's doing. I'm not sure if there's any way to make it more opaque, other than using some sort of byte-code compilation process (.wasm).

You can license your original works however you like. I would prefer a very liberal license (like MIT, which I think is Electron's license) but GPLv3 (as used by OXT IDE) or similar I think are good in that they ensures it con be used freely, maintains original it's copyright notice, and that it remains open-source.

Dan's HC sim has a very simplistically worded license attached it's free to use, must keep the copyright notice, but only for non-commercial use otherwise contact him. We can of course read all of the JS source code for it, and the importer script and learn from the code (the importer is php I think, but I beleive I could port the HC stack importer to OXT script).

[tperry2x]

I know these are probably rhetorical questions, but:

Can the browser create a new custom menu bar or 'system tray' item?...

No

Can the browser directly read files in some folder on your local drive (not a web cache) without user initiated (or simulated) interaction?...

Yes

Can a web page run shell scripts?...

Yes, depending on OS & browser version

Can a web page run Node modules...

Yes

Can a web page run stuff like react-native or how about foreign code libraries?...

Yes, via extra JS plugins.

Can a web page communicate with another web page (or inter process communication), or launch a sub process or slave-app?

It used to be able to, but this has largely been squashed.

Dan's HC sim has a very simplistically worded license attached it's free to use, must keep the copyright notice, but only for non-commercial use otherwise contact him. We can of course read all of the JS source code for it, and the importer script and learn from the code (the importer is php I think, but I beleive I could port the HC stack importer to OXT script).

Yes, I want to keep my implementation as open as possible. I'll no doubt use something very similar to Dan's license. No need for pages upon pages of legalese.

[OpenXTalkPaul]

I know these are probably rhetorical questions, but:

Well yes, but I try to always stay open to the possibility that I'm wrong about something. And it it's these cases, it could even make things easier for a running as a web app without a desktop wrapper.

Can the browser directly read files in some folder on your local drive (not a web cache) without user initiated (or simulated) interaction?...

Yes

Can a web page run shell scripts?...

Yes, depending on OS & browser version

Can a web page run Node modules...

Yes

Are you sure about these? I mean without turning on the browsers developer tools options (lie disabling 'local file restrictions'). If a browser has these capabilities enabled by default that seems like it would be serious security risks right there.
And Node JS libraries often come in a web version and a desktop version, I'm sure there's reasons for that.

Can a web page run stuff like react-native or how about foreign code libraries?...

Yes, via extra JS plugins.

I'm talking about as-is, by default, because you can't ask a user to install a JS plugin, but you could include a web plug-in inside your desktop app packaged version, probably. In the past I've used Jazz-MIDI-Plug-in (installed into the System) and the Browser Widget to enable cross-platform MIDI instrument I/O, and that worked OK but people said it didn't work when I released a demo of it (because they didn't 'read the docs' that said you needed a browser plugin installed)

Can a web page communicate with another web page (or inter process communication), or launch a sub process or slave-app?

It used to be able to, but this has largely been squashed.

As it should be squashed, for the same reason I doubt some of those other assertions.

Dan's HC sim has a very simplistically worded license attached it's free to use, must keep the copyright notice, but only for non-commercial use otherwise contact him. We can of course read all of the JS source code for it, and the importer script and learn from the code (the importer is php I think, but I beleive I could port the HC stack importer to OXT script).

Yes, I want to keep my implementation as open as possible. I'll no doubt use something very similar to Dan's license. No need for pages upon pages of legalese.

I would prefer very liberal license. I'm more incline to try to help with that, but any FOSS license is good too. I don't want an xTalk author's scripts to be entirely dependent on, or otherwise permanently tied to the xTalk interpreter being used, that's what we currently have if the scripts use any syntax or feature that's only available with the MC/RR/LC/OXT engines. If you want to free your stacks/scripts work from that 'legacy' engine's GPLv3 license agreement, then your stacks/scripts must NOT be dependent on that particular interpreter to be functional. In order to detach our work from that legacy, we need to build an OXT-dialect compatible 'engine', ultimately that is what I want.