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 m...@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. > _______________________________________________ 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
