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

Reply via email to