No, no, no. Wrong answer. (We built the ability to interface with JavaScript into Snap!, but @18001767679 is one of the people who use it as their first resort, rather than the last resort as we intended.)
Snap! has very good support for object-oriented programming, in two different ways, each of which has a chapter in the Reference Manual.
One way uses Snap!'s natural objects: sprites. Even before we set out to make them full objects, they already had the ability to have sprite-local variables and sprite-local procedures (methods). The main thing that we had to add was inheritance. When you make a clone of a sprite, it isn't just a copy; it shares many characteristics with its parent by default, and can be told to share other things too. (For example, methods are shared by default, but sprite-local variables aren't, because too many projects use the idiom
so that each clone has its own ID.) There's message-passing with the TELL and ASK blocks. (TELL is a command; ASK is a reporter.) This is a prototyping OOP system, because kids making projects aren't like teams of adult programmers; the kid typically creates a sprite and experiments with its methods and general behavior before deciding to make more sprites like this one. So the first one is the prototype for all its clones.
The second way to do OOP is with closures as the objects. The local variables in a procedure call persist forever, instead of disappearing when the procedure finishes, if what the procedure returns is another procedure made by a lambda expression (a gray ring) in the body of the original procedure. It turns out to be very natural and easy to build a class/instance system based on closures.