Questions on Wasm export, licenses and file siz

[David Bovill]

Hi Richard specifically I need to know if I create an web page with
multiple HTML5  export embeds whether the Livecode wasm approach forces the
engine to be exported multiple times.

On Thu, 12 Oct 2023 at 17:09, ambassador--- via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>