In the quest for ever faster JavaScript, there has been a recurring refrain: why use JavaScript at all?
JavaScript engines have been a major focus of browser developers for some years, and the result has been substantial performance improvements from every vendor. JIT ("just-in-time") compilation that turns JavaScript code into instructions that can be directly executed on the processor brought huge speed gains. New data types have been added to the language to reduce the overheads when crunching numbers, and combined with asm.js, a high performance limited subset of JavaScript, applications running in the browser can achieve performance that's comparable with that of native code.
In spite of these improvements, the question of "why JavaScript?" remains. This is not without reason. The use of JavaScript incurs certain overheads: browsers have to read and interpret a text-based language that was designed for human authors, not for machines. The design of JavaScript itself has features that are suboptimal from a performance perspective; the way a single JavaScript variable may at different times represent a number, a string, or a fragment of HTML means that a JIT compiler may not be able to optimize as aggressively as it would like. The ability to modify the behavior of even built-in objects such as arrays can be similarly problematic.
Read 11 remaining paragraphs | Comments
No comments:
Post a Comment