Questions on Wasm export, licenses and file siz

[ambassador at fourthworld.com]

David Bovill wrote:
> With the old JavaScript export you had a separation between the engine
> and stacks such that you could cache the engine part in the browser to
> speed up the loading of the much smaller stacks. Is that the case (or
> it is intended to be the case in the future) with the wasm export?

A couple years ago Andre outlined the differences between JS and WASM, worth reviewing:
https://www.mail-archive.com/use-livecode%40lists.runrev.com/msg111108.html

With your background you're probably well aware of the differences, but since we see so many conceptualizing WASM as "compiled JavaScript" it's worth taking a moment to review their respective boundaries.

Given that WASM has no direct access to the DOM, and therefore no direct manipulation of controls or events, it is not a drop-in replacement for JS.

In LC terms, it may be best to think about WASM's relationship to the browser as similar to what externals are to LC.

Of course externals are very powerful; most of the v8 bullet points were new externals. But they still need LC Script to interface with our apps.

The degree to which LC Ltd will be able to compile the whole engine into WASM is a good question, but it seems clear it will be limited in some ways, and it's unlikely we'll see compilation of LC Script to WASM for the foreseeable future.

The good news is that the LC Community has a growing body of knowledge around JavaScript: some of the cooler widgets are just wrappers around a browser instance running JS/HTML/CSS.  And given the vast amounts of web-native (JS/HTML/CSS) code out in the world, folks are continually finding new ways to integrate the native web stack with LC stack objects nicely.

If web deployment is the goal, I see no downside and much to be gained from spending more time practicing JavaScript. While different from xTalk, it's a good language, and arguably closer to what xTalk might have looked like if HyperCard premiered 10 years later than it did.

Being comfortable with JS means being able to fill in gaps between your LC work and LC's web export more easily, and even within LC today it's the gateway to vast components via the browser widget.

JS is the only interactive language included in browsers.  The best time to learn it was yesterday. The second best time is today.

Like AppleScript, PowerShell, bash, and others, learning other languages opens new doors for integrating LC across a wide variety of systems.

Bonus: the more you learn JS, the less you need to wait for with the feature completion in LC's web export.

As for your question about deployment size, we can expect a WASMified engine to be smaller than its JS version, but there are so many factors that go into that it may just be too early to tell.

If you do a web search for "WASM replace JavaScript" you'll not only get deeper discussions than what I've offered here, but also some confounding benchmarks where it's possible to have compiled WASM larger than the source code, and sometimes only slightly small, and then some amazingly smaller.  So much will depend on so many implementation details...

--
Richard Gaskin
Fourth World Systems