Why is node.js faster than LC server?

[Andre Garzia]

IMHO opinions it is not fair to compar NodeJS and LC Server on merits of
performance because they are really different beasts, I will try to digress
a little about why I think this below.

NodeJS is the union of two things, one of which is the lightning fast JS
Engine from Google called V8 and the other is libuv for handling events.
This works well because JS has always been an asynchronous language on the
front-end. This leads to a programming style that is not as straight
forward as the one we're used. We had the "callback hell" in JS for a long
time where the request for doing something was decoupled from the response
of that call, it worked well but it was hard to follow. That was made
easier with the introduction of "Promises" which you may know as "Future"
from other languages which made the asynchronous flow more explicit and
easy to follow and now finally there are async/await calls like the ones
from C#. All this changes both inside the language itself and on top of it
in form of syntatic sugar serves one purpose only, give the developer good
ergonomics while keeping the code asynchronous/non-blocking.

LiveCode is not an asynchronous language. It has some APIs that work
asynchronously when we want them to, but it is not a non-blocking engine.
All our "PUT URLs" calls are blocking, which is one of the reasons that
early attempts (or toys like the ones I built) to ship an LC based Web
Server suffer from an easily DDOS architecture. Languages don't need to be
non-blocking or asynchronous to be good. LC is good. NodeJS is also good.
They are not necessarily good for the same stuff though.

Also remember that NodeJS uses V8 which along with Mozillas own
SpiderMonkey engine has strong JIT features and can basically compile your
source at runtime into x86 instructions (at least the hot parts of the
code). There are millions invested in JS engine, both in terms of money and
in terms of developer-hours. It is not something easily replicable unless
of course you're a robot from the future like Mike Pall is and build LuaJIT
alone (an engine that for a long time outperformed every other JIT engine).

Your original email about scaling anything to millions of users doesn't
outline some needs of working at that scale. Most of us don't work on that
scale. That kind of scale, is the kind where people start looking at how a
database places stuff in RAM so that fetches are easier by just multiplying
funky pointers, the kind of scale where a node balancer and a devops team
on call is necessary just for your development server to be alive and
useful.

LC Sever works pretty well if you have thousands of users, you just need to
be able to shift some gears and use the client-side of the web better. A
PWA that talks with an LC Server will require much less power on the
server-side than a server rendered one like what we usually build here. If
you have millions of users, then you can scale horizontally by adding more
servers...

On Mon, Dec 4, 2017 at 3:13 PM, Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:

> jonathandlynch wrote:
>
> > Thinking about this further...
> >
> > Could we set up LiveCode to run on a VPS, so it is always live and
> > listening to a port. When a request comes in, it would use TSnet to
> > send an asynchronous request to a local database. When TSnet gets the
> > callback, it passes the data back to LC, which processes it and passes
> > the information to the user through the port.
> >
> > This would always be asynchronous and thus never get hung up waiting
> > for a long request. It seems like it could be quite fast. Would that
> > work?
>
> I don't even think we'd need tsNet for that.  Sockets should suffice for
> communicating between backend services, and using the "with messages"
> option makes them async; indeed that single-threaded message-driven
> approach is a big part of what makes Node.js so performant, offloading as
> much as practical from the process thread to the OS.
>
> A while back Pierre Sahores posted some benchmarks here related to these
> sorts of explorations, generally quite flattering to LC.  Of course the LC
> engine is made by a small team in Edinburgh while JS has millions opf $
> invested from some of the largest companies in the world, so we may want to
> temper expectations of comparative performance accordingly.  But for a wide
> range of workloads, LC-based daemons can work well with backend services,
> at least much more efficiently than relying on the CGI model.
>
> The bigger question re. LC on the backend is perhaps why we're having this
> discussion at all:  if performance is critical enough for us to work out LC
> daemons from scratch, why not just use an existing toolkit for that work
> and enjoy the advantages of a large ecosystem of prefab solutions?
>
> And that's the chickens-and-eggs of this:  until we have such a large
> community of prefabs the cost-effectiveness will continue to favor current
> leaders, but without someone starting such an effort we have little choice
> but to use current leaders and thus it becomes a self-fulfilling prophecy.
>
> Software evangelism is tricky business.  And when building business
> infrastructure, our responsibility to the company owners requires us to ask
> whether evangelizing a personal favorite language is a higher priority than
> delivering a cost-effective robust solution ASAP.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.