It has substantial and wide ranging implications - all to the good. At the very least 'WASM' is more compact than asm.js and eliminates the compiling overhead which you have when you load a text based representation of the language.
We've got a fair bit of housekeeping to do (particularly in our build system) to be able to start leveraging it, but it is a case of when and not if. Warmest Regards, Mark. Sent from my iPhone > On 2 Jun 2017, at 07:53, Dan Brown via use-livecode > <use-livecode@lists.runrev.com> wrote: > > A bit OT but there's an interesting discussion here > https://news.ycombinator.com/item?id=14458648 on the merits of WebAssembly > vs JavaScript for in browser applications. As WebAssembly matures it will > be interesting to see what implications (if any) it has for livecode html5 > i.e. will it ultimately become a better fit > > > On 2 Jun 2017 3:08 am, "Andre Garzia via use-livecode" < > use-livecode@lists.runrev.com> wrote: > >> What I believe BR was referring to is that we can expose LC handlers to the >> local JS context of a browser widget thus enabling liveCode.* calls. What >> would be good, was to have functions (synchronous ones for the sake of >> complexity) exposed as well so that calling a liveCode.* function from JS >> on a browser widget not only would trigger the function but also return the >> results. >> >> Right now, we need to play musical chairs where JS calls a liveCode.* >> handler, which doesn't return anything but executes, then the said handler >> execute something in the JS context which is essentially a callback thus >> forcing every call into an async call. I know pretty well how async JS >> world is but even if we could simply have synchronous functional calls >> there it would be awesome and open a whole new world to customized >> experiences. >> >> On Thu, Jun 1, 2017 at 9:50 PM, Mark Wieder via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >>> On 06/01/2017 04:59 PM, Monte Goulding via use-livecode wrote: >>> >>> Why not check for CopySpecial() if the object is a widget before passing >>>> to the owner? It makes more sense that the library handler a widget >> exports >>>> is part of the message path. That way we can dispatch to the instance >> and >>>> the instance can overload/override it if they want necessary. >>>> >>> >>> +1. I like the way you think. >>> >>> -- >>> Mark Wieder >>> ahsoftw...@gmail.com >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> http://www.andregarzia.com -- All We Do Is Code. >> http://fon.nu -- minimalist url shortening service. >> _______________________________________________ >> 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 _______________________________________________ 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
