Because I still feel stupid for having made my original post without knowing that you needed to enable Tracemonkey, here's results from my home Windows machine, which is similar to my work machine (Intel Core2 Quad Q6600; work is XP 32 bit, home is Vista 64 bit):
Tracemonkey was faster than Chrome. I think it's odd that Chrome was slower than at work considering my home machine has much better parts. Chalk it up to Vista 64bit or something, I dunno.
After reading the rest of the article, and a reply below me, I think Tracemonkey wasn't enabled when I ran the Sunspider test on the 3.1 build. Therefore the numbers in my post are useless. Ignore.
The first thing I did after installing Chrome was run Sunspider. It averaged completion on my work machine in ~1.4 seconds. I went and got two different 3.1 builds with Tracemonkey (9/3 and 9/2) and it averaged ~2.3 seconds. I was kind of surprised as I did expect Tracemonkey to be faster than V8. The only test that Tracemonkey outperformed V8 was the regex test, all the others it got completely spanked.
Sorry, don't have the actual numbers. Like I said, this was on my work computer.
The task manager in Chrome lies. It reports to me that none of its processes are using more than 0% CPU time, yet I can clearly see from both Windows Task Manager and Process Explorer that one of the processes is using up one of my cores entirely (20-25% CPU time on a 4 core system), and I have 1 tab open at the home page, and it is displaying nothing. *shrug*
Which is funny because they could solve that and be the fastest very easily: just toss the Javascript into the.NET runtime, it already includes a JScript.NET compiler.
Then, apparently since you AGREE WITH ME? Your point was flawed - it's pretty simple to fix, in that IF you don't use javascript, then you ARE SAFE vs. attacks that involved the use of javascript... period.
So I take it is your opinion that if browsers used Python instead of Javascript as their page scripting language that we would not see XSS attacks?
I didn't answer your post because you clearly didn't read mine, or at least failed to comprehend it. It is not a Javascript issue, it is a browser security issue. Yes, turning off Javascript eliminates the problem. But that's merely treating a symptom, not the disease.
As I said, if more browsers than IE supported multiple scripting languages you would see these exact same attacks in other languages. It's like claiming that because Windows is written in C/C++, and Windows has lots of virus problems, therefore C/C++ are at fault (well, C++ is for being a shoddy language >_>), not Windows security.
Does this make sense to you now or is it still flying right over your head?
Those have nothing to do with Javascript. XSS attacks are all about flaws in the browser's security (or the specific web app). The fact that Javascript is used to take advantage of them is completely irrelevant; you could take advantage of them using VBScript in IE, or if you plugged a Python/Ruby/Lua/*insert language here* runtime into your browser of choice, you could use those languages to take advantage of the same flaw.
Christ, between people's completely clueless ranting about XSS and the DOM, it's a wonder that Brendan Eich hasn't been declared a terrorist and sent to Gitmo.
Only Spidermonkey based browsers currently can do it, obviously. Personally, I think this is a better solution than a heavy-weight threading system. Real coroutines would be even better, though you really have to hand it to the guy for coming up with the solution he did.
And I left a Vista box I was using at work on for 3 months before finally deciding to reboot it one weekend because Windows Update was so backed up with patches I needed to install that it was bothering me constantly to reboot. Plus I don't recall a single reboot of our file server that was running Windows 2003 server during the time I was there (~9 months). So what's your point?
Maybe you don't work in an at-will state, but in those states either side can terminate employment at any time for any reason (caveat: employers cannot terminate for discriminatory reasons such as age, gender, race, etc) without notice or further compensation.
Yes, I have. At my last job basically our entire test framework was written in Javascript. Why, I'm not sure, but it was. I also do most of my scripting in Javascript and execute using Rhino. If it's not going fast enough, I just use Rhino to compile it all to Java bytecode and execute it directly in the JVM.
As I said elsewhere in this thread, just because Javascript is widely used for browser scripting, does not mean that is its only use. Your blurb at the beginning is completely irrelevant to this topic.
To display anything at all with javascript requires you to reference the DOM means that they are effectively parts of the same problem.
You seem to be under the mistaken assumption that Javascript only executes in the browser. A lot of my one off scripting is done in Javascript which I run using Rhino, a standalone Javascript interpreter. There are many other Javascript interpreters which are not tied into the browser.
The fact that Javascript is widely used for browser scripting does not mean that Javascript can only be used to do browser scripting. Hence it is completely valid to dismiss claims of Javascript incompatibilities between browsers when the actual incompatibility being referenced is a DOM implementation problem.
I really like the type-safety features and the MUCH better way to do OO.
Javascript never really got prototypes right. I think the looks-like (duck typing) way of doing OO is very nifty, and prototypes (true prototypes like in Io and SELF) is probably one of the best ways of doing it.
Slashdot Mirror
Because I still feel stupid for having made my original post without knowing that you needed to enable Tracemonkey, here's results from my home Windows machine, which is similar to my work machine (Intel Core2 Quad Q6600; work is XP 32 bit, home is Vista 64 bit):
Chrome Sunspider results (TinyURL to Sunspider results)
Tracemonkey Sunspider results (TinyURL to Sunspider results)
Tracemonkey was faster than Chrome. I think it's odd that Chrome was slower than at work considering my home machine has much better parts. Chalk it up to Vista 64bit or something, I dunno.
After reading the rest of the article, and a reply below me, I think Tracemonkey wasn't enabled when I ran the Sunspider test on the 3.1 build. Therefore the numbers in my post are useless. Ignore.
The first thing I did after installing Chrome was run Sunspider. It averaged completion on my work machine in ~1.4 seconds. I went and got two different 3.1 builds with Tracemonkey (9/3 and 9/2) and it averaged ~2.3 seconds. I was kind of surprised as I did expect Tracemonkey to be faster than V8. The only test that Tracemonkey outperformed V8 was the regex test, all the others it got completely spanked.
Sorry, don't have the actual numbers. Like I said, this was on my work computer.
The task manager in Chrome lies. It reports to me that none of its processes are using more than 0% CPU time, yet I can clearly see from both Windows Task Manager and Process Explorer that one of the processes is using up one of my cores entirely (20-25% CPU time on a 4 core system), and I have 1 tab open at the home page, and it is displaying nothing. *shrug*
Which is funny because they could solve that and be the fastest very easily: just toss the Javascript into the .NET runtime, it already includes a JScript.NET compiler.
Spidermonkey
Interactive shell and supports shebang.
Rhino
Interactive shell but doesn't support shebang.
Beanshell. Tada! Java scripting, not to be confused with Javascript.
You're right. I was trying to point out that the problem is not contained specifically to, nor inherently caused by, Javascript. Silly me.
Now you're just being disingenuous. Offtopic my ass...
Then, apparently since you AGREE WITH ME? Your point was flawed - it's pretty simple to fix, in that IF you don't use javascript, then you ARE SAFE vs. attacks that involved the use of javascript... period.
So I take it is your opinion that if browsers used Python instead of Javascript as their page scripting language that we would not see XSS attacks?
Yes, turning off Javascript eliminates the problem. But that's merely treating a symptom, not the disease.
No, I get your point. It's just flawed. This is pointless.
I didn't answer your post because you clearly didn't read mine, or at least failed to comprehend it. It is not a Javascript issue, it is a browser security issue. Yes, turning off Javascript eliminates the problem. But that's merely treating a symptom, not the disease.
As I said, if more browsers than IE supported multiple scripting languages you would see these exact same attacks in other languages. It's like claiming that because Windows is written in C/C++, and Windows has lots of virus problems, therefore C/C++ are at fault (well, C++ is for being a shoddy language >_>), not Windows security.
Does this make sense to you now or is it still flying right over your head?
Those have nothing to do with Javascript. XSS attacks are all about flaws in the browser's security (or the specific web app). The fact that Javascript is used to take advantage of them is completely irrelevant; you could take advantage of them using VBScript in IE, or if you plugged a Python/Ruby/Lua/*insert language here* runtime into your browser of choice, you could use those languages to take advantage of the same flaw.
Christ, between people's completely clueless ranting about XSS and the DOM, it's a wonder that Brendan Eich hasn't been declared a terrorist and sent to Gitmo.
Coroutines in Javascript 1.7
Only Spidermonkey based browsers currently can do it, obviously. Personally, I think this is a better solution than a heavy-weight threading system. Real coroutines would be even better, though you really have to hand it to the guy for coming up with the solution he did.
And I left a Vista box I was using at work on for 3 months before finally deciding to reboot it one weekend because Windows Update was so backed up with patches I needed to install that it was bothering me constantly to reboot. Plus I don't recall a single reboot of our file server that was running Windows 2003 server during the time I was there (~9 months). So what's your point?
Maybe you don't work in an at-will state, but in those states either side can terminate employment at any time for any reason (caveat: employers cannot terminate for discriminatory reasons such as age, gender, race, etc) without notice or further compensation.
Yes, I have. At my last job basically our entire test framework was written in Javascript. Why, I'm not sure, but it was. I also do most of my scripting in Javascript and execute using Rhino. If it's not going fast enough, I just use Rhino to compile it all to Java bytecode and execute it directly in the JVM.
As I said elsewhere in this thread, just because Javascript is widely used for browser scripting, does not mean that is its only use. Your blurb at the beginning is completely irrelevant to this topic.
To display anything at all with javascript requires you to reference the DOM means that they are effectively parts of the same problem.
You seem to be under the mistaken assumption that Javascript only executes in the browser. A lot of my one off scripting is done in Javascript which I run using Rhino, a standalone Javascript interpreter. There are many other Javascript interpreters which are not tied into the browser.
The fact that Javascript is widely used for browser scripting does not mean that Javascript can only be used to do browser scripting. Hence it is completely valid to dismiss claims of Javascript incompatibilities between browsers when the actual incompatibility being referenced is a DOM implementation problem.
Stop confusing DOM for Javascript. They are completely unrelated.
The Screaming Vacuum?
Get TweakUI and enable X-Mouse. Set delay to 0 ms and window focus will follow the mouse cursor.
I really like the type-safety features and the MUCH better way to do OO. Javascript never really got prototypes right. I think the looks-like (duck typing) way of doing OO is very nifty, and prototypes (true prototypes like in Io and SELF) is probably one of the best ways of doing it.
Yeah, NTFS has implemented execution privileges since forever. Not anyone's fault but your own you don't know how to use them.
You should probably have that ego checked out; it might lead to your head spontaneously exploding if left unchecked.