Thoughts on Livecode Server

[Richard Gaskin]

David Bovill wrote:

 > I want to be able to use standard javascript libraries where they
 > are available and not have to code every library myself in Livecode.

Practical, even smart.  But disappointing. :)  It would be super-cool if 
we had time to rewrite those in native LC, so the body of code in our 
community grows.  But I can't argue against the practicality of not 
reinventing every wheel.


 > So the main requirement - I think - is for practical Javascript
 > interoperability on the server side. Ideally we could just "do
 > javascript" in the server environment, and load whatever node modules
 > we want to do their thing in Javascript = Livecode server extensions
 > written in Javascript.
 >
 > Based on your feedback that we can use "the template xxx" or a stack
 > with a widget and execute these in the server environment - the
 > thought is that "do as javascript in browser" would do the job here...

Embedding an entire browser application into a GUI widgets seems an 
expensive way to execute JavaScript.  On the desktop we have little 
choice, but in a Node.js environment isn't there some way to pass JS off 
to Node for evaluation?

Whether through command line or sockets or whatever else Node may 
provide, since it already has a great JS interpreter it would seem a 
shame to introduce a second one just for LC.

Moreover, I'm not sure the embedded browser app has options for running 
facelessly; designed for GUI rendering, I would expect it requires GUI 
libs not normally present on servers.

We sometimes get spoiled by LC's GUI-agnostic design, where a simple -ui 
flag turns a GUI system into CLUI.  I'm not sure browser vendors provide 
that.

I don't have enough experience with Node.js to point toward a solution, 
but I suspect that a JS-based environment has options for evaluating JS.

If simpler methods like a command-line call to Node aren't available for 
that, I would imagine any API it has can be accessed from LC Builder.



 > The other strategy is basically a web assembly (WASM) take on the same
 > issue. WASM promises (AFAIK) a medium term strategy not just for
 > creating elements in the browser - but also for creating applications
 > based on gluing together various wasm components that could be
 > authored in different environments / languages.

Apparently WASM is available in Node.js, so once you work out how to 
exchange calls between LC and Node I'd guess that could include WASM code.



 > Related to this approach could be a stop-gap experiment where we
 > create a javascript server in node / vue - that loads a Livecode
 > engine and modules based on emscripten export.

I would be disinclined to use an interpreted version of the LC engine 
while a machine-code compiled version is available.

Maybe I'm not seeing the vision there, but I can't see the advantage of 
using a version of the engine which can only execute more slowly and 
require more RAM than the compiled version we already know and love.



 > From my perspective I'm looking to develop some slow applications over
 > a 3-5 year timescale - from that perspective a LAMP / cgi style
 > solution looks like it might be a question of running an emulator :)

Maybe.  Half a decade is a long time; so much can happen.  Emulators are 
good where emulation is needed, but it's hard to beat the horsepower of 
machine-native code.


 > I also need a positive path / argument for investing more in Livecode
 > long term - so having a clearer picture about where the whole open
 > language / emscripten / wasm / server strategy is going would give me
 > a warm feeling inside. It's also kind of interesting :)

Very interesting.  Perhaps Mark Waddingham will be in a position to tip 
his hand about future options.

For client-side work I would imagine the Emscripten team already has 
WASM output, so LC would likely be able to use that output with little 
work from the LC team, at least for those browsers that support WASM at 
this time.


For the bigger question about justifying investment in LC, there are so 
many factors there that for myself I consider it almost entirely 
subjective, and often positively favoring LC in that regard.

If developers were to choose languages based only on popularity rather 
than features, there would be only one.  But we have hundreds, with new 
ones invented every year.

Ruby was a nearly-forgotten niche project that enjoyed an explosion of 
interest only after some clever team outside of the Ruby core project 
decided to invest in building a framework unique to that language they 
called Rails.

There's always the chance that a sufficiently-compelling toolkit will 
emerge in our community, based wholly in LC as Rails is on Ruby, where 
the benefits are so self-evident it takes off as rapidly as RoR did.



An arguably space-cadet-but-maybe-not PS:

I'm still not over the grace and utility of delivering stack files over 
HTTP.

There's something almost magical about being able to deliver a 
native-app experience with all the flexibility of HTTP delivery, all in 
a compact binary stack file that can be sent compressed over the wire 
with glorious ease, unencumbered by the confines of an ordinary HTML 
browser.

I don't think we've seen the end of that yet.  Right now it may seem a 
solution in search of a problem, but once the right problem is 
discovered it just might be the thing that turns more than a few heads 
toward LC...


Sometimes being an island without universal interoperability is a 
feature rather than a bug, a universe of private graynets where 
collaboration happens outside the indexable Web with more freedom and 
fluidity than conforming to existing standards designed for general 
public consumption.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com