Forgot your password?
typodupeerror
Mozilla The Internet Java Programming

Firefox Gets Massive JavaScript Performance Boost 462

Posted by Soulskill
from the firefox-has-a-caffeine-buzz dept.
monkeymonkey writes "Mozilla has integrated tracing optimization into SpiderMonkey, the JavaScript interpreter in Firefox. This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts. Ars Technica interviewed Mozilla CTO Brendan Eich (the original creator of JavaScript) and Mozilla's vice president of engineering, Mike Shaver. They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.' The eventual goal is to make JavaScript run as fast as C code. Ars reports: 'Mozilla is leveraging an impressive new optimization technique to bring a big performance boost to the Firefox JavaScript engine. ...They aim to improve execution speed so that it is comparable to that of native code. This will redefine the boundaries of client-side performance and enable the development of a whole new generation of more computationally-intensive web applications.' Mozilla has also published a video that demonstrates the performance difference." An anonymous reader contributes links the blogs of Eich and Shaver, where they have some further benchmarks.
This discussion has been archived. No new comments can be posted.

Firefox Gets Massive JavaScript Performance Boost

Comments Filter:
  • As fast as C code??? (Score:5, Interesting)

    by ACDChook (665413) on Friday August 22, 2008 @09:10PM (#24714765)
    Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
    • by Anonymous Coward on Friday August 22, 2008 @09:17PM (#24714803)

      Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.

      Well, it has a JIT compiler, so that would transform it into bytecode essentially. It's the reason why C# is as fast as C code, because it too has a JIT. Google JIT :)

      • by Anonymous Coward on Friday August 22, 2008 @09:35PM (#24714941)

        Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?
        Next you'll be telling me Java hasn't got obscene memory requirements in comparison to native C/C++...

        • by CustomDesigned (250089) on Friday August 22, 2008 @10:10PM (#24715229) Homepage Journal

          In general, JIT systems can really provide CPU performance near C speed, or even faster for some benchmarks, once the application gets going. The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

          Even dynamic languages like Python can have a JIT - it specializes a function for various combinations of argument types, and then provides a catchall generic version for general objects. The catchall version is not much faster than the interpreter, usually (in fact it could *be* the interpreter), but the specialized versions can be much, much faster. (Also blocks can be specialized within any of the function versions.) But all those specialized versions take up memory. So the JIT keeps stats and tries to make only the ones that really help.

          • by CoughDropAddict (40792) * on Friday August 22, 2008 @11:22PM (#24715633) Homepage

            The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

            That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.

            For example, take LuaJIT [luajit.org], a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead [debian.org]. It also takes 2-8x less memory and starts up 10x faster than the JVM [debian.org], despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.

            I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.

          • Re: (Score:3, Insightful)

            by Z00L00K (682162)

            Since web browsers usually can cache JavaScript it will be useful to cache the compiled JavaScript.

            Next step is that we shall be able to see a server-side compiled JavaScript, but we will have to wait for browsers to support that. In that case we will be able to have language-agnostic browsers since the compiled code won't necessarily have to reflect which language that was used to write the script.

          • Re: (Score:3, Insightful)

            by Haeleth (414428)

            In general, JIT systems can really provide CPU performance near C speed

            You mean "in theory", not "in general". In general, real-world JIT systems are significantly slower than native code, though they certainly are noticably faster than regular bytecode, which in turn is faster than a pure interpreter.

        • Re: (Score:3, Interesting)

          by nmb3000 (741169)

          Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?

          .NET languages have a JIT compiler that is automatically invoked when the application is run. This compiles the program down to native binary code for the current architecture and operating system. The resulting binary is cached on the system so future executions can skip the compiling process. Additionally the compiler can be executed manually wh

        • by Toonol (1057698) on Saturday August 23, 2008 @12:50AM (#24716123)
          Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?

          Yes. Javascript will, just like C# or Java, be as fast as C/C++ in theory, and just like C# or Java, slower in practice.

          On the bright side... Javascript will be as fast as C# or Java, which is certainly good enough for a lot of things.
      • by xquark (649804) on Friday August 22, 2008 @11:18PM (#24715615) Homepage

        You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C. There is no example you can provide where the running time of an optimized C version will be as fast or slower than the most optimized C# version. Even with JIT and supposed optimal native code generation for tight-loops there is no way you can get the same performance.

        You are obviously just regurgitating MS marketing without thinking critically.

        • by shish (588640) on Saturday August 23, 2008 @05:07AM (#24717137) Homepage

          C# by its very nature can not be as fast as C

          C#, once JIT'ed, is just a bunch of binary. C, when compiled, is also a bunch of binary. Given a theoretically perfect JIT compiler vs the theoretically perfect static compiler, they'll both output exactly the same code.

          You are obviously just regurgitating anti-MS propoganda without thinking critically :P

          (Note: I'm not saying that C# implementations are *currently* as fast as C ones, just that there's nothing to stop them becoming so in the future)

        • Re: (Score:3, Insightful)

          by mpcooke3 (306161)

          A JIT can work out the OS and exact chipset on which it is running and therefore choose to generate different native code optimized specifically for you system.

          Even if a static C compiler happens to have been optimized for your exact CPU, cache size and memory a JIT could still collect or access runtime statistics about your application and do optimizations based on this information - this information is not available to a static C compiler.

          Perhaps the .NET JIT sucks or always produces code that is slower t

        • C is inefficient (Score:5, Interesting)

          by speedtux (1307149) on Saturday August 23, 2008 @10:16AM (#24718803)

          You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C.

          The C# JIT has all the information that a C compiler has (essentially, the entire source code). In addition, it has a lot of global program information and it has runtime statistics. And, the C# language has better defined semantics. All of this taken together means that C# can be optimized better than C.

          In terms of performance, C is a lousy language; Fortran is a "faster language" than C.

          The only reason C even runs as well as it does is because people have invested 20 years in making compilers squeeze out the last cycle, because C compilers play fast and loose with C semantics at high optimization, and because even CPUs have been tuned to accommodate its semantics.

      • by beelsebob (529313) on Saturday August 23, 2008 @03:30AM (#24716815)

        Except that C# code isn't as fast as C code [debian.org]. It's 2.7 times slower.

        • Re: (Score:3, Insightful)

          by pbhj (607776)

          I'd have thought that it's possible in a limited scenario to produce the same machine code from various high-level languages. It surely depends on the compilation not the language?

          [You're right, I'm not a programmer]

        • by hattig (47930) on Saturday August 23, 2008 @06:27AM (#24717423) Journal

          1) That's the Mono implementation of C#

          2) Intel's C++ compiler is known to be one of the best but cannot handle all situations. GCC's takes 1.3 times longer. Java 'only' takes 1.96 times longer.

          2a) Intel's C++ compiler got 3 errors in the benchmarks you linked to, thus it should have been disqualified. The Intel C got 1 error and a "no program", so again, disqualified. The first compiler to run all the tests was in fact the Gnu C++ compiler.

          Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.

          • Re: (Score:3, Insightful)

            by gbjbaanb (229885)

            Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.

            nonsense :) if you want machine performance, go with C/C++. If you don't care about how fast your app runs becuase you're focussed on programmer productivity go with Ruby or Python. Java/C# therefore is a worse-in-every-case option :)

    • by Bjarke Roune (107212) on Friday August 22, 2008 @09:21PM (#24714841) Homepage

      The optimization in the story is to compile parts of code written in Javascript. So when using this optimization, the Javascript is only partly interpreted, and if the compiled part is the part that takes up most of the runtime, then the Javascript could conceivably be something like the speed of natively compiled C.

    • Re: (Score:2, Informative)

      by fozzy1015 (264592)

      Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.

      A real world Javascript program will rarely, if ever, be as fast as C. The idea with this is: Normally, loops, no matter how tight, are executed in the interpreter environment with all the overhead that it entails. The idea is to profile loops that are 'hot' enough to be compiled to machine code so that the following iterations don't have the overhead of the interpreter. The more iterations for a loop the potentially faster speedup. Since compiling in itself takes time obviously part of the profiling will b

      • by Rockoon (1252108) on Friday August 22, 2008 @09:57PM (#24715113)
        The amount of ignorance in this community is quite disturbing. I suspect that part of the cause is the unchecked pro-c religion, which always begins "C as faster than ...."

        Clue phone guys. Ring. Ring.

        C is a high level language and like all high level languages it can either be compiled, interpreted, or even translated. JavaScript is no different than C and can also also be compiled, interpreted, or even translated. There is nothing special about the C language that makes it inherently faster than other languages. C itself is a derivation of the language BCPL, whos shortcomming was a lack of datatypes. The design goal of these language syntaxes was parsing with minimal overhead because RAM was in short supply in those days. C was not designed to be "faster" than anything.

        C is commonly mistaken to be superior because the most popular C compilers are commonly more advanced than the compilers of other languages due to simple supply and demand metrics. C is more popular, so its compilers have traditionally gotten more development effort. C itself isnt special beyond its popularity.
        • by cbrocious (764766) on Friday August 22, 2008 @10:13PM (#24715241) Homepage
          Well, you're on the right trail, but not quite right. The key difference between Javascript and C, from an optimization standpoint, is the type system. The overhead of dynamic types is quite immense even at its most optimal. I suggest looking into the architecture of the DLR -- it really shows the key problems behind compiling dynamic languages and how they're being solved.
          • Re: (Score:3, Interesting)

            by billcopc (196330)

            It's true that dynamic typing is a clock-cycle hog, but almost all new languages use it... I'd be perfectly happy with a strongly-typed variant of Javascript if it will run faster.

          • Re: (Score:3, Interesting)

            by mdmkolbe (944892)

            The overhead of dynamic types is quite immense

            That is a common myth but unless you call a factor of 2.0 immense, it it wrong. The truth is that the cost is immense only in the most naive implementations (*cough* ruby *cough). For example, while the compiler has to insert type checks whenever you do something like "+", with a well designed implementation that uses pointer tagging that should cost at most one bitwise-and and one branch-if-zero (with modern CPU pipelines that should cost a fraction of a cycle since the branch should predict fail and in

      • by BZ (40346) on Friday August 22, 2008 @10:25PM (#24715309)

        For what it's worth tracemonkey is about the same speed as unoptimized C on integer math at this point. The difference is register allocation (which tracemonkey doesn't do yet).

        Moving to more complicated examples, things get more interesting. Since the jit has full runtime information, it can do optimizations that a AOT compiler cannot do. At the same time, the lack of a type system does hurt, as you point out. At the moment, tracemonkey handles this by doing type inference and then if it turns out to be wrong (e.g. the type changes) bailing out and falling back on the interpreter. Turns out, types don't change much.

        The real issue for a real-world Javascript program is that most of them touch the DOM too, not just execute JS. And right now tracemonkey doesn't speed that up at all. In fact, it can't jit parts of the code that touch the DOM. Eventually the hope is to add that ability.

    • As I understand it, in this case tracing basically means converting the specific javascript path that is executed to compiled machine code, as it is run.

      So if you're iterating through a loop a thousand times, you run it once as interpreted javascript, generate and cache a machine language version of the javascript you just ran, and run that version 999 times.

      The basic concept isn't that new. Intel even had something similar implemented in hardware called a trace cache on the Pentium4 (I don't recall it bei

    • by zuperduperman (1206922) on Friday August 22, 2008 @09:59PM (#24715141)

      It's kind of a non-sensical concept because Javascript as a language is capable of things C can't do, like eval new code at run time, modify existing types etc.

      By the time you have a fair comparison (ie. written C code that can really do everything Javascript can), you have basically written Javascript itself in C. So all these comparisons are really just based on getting subsets of Javascript where it is really doing no more than plain C can do to run as fast as similar plain C, and guess what, that is done more or less by compiling said Javascript to native code.

      I find it amusing that all these higher level languages (everything from Java, to Javascript to Python or VB) continuously promote how they are "nearly as fast as plain C now" but then a release or two rolls by and voila they suddenly announce they have improved performance by 10x or some similar metric. But when you ask the question, "oh, so are you 10x as fast as C now?", the reply will be "oh, no, but we're nearly as fast as C!"

    • by cyberjessy (444290) on Friday August 22, 2008 @10:08PM (#24715215) Homepage

      Concurrency is another big win for interpreted (and to jit-ted code like Java) code. The compiler on the target machine gets to decide how to optimize the the code based on the number of processors.

      So, _eventually_ C may be slower than JS/Python/Java. :)

      And of course, as other pointed out the article says that JS is now getting compiled.

      • by Anonymous Brave Guy (457657) on Friday August 22, 2008 @10:53PM (#24715487)

        Concurrency is another big win for interpreted (and to jit-ted code like Java) code. The compiler on the target machine gets to decide how to optimize the the code based on the number of processors.

        Which would be great, if only someone had invented algorithms that could take advantage of that in cases other than trivial parallelisation where the more cores the better. Unfortunately, understanding of how to do that is still in its infancy even in academia, which means that the combination of old fashioned compilation plus moderate run-time adjustments are still likely to blow away anything interpreted for a while to come, and JIT compilation is no big advantage yet either.

  • Wow (Score:2, Insightful)

    by hairyfeet (841228)
    Script kiddies will be able to infect a Windows user in record time! Seriously,I install Noscript automatically with every new build and show the customer how to use it. It has just gotten too easy to infect Windows with JavaScript and it seems like everyday you're reading of a new JavaScript exploit. So it is safer just to kill it than to take the chance. So for me and my users at least it doesn't matter how fast FF renders JScript,because it has just gotten too dangerous to use. It is like saying "We've i
    • by Urza9814 (883915)

      Or you could just install Linux for them and save all the hassle. :)

      • Re: (Score:3, Interesting)

        by hairyfeet (841228)

        Because then their damned Lexmark printers don't work and I go out of business? Until linux can run Windows games with a "clicky clicky,next next next" installer,and I can install those damned Lexmark all-in-ones that everyone seems to have there is just no way i can survive selling Linux boxes. i tried and ended up having to reformat them and put Windows because folks didn't want them. You can talk about how much safer Linux is to a customer all day long,but if it doesn't work with their hardware and they

  • by i.of.the.storm (907783) on Friday August 22, 2008 @09:12PM (#24714779) Homepage
    Interestingly, one of the linked blogs talks about how this could lead to more of Firefox being written in Javascript. I haven't done much non-web related Javascript programming, and I haven't really used those new frameworks, but it seems to me like application programming in Javascript is like trying to hammer a nail with the handle of a screwdriver. Sure, it might work, but there are much better tools for the job. What do you guys think?
    • by Shados (741919) on Friday August 22, 2008 @09:17PM (#24714799)

      Javascript, especially when tied to a full featured framework such as ExtJS, is actually freagin cool. Add some IDE support, like in Visual Studio 2008, or in Aptana, and you've got one rock solid, multi purpose dynamic language that is already mainstream and well supported.

      Not as cool as Groovy, and I'm a static typing fan myself, but thats the next best thing.

      • The main problem I see with this (and again, I'm an amateur right now so take this with a grain of salt) is that these frameworks aren't as standardized as say, Java. I'm fairly certain that there are far more Java or C++ programmers than JS programmers who use ExtJS. I suppose it wouldn't be too hard to learn a framework but it just seems like a waste of time when you could be writing faster native code, or even Java code which at least you might already know.

        Also, I was actually wondering about this top
    • Firefox is already written in XUL, which is heavily based on web technologies. If Firefox uses CSS for themes then I see no reason not to increase the usage of JavaScript in the application.

      Afterall, Firefox developers probably aren't the most 1337 C/C++ coders out there, but they are probably amongst the best JavaScript ones.

      • Re: (Score:3, Informative)

        Well, XUL is just an XML language used for the UI. As far as I know the main codebase is C++/JS right now, but probably more C++ than JS.
      • Re: (Score:3, Informative)

        by Randle_Revar (229304) *

        JS drives most of GUI interaction in FF. The bulk of the C++ is down in gecko, for rendering speed.

    • Re: (Score:3, Insightful)

      by bcrowell (177657)
      What do you consider to be the problem with JavaScript as a general-purpose programming language? I think it's a sweet language. Just because a lot of people learn it as a set of cookbook recipes for doing little things on web pages, that doesn't mean the language isn't a good language. The only really serious problem with JavaScript, IMO, is the lack of standardization of the DOM, and that's not even a real language issue, it's just a problem with the way the language gets interfaced to browsers.
      • I don't know, it's just that coming from Java first Javascript really bugs me. I guess the lack of standard OOP stuff, and function declarations seem weird to me. I guess I've never really given it a serious look, and most of the times I used it a lot of my annoyances were related to the DOM.

        My post was really more about generating discussion though, because I'm genuinely curious about this. I don't have enough JS experience to really say more than it feels awkward to me. I kind of expect things to work
    • Re: (Score:3, Interesting)

      by T-Ranger (10520)
      Its a question of what is "core framework" type stuff, and what is "actual application". Things like UI layout, interaction, networking, security, caching, rendering - as well as executing run time JS - is "core" functionality. I'd wager that >90% of binary code of Fx and, say, Thunderbird is the same.

      And most of that core stuff is written in C++. Well, actually, its written in an obscure dialect of C++, developed when Netscape ran on a dozen various platforms, with mutually incomparable cpp compilers.

      Bu
      • Thanks, that's pretty informative. I think this is why they're trying to move to XULRunner eventually for Firefox and Thunderbird, then there will be less hard drive space wasted on identical software and possibly less RAM used as well. I hadn't really thought of that when I made my comment.
      • Re: (Score:3, Interesting)

        by shaitand (626655)

        'actually, its written in an obscure dialect of C++, developed when Netscape ran on a dozen various platforms'

        Really? I was under the impression that the core of Firefox 1.0 was a complete rewrite because the developers determined that the old Netscape stuff was a mess that wasn't worth moving forward with.

    • by cmacb (547347)

      Javascript is like trying to hammer a nail with the handle of a screwdriver.

      Or program the Windows OS in .net?

      • Kind of what I was thinking. That's not actually being done though, except for the Singularity research project in the MS research division that will probably never see production status. Then again, I don't know what the future holds. http://www.codeplex.com/singularity [codeplex.com] seems to be the site for anyone interested.
    • Re: (Score:3, Insightful)

      by RedWizzard (192002)

      Interestingly, one of the linked blogs talks about how this could lead to more of Firefox being written in Javascript. I haven't done much non-web related Javascript programming, and I haven't really used those new frameworks, but it seems to me like application programming in Javascript is like trying to hammer a nail with the handle of a screwdriver. Sure, it might work, but there are much better tools for the job. What do you guys think?

      Why do you think Javascript is so unsuitable? I've done a fair bit of application programming in Javascript and it's fine so long as you keep your code structured (so no different to Perl or even C in that regard).

  • by gandhi_2 (1108023) on Friday August 22, 2008 @09:13PM (#24714783) Homepage
    is the root of all evil. --C. A. R. Hoare

    Now if we can just stop all the xss. Now it's just xss 20-40 times faster (in certain contexts).

    Actually, if JS gets fast enough, it could rival Flash [slashdot.org]. This is a good thing.

  • Isn't that like dividing by zero?
  • by EmagGeek (574360)

    Will it make my Sony Bluray player take less than 10 minutes to boot and play a disc?

  • Not bad (Score:5, Insightful)

    by neokushan (932374) on Friday August 22, 2008 @09:39PM (#24714977)

    Firefox 3 already gave quite a nice performance boost to Javascript, enough to actually impress me (google maps is a great demonstration of this). It's good to see they haven't stopped there and are busy improving it further, a lot of software developers tend to spend too much time on making new features and not enough time fixing/optimising the existing one, but I think after the backlash from FF2's memory usage, Mozilla has rethought their priorities and I'm glad to say they're doing things right.

    • Re: (Score:3, Insightful)

      by nyctopterus (717502)
      Yes. If you think about it, this is the best way to add "features"--faster javascript means more complex code can be written and run in browsers; including both web pages and extensions.
  • Oh no! (Score:4, Funny)

    by Das Modell (969371) on Friday August 22, 2008 @09:42PM (#24715003)

    This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts.

    What does the scouter say about its power level?!

  • Dr. Michael Franz (Score:5, Interesting)

    by tknd (979052) on Friday August 22, 2008 @09:56PM (#24715109)

    The theories behind tracing optimization were pioneered by Dr. Michael Franz and Dr. Andreas Gal, research scientists at the University of California, Irvine.

    Hey that's my old compilers professor and my school!

    This PDF [uci.edu] looks like the paper the article is referencing.

  • by MasterC (70492) <cmlburnett@gm[ ].com ['ail' in gap]> on Friday August 22, 2008 @10:01PM (#24715163) Homepage

    I've written my share of JS-heavy apps and the boost will be nice for that. However, my complaints with JS don't lie with performance.

    • Tied too much to the browser. JS works great for some (some love it) but syntactically I hate every last part of it. However: web == JS so I have no other option.
    • Typing. Yeah, it has types but they're practically worthless. A Number represents a float/double and an integer? Say what?
    • Type checking.
    • No reflection.
    • No dictionary. Sure, you can use an Object as a dictionary but the second someone prototypes it to add root functionality then you've introduced other items in your "dictionary". (I'm looking at you prototype.js)
    • Nothing resembling libraries. No dependencies, etc.
    • It's bastardized to accommodate the short comings of HTML (drop downs, combo boxes, etc.)
    • Obey's Postel's law [wikipedia.org] too much. Error handling and exceptions is a sad state.
    • No threading. No locking. Nothing resembling concurrent programming. The more complicated your app the more arbitrary events and multithreading are important.
    • No classes. Prototyping & cloning is a neat paradigm for where it fits but so do class-based objects. This isn't just JS I have this problem with. Being able to do both and using the right one where necessary would be great.
    • When is the document loaded? And if you have two libraries vying for that event? (See library complaint)
    • Since it has no real library support I have to blame the browser for not providing more general functionality. XML parsing, date stuff is abysmal, and other "routine" stuff you do when making web sites.
    • Scoping. Scoping is mind-numbingly bad.
    • Namespaces (again, see library complaint) are implemented via object nesting, which isn't really namespaces
    • Logging and debugging. I haven't delved into the likes of Firebug to see how it works but when the language (again no libraries so I blame the language) itself only provides alert() then it's clear the creators weren't thinking about debugging at all. At least IE natively will let you debug JS!
    • Standard dialogs are alert() and confirm(). Anything and everything else you have to roll your own. I really, really don't want to write something for a Yes/No dialog instead of OK/Cancel confirm().
    • Drag-and-drop. If you've done it then you know it's no walk in the park.
    • Browser identification and JS version identification. Why should I have to jump through hoops, poke & prod things, and guess at what my JS run-time is? Everyone has their own means to detect it and it's absolutely ludicrous. I'm fine if there's no real "standard" but at least give me the variables to know what I'm writing against so I can adequately work with it. (Again tied too close to the browser.) Every language I use frequently has means for me to identify such things.

    I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.

    Basically my point is that performance does not bring JS up another tier. It just prolongs the pain of having a grossly inadequate language for rich application development. JS does have some nice things about it (first-class functions, closures, for(..in..), etc.) but in no way would I consider it "good" for application development.

    Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer and this performance boost is just a Bluepill [wikipedia.org] in disguise.

    • Re: (Score:3, Insightful)

      by tepples (727027)

      Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer

      Then what technology is The Answer on a platform where native code must be digitally signed by someone other than the user but JavaScript code need not be? Examples of such platforms include PSP, PS3, Wii, iPhone, and some enterprise installations of Windows.

    • Re: (Score:3, Informative)

      by MrMunkey (1039894)

      At least IE natively will let you debug JS!

      That's the first I've heard of that. In order to debug JavaScript you either have to have Office installed, or download the MS Script Debugger. IE does report errors, but their description is horrible. I've found that just the error console in Firefox is much, much better than IE's error reporting. You really should look into Firebug. It's invaluable [ejohn.org]

  • DIGG! (Score:2, Troll)

    by furry_wookie (8361)

    WHOOPIE!!!

    Digg.com will almost be usable now...hehe.

  • by Anik315 (585913) <anik@alphaco r . n et> on Friday August 22, 2008 @10:27PM (#24715321)

    It would nice to see some demos of this with John Resig's Processing.js [ejohn.org]. It could definitely use the kind performance boost being discussed here.

    In addition to a performance considerations, it would also be nice to have addtional some additional bit depth in JavaScript.

    I anticipate JavaScript will continue to be very popular, but there are alot a lot of reasons other than performance that people won't want to use the language for writing desktop applications over C/C++/Java. That said, there have been alot of recent developments that have made me cautiously optimistic about the future of the language along these lines.

The difficult we do today; the impossible takes a little longer.

Working...