Solving the JavaScript Memory Management Problem

Syntax is a tiny portion of Smalltalk. Smalltalk is all about the tools. Objective-J has no tools. Smalltalk without the environment and the tools isnt Smalltalk. Thus, my Objective C not Smalltalk comment.

That was true for Objective-C, but JavaScript has closures, which can be used seamlessly in Objective-J.

Of course now Objective-C also has closures/"blocks" too.

I'm not going to claim to be an expert here, but I think the relationship is a little different between Objective-J and JavaScript than between Objective-C and C. The features of Objective-C pretty much across the board make operations simpler than they are in C. JavaScript already makes a lot of things pretty much as simple as it gets, and in some ways makes it too easy to accidentally do something wrong. So, Objective-J actually serves to impose a bit of structure on your code (and could even impose strict+static typing).

That's basically how I've used it: Objective-J classes define the larger-scale architectural components of a project, but for smaller collections of data that are somehow related, especially for short-lived collections of data, I usually drop down to JavaScript and use the convenient hashes and arrays.

Performance-wise, some operations will be faster in JavaScript than Objective-J, because things like message passing have an extra function call. I haven't found it to be a particularly noticeable difference, but admittedly I haven't been writing a lot of performance-critical code, so others might have better insights on that subject.