Re: HTML Platform

[Richard Gaskin via use-livecode]

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=25210=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.comhttp://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

Re: HTML Platform

[Mark Waddingham via use-livecode]

On 2020-05-06 18:40, Richard Gaskin via use-livecode wrote:

And mySQL from LC in the browser is tonnes faster than on the desktop
- massively! Because they’re both on the same server. Even though the
message path is LC>JS>(AJAX)>PHP>JS>LC!


I suspect there's something going on there that can be remedied.  As
you noted, compiled object code should be faster than interpreted
JavaScript.  In every other respect the calls should be the same, so
throughput should be faster in the OS-native implementation.  If it's
not let's review that to bring it up to speed.


This isn't true - any thing which involves communication to a remove 
server is dominated by transit time of the data - code on either end 
doing the marshalling will make little difference (regardless of how it 
is implemented).


The only thing I can think of is that the data being sent both ways is 
being compressed - as there are HTTP facilities to make that 
transparent. In contrast, the standard socket protocol of MySQL does not 
compress data so more is transferred. (This is assuming the comparison 
here is direct-socket-connnection-in-LC against 
HTTP-based-requests-from-HTML5-LC-in-browser).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: HTML Platform

[Richard Gaskin via use-livecode]

Pi Digital wrote:

> Richard wrote:
>> But most apps that might make good candidates for LC's HTML export
>> have characteristics that lend themselves very well to not doing HTML
>> at all, instead using a one-time download of an LC standalone which
>> then downloads and runs stack files (a practice that, in the absence
>> of a more common label, I like to call "streaming apps").
>
>
> Two words, Richard.
> IT Departments.
> Of the 150+clients my client has, 150+ of them would emphatically
> prefer a web based app than a desktop one. They don’t want stuff
> ‘installed’ or ‘run’ on their machines that haven’t been thoroughly
> tested before use. Each and every update. And they really don’t want
> to have to keep testing each and every update. Using Chrome/Edge-
> Chromium overcomes all of that.

I hear you loud and clear on that, Sean. I've run into that myself 
(humorous anecdote below).


In the subset of cases where IT is absolutely forcing the entire 
enterprise to ditch OS-native apps in favor of browser apps, there's 
little you can do to stop that.


And where the limitations inherent in any Emscripten-based solution pose 
no impediment to functionality, why not?  You'll still need to do 
significant rework of the stack to meet user expectations (e.g. more 
than half of all net traffic is on mobile devices so responsive design 
has become a common expectation for web apps), but where Emscripten does 
what you need by all means use it.


There is no one-size-fits-all for any of the work each of us does.  We 
evaluate the needs of our audience and make our deployment choices 
accordingly.



But the advent of the web hasn't killed OS-native apps.  The Mac app 
store is filled with them, and they remain a mainstay throughout 
organizations big and small.


Indeed, even the rise of the cloud hasn't killed off OS-native apps, but 
simply validated the "streaming app" model with the popularity of 
net-savvy apps like Adobe's Create Suite, Microsoft's Office 365, and 
Apple's iTunes.


An OS-native app allows a level of integration with common OS services 
and workflows difficult or impossible to achieve in the confines of a 
browser window.


Extra bonus points that it's also often a better overall user 
experience, and far cheaper to build and maintain in the LC we know and 
love.




> And mySQL from LC in the browser is tonnes faster than on the desktop
> - massively! Because they’re both on the same server. Even though the
> message path is LC>JS>(AJAX)>PHP>JS>LC!

I suspect there's something going on there that can be remedied.  As you 
noted, compiled object code should be faster than interpreted 
JavaScript.  In every other respect the calls should be the same, so 
throughput should be faster in the OS-native implementation.  If it's 
not let's review that to bring it up to speed.




--
Aside: A Humorous Anecdote about working with Corporate IT

I was once a partner in a company that deployed a networked app which we 
delivered to institutions on CD-ROM.  As we told customer IT, we 
designed it for their convenience, so installation is simply copying a 
folder from the CD-ROM to a shared volume.  That's it.


IT at one facility didn't believe us.  They were up to their armpits in 
lesser tools than LiveCode, they were unable to conceive of a true 
standalone, accustomed to apps that spew DLLs all over the hard drive 
and then also require mods to their firewall.


They insisted we produce an Installation Guide.  We did.  It was one 
paragraph describing how to copy a folder from a CD to a shared drive, 
with the rest of the page being an illustration of doing that.  They 
were fully satisfied with that deliverable. :)



Years later we did migrate the consumer portion to a web-native 
implementation (using LC to generate it).  And since the original was 
built in LC, we easily moved a lot of the logic that had been in the 
client onto the server with minimal effort.  More on that in a moment.


We kept the authoring desktop-native, and expanded it into a streaming 
app where it was used by dozens of collaborating authors in offices 
around the world.


Authoring had originally been slated for migration into an existing 
Java-based system the org had built for similar products. The only 
reason for expanding our own authoring system to become multi-user was 
because the IT staff at an acquiring company was so busy with other 
tasks it became more cost-effective to build out ours than to wait for 
IT to catch up on the tasks the org relied on them for.  Great IT staff, 
just busy.  The authoring system written by a single LC dev eventually 
had more features than their similar system built in-house by an entire 
team of Java programmers, and for a much lower cost.



But on the consumer-facing web side, we have one more punchline:

One of the orgs that had insisted on a browser-based version did so for 
the usual reason, the one you noted, the concern for security.  As a 
regional hospital network 

Re: HTML Platform

[Richard Gaskin via use-livecode]

Erik Beugelaar wrote:

> It would be great if a lesson comes available how to create streaming
> apps with LC.

Thank you for your interest.  I'll do that, but it'll have to wait until 
I finish some client projects first.


In the meantime, the beauty of this approach is its simplicity.  Like 
anything else it can be made complicated, but it boils down to:


1. Make a slim standalone that contains just a splash screen and
   only enough code to download a stack file from your server
   (or report a network error if it can't).  "Load URL" is a good
   choice for larger stacks because it lets you display a progress
   indicator asynchronously, but for smaller stack files simply
   "go stack " will work just fine.

2. Put a stack file with the guts of your app on a server.

3. Run your standalone.

It gets even better when you use LC's built-in gZip compression to 
reduce download times.


And better still, you can also cache what you download to support 
offline modes where practical.  Using a small text file on the server 
containing the build number of the stack file there makes it quick and 
easy to check if a fresh copy of the stack file needs to be downloaded, 
otherwise it opens the cached copy.


The beauty of this is that it's neither new nor exotic.  We've been 
doing it since MetaCard first made a one-liner out of HTTP GET with 
libURL back in the '90s.


For a fairly simple example, see LiveNet (in the IDE, Development -> 
Plugins -> GoLiveNet).  That small plugin downloads a stack file that 
includes fields and other containers that are then populated with data 
it pulls from multiple sources, exemplifying both the ease of 
downloading stack files and (hopefully) serving as an inspiration for 
building mash-ups.


--
 Richard Gaskin
 Fourth World Systems



-Original Message-

Mark Wieder wrote:

On 5/5/20 4:47 PM, Trevor DeVore via use-livecode wrote:
 >> I don't use HTML deployment myself, but thought I would mention 
that  >>

there has been some emscripten activity in GitHub lately. Looks like  >>
WebAssembly (WASM) support is being added.
...
 >
 > Yeah, I saw the github posts come flying by, and that's a promising  >
feature, but it doesn't address the limitations and broken features of  >
the current html implementation.

In my own mind I phrase that differently.  Whether it's gentler or more
stark is up to the reader, but for me it's more:

   ...it can't address the fundamental differences between desktop
   and web architectures, and the limitations inherent in Emscripten.

Emscripten is good for what it was designed to do.  But look deeply at LC,
consider what Emscripten is, and the more time you spend pondering it the
clearer it becomes how difficult it is to put a desktop app's square peg
into a browser hole.

"Difficult" is maybe unfairly optimistic. And "impossible" never applies to
software. Perhaps "prohibitively expensive" is fair.


 > Also, it remains to be seen how much bloat this adds to deployed web
 > apps.

Putting an entire scripting engine and object model into a browser
application that already has its own scripting engine and object model
cannot achieve size, performance, and integration features as well as a
web-native implementation.

If you truly need a browser as your only deployment option, it's kinda
hard to argue against going with the grain of the browser.

But most apps that might make good candidates for LC's HTML export have
characteristics that lend themselves very well to not doing HTML at all,
instead using a one-time download of an LC standalone which then
downloads and runs stack files (a practice that, in the absence of a
more common label, I like to call "streaming apps").

Fits most of the same uses cases, but provides a more focused user
experience that integrates with the OS as only a native app can.

Extra bonus points that they're cheap and easy to build in LC, fast
cheaper to deliver sophisticated works than even web-native implementations.

For the sorts of vertical audiences where LC's HTML would seem
interesting, I believe simply streaming stacks in a standalone is the
most underappreciated and underutilized opportunity in our community.

MetaCard promoted the idea heavily with some nice example downloads, but
in all these years only a few of us make streaming apps regularly.

If you're waiting for LC's HTML to get good, let's discuss streaming
apps for those where they might be a great solution.  We really don't
need to wait for anything to have the benefits of net-distributed apps.
You can have it all today, with the LC you know and love already.

--
  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

Re: HTML Platform

[David Bovill via use-livecode]

WASM support is very important to Livecode future. It will address most of the 
problems of current HTML5 deployment, and I definitely intend to use it - for 
micro service deployment, and blockchain integration for instance.

It will doubtless be a commercial feature, which is also important for a 
Livecode feature but as soon as I can play in an equal footing as other high 
level languages - then I can build commercial solutions with project partners 
and universities. Until then I can only really prototype in Livecode.
On 6 May 2020, 11:28 +0100, Pi Digital via use-livecode 
, wrote:
> Two words, Richard.
> IT Departments.
> Of the 150+clients my client has, 150+ of them would emphatically prefer a 
> web based app than a desktop one. They don’t want stuff ‘installed’ or ‘run’ 
> on their machines that haven’t been thoroughly tested before use. Each and 
> every update. And they really don’t want to have to keep testing each and 
> every update. Using Chrome/Edge-Chromium overcomes all of that.
>
> Having built his business over 10 yrs ago with zero coding experience and 
> learning LC from scratch, to now, remaining his only coding 
> platform/language, he wants a way to continue being able to contribute 
> without having to learn a new language while still taking his maaassive app 
> suite onto the web. Emscripten is (part-way to) a godsend.
>
> If only the basics worked as they had before chromium deprecated old event 
> handler syntax. That’s the major crux of its current downfall. Otherwise it’s 
> an incredibly powerful way of coding for the web.
>
> And mySQL from LC in the browser is tonnes faster than on the desktop - 
> massively! Because they’re both on the same server. Even though the message 
> path is LC>JS>(AJAX)>PHP>JS>LC!
>
> Sean
>
> > In my own mind I phrase that differently. Whether it's gentler or more 
> > stark is up to the reader, but for me it's more:
> >
> > ...it can't address the fundamental differences between desktop
> > and web architectures, and the limitations inherent in Emscripten.
> >
> > Emscripten is good for what it was designed to do. But look deeply at LC, 
> > consider what Emscripten is, and the more time you spend pondering it the 
> > clearer it becomes how difficult it is to put a desktop app's square peg 
> > into a browser hole.
> >
> > Putting an entire scripting engine and object model into a browser 
> > application that already has its own scripting engine and object model 
> > cannot achieve size, performance, and integration features as well as a 
> > web-native implementation.
> >
> > If you truly need a browser as your only deployment option, it's kinda hard 
> > to argue against going with the grain of the browser.
> >
> > But most apps that might make good candidates for LC's HTML export have 
> > characteristics that lend themselves very well to not doing HTML at all, 
> > instead using a one-time download of an LC standalone which then downloads 
> > and runs stack files (a practice that, in the absence of a more common 
> > label, I like to call "streaming apps").
> >
> > Fits most of the same uses cases, but provides a more focused user 
> > experience that integrates with the OS as only a native app can.
> >
> > Extra bonus points that they're cheap and easy to build in LC, fast cheaper 
> > to deliver sophisticated works than even web-native implementations.
> >
> > For the sorts of vertical audiences where LC's HTML would seem interesting, 
> > I believe simply streaming stacks in a standalone is the most 
> > underappreciated and underutilized opportunity in our community.
> >
> > MetaCard promoted the idea heavily with some nice example downloads, but in 
> > all these years only a few of us make streaming apps regularly.
> >
> > If you're waiting for LC's HTML to get good, let's discuss streaming apps 
> > for those where they might be a great solution. We really don't need to 
> > wait for anything to have the benefits of net-distributed apps. You can 
> > have it all today, with the LC you know and love already.
> >
> > --
> > Richard Gaskin
> ___
> 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

Re: HTML Platform

[Pi Digital via use-livecode]

Two words, Richard. 
IT Departments. 
Of the 150+clients my client has, 150+ of them would emphatically prefer a web 
based app than a desktop one. They don’t want stuff ‘installed’ or ‘run’ on 
their machines that haven’t been thoroughly tested before use. Each and every 
update. And they really don’t want to have to keep testing each and every 
update. Using Chrome/Edge-Chromium overcomes all of that. 

Having built his business over 10 yrs ago with zero coding experience and 
learning LC from scratch, to now, remaining his only coding platform/language, 
he wants a way to continue being able to contribute without having to learn a 
new language while still taking his maaassive app suite onto the web. 
Emscripten is (part-way to) a godsend. 

If only the basics worked as they had before chromium deprecated old event 
handler syntax. That’s the major crux of its current downfall. Otherwise it’s 
an incredibly powerful way of coding for the web.

And mySQL from LC in the browser is tonnes faster than on the desktop - 
massively! Because they’re both on the same server. Even though the message 
path is LC>JS>(AJAX)>PHP>JS>LC!

Sean

> In my own mind I phrase that differently.  Whether it's gentler or more stark 
> is up to the reader, but for me it's more:
> 
>  ...it can't address the fundamental differences between desktop
>  and web architectures, and the limitations inherent in Emscripten.
> 
> Emscripten is good for what it was designed to do.  But look deeply at LC, 
> consider what Emscripten is, and the more time you spend pondering it the 
> clearer it becomes how difficult it is to put a desktop app's square peg into 
> a browser hole.
> 
> Putting an entire scripting engine and object model into a browser 
> application that already has its own scripting engine and object model cannot 
> achieve size, performance, and integration features as well as a web-native 
> implementation.
> 
> If you truly need a browser as your only deployment option, it's kinda hard 
> to argue against going with the grain of the browser.
> 
> But most apps that might make good candidates for LC's HTML export have 
> characteristics that lend themselves very well to not doing HTML at all, 
> instead using a one-time download of an LC standalone which then downloads 
> and runs stack files (a practice that, in the absence of a more common label, 
> I like to call "streaming apps").
> 
> Fits most of the same uses cases, but provides a more focused user experience 
> that integrates with the OS as only a native app can.
> 
> Extra bonus points that they're cheap and easy to build in LC, fast cheaper 
> to deliver sophisticated works than even web-native implementations.
> 
> For the sorts of vertical audiences where LC's HTML would seem interesting, I 
> believe simply streaming stacks in a standalone is the most underappreciated 
> and underutilized opportunity in our community.
> 
> MetaCard promoted the idea heavily with some nice example downloads, but in 
> all these years only a few of us make streaming apps regularly.
> 
> If you're waiting for LC's HTML to get good, let's discuss streaming apps for 
> those where they might be a great solution.  We really don't need to wait for 
> anything to have the benefits of net-distributed apps. You can have it all 
> today, with the LC you know and love already.
> 
> -- 
> Richard Gaskin
___
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

RE: HTML Platform

[Erik Beugelaar via use-livecode]

It would be great if a lesson comes available how to create streaming apps
with LC.


-Original Message-
From: use-livecode  On Behalf Of
Richard Gaskin via use-livecode
Sent: woensdag 6 mei 2020 08:42
To: use-livecode@lists.runrev.com
Cc: Richard Gaskin 
Subject: Re: HTML Platform

Mark Wieder wrote:

On 5/5/20 4:47 PM, Trevor DeVore via use-livecode wrote:
 >> I don't use HTML deployment myself, but thought I would mention that  >>
there has been some emscripten activity in GitHub lately. Looks like  >>
WebAssembly (WASM) support is being added.
...
 >
 > Yeah, I saw the github posts come flying by, and that's a promising  >
feature, but it doesn't address the limitations and broken features of  >
the current html implementation.

In my own mind I phrase that differently.  Whether it's gentler or more
stark is up to the reader, but for me it's more:

   ...it can't address the fundamental differences between desktop
   and web architectures, and the limitations inherent in Emscripten.

Emscripten is good for what it was designed to do.  But look deeply at LC,
consider what Emscripten is, and the more time you spend pondering it the
clearer it becomes how difficult it is to put a desktop app's square peg
into a browser hole.

"Difficult" is maybe unfairly optimistic. And "impossible" never applies to
software. Perhaps "prohibitively expensive" is fair.


 > Also, it remains to be seen how much bloat this adds to deployed web
 > apps.

Putting an entire scripting engine and object model into a browser 
application that already has its own scripting engine and object model 
cannot achieve size, performance, and integration features as well as a 
web-native implementation.

If you truly need a browser as your only deployment option, it's kinda 
hard to argue against going with the grain of the browser.

But most apps that might make good candidates for LC's HTML export have 
characteristics that lend themselves very well to not doing HTML at all, 
instead using a one-time download of an LC standalone which then 
downloads and runs stack files (a practice that, in the absence of a 
more common label, I like to call "streaming apps").

Fits most of the same uses cases, but provides a more focused user 
experience that integrates with the OS as only a native app can.

Extra bonus points that they're cheap and easy to build in LC, fast 
cheaper to deliver sophisticated works than even web-native implementations.

For the sorts of vertical audiences where LC's HTML would seem 
interesting, I believe simply streaming stacks in a standalone is the 
most underappreciated and underutilized opportunity in our community.

MetaCard promoted the idea heavily with some nice example downloads, but 
in all these years only a few of us make streaming apps regularly.

If you're waiting for LC's HTML to get good, let's discuss streaming 
apps for those where they might be a great solution.  We really don't 
need to wait for anything to have the benefits of net-distributed apps. 
You can have it all today, with the LC you know and love already.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  
  ambassa...@fourthworld.comhttp://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


___
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

Re: HTML Platform

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

On 5/5/20 4:47 PM, Trevor DeVore via use-livecode wrote:
>> I don't use HTML deployment myself, but thought I would mention that
>> there has been some emscripten activity in GitHub lately. Looks like
>> WebAssembly (WASM) support is being added.
...
>
> Yeah, I saw the github posts come flying by, and that's a promising
> feature, but it doesn't address the limitations and broken features of
> the current html implementation.

In my own mind I phrase that differently.  Whether it's gentler or more 
stark is up to the reader, but for me it's more:


  ...it can't address the fundamental differences between desktop
  and web architectures, and the limitations inherent in Emscripten.

Emscripten is good for what it was designed to do.  But look deeply at 
LC, consider what Emscripten is, and the more time you spend pondering 
it the clearer it becomes how difficult it is to put a desktop app's 
square peg into a browser hole.


"Difficult" is maybe unfairly optimistic. And "impossible" never applies 
to software. Perhaps "prohibitively expensive" is fair.



> Also, it remains to be seen how much bloat this adds to deployed web
> apps.

Putting an entire scripting engine and object model into a browser 
application that already has its own scripting engine and object model 
cannot achieve size, performance, and integration features as well as a 
web-native implementation.


If you truly need a browser as your only deployment option, it's kinda 
hard to argue against going with the grain of the browser.


But most apps that might make good candidates for LC's HTML export have 
characteristics that lend themselves very well to not doing HTML at all, 
instead using a one-time download of an LC standalone which then 
downloads and runs stack files (a practice that, in the absence of a 
more common label, I like to call "streaming apps").


Fits most of the same uses cases, but provides a more focused user 
experience that integrates with the OS as only a native app can.


Extra bonus points that they're cheap and easy to build in LC, fast 
cheaper to deliver sophisticated works than even web-native implementations.


For the sorts of vertical audiences where LC's HTML would seem 
interesting, I believe simply streaming stacks in a standalone is the 
most underappreciated and underutilized opportunity in our community.


MetaCard promoted the idea heavily with some nice example downloads, but 
in all these years only a few of us make streaming apps regularly.


If you're waiting for LC's HTML to get good, let's discuss streaming 
apps for those where they might be a great solution.  We really don't 
need to wait for anything to have the benefits of net-distributed apps. 
You can have it all today, with the LC you know and love already.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: HTML Platform

[Mark Wieder via use-livecode]

On 5/5/20 4:47 PM, Trevor DeVore via use-livecode wrote:


  I don't use HTML deployment myself, but thought I would mention that there
has been some emscripten activity in GitHub lately. Looks like WebAssembly
(WASM) support is being added. You can see the commits here:

https://github.com/livecodeian/livecode/commits/feature-emscripten-llvm

And here is the specific commit with the README:

https://github.com/livecodeian/livecode/commit/11dd134996f441abbbc802dba64c760ec800a10e



Yeah, I saw the github posts come flying by, and that's a promising 
feature, but it doesn't address the limitations and broken features of 
the current html implementation. Yet, at any rate. Also, it remains to 
be seen how much bloat this adds to deployed web apps.


These may be of interest:
https://floooh.github.io/2017/06/09/webassembly-demystified.html


--
 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

Re: HTML Platform

[Trevor DeVore via use-livecode]

On Tue, May 5, 2020 at 4:03 PM Pi Digital via use-livecode <
use-livecode@lists.runrev.com> wrote:

> ...
> Because LC HQ seems uninterested in further development of the HTML
> platform and recent eco issues my client is rethinking if this is the best
> way to go. As it stands it does seem high-risk that it becomes outright
> abandonware in terms of HTML deployment. I’m on tender hooks whether we
> will continue development given this lack of LC HQ interest.
>

 I don't use HTML deployment myself, but thought I would mention that there
has been some emscripten activity in GitHub lately. Looks like WebAssembly
(WASM) support is being added. You can see the commits here:

https://github.com/livecodeian/livecode/commits/feature-emscripten-llvm

And here is the specific commit with the README:

https://github.com/livecodeian/livecode/commit/11dd134996f441abbbc802dba64c760ec800a10e

-- 
Trevor DeVore
ScreenSteps - https://www.screensteps.com
Levure App Framework for LiveCode - https://github.com/trevordevore/levure/
LiveCode Repos -
https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos -
https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
___
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