A well known pain point of the CLR is that loading your program and running a few lines takes too long. While I don't know where exactly my beliefs came from, my beliefs are that this is because of

a) assemblies needing to be JITTED from MSIL in order to execute
b) in order to JIT you need to load lots of types which reference other types that reference other types, partly so the CLR can try to enforce type safety, partly because that's just how CLR works. There's cross-referencing baked in.
c)  therefore, basically needing to load and process data that's spread out in lots of files on your disk

So we can say it's because you have to do lots of compilation of your code, not just running it. And hence a new trend towards .net language code (C# etc) that is actually precompiled to native code, with thrilling statistics like 'starts up to 60% faster and uses less memory!'

Cool. But anyway. I have wondered, is a scripting language like javascript any better off in theory than this? On the face of it it seems that yes, it still needs to do lots of compilation to load your script and use a smart JIT to optimize it, but no, it doesn't have to do nearly as much this type references other type and type safety checking stuff.

What javascript does have as downsides from no inbuilt cross-referencing of types is a certain lack of safety such as a) you don't make type errors, and b) you need to figure out yourself how to get all your code loaded in the order that it is needed, so that you don't have the problem of calling functions before they are fully defined yet, or accidentally undefine and redefine things.

With recent advances in javascript though, it seems like there are kind of solutions to these problems. Typescript can help a lot with a), and a module system like ARM can help you a lot with b). So, trollish question - is there any reason now not to write your servers in typescript+node.js? :)