If I was trying to think of something less representative of large well written javascript application I would have a hard time thinking of something better than JSLint.
It doesnt touch the dom, is not event driven, doesnt involve loading lots of files and does not render anything
> It doesnt touch the dom, is not event driven, doesnt involve loading lots of files and does not render anything.
It can be argued what constitutes JS engine, and what makes other parts of browser. I'd tend toward `pure JS' view of the JS engine; excluding DOM document and DOM events. [0]
Measuring speed of `naked, bare' JS engine makes some sense, even if not directly for web developers and web users. As some other posters pointed out, JS itself may be used for server-side scripting or general data processing, where access to DOM may be irrelevant. Just raw JS and some custom API for I/O.
However, I don't trust this method of benchmarking fully. There are optimization techniques that may skew results quite a bit. I guess dead code optimization could end up taking whole loops out of JSLint's code, if there are no side effects. That was implicated in discussions about some earlier benchmarks by other authors.
----
[0] Not sure if it makes a strong case, but here goes: when Apple forked Konqueror's KHTML into WebKit, they used own JS engine instead of KJS.
I agree that its a good idea to test raw js performance, particularly for browser developers, however its extremely disingenuous to represent it as a typical workload of a javascript browser application when its pretty much the opposite
You are 100% correct. Benchmarking Javascript on "well-written Javascript applications" doesn't even make sense to do. When benchmarking stuff, we should be worried about things where speed actually matters.
For instance:
What FPS rate can your browser can get when performing certain rendering operations on an HTML5 canvas?
Or how well does it perform with WebGL? Oh wait, IE10 won't even have WebGL.
Let's be honest here. Most people are using jQuery to write new applications. Shouldn't we mostly be benchmarking jQuery and some common plugins? Maybe prototype as well. And benchmark the most common functions etc.
There are many server-side applications that do exactly what you just described and JavaScript is starting to move into that space. So this is quite relevant and will become even more so over time.
and that aside I dont think its anywhere near a good test for server side javascript either, server side js in particular its bottlenecks are mostly about shifting bits, pulling stuff down from the database or retrieving from the http socket, they usually do some string manipulation as well but its fairly minor compared to io
It doesnt touch the dom, is not event driven, doesnt involve loading lots of files and does not render anything