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