I always find it odd that the same developers who deride PHP look at things like IIFE and think "wow, JS is a cool, modern language!"
Thanks for the article though, if I ever need to write some JS this will help keep me a little more sane.
Thanks for the article though, if I ever need to write some JS this will help keep me a little more sane.
I don't deride PHP (I don't know it), but I see nothing wrong with IIFE. Yes, it could benefit from some syntactic sugar, but otherwise it is just using one of the best features of JavaScript, function support (first-class functions, anonymous functions, etc.).
It makes perfect sense to use a pattern like IIFE in order to encapsulate code, often using closures to allow access in a controlled manner from the outside, etc.
I suppose perhaps you don't like closures and so forth, and that's fine, but many people including me love them.
Language design by committee is seriously flawed and until a feature is shipping in all the major browsers it isn't real.
*depending on which version of ECMAscript is being used.
And even those Scheme uber-nerds considered it big hack, more useful in theory then in practice.
This means that the vm would be lowlevel enough that performance would start to approach that of native code, with complete freedom for the programmer to write the code for it in any language he desired.
The browser would then be able to execute this code instead of the corresponding Javascript file (e.g you compiler outputs two different object codes, one minified javascript for legacy browsers, one modern vm file for modern browsers).
That article starts from the assumption that any in browser VM will resemble the JVM; which is a faulty assumption. In fact, any in browser VM would have to be very different from the JVM since Rule 0 for any such VM would be "acceptable Javascript performance".
From that article:
> Meanwhile, JVMs don't do these optimizations. Since all types are statically
> known, the compiler knows exactly how much storage they need and what
> operations they support. It can then generate appropriate tight code for those
> types. This is fast if your language is statically typed, but if you're trying to
> compile a dynamically typed language to the JVM, it won't be able to run as fast as a
> VM that can assume dynamic typing all the way down and optimize specifically
> for that.
A whole wasted paragraph. Of course a browser VM wouldn't be statically typed, that'd make compiling/running Javascript a bear. One would hope there'd be some system of type-hinting, because eliminating dynamic dispatch is really low hanging fruit in terms of optimization, but JVM/CLR-style static typing? Madness.