What is JavaScript, really? Part 1, the runtime.
I am currently in the process of preparing to teach some Java/backend developers JavaScript and intend to try my damn hardest to teach them the potential JavaScript can bring to any environment. Unfortunatly that entails going into low level JavaScript to first explain the difference between an expressive dynamic script language and a rigid compile language. We frontend developers use JavaScript daily and never really sit back and think about what it is that we're actually working with and thus the language persists of having a reputation of being arcane, illogical and certainly not better then a good compiled application. That's just plain wrong, but how do we explain that!
Don't compare!
Comparing JavaScript with any compile language is a farce though, it's apples and bananas, in fact, comparing JavaScript with other dynamic languages is also equally ridiculous as most other script language still compile into bytecode or simply isn't muteable at runtime. No, what really sets JavaScript apart is not so much the language, but it's marriage with the runtime interperter (engine). Frontend developers complain about various runtime engines (usually IE's) and never really stand still to marvel at the brilliance of those engines, wether they support JavaScript entirely or not.
JavaScript ROCKS!
I mean, here we have an environment where we can plug in our programs and on runtime adapt the program entirely changing it's behaviour and logic on the fly! It goes far beyond the realm of write and run. A lot of credit for this goes to the engine, however the standards on which JavaScript is based creates a perfect marriage of language and runtime. For example, without muteable objects, applications that make use of extreme dynamics would be bloated hogging too much memory, take away lambdas and all throw-away-execute-once methods would be persisted on objects, again hogging more memory. And then there are closures, lovely, brilliant closures, without closures lamda's wouldn't even be half as effective as you would always be forced to create methods instead of functions to adress other objects.
JavaScript SUCKS!
All this expressive power and potential however comes at a cost. Obviously not compiling to bytecode and interpeting commands at runtime sacrifices performance, the algorithms you can and should perform are restricted to relative simplicity limiting the things you can do with JavaScript and it's runtime. Is that bad? No, not really, we go from a process taking nano seconds to miliseconds and whilst huge computations (3D or even 2D rendering for example) remain out of grasp for JavaScript, it's still more then good enough for most mundane tasks. For example, you simply do not need immense processing power for 3D and 2D x,y,z calculations whilst leaving the rendering to native or more specialist API's, which coincidentally can be added to the JavaScript runtime.
So how does it compare?
Ok, time to compare apples and bananas as I feel it's needed to fully understand. Languages that compile to bytecode and pretty much have everything predefined inside a container, are overkill and too rigid for mundane tasks. You can get pretty far with compiled programs, but that means having a huge initial code base for simple functionality, forcing you to use predefined components in places where flexibility is required. Components are adapted to support more functionality and flexibility and become unwieldy and ambiguous to work with. So basically, with compile languages it only makes sense to make ok looking applications, otherwise it would simply cost too much time to develop.
Whereas in JavaScript, this becomes as easy as pie (if you learn it properly) since you are not restricted by the conventions most compile languages impose on a developer and whilst all this expressive power creates at first glance, ambiguous confusing code, it's really not that hard to maintain once you can let go of all the conventions and restrictions other languages put on you. So JavaScript liberates you in the right places.
In conclusion
Whilst JavaScript is currently being ported to the backend and desktop, it's my opinion that this is a mistake if you can't make it talk or integhate to/with compiled programs. I see JavaScript more as a language that tells other program API's what to do, preprocessing and reformating user defined options before inserting the data or commands into an compiled application. This is where the dynamic runtime shines and where the compiled runtime becomes restrictive. In browsers JavaScript is the language developers use to push other application API's around like the DOM, Flash, and even the browser itself. It can do the same with serverside API's whilst integrating directly with the clientside API's and with some imagination, JavaScript can be used as a logic operator between multiple platforms simplifying interfaces to bare essentials.
I will have a hard time teaching JavaScript properly to java/backend developers... Part 1 is about showing them it's not *another* programming language, but a rich addition to *any* programming language. Time to kick them out of their sandbox!