Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Firefox Gets Massive JavaScript Performance Boost

Soulskill posted more than 6 years ago | from the firefox-has-a-caffeine-buzz dept.

Mozilla 462

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.

Sorry! There are no comments related to the filter you selected.

The Greatest Idea (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24714733)

I have just the thing for bovine America.

Every major highway should have a huge HUGE billboard with a full-color photo of a big fat chick. I'm talkin', can't tell where her tits end and her stomach begins fat. I'm saying ROLLS OF DISGUSTING FAT. And the huge, easily legible caption should say "WADDLING: It's only cute when ducks do it." Whattya think?

Re:The Greatest Idea (1, Insightful)

Anonymous Coward | more than 6 years ago | (#24714933)

Microsoft hates the idea of fast, cross-platform Javasript.

Expect this discussion to be full of astroturf, red herrings and trolls.

Re:The Greatest Idea (0, Troll)

Anonymous Coward | more than 6 years ago | (#24715085)

Microsoft needs to embrace fast, cross-platform Javascript and here's why: because better Javascript use means more responsive, rich-content, user-customizable, next-gen web platforms. To meet the challenges of today's globalized, fast-changing environment, business needs to find ways to improve productivity while making better use of resources. That means more state-of-the-art service provision for Slashdot users eat mare pussy fuck all yall

Re:The Greatest Idea (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24715475)

Mod parent up. He is absolutely correct that Microsoft needs to embrace fast, cross-platform JavaScript. And here is why: AJAX applications are only going to evolve in time, and slow JavaScript is a hindrance. Worse yet, JavaScript is slowest on the most popular platform for its use. Even Firefox, the most bloated of the modern browsers, is faster now. The sooner Microsoft can get on board with a fast JavaScript engine, Slashdot readers eat boxes of raw pig anus for fun.

Re:The Greatest Idea (-1, Troll)

93 Escort Wagon (326346) | more than 6 years ago | (#24715143)

Microsoft hates the idea of fast, cross-platform Javasript.

Expect this discussion to be full of astroturf, red herrings and trolls.

It won't be just from the Windows side - a good chunk of Linux-heads hate anything but static black text on plain white backgrounds. So this should get interesting...

Re:The Greatest Idea (3, Funny)

Anonymous Coward | more than 6 years ago | (#24715477)

It won't be just from the Windows side - a good chunk of Linux-heads hate anything but static black text on plain white backgrounds. So this should get interesting...

Goes to show what you know. Real Linux-heads hate anything but static white or green text on plain black backgrounds.

Re:The Greatest Idea (4, Funny)

Spy der Mann (805235) | more than 6 years ago | (#24715271)

Expect this discussion to be full of astroturf, red herrings and trolls

Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)

Re:The Greatest Idea (4, Funny)

Yvan256 (722131) | more than 6 years ago | (#24715387)

I am rubber, you are glue.

Re:The Greatest Idea (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#24715175)

Wow, that's phunny as phuck, you phucking gee knee us.

As fast as C code??? (5, Interesting)

ACDChook (665413) | more than 6 years ago | (#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.

Re:As fast as C code??? (5, Informative)

Anonymous Coward | more than 6 years ago | (#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 :)

Re:As fast as C code??? (5, Insightful)

Anonymous Coward | more than 6 years ago | (#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++...

Fast as C but uses lots more memory (5, Informative)

CustomDesigned (250089) | more than 6 years ago | (#24715229)

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.

Re:Fast as C but uses lots more memory (1)

lubricated (49106) | more than 6 years ago | (#24715481)

So, really the memory access will be a bottle neck, you can never hope to have your program in cache and it will be much slower than C.

Re:As fast as C code??? (2, Interesting)

nmb3000 (741169) | more than 6 years ago | (#24715281)

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 when the program is installed to prevent the first-run delay.

That said, in general programs written using the .NET framework end up with the same basic overhead as a program written in C/C++. The biggest difference are all the .NET libraries and other managed features of the language. In this way C# would be about the same as C++ using a bunch of dynamically-linked 3rd party libraries and a completely autonomous garbage collection library.

Obviously this is more overhead than a small and simple C program but that wasn't the point. I think it would be interesting if you could provide pre-compiled Javascript files to browsers for execution -- give it the bytecode directly and allow it to skip the compile process. This would make Javascript much more like Java in that regard.

Re:As fast as C code??? (5, Informative)

Bjarke Roune (107212) | more than 6 years ago | (#24714841)

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:As fast as C code??? (2, Informative)

fozzy1015 (264592) | more than 6 years ago | (#24714891)

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 be to determine if a loop is worth compiling or not.

Re:As fast as C code??? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#24715031)

Clear identification and optimization (e.g. compiling) of invariants can also dramatically increase speeds. I can't think of a loop that cannot be optimized (except for recursion, where you will have to unwind it and implement it in another way i.e. iteratively). So can looking at the problem from a different angle--i.e. the loop is different.

Re:As fast as C code??? (5, Informative)

Rockoon (1252108) | more than 6 years ago | (#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.

Re:As fast as C code??? (5, Informative)

cbrocious (764766) | more than 6 years ago | (#24715241)

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:As fast as C code??? (1)

morcego (260031) | more than 6 years ago | (#24715397)

I would even go a step further. People keep saying that JIT-based languages can be just as fast, but use a lot more memory. I don't know on their computers but, on line, allocating and deallocating memory takes time. Even if those languages "hide" all the allocation and addressing issues from the programmer, those still happen.

Would take alone make those languages "much" slower ? No. But it is another penny in the box.

Re:As fast as C code??? (5, Interesting)

BZ (40346) | more than 6 years ago | (#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.

Re:As fast as C code??? (0)

jfmiller (119037) | more than 6 years ago | (#24714969)

I do not believe this is still true. Java ByteCode is interpreted and is still equal to C in speed -- though admittedly still compiled. Even purely interpreted languages are seeing a large speed boost from JIT compilation. I believe the stratigy is to "compile" JavaScript for a page an remember the optimized control flow. In doing so JavaScript could execute faster then even a natively compiled C plug-in within the browser environment.

Re:As fast as C code??? (1)

RalphBNumbers (655475) | more than 6 years ago | (#24715029)

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 being on their newer chips, but I might have missed it), where they cached executed micro-ops, rather than only storing information about jump targets in a branch predictor and then re-cracking instructions into micro-ops as they were needed like most other chips.

This should make repetitive loops a lot faster, but with code that is only executed a few times, the overhead may outweigh the benefits. Used with good judgement, this should be very interesting. But, given the abundance of javascript code that is not run many times, I'll still be interested to see how SquirrelFish's non-JIT approach compares in real usage (as opposed to benchmarks, which tend to favor repetitive code).

Re:As fast as C code??? (0)

Anonymous Coward | more than 6 years ago | (#24715343)

I'd imagine that as we use Javascript for more application-style code, where you have significant amounts of reusable logic (via frameworks) rather than just glue that gets called when you press a button, code will be called frequently enough to make the compilation worth it.

The JIT only kicks in when the interpreter detects that a piece of code is being executed very frequently, so code that only gets executed a few times needn't pay the price of compilation. Even if you're in a loop that only gets called once during initialization, if it spends enough time in the loop it can compile a trace and make the rest of the iterations through that loop faster.

Re:As fast as C code??? (5, Insightful)

zuperduperman (1206922) | more than 6 years ago | (#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!"

Re:As fast as C code??? (4, Insightful)

cyberjessy (444290) | more than 6 years ago | (#24715215)

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.

Re:As fast as C code??? (3, Interesting)

Anonymous Brave Guy (457657) | more than 6 years ago | (#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.

Sweet! (0)

Anonymous Coward | more than 6 years ago | (#24714769)

JS can always be faster!

Wow (2, Insightful)

hairyfeet (841228) | more than 6 years ago | (#24714773)

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 increased the speed of ActiveX by 300%!". But as always this is my 02c,YMMV

Re:Wow (0, Flamebait)

the_B0fh (208483) | more than 6 years ago | (#24714931)

Why is parent a flame bait? /. just yesterday had an article about a javascript attack in firefox that takes over the clipboard. I tried it on my firefox, and it worked.

Re:Wow (2, Insightful)

erayd (1131355) | more than 6 years ago | (#24714983)

That attack was via flash, not javascript.

Re:Wow (1)

Urza9814 (883915) | more than 6 years ago | (#24715083)

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

Re:Wow (2, Interesting)

hairyfeet (841228) | more than 6 years ago | (#24715497)

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 can't easily install and play their games,it is no sale.

And as for flamebait? Has nobody seen the massive amounts of JavaScript exploits hitting the net lately? If this was an article touting an increased speed for ActiveX would we all be cheering? JavaScript is the script kiddies tool of choice ATM,and it is just getting worse. Don't believe me? Just go here [builderau.com.au] or here [aplawrence.com] and look for yourself. Or type "JavaScript Exploit Firefox" into Google and see how many hits you get. I counted over 702,000! We need to be increasing the security of JavaScript,not the speed. Who cares how fast it'll render if you are afraid to allow your users to have it on for fear of being hacked? But as always this is my 02c,YMMV

Precursor to more of Firefox being in JS (4, Insightful)

i.of.the.storm (907783) | more than 6 years ago | (#24714779)

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?

Re:Precursor to more of Firefox being in JS (4, Insightful)

Shados (741919) | more than 6 years ago | (#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.

Re:Precursor to more of Firefox being in JS (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#24714837)

Gecko *is* a full-featured framework.
ExtJS is for the more restricted web stuff without code signing.
But then, the parent probably doesn't even know what a prototype is or a closure.

Re:Precursor to more of Firefox being in JS (0)

Anonymous Coward | more than 6 years ago | (#24715079)

... and by parent, I mean the dude who started it all with his "hammer a nail with the handle of a screwdriver"

Re:Precursor to more of Firefox being in JS (4, Funny)

93 Escort Wagon (326346) | more than 6 years ago | (#24715205)

Gecko *is* a full-featured framework.
ExtJS is for the more restricted web stuff without code signing.
But then, the parent probably doesn't even know what a prototype is or a closure.

Reading your first two sentences, I found your post informative and worthwhile. But, with the last sentence, the voice reading your comment in my head suddenly turned into that whiny, high-pitched geek voice they use on cartoons.

Re:Precursor to more of Firefox being in JS (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#24715287)

That's MY voice, you insensitive clod!

Re:Precursor to more of Firefox being in JS (1)

i.of.the.storm (907783) | more than 6 years ago | (#24714911)

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 topic earlier today (/. is becoming sentient, run!) and I was wondering, do colleges actually teach Javascript as part of their CS curriculum? It doesn't seem that likely to me, but I'm actually going to start college next week, majoring in EECS so I'll find out soon enough I guess. I'd guess that the people who would learn JS would be more likely to learn it from web development classes and not CS, so (I'm stereotyping here) the code might not be as optimized as it could be. Then again, I'm sure the guys writing the interpreters have a CS background so I guess maybe they do teach some JS in CS courses?

Re:Precursor to more of Firefox being in JS (1)

Chandon Seldon (43083) | more than 6 years ago | (#24715203)

For a project that's going to go on for more than a couple months, selecting a task-appropriate programming language will be more useful than selecting one that some single programmer happens to know. As for whether a given language is taught in University or not - I don't see how that could possibly matter. A good University CS program will teach the student to pick up new languages whenever they feel like it.

Re:Precursor to more of Firefox being in JS (1)

Warbothong (905464) | more than 6 years ago | (#24714809)

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:Precursor to more of Firefox being in JS (2, Informative)

i.of.the.storm (907783) | more than 6 years ago | (#24714859)

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:Precursor to more of Firefox being in JS (0)

Anonymous Coward | more than 6 years ago | (#24714879)

Exactly. There are leagions of people developing extension for firefox right now who could be possible future firefox UI developers.

Re:Precursor to more of Firefox being in JS (2, Informative)

Randle_Revar (229304) | more than 6 years ago | (#24715049)

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

Re:Precursor to more of Firefox being in JS (2, Interesting)

eclectechie (411647) | more than 6 years ago | (#24715449)

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

Whoa! Not so fast!

The Javascript interpreter in Firefox is written in C, and related stuff (XPConnect, etc.) is written in C++. You should go read it some time; this stuff was definitely NOT written by mere mortals.

You can browse the source at the Mozilla Developer Center; no link, so only the truly interested will go there. Look in mozilla/js/src.

Re:Precursor to more of Firefox being in JS (2, Insightful)

bcrowell (177657) | more than 6 years ago | (#24714847)

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.

Re:Precursor to more of Firefox being in JS (1)

i.of.the.storm (907783) | more than 6 years ago | (#24715007)

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 like they do in Java and get annoyed when they don't.

Re:Precursor to more of Firefox being in JS (2, Funny)

Anonymous Coward | more than 6 years ago | (#24715439)

its not your fault. java made you retarded.

Re:Precursor to more of Firefox being in JS (2, Interesting)

T-Ranger (10520) | more than 6 years ago | (#24714909)

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.

But that 10% that makes an application engine a web browser, or a mail client.. Most of that is written in Javascript. And most of it is "leaf" code, with not much cross calling, or dependencies that don't go through the underlying engine. Stuff that the just about total lack of "programming in the large" that Javascript has doesn't much matter.

Re:Precursor to more of Firefox being in JS (1)

i.of.the.storm (907783) | more than 6 years ago | (#24715043)

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:Precursor to more of Firefox being in JS (1)

cmacb (547347) | more than 6 years ago | (#24715033)

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

Or program the Windows OS in .net?

Re:Precursor to more of Firefox being in JS (1)

i.of.the.storm (907783) | more than 6 years ago | (#24715081)

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:Precursor to more of Firefox being in JS (2, Insightful)

RedWizzard (192002) | more than 6 years ago | (#24715107)

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).

Re:Precursor to more of Firefox being in JS (0)

Anonymous Coward | more than 6 years ago | (#24715165)

Javascript is:

- cross-platform
- very memory-corruption-safe
- extensible as a fundamental part of the language

and with this, it takes away one of the only advantages that compiled code has over this: performance.

Premature optimization.... (3, Insightful)

gandhi_2 (1108023) | more than 6 years ago | (#24714783)

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.

Re:Premature optimization.... (5, Funny)

Shados (741919) | more than 6 years ago | (#24714793)

Considering how long Javascript has been out, and that javascript intensive applications are clearly there in the present, I don't think this is premature =P Its late!

Re:Premature optimization.... (0)

Anonymous Coward | more than 6 years ago | (#24714819)

Its late!

Its late what?

Re:Premature optimization.... (0)

Anonymous Coward | more than 6 years ago | (#24715119)

August.

Re:Premature optimization.... (1)

ArsonSmith (13997) | more than 6 years ago | (#24715013)

Javascript is great for all intensive purposes on the web.

Re:Premature optimization.... (1)

Tontoman (737489) | more than 6 years ago | (#24715065)

javascript is a "macro language for browsers" and has all the benefits and drawbacks of any other macro language. If you need tight and responsive interraction among standard html form elements, and need cross-browser compatibility, then javascript rules.

Re:Premature optimization.... (0)

Anonymous Coward | more than 6 years ago | (#24715413)

Repeat after me:

intents and purposes
intents and purposes
intents and purposes

Re:Premature optimization.... (4, Informative)

Just Some Guy (3352) | more than 6 years ago | (#24715417)

intensive purposes

"Intents and purposes." Somewhere, an English teacher cries.

Re:Premature optimization.... (1)

walt-sjc (145127) | more than 6 years ago | (#24714877)

In order to COMPETE with flash, you need to do more. Like stupid simple multimedia.
Flash is not just a language - it is a rich media application framework.

And lets not forget that you would need to make javascript fast on IE. Good luck with that...

Re:Premature optimization.... (0)

Anonymous Coward | more than 6 years ago | (#24714947)

Why would you NEED to make it faster on IE? If IE performance is horrible for your favorite web app then you'll just move on to other browsers like... Firefox. This is a good thing.

Re:Premature optimization.... (1)

Firehed (942385) | more than 6 years ago | (#24715233)

Well aside from open-source evangelists being about choice (and it trumping them being against MS), it's a seriously flawed plan due to that little thing we call the business world. Thankfully nowhere I've worked has such a policy, but it's not at all rare for companies to require a certain browser because of some stupid proprietary shit on their intranet.

Don't get me wrong - I'd love to see IE die a miserable death, at least anything prior to the first fully standards-complaint version (8 supposedly, I'll reserve judgment until it ships), as it certainly causes me more than enough headache as a web developer. But until that time comes, I need to recognize and account for the very large number of users who either can't or won't shift off of IE. Depending on the nature of the site I'd consider putting a conditional tag that displays a "Switch to !IE" banner, but I'm not stupid enough to completely ignore anywhere from 60-80% of all internet users.

If slow web app performance helps shift users away from IE, so much the better. However, most of the people who think about their browser at any level are probably not using IE. Apple is doing their bit with an IE warning on the MobileMe site, but they're also one of few companies who can put that kind of thing on a high-profile site and get away with it. I'm sure that all of the web developers at Google, Yahoo, Facebook, et al would love to do the same, but their business models don't revolve around taking jabs at Microsoft either.

Re:Premature optimization.... (1)

erayd (1131355) | more than 6 years ago | (#24715015)

And lets not forget that you would need to make javascript fast on IE. Good luck with that...

Mozilla is doing just that - they're in the process of developing an IE plugin to port the entire firefox javascript engine over into the IE environment. It should run on at least IE 6+.

Re:Premature optimization.... (3, Informative)

Randle_Revar (229304) | more than 6 years ago | (#24715075)

Like stupid simple multimedia.

like SVG, <canvas> <audio> and <video>

Re:Premature optimization.... (1)

Jeff DeMaagd (2015) | more than 6 years ago | (#24715191)

I would be happier if they make it so I don't have to restart Firefox every few days, once a day or even a few times a day, in order to get it to be useable.

And no, for anyone with helpful suggestions, I don't have oodles of plug-ins, in fact, a very tiny number: 4. Adblock Plus, Flashblock, FxIF and NoScript.

link to nightly builds... try it out yourself (0)

Anonymous Coward | more than 6 years ago | (#24715285)

IF that's the case, he's a little chunk of hell:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Re:Premature optimization.... (1, Informative)

Anonymous Coward | more than 6 years ago | (#24715405)

It does rival Flash. They're working with Adobe on Tamarin, which is using the same core JS engine in Mozilla and Flash (ActionScript).

The environment the JS runs in is different, of course. But the language itself... not so much. (They do have different parsers, though. They're different dialects of ECMA-262)

Re:Premature optimization.... (1)

Tiles (993306) | more than 6 years ago | (#24715411)

Seeing as how the new improvements are based on Nanojit [mozillazine.org] , a component of Tamarin, the JIT ECMAScript compiler that powers Flash and which Adobe donated to Mozilla, I should think these improvements could rival Flash.

So super boosted JavaScript + NoScript.... (1)

More_Cowbell (957742) | more than 6 years ago | (#24714939)

Isn't that like dividing by zero?

Yeah.. but... (2, Funny)

EmagGeek (574360) | more than 6 years ago | (#24714961)

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

Re:Yeah.. but... (0)

Anonymous Coward | more than 6 years ago | (#24715137)

What does Javascript or Firefox have to do with a Sony Blu-ray player? Neither is used in it.

Not bad (5, Insightful)

neokushan (932374) | more than 6 years ago | (#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.

Oh no! (3, Funny)

Das Modell (969371) | more than 6 years ago | (#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?!

Re:Oh no! (0)

Anonymous Coward | more than 6 years ago | (#24715377)

It's over nine thousaaannnndd!!

so this means (0)

Anonymous Coward | more than 6 years ago | (#24715053)

So this means the javascript exploit of the week will be executed 20-40 times faster? Well, hellyah that's an improvement!!1 WTG! Next up, work on activejavaflashscript-X, because we need all the bases covered!

the proceeding was a paid advertisement for the Russian Business Network-because taking care of Your business is Our business

Server-Side is still the way to go if you can (1)

MazzThePianoman (996530) | more than 6 years ago | (#24715097)

Javascript still has its quirks because it works its magic client side. I am moving to use it as little as possible and never as a required piece of the site. PHP and other server side languages can do many of the things javascript can but with better support and accessibility.

Re:Server-Side is still the way to go if you can (1)

Firehed (942385) | more than 6 years ago | (#24715311)

Yes, for text transformations and such, do it server-side. When you find a way where I can move shit around the page at runtime in PHP, let me know - I'd love to be able to do that kind of thing for a dozen different reasons (fewer http requests for faster loading, no worries about browser inconsistencies, no concern about noscript, etc.) I could make some sort of Tab class and addTab($label, $content) method in my code and have it automatically output the relevant HTML and jQuery calls, but there's no way for me to do things with no javascript at all.

Doing anything that can be done server-side on the client side is generally a bad idea, so you're definitely taking the right approach. Unfortunately, there's just a ton of stuff that simply cannot be done server-side that you have to at least be reasonably familiar with both sides of things.

Re:Server-Side is still the way to go if you can (0)

Anonymous Coward | more than 6 years ago | (#24715341)

How else are you going to tackle a problem which requires dynamic form fields? You can either force the user to keep posting back to receive a new page with X more form fields (which is a frustrating headache), or you can use client-side interactivity to add form fields without talking to the server. That's only one of the plethora of situations where the best solution requires client-side processing. Go take a look at Google maps and tell me how you would pull that off with only PHP. (not to bash PHP, but use the appropriate tool)

Javascript is good (1)

Mike610544 (578872) | more than 6 years ago | (#24715103)

Most of my experience with Javascript has been adversarial just because one of my hobbies is screen scraping for raw data. For normal purposes though it seems like a near perfect solution. I have only a passing knowledge of its capabilities, but it seems that it's the rare technology that both hardcore comp-sci people and entry level developers can like. It's a custom purpose language, but doesn't it have first class functions? (They say every feature added to a language in the last 20 years is a less good version of something that's in Lisp, but I get the impression that the Javascript people really got it right.)

Re:Javascript is good (1)

fimbulvetr (598306) | more than 6 years ago | (#24715279)

If you took the time to learn JS well, you may find it's actually extremely well suited for screen scraping with.

Re:Javascript is good (1)

Mike610544 (578872) | more than 6 years ago | (#24715419)

I wasn't trying to screen scrape with Javascript (although you've piqued my interest now.) I was saying that embedded Javascript on the target pages was an impediment.

Dr. Michael Franz (4, Interesting)

tknd (979052) | more than 6 years ago | (#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.

Javascript is so broken in Linux Firefox... (0)

Anonymous Coward | more than 6 years ago | (#24715121)

It makes me want to go back to Win or buy a Mac or something. Recursing recursing recursing BLAM.

WTF Mozilla.

This moment of lost productivity... (-1, Offtopic)

buss_error (142273) | more than 6 years ago | (#24715123)

(fruity announcer's voice)

This moment of lost productivity is brought to you by...

JAVA...

It's what makes you wait!

(/voice)

Boosting Java performance is #1, but boosting compatibility would be even better. Nothing is worse than having to maintain multiple tens of thousands of desktops to run various versions of Java, depending on which application one wishs to run, and figuring out which version is better supported and making that all happen without the user being involved.

Welcome to my nightmare!

Re:This moment of lost productivity... (1)

Randle_Revar (229304) | more than 6 years ago | (#24715147)

What does Java have to do with this story?

Re:This moment of lost productivity... (0)

Anonymous Coward | more than 6 years ago | (#24715201)

Huh? Please mod down my parent for pure ignorance. Next he'll be talking about Ford performance, or perhaps horse racing. Javascript has absolutely NOTHING to do with Java.

Performance is great and all (5, Interesting)

MasterC (70492) | more than 6 years ago | (#24715163)

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.

Thank-youl (0)

Anonymous Coward | more than 6 years ago | (#24715385)

I hate Javascript. Using it is painful in ways that it doesn't need to be.

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!

Firefox has an error console that you can bring up to see errors in the script. This actually works quite well.

Re:Performance is great and all (0)

Abcd1234 (188840) | more than 6 years ago | (#24715393)

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.

Darn right. Virtually everyone one of your complaints is either based on personal taste (classes, strict typing, etc), missing bits of framework (threading, logging), or the inability to differentiate the DOM from JS the language (load order issues, dialog complaints, etc). About the only legitimate complaints I was able to identify are:

* lack of modules
* lack of namespaces

And both of these are well-known issues that were *supposed* to be addressed in JS4 (and hopefully will be addressed in the future).

Re:Performance is great and all (1)

Dwedit (232252) | more than 6 years ago | (#24715431)

Javascript-like languages can be compiled to bytecode as well, then the bytecode gets interpreted. Flash is the best example, all actionscript code gets compiled to actionscript bytecode, which Flash then interprets.

The biggest bottleneck for Javascript is the dynamic typing system. But there are still possibly ways to optimize around that. If you run through the code and find out what type a variable is really used as, you can remove the overhead of checking a variable's type all the time.

SpiderMonkey? SquirrelFish? (1)

FireIron (838223) | more than 6 years ago | (#24715177)

Wait 'til they see my new PlatypusLobster [tm] VM!

DIGG! (1, Troll)

furry_wookie (8361) | more than 6 years ago | (#24715189)

WHOOPIE!!!

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

Javascript can never run as fast as C (0)

martin-boundary (547041) | more than 6 years ago | (#24715305)

Javascript can never run as fast as equivalent C code, for the simple reason that Javascript is an interpreted language, whereas C is a compiled language.

Fundamentally, when C code is deployed, it is deployed as already compiled machine code, which takes essentially no overhead to execute directly.

When Javascript is deployed, after the source text is downloaded from a web site, it must first be converted into executable form suitable for a VM. That extra translation step is an overhead which must be amortized over the execution time of the code. Since most Javascript code takes very little time to execute in the first place, this translation overhead is a significant fraction of total computing time in typical applications.

It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.

Re:Javascript can never run as fast as C (1)

Abcd1234 (188840) | more than 6 years ago | (#24715425)

It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.

They are? Really! So you're saying Google Maps and gmail just fire off a bit of Javascript and then stop?

Oh, and you are aware that a significant portion of Firefox, itself, is written in Javascript?

That's pretty impressive... (4, Interesting)

Anik315 (585913) | more than 6 years ago | (#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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?