Slashdot Mirror

In typical MS fashion it didn't get good until 3 versions later, IE4, before getting proprietary vendor lockin with that piece of shit IE6.

If IE6 was such a piece of shit, as you put it, that implies that the other browsers at the time were much worse than that. You've inadvertently made a profound statement about the browser landscape of the day. IE6 rightfully earned infamy in its unnaturally long life even more repugnant is rampant revisionism. IE introduced a feature that is the foundation of today's web, some of you might be aware of the XMLHttpRequest object, for the non-developers it's like the force now, all around us. JavaScript support and performance, CSS support. Unfortunately this period had to occur, and it will occur again once these lessons are forgotten; Without the stranglehold IE6 eventually obtained, and more importantly stagnated the web with, the choices we have today wouldn't exist.

Their stupidity of not being able to down-grade IE or simultaneously install different versions so web developers could test ALL the various versions, forcing people to rely on hacks like SandBoxie, was absolutely retarded.

As much as it pains me to say Microsoft wasn't unique in this regard, as an aside, try installing multiple versions of Safari. Even the easy mode package managers don't support multiple versions of browsers out of the box (not to say it's difficult). Internet Explorer 6 released in 2001 following the launch of Windows XP. For those unfamiliar with their history, Web Development of that era revolved around IE and Netscape. With IE being the Chrome of its day (as in "works here, onward!") since the browser market was 90%+ IE and IE6 was supported on Windows 98, NT, and 2k. Low usage for potential targets results in a chicken and the egg problem. Low single digits just aren't a priority for many shops, see Opera.

Sandboxie came out in 2004ish and has its uses, especially on 32bit machines. However, for web development involving IE it's much easier to use MultiIE which has been around since 2006. IETester is worth another mention. Not to mention there are alternatives due to the ever growing number of devices and variants released year after year, requiring a different approach such as farms that show screenshots from targeted browsers. Regarding the hassle of Sandboxie, limiting yourself to one tool is pretty silly.

This is a little off topic. Since this criticism is being framed as a Microsoft issue you might be shocked to discover how apps and to a lesser extent websites, are developed and tested in 2015 on devices manufactured and supported by multiple vendors. This process requires physical devices, in many cases multiple to support the popular OS versions on them (there are other OS, but they're less than 8%). Think it's a hack to wrangle Sandboxes or multiple installations, try wrangling devices that let you only upgrade! But what about device simulators, one might ask? Oh yes, they do exist and they're improving but there isn't a substitute for deploying and testing on device. IE variants are a dwindling piece of the very large fragmentation pie.

Microsoft writing the browser from scratch, is too little, too late.

Too late for whom? W

asm.js is fantastic! Anyone who says JavaScript is slow should read about how they ported the Unreal Engine 3 to asm.js and got over 140 fps.

To be fair there's been a lot of new stuff introduced from 1.8 onwards as part of ECMAScript 5, which do address a lot of the shortcomings of the language, including a lot of object changes - properties and descriptors, frozen objects, Object.getOwnPropertyNames etc. Development is proceeding rapidly after a long period of stasis.

Well just to make the situation a bit clearer

So perhaps this decision to go javascript was influenced by the programming luminary John Resig (he recently joined Khan Academy [1] )?

Or is it the other way around, did Khan Academy go and hire Resig because he's a javascript ninja [2] ?

Either way, despite my discomfort with some of the features of javascript, this decision makes complete sense. JS has really been pushed forward by the ECMA [3] giving it a strong momentum for solid, controlled, future growth. Finally and most importantly, unlike any other language, javascript has the most available full programming environment, as the VM exists in every browser and IDE and testing tools (firebug, webkit inspector, etc) are numerous and powerful.

[1] http://ejohn.org/blog/next-steps-in-2011/
[2] http://jsninja.com/
[3] http://en.wikipedia.org/wiki/ECMAScript

After all, I read John Resig's blog post about this in December 2011.

If you enjoyed reading that, you might also enjoy reading this and the follow-up about efficiently storing a dictionary of words and dealing with memory v.s processing trade-offs.

If you enjoyed reading that, you might also enjoy reading this and the follow-up about efficiently storing a dictionary of words and dealing with memory v.s processing trade-offs.

Ruby and others in a browser, not so revolutionary now but interesting.
http://ejohn.org/blog/the-browser-scripting-revolution/

TCL in a browser, if it were integrated it would be more relevant.
http://www.tcl.tk/software/plugin/:Python

I doubt gawk, perl, bash scripting or others will run in a browser soon.

http://ejohn.org/blog/running-java-in-javascript/

I think you've been inhaling a bit too much PHP. Just because Javascript is dynamically typed (and it's not alone in this respect, many interpreted languages are), doesn't mean the types are irrelevant. Sure, Javascript will coerce types sometimes, but it's pretty logical about it once you understand how it works. The only real complaint I have is overloading + for string concatenation as well as addition.

What you're asking for is an object that will coerce its inputs, which you can do, you just need to follow good programming practices--mainly, never allow public access to an object's members. If you use getter/setter functions, you can explicitly coerce your types once in the object and then everywhere you use it you no longer have to worry about it. It's standard OO best-practices. http://ejohn.org/blog/javascript-getters-and-setters/ is a good place to start to explore that in JS.

Programming languages have never had "reads the programmers mind" as a feature.

Well, there's this article, but it's quite outdated and benchmarking technique is not clear.

Hmm, it would be fun to compare browser JS engines' performance growth vs libraries bloat...

Sorry for the error in line breaks. Here it is again.

I feel like I'm the only one who likes it. Very clean and non distracting. The comment control is AWESOME.
Of course, there is lots of room for improvement. Here are some technical performance suggestions:

* Its YSlow grade is C. For a site with such huge traffic as /. has, it could be better. A good part is due to advertisement and A/B testing. A/B testing should be removed eventually so I will get better. However, there is still a couple of changes that could help:
- Enable GZip compression for javascript files in a.fsdn.com
- Combine comments_minified.js with all-minified.js. It's not worth it to have it separated into a different script. You can just delay the execution. Specially when gzipped it would weight around 6-7kb instead of 30kb.
- Slashdot pages are rather big. I believe that's why you chose to put a lot of javascript in the head. You should consider at least moving it after the article/s. That way the article will be shown faster even if the rest of the page and the comments are delayed a bit.
- It would help a lot to reduce the size of the page. Using the scroll event to show more comments as twitter does could be a good idea. Check out John Resig's latest post about it http://ejohn.org/blog/learning-from-twitter/
- Extend the life of the cached files. Use "access plus ten years" instead of a two week period. The correct strategy isn't to use the query string to manage versions but to use the filename for it. Rename the all-minified.js file to all-v1-minified.js and change it when needed.
- Add the expires header for logo.png and favicon.ico
- Remove E-tags
- In the homepage, the RSS, facebook and twitter buttons are three different images. You should reuse the sprite from the add-this widget http://s7.addthis.com/static/r07/widget26_32x32.png and consider writing your own widget and adding it to your main script.

I feel like I'm the only one who likes it. Very clean and non distracting. The comment control is AWESOME. Of course, there is lots of room for improvement. Here are some technical performance suggestions: * Its YSlow grade is C. For a site with such huge traffic as /. has, it could be better. A good part is due to advertisement and A/B testing. A/B testing should be removed eventually so I will get better. However, there is still a couple of changes that could help: - Enable GZip compression for javascript files in a.fsdn.com - Combine comments_minified.js with all-minified.js. It's not worth it to have it separated into a different script. You can just delay the execution. Specially when gzipped it would weight around 6-7kb instead of 30kb. - Slashdot pages are rather big. I believe that's why you chose to put a lot of javascript in the head. You should consider at least moving it after the article/s. That way the article will be shown faster even if the rest of the page and the comments are delayed a bit. - It would help a lot to reduce the size of the page. Using the scroll event to show more comments as twitter does could be a good idea. Check out John Resig's latest post about it http://ejohn.org/blog/learning-from-twitter/ - Extend the life of the cached files. Use "access plus ten years" instead of a two week period. The correct strategy isn't to use the query string to manage versions but to use the filename for it. Rename the all-minified.js file to all-v1-minified.js and change it when needed. - Add the expires header for logo.png and favicon.ico - Remove E-tags - In the homepage, the RSS, facebook and twitter buttons are three different images. You should reuse the sprite from the add-this widget http://s7.addthis.com/static/r07/widget26_32x32.png and consider writing your own widget and adding it to your main script.

At this point, this is nothing more than another "me too" sort of post, but I like it. I can agree that there is probably more whitespace than needs to be, but I don't find it distracting. I'm fairly indifferent on "position: fixed" elements on a page, so I can't relate to the out-rage over the header and sidebar. I can copy & paste into text boxes again, so that's a plus. As for performance, if there's any kind of "comment auto-loading" based on scrollbar event firing, see Learning from Twitter by John Resig. I haven't personally experienced this yet, so this may not be the issue at all. Anyway, definitely an improvement in appearance.

you know, there was a great post about how badly twitter went downhill with some simple scrolling issues.

ah, here it is: http://ejohn.org/blog/learning-from-twitter/

please, slashdot, learn from twitter. please?

Here:

The trackpad is absolutely infuriating. It’s as if Google attempted to create a similar trackpad to the Macbook Pro but just got it all wrong. There is two-finger scrolling (good) but no acceleration. Tap-to-click is frustrating and I disabled it immediately. There is no three-finger swipe-to-go-back gesture (which I miss a lot). Performing text selection is absolutely insane. It seems like any combination of having two fingers on the mouse pad simultaneously throws the laptop into “scroll” mode. It’s so bad that it makes me not want to write things on the laptop until it is fixed. As mentioned before there appears to be physical way of doing a right click – but I can’t find a single place in the UI where right-clicking has an effect.

I found this almost exact issue with the cheap netbook trackpads. Too bad Google didn't put a bit more effort into their prototype there.

The keyboard is easily the best part of the Cr-48 hardware. Replacing Capslock with a “New Tab” button is truly inspired. I’ve found myself already starting to rely upon it very heavily. The keyboard feels good to type on and the large Ctrl + Alt keys make for easy key combinations (important when using screen).

Sounds great.

Right now my ideal laptop would be: Take a 13 Macbook Pro, replace the HD with an SSD, replace the DVD drive with more battery, add 3G. I would use that laptop until the end of time.

This is pretty much my setup (external battery unfortunately, and USB 3G card).

Firstly, it's not my choice.

Wait, is it "not your choice" or is your policy to only fix "absolute brokens" (whatever those are)?

Secondly, I do not understand what all these "performance" comments are lately. I havnt' seen any browser that had bad performance on a modern machine. What are you doing, playing networked quake???

No, I'm not playing games, I'm writing large-scale online service applications. You know, the same sort of Javascript-powered applications that Google produces (Maps, Gmail, Docs, etc).

Here's an example. This is a Javascript benchmark for several recent browsers. You can see that IE8 is an order of magnitude slower than everything else:

http://ie.microsoft.com/testdrive/benchmarks/SunSpider/Default.html

Also notice that IE9 is there, it's faster than Firefox 3.7. Notice also what's missing from that graph: IE6 and IE7. If you look at that graph and think that IE8 is pretty far behind, take a look at this:

http://ejohn.org/blog/javascript-performance-rundown/

The first graph on that page shows IE7. While IE8 on that graph is 2x slower than the next slowest, IE7 is nearly 4x slower than IE8. IE7 is more than 10x slower than the fastest browser in that graph.

And I'm just talking about IE7 here. IE7 was an improvement over IE6, so you can imagine where IE6 would place there. In fact, IE6 is both so old and so bad that I'm having a hard time even finding benchmarks which include it.

But hey, since you clearly have access to IE6, go ahead and take the test yourself:

http://www2.webkit.org/perf/sunspider-0.9/sunspider.html

Keep in mind that lower is better because it's a measure of time, and that Microsoft is reporting a score for Opera 10.5 at about 300ms. I just ran the test here on my POS laptop with Opera 10.5 with 12 other tabs open, and it completed the test in 1126ms. You go ahead and run that test with IE6 and, assuming it's even able to finish it, then maybe you'll understand what all this "performance" talk is about.

I havnt' seen any browser that had bad performance on a modern machine.

No, I disagree, I think that you haven't seen a browser which had good performance on a modern machine, and you don't even realize there's an alternative to the only thing you know.

Don't get your hopes up for IE9.

All IE versions including IE8 have a subtle knife to hold back web progress. IE doesn't style unknown elements without the hideous HTML5 shiv hack.

There are several other things, the most significant of which in my opinion is property descriptors:

eg. For any property (value/function) of an object you can specify whether it is: writable, enumerable, or configurable; allowing for read only properties, properties which do not pollute a for(val in obj) call, and properties which cannot be messed with by other programmers.

See: http://ejohn.org/blog/ecmascript-5-objects-and-properties/ for a better description.

Brendan Eich's notes about an early draft and "Programming in the large" and a blog post about ECMAScript 5's strict mode (which does far more checking) talk of features that will hopefully give people a better change at dealing with the issues you raised.

OK not so useful to you now but hey...

They're called web workers, in the process of being W3C standardized, with shipping code in Firefox 3.5, Safari 4 and Chrome, with fallbacks possible to google gears on other browsers. Basically they're threads with no shared memory model, relying only on message passing / event mechanisms for synchronization.

With web workers you can do stuff like ray tracing or interactive video processing in the browser. If you can't see the potential for that in client-side code then nothing I say further will convince you otherwise.

john reisig ...

http://ejohn.org/blog/javascript-sparklines/

N///

To extend the analogy someone else used earlier, OO in Javascript is like attempting to tighten a screw with a hammer.

I respectfully disagree.

See for example John Resig's approach. Basically it adds more familiar class-based inheritance to JavaScript, building upon the existing prototype-based inheritance. I am using it in a large project (see my homepage link), and it works great. Btw, it seems Google has something similar in the Closure Library, as well, but I didn't check if it was as concise as Resig's.

JavaScript is a flexible language (Crockford once called it "Lisp in C's clothing"), which lets you 'extend' it in ways like the one linked to above.

There is already a Ruby VM that runs in a browser: Hotruby : http://hotruby.yukoba.jp/

John Resig even blogged about it ages ago: http://ejohn.org/blog/ruby-vm-in-javascript/

Also, JS.class, while not a Ruby VM, is pretty cool and actually useful: http://blog.jcoglan.com/2009/06/08/jsclass-21-an-improved-pacakge-manager-proper-hashes-and-lots-of-ruby-19-goodness/ - http://ajaxian.com/archives/jsclass-21-released

Knowing John Resig, I doubt this is vaporware. He's come up with some really amazing stuff and is constantly posting interesting JavaScript tidbits and information for developing real production code on his blog.

> Does IE have better javascript performance?

Yes - massively so, than before, though the gains are not as much as other browsers. This link is old but you can see even in beta 2 IE8 was at least 4 times as fast as IE7 and that was before a lot of optimisation was done. In the final cut I would expect an order of magnitude improvement - which of course, is *still* less than other browsers, but nonetheless it approaches being game changing in terms of what you can do ... if only we didn't have to support IE6 .... argh!

http://ejohn.org/blog/javascript-performance-rundown/

Saw this yesterday my time

You might be interested:

http://ejohn.org/blog/ocr-and-neural-nets-in-javascript/

"A pretty amazing piece of JavaScript dropped yesterday and it's going to take a little bit to digest it all. It's a GreaseMonkey script, written by 'ShaunF', that automatically solves captchas provided by the site Megaupload. There's a demo online if you wish to give it a spin."

Fairly basic (the captcha's) but as a proof of concept piece of code it is interesting.

That? That's easy.

http://lbi.lostboys.nl/blog/artikelen/canvas-in-full-3d/
http://www.nihilogic.dk/labs/wolf/
http://www.nihilogic.dk/labs/canvas3dtexture_0.2/
http://blog.nihilogic.dk/2008/06/3d-javascript-chess-mouse-support.html
http://www.kaarellumi.com/asylum/html/dyn10.htm
http://acko.net/files/projective/index.html
http://wiioperasdk.com/

I have seen 3D experiments that do environment mapping like you showed, but I'm afraid I don't have them handy. Of course, I doubt either Papervision 3D or a Javascript 3D engine would work very well on the iPhone. If the Canvas3D spec gets finalized, then we might end up with direct access to the 3D hardware which *would* make it possible to run 3D on such devices. (I've been asking for that on the Wii for some time. Especially since the fill rate in the browser is awful.)

Don't let my little game fool you. I'm limited to the technical capabilities of a much less powerful machine than your average desktop. (i.e. The Nintendo Wii) Since I couldn't push as many pixels on that platform, I threw in a few cinematic effects to add some pizazz. I can and have made that game run so fast on the desktop so as to be unplayable. Thus what you see is intentional limiting to keep a game at a reasonable speed. Browsers are capable of a LOT more these days.

It's not so much about what you CAN do in Javascript/DHTML, but how much you have to invest to make certain things a reality. I've been coding in Flex for the last year and I cannot imagine how much work I'd have to go through to reproduce some of the applications I've built in Javascript/DHTML, much less to have it work consistently on a variety of operating systems.

It's really not that hard once you get the hang of it. The big difference I think is that it's not a very mature market yet. But it is growing and FAST. I give it a year, maybe two before JS applications start displacing Flash.

Check these out:
http://blog.nihilogic.dk/2009/01/2008-year-of-awesome-javascript.html
http://www.pixastic.com/
http://ejohn.org/blog/processingjs/
http://jstween.blogspot.com/

That being said: Jon Resig, the author of jquery did publish some fairly minimal class-like system on his blog that I found useful at times..

If you're into grokking the underlying language, try reading John Resig's book or his articles online.

I've found that my desire to have a fundamental understanding of javascript, which kept me away from most of the popular libraries for quite a while, is one of the main reasons I love jQuery, and also that understanding jQuery and how it works has given me a much better fundamental understanding of javascript.

While jQuery does create a pretty big abstraction from the core DOM functions, it does so efficiently.

I'm confident that when I use jQuery to find a list of elements with a particular class for example, that I wouldn't be able to write something from scratch to achieve the same effect that would be substantially more resource efficient.

It's also, last I looked, the smallest download of any of the major js libraries.

However, when we contacted Mozilla, they advised us to use the release version which is the most compatible and bug-free. (The latest 3.1 beta does not include the code that optimizes JavaScript apps, however.)

FF3.1 t is not including lately tracemonkey?

Anyway, there was a (2 months old, not sure how much changed things since) comparision between js engines in http://ejohn.org/blog/javascript-performance-rundown/ if you want to compare it against chrome.

I pretty much agree with what you wrote. Just as an addendum, here's a very recent example of a successful cooperation between a person who discovered a security vulnerability (John Resig) and the software vendor (Apple):

Clickjacking iPhone Attack

Did you try it with the latest beta of Firefox with TraceMonkey turned on?
The new engine in Fx 3.1 is supposed to be faster than V8, and V8 is the fastest JavaScript engine right now.
http://ejohn.org/blog/javascript-performance-rundown/

Tower Defense in javascript

http://ejohn.org/blog/processingjs-tower-defense/

"It is surprising how different the versions of webkit are."

This is untrue, and mostly a product of misunderstanding but partly a product of FUD as well. More on this below...

"the current release of Chrome is almost 4 times faster than the current release of Safari"

This really has almost nothing to do with Webkit, and does not demonstrate a difference in the rendering engines at all. Ultimately what we're looking at here is a comparison of JavaScriptCore (Safari's current* ECMAScript interpreter)â"released 19 June 2008, with only minor changes from the major version from more than a year earlierâ"and V8 (Google's ECMAScript-bytecode translator engine)â"released 5 September 2008 against a codebase that was nearly brand new; while it's true that JSC is a [legacy] part of Webkit, V8 is not a part of Webkit at all. Comparing the two isn't really meaningful.

Moreover, Chrome is not released, it's a very, very early, unpolished beta.

A more apt comparison would be...

"It would be interesting to see if the Safari nightly builds have closed this gap." ... the nightly builds, which use a similar engine (SFX is somewhat different in its approach, but ultimately in the same class as V8). And in fact, performance is roughly the same. It's not like this information isn't widely available, either.

I can't speak to the particular benchmark in question or whether it even has merit as a general browser benchmark (note, Google's benchmark has little merit here, as it strictly tests JS language speed, rather than DOM performance [which is extremely important for nearly all browser performance experiences]), and I don't have an environment which would be suited to finding out for myself, but I encourage you if you're that curious to try a nightly build on the test yourself.

With that said, there are existing browser benchmarks (eg Dromaeo 2) that tell a story much more interesting story.

John Resig on JS engine performance
This shows JSC (not SF or SFX) beating V8 on a bunch of DOM tests

But I want to reiterate, this is hardly a good example of differences in Webkit releases. These are differences in browser releases and over a very wide stretch of time (in the current JS engine war, especially).

* By "current", I mean "released"; it is current in that sense, but actually two generations old in the Webkit project. The Webkit team has since produced SquirrelFish and SquirrelFish Extreme, the latter being much closer to (and often faster than) Chrome's performance on every task except (if I recall correctly) recursion.

The whole article is just a troll.
Have a look at John Resig's benchmarks to see some real numbers.
What is notable there is that IE8 has massive javascript performance improvements over IE7 and while it's behind it's still comparable to (as in, same order of magnitude) as the other browsers of the coming generation.

• from John Ressig
• from Darren Hobbs
• From Brendan
• SquirrelFish seems faster?

http://ejohn.org/blog/processingjs/

http://ejohn.org/blog/processingjs/

``Also a real pity, i wonder if the so called improved javascript VM will actually ever make it in the real world... cause we REALLY REALLY need optimized javascript;''

Well, it seems several people are already working on that. From Mozilla, there is Tamarin. From Apple, there is SquirrelFish.

And here's a comparison of the performance of various JavaScript engines, including Tamarin, SquirrelFish, and Chrome's V8.

So google stripped the HTML 5 standard local storage api from Webkit to use their own implementation Google Gears. Why? The api was already there, and it worked, so they had to strip it out to go with google gears, their own, not w3c compliant. I think they are starting to become evil.

Webkit page rendering has always been very fast. On Windows, Chrome feels like Safari. John Resig has some benchmarks for the javascript engines. Disclaimer: He is a guy from Mozilla. http://ejohn.org/blog/javascript-performance-rundown/. Summary: Javascript performance should feel about the same. Google is guilty of pr crap with their own "benchmark".

http://developer.mozilla.org/En/DOM_improvements_in_Firefox_3

It seems they have been focusing on extending the DOM support but TraceMonkey will eventually be used to enhance FF's DOM performance

(Excerpt from this page: http://ejohn.org/blog/tracemonkey/)

Right now there isn't any tracing being done into DOM methods (only across pure-JavaScript objects) - but that is something that will be rectified. Being able to trace through a DOM method would successfully speed up, not only, math and object-intensive applications (as it does now) but also regular DOM manipulation and property access.

Did you read that press release all by yourself? Let's wait for some solid testing before we judge eh?

Newer doesn't necessarily = better

http://ejohn.org/blog/javascript-performance-rundown/

You mean like this solid testing?

Disclaimer; it's beta, and I've been using it for only ~20 minutes.

First off it installed fine, it's attractive, it has some good ideas. I have to say though it uses more memory, and is slower, doing a side-by-side comparison with Firefox. Using it to view a youtube video while running a processing.js script, and scrolling, seemed to show Firefox running much faster and with fewer interruptions than Chrome.

Also one thing that'll bug Chrome users is that when you click on a tab, if you click&drag just a tiny bit the tab breaks off into a new window, and you have to drag it back into the window it was previously in.

I think this has promise, and it's a very welcome addition, but it's not gonna top Firefox from day 1.

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

Next step is that we shall be able to see a server-side compiled JavaScript

If you're talking about servers sending precompiled bytecode in place of javascript, no that isn't the next step or even on the agenda. Unless that is you have a VM in javascript.

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.

You don't need bytecode for that.

• http://haxe.org/doc/intro
• http://www.openlaszlo.org/
• http://code.google.com/p/pyjamas/
• http://code.google.com/webtoolkit/

Let's spell it out, some want to use the CLR for web applications (I'm never installing Mono). Some don't like the fact that web client apps in javascript are inherently open source. Seems to me that there are more compelling reasons not to standardize on a common bytecode.

It would nice to see some demos of this with John Resig's Processing.js. 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.

There are already some Javascript games out there. Two examples I can think of off the top of my head are:

Processed Tower Defense is a strategy game where you try to defeat waves of dangerous monsters before they reach your tower. Of course, its less of a tower and more of a blueish square on the right side of the screen, but the idea stands.

It is created using the Canvas element and the Processing.js Library by John Resig

Track Attack is a puzzle game where you have to lay out the tracks to to the destination so that the train does not crash. Yes, I am aware that I made this game, and I am aware it's still a work in progress.