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