- Security
- Abstraction / High-level Constructs
- Scoping / How Could it be Better?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Abstraction
The web is ideally architecture-neutral. The point of using something like JavaScript is that the same code will run on an ARM smartphone, a MIPS netbook, or an x86 desktop. This is something that JavaScript does very well. It does not expose any details of the underlying architecture to the programmer.
Unfortunately, this also comes at a cost: namely the inability to make use of many of the features of modern architectures. One thing in particular is trivial in most languages, implemented in hardware on any vaguely modern CPU, and yet amazingly hard in JavaScript. I refer, of course, to 64-bit integer arithmetic. Even creating a 64-bit integer value is nontrivial in JavaScript. JavaScript provides only one numeric type, with the range of a 64-bit double-precision floating point value. The mantissa of such a value is sufficiently large to represent a 32-bit integer, but to represent a 64-bit integer you need two of them and you then need to check for overflow in any operations.
That's not the only thing that's difficult to implement in JavaScript. Although it provides garbage collection, it does not provide any form of weak reference. This makes certain patterns common in other languages very difficult. For example, most Objective-C code uses a notification center for asynchronous event delivery (at which point, I should add, the obligatory plug for the second edition of my Objective-C Phrasebook). Objects hold a reference to the notification center and it, in turn, holds a weak (non-owning) reference to any objects that have registered to receive notifications. When an object is no longer referenced by anything (except the notification center), it unregisters itself.
Because JavaScript provides only strong references, code that tries to work the same way in JavaScript will simply leak memory.
High-level Constructs
One of the challenges for a runtime environment is providing reusable high-level abstractions. Most procedural languages on modern operating systems, for example, use the same stack frame layout so you can call functions written in one language from another. This was not always the case. Traditionally, Pascal and C passed parameters in the opposite order to each other, so you needed special support for calling C functions from Pascal, and vice versa.
On systems such as .NET and the JVM, all languages have to either use the same object model or implement their own on top. Unfortunately, as the author of RedLine Smalltalk discovered, these object models are not always flexible enough to represent everything that you need.
At the opposite end of the spectrum is something like the Common Lisp Object System, which is so complex that getting good performance out of it is difficult.
So how does JavaScript do? Somewhat unusually for modern languages, JavaScript is prototype-based. This is actually very nice when implementing other languages: It's much easier to implement a class-based language on top of a prototype-based one than vice versa. Even better, implementations such as V8 actually do the reverse transformation, so if you are implementing a class-based language, it's relatively efficient.
There are, however, some limitations of the JavaScript model. For example, it has no equivalent of Smalltalk's #doesNotUnderstand: or Objective-C's -forwardInvocation:. They allow an object that does not have a specific method to implement the call another way. I had to work around this by implementing an objc_msgSend() function in JavaScript that first checked for the existence of a method and then called some fallback code if it did not exist.
In implementing this function, however, I made use of one of the most useful features of JavaScript: something that it does and even C lacks. It is trivial to write trampoline functions in JavaScript. In C, you cannot write a variadic function that calls another function with the same arguments that it was called with. The objc_msgSend() functions in real Objective-C runtimes therefore have to be implemented in assembly and have to be reimplemented for every target architecture.