Lets take the following scenario: 1) We have a library of interactive components created in Livecode. They are structured as (Levure) components. They could be turned into script components easily, or LCB based components with a little more work. 2) We wish to compose a series of apps based on these components in which 3-15 of them interact with each other on any given screen. 3) We can prototype and deliver these apps in a Livecode based prototype. 4) There is a project need for an advanced architecture that engages the enthusiasm of University students and the wider developer community. We therefore require a strategy that enables developers in a range of modern language - particularly rust, javascript and python to participate. 5) It is a long term project - so we can take out time and wait for technologies to mature. However we wish to deliver rapid prototypes that can be tested with communities in the short term.
Given the above I’d like to be able to prototype the software(s) by exporting these Livecode (Levure-style) components as wasm - and embed these on web pages in which they communicate with each other securely. Components that need speeding up, or reduced in file size once tested may be rewritten eventually in another language. My concern is: - having several wasm components on a single web view will involve multiplying the quite large engine download for each component? - which licence will be required so that these wasm components over the duration of the project? On Thu, 12 Oct 2023 at 20:16, David Bovill <david.bov...@gmail.com> wrote: > 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@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@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > _______________________________________________ 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
