5 ms·

"Just let that sink in for a moment — it's a mobile OS powered by JavaScript!" Scary thought ;)

• tsahyt 14y ago
  It is. Sounds like a big waste of performance to me.
  • robhawkes 14y ago
    You'd be surprised at how well JavaScript performs when allowed.
    • tsahyt 14y ago
      Probably. I haven't witnessed that yet though.
    • praptak 14y ago
      The scary part of JavaScript is not performance, it is the hell of inconsistency. '1' - 0 is 1. Guess what '1' + 0 is? Nope, it's '10'. Crockford's JavaScript truth table is mind-bending. On top of that, semicolon insertion.
      • ajanuary 14y ago
        Type coercion and asi are probably the least troublesome odd parts of js I encounter day to day. I find the weird scoping rules around 'this' and the verbosity of anonymous functions far worse. [1] (Sincerely and non-rhetorically) Do you really find the former more annoying than the latter? I see a lot of people using those examples to call out JS inappropriateness for development, but it seems like they're focusing on the wrong things to me. [1] I know they can be fixed by using a language that compiles down to JS. So can the parent's criticisms.
      • scriptproof 14y ago
        Not inconsistency to me. + is a string concatenation operator, - is not (maybe it could be) and '1' - 0 is just a fallback.
      • MatthewPhillips 14y ago
        Not really scary day-to-day. If you want to do integer math, make sure you're dealing with integers.
      • deleted 14y ago
        [deleted]
      • deleted 14y ago
        [deleted]
    • pkolaczk 14y ago
      It performs well, until the code is too complex for the JIT compiler to get type inference / speculative optimizations right. Then it suddenly performs very, very poor, because it falls back on dynamic (very slow compared to inline) dispatch and doubles instead of ints.
      • guilloche 14y ago
        The language seems in need of refinement to get significant performance in match of JVM JIT, not to mention c.
• cincinnatus 14y ago
  Web standards apps will always have to make bad compromises. We need browser byte code.
  • robhawkes 14y ago
    What sort of compromises?
    • cincinnatus 14y ago
      Having to target JavaScript. You then have issues with debugging, overly convoluted build processes etc.
  • mtrimpe 14y ago
    JavaScript is browser byte code. Just like Java byte code it's not that great for a lot of cases but, just like Java, eventually the JIT will get pretty decent.
    • dons 14y ago
      Only by accident. It has terrible semantics for a target assembly.
    • adestefan 14y ago
      The JIT in the JVM is not for Java, but for Java bytecode. That, along with the easy integration into existing Java classes, is what makes the JVM such an attractive target for things like Scala, Jython, and Clojure.
      • mtrimpe 14y ago
        Java bytecode is pretty close to Java "the language." You can try decompiling some Java classes and see how close to the original you end up getting. Because of that it's also a pretty awful assembly target, something which is only now being addressed with things like invokedynamic, finally moving Java byte code beyond Java 'the language.'
• cincinnatus 14y ago
  Web standards apps will always have to make bad compromises. We need browser byte code.