LiveNode Server

[Mark Wilcox]

This is an interesting thread. Let me add a few comments:

The CGI / FastCGI thing is a red herring. CGI is slow and so is FastCGI.
:)
Slighter faster options (e.g. for things like PHP and Python) implement
the language runtime via a plugin module to the web server.
However, things like Node.js and Go are fast because they don't have
Apache or similar in the way. I once saw a presentation by a guy that
had built the most carefully optimised (and very popular) HTTP proxy in
Python and then discovered that a very simplistic implementation with
Node.js was more than an order of magnitude faster. This was because
Apache was out of the loop, not because JavaScript is so much faster
than Python (it is faster but nowhere near that much).

Now Apache and other web servers are really good at serving up files but
these days we often want to build APIs. If you've got static files
you're better off putting them on Amazon S3 or similar. For getting a
chunk of JSON querying a database and spitting some more JSON back the
other way you're better off with something architecturally like Node.js.
The fact that the whole ecosystem has been forced to do everything
asynchronously is a big help. JavaScript and its single threaded nature
are not virtues here but not a fatal handicap either. Someone mentioned
Meteor.js - that's built on Node.js but they actually use Node Fibers,
basically lightweight threads (that have to yield explicitly - no
pre-emption) - it makes the code a whole lot more readable.

Not having real threads is bad when it comes to processor intensive
operations but Node.js got a very long way without them and I think a
Node-like LiveCode server could too. It would need to have proper
asynchronous I/O everywhere though and that's not trivial from where we
are now. It is definitely a project worth pursuing if anyone has the
time. The quickest way to get their might be to integrate libevent (as
used in Chromium) rather than libuv (as used in Node.js) because it
comes with DNS, HTTP and SSL support - you really want all of those in
the C/C++ layer, not implemented in LiveCode on top of a raw socket . It
might not be the best way overall but alternatives probably involve
quite a lot more work.

Adding something like blocks in Objective-C (very closure-like), or
Node's TAGG, to enable real multi-threaded programming but limited to
avoid all the usual thread synchronisation headaches would also be
fantastic for LiveCode but another big chunk of work. There didn't seem
much point in even looking at any of these things while the engine was
undergoing a major architectural overhaul but maybe things are starting
to stabilise enough now that it'll make sense to think about them again
soon.

Mark

-- 
  Mark Wilcox
  mark at sorcery-ltd.co.uk

On Wed, Apr 8, 2015, at 02:47 PM, Andrew Kluthe wrote:
> To clarify just a little bit further. The code and objects weren't
> holding
> onto memory, the variables used in that code were due to weird scoping.
> Big
> chunks of db results, etc that persist after I've already done my
> business
> with them and tried to move on.
> 
> If I can recommend a book on Javascript, I can't speak highly enough of
> the
> insights given by  "JavsScript: the Good Parts" from O'Reilly. He
> provides
> some history behind some of the design choices in javascript and some of
> the problems still being worked around today in regards to the bad parts.
>