David Bovill wrote:
> WASM support is very important to Livecode future. It will address
> most of the problems of current HTML5 deployment
WASM will definitely benefit the two most visible issues, load time and
performance.
Performance is an unqualified benefit, but with load time the benefit
with web use is minimal, since the engine is re-downloaded nearly every
time the user visits your site (unless of course yours is the only site
they visit, so cache never purges).
While an OS-native app is downloaded once, the impact of download times
on web apps is multiplied by frequency of use.
In compiled object code the LC engine ranges from about 17 MB (Win) to
32 MB (Mac). Assuming the WASM export comes closer to that, it's still
outside the short patience most end-users have acquired for public sites.
Can still be quite good for specialized audiences who understand up
front the value of waiting for what you're delivering. But where a
priori buy-in is that deep I find those audiences often equally
amendable to a one-time download of a desktop app.
That said, even with improvement on the most immediately-visible issues,
switching interpreters from JS to WASM can't address the less visible
ones we discover only after we commit to that path. We're still stuffing
a desktop object model and functionality into an HTML Canvas object
inside of a browser application.
As I wrote in a recent forum thread on a related subject:
And even if the size and speed impediments could be overcome
affordably, then what? Given that the desktop and the browser
are such fundamentally different platforms, the vision of
exporting an existing desktop app to the web is impractical
from a design standpoint alone. File I/O, windowing, menus,
OS integration, layout flow, etc. - all vastly different, some
non-existent on the web altogether given its vastly different
role.
https://forums.livecode.com/viewtopic.php?f=120&t=25210&start=75#p190586
Emscripten-based export can be good for some use cases. But I'd wager
that the number of use cases where it's an ideal fit is the same or
fewer than those where a net-savvy OS-native app would also be welcome.
For all the popularity of the web, native apps haven't gone away. They
are different animals.
> and I definitely intend to use it - for micro service deployment, and
> blockchain integration for instance.
I have a friend who's been nudging me to spend more time with
blockchains. Please keep us posted. I'll be interested to learn how
much of the business logic is in the client and how much is on the
server. So many options there...
> It will doubtless be a commercial feature
Oh dear I hope not. It's too easy to be attracted by a shiny nickel
today at the cost of a dollar tomorrow.
LiveCode as a product has its fate bound by LiveCode as a *platform*.
Unless we want to limit its audience to mostly retired HyperCard fans,
we'll need to encourage a reconeptualization of the role of the
Community Edition in platform-building.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.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
