Thank you, Andre, for you wisdom. What I take from your comments is if I want 
to develop dynamic interactive web based apps with Livecode, I should get up to 
speed on JavaScript and will need to either use Livecode to generate html5, 
compiled with webAssembly, or find another platform to develop the software.

Perhaps this topic is an idea for a short book (hint, hint).


William Prothero

> On Jan 20, 2021, at 8:03 AM, Andre Garzia via use-livecode 
> <> wrote:
> WebAssembly (aka WASM) is not a silver bullet. It is not something like
> "you compile to WebAssembly and then PROFIT".
> WebAssembly and ASM.js (which is what the current HTML5 LC Runtime uses)
> are very similar. The advantages of WASM is that it is a lot smaller –
> since it is bytecode and not strings in source code – than ASM.js, also, it
> can be streamed so you can start loading it in the VM before it finishes
> transferring. Given the same source code in WASM and ASM.js, the WASM one
> will transfer and load faster, but that is it. One of the main objectives
> of WASM was to reduce latency between the beginning of the load action and
> having something running.
> WASM backends have been integrated in many languages – mostly notable LLVM
> – which means that is somewhat doable to compile C/C++ code to WASM. That
> doesn't mean that all libraries work. WASM has no graphics part. It deals
> with memory and integers (floats?). It doesn't even have a string type. It
> is basically a small assembly language to be targeted by compilers.
> Apps made with WASM do not work with just 100% WASM. You always need JS.
> JavaScript is the glue that links DOM, events, and WASM. What you usually
> do is have a bunch of JS and then speed up some parts of that code with
> WASM. WASM can't touch the DOM, WASM can't handle input events. JS and WASM
> are built to complement each other.
> Most languages targeting WebAssembly deployments have their own "JS
> Standard library toolkit" so that when you compile, you end up with a
> combination of WASM and JS files (maybe even HTML).
> The benefit for LC would be a smaller runtime and faster loading, both are
> great.
> Just don't believe it is something magical like we were promised in the 90s
> with Java Applets that you'd compile your Java App and it would magically
> load on the Web. That is not how this works.
> If you want to learn more about WebAssembly go to the learning area of MDN
> WebDocs:
>> On Wed, 20 Jan 2021 at 15:53, Andre Garzia <> wrote:
>> So,
>> Displaying bundled content only (or mostly) allows Apple's static analysis
>> tools to take a look at your app. They can also identify outgoing
>> connections, so they know if you are opening remote pages. If all you do is
>> display local content, and there is no outgoing connections, then security
>> analysis of your app is easier (also, it works offline from the start which
>> is good). This is not an infalible system, but it works for the average
>> case.
>> As for having an app, that displays external webpages which allow you to
>> buy stuff might be a violation of Apple TOS. That is why you don't buy
>> Kindle books on the Kindle app on iOS. Amazon doesn't want to give Apple a
>> cut. An app that advertises itself as a browser has more leeway with this
>> than others. For example it is OK for Mozilla to ship "Firefox" (not really
>> Firefox, more like mozSafari) in iOS even though you can open web pages and
>> buy stuff with it. It is not OK for you to create an app that opens your
>> webstore and sells stuff.
>> I'll write another message about WebAssembly...
>> On Wed, 20 Jan 2021 at 12:22, Mark Smith via use-livecode <
>>> wrote:
>>> Thanks Kee, but I am a bit puzzled by the restriction.
>>> That would require complicity from the businesses, which if reputable
>>> would be a stretch, no? For example, if I had an app that linked to course
>>> selections on University websites, are they going to suggest that these
>>> could be portals to pedophile shopping sites by entering a secret pass
>>> phrase? By the sounds of it, please correct me if I am wrong, no iStore app
>>> can link to a website for content regardless of the status of the
>>> organization that stands behind the site? Hmmmm, I still have a lot to
>>> learn in this space.
>>> Are there any links available to guidelines that describe these
>>> limitations?
>>> Thanks
>>> Mark
>>>> On Jan 20, 2021, at 4:25 AM, kee nethery via use-livecode <
>>>> wrote:
>>>> An app to web content is a mystery app. Your restaurant review app that
>>> pulls from the web could easily be transformed into a pedophile shopping
>>> app by entering a secret pass phrase and then changing the data on the web
>>> site. (as an extreme example)
>>> _______________________________________________
>>> use-livecode mailing list
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>> --
>> <>
>> Want to support me? Buy me a coffee at
> -- 
> <>
> Want to support me? Buy me a coffee at
> _______________________________________________
> use-livecode mailing list
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to