(no title)
TrevorBurnham | 14 years ago
This applies to HTML and CSS preprocessors as well: I'd advocate Jade over Haml and Stylus or Less over Sass, simply because Jade and Stylus/Less aren't tied to the Ruby ecosystem. JS is the real deal for "Write Once, Run Anywhere."
bodyfour|14 years ago
I know I'm in a tiny minority of HN readers, but I have to deal with a pretty wide variety of UNIX platforms.. my code needs to run on SPARC, Itanium, etc. Sure most of these have a foot-and-a-half in the grave but one still is hanging in there: I still see a decent number of AIX customers; it'll be with me for the next few years at least. If something can't be made to run on a POWER CPU I can't touch it.
In the past, the widely used scripting languages (perl/lua/python/ruby/...) always treated CPU portability as sacrosanct. In time, there have been CPU-specific optimizations work done (LuaJIT, etc) but there is always a way to run the underlying language anywhere.
In the JS world, all of the modern work seems to carry an assumption that node.js is available, which in turn relies on the V8 JIT engine. V8 supports Intel, ARM, and (to some extent) MIPS CPUs -- IIRC node itself only supports the first two of those.
I'm all for optimizing for the 99%-case CPUs, but it's frustrating that I can't use these JS-based tools even at a large performance penalty.
I was heartened by the existence of the "SpiderNode" project since it would provide some engine diversity to the node.js world. From what I can tell it doesn't seem to be getting much traction in the wider community though, so I don't know if that's going anywhere.
Last I heard, the V8 team's opinion on portability was "ARM is our bytecode, just emulate that".. which is a fine answer as far as it goes. However, I haven't seen anything that actually implements this advice though (short of emulating an entire linux kernel in qemu) I keep hoping that V8 will add a fallback non-JIT mode for greater portability but I'm sure it's not a priority for Chrome.
So JavaScript portability has ended up in an unfortunate predicament: the language itself should be portable to "any OS" but in reality all of the non-browser projects have tied their wagon to a single engine.. and that engine doesn't have wide portability as a goal.
alexis-d|14 years ago
andrewflnr|14 years ago
flywheel|14 years ago
[deleted]