(1) Why not packaging and releasing separate JDK and JRE (here, J is for JavaScript), that is, outside Mozilla releases ?

While more speed gives JS a greater interest as a language, it deserves separate JDK and JRE. Then, it might be a candidate for other script language (Perl ? may be more Tcl/TK ?) replacement, for scripting outside browsers.

(2) The first point raises the question of the JavaScript standard library.

I have suggested, when commenting a previous post (Comparing the evolution of Java and JavaScript), that JS needs a more standard library like Java (a CPAN web site ?). If one wants to push JS higher, and, as one example, outside browsers for more scripting, then JS needs a API giving more access to system resources, like file resources.

(3) A JIT compiler is better efficient while having more type information. JS may need optional (!) type information for execution speed improvement.

Currently, one could define a counter like “var i = 1;” while a “int i = 1;” definition could be more interesting for a compiler :
(a) the first form just says “i” is a variable, currently initialized as an integer, but with no constant type attached.
(b) the latter option just says that “i” is always an integer and if no conversion could be done when assigning later this variable, then an error should be raised.
As a scripting language, the constraint is that both forms should be accepted by JS. Questions remain about introducing more (optional!) typed styles for defining variables into JS as a language.

I was always hoping Gears would took the mantle on this, as well as extending Canvas support to IE6. :)

As for Canvas, it very much depends on what you’re doing.

For JS heavy things that require little to no rendering such as per pixel manipulations ( convolutions, morphoMath operations, and other color manipulations ) JIT can provide a significant improvement. However for rendering heavy things ( think polygon rendering, whole Canvas based post-processing, … ) JIT won’t do much as in such cases the bottle neck is clearly — even today — the graphic engine of the browser.

Which is pretty much the way all these work. They compile to JavaScript.

Hmm, not strictly true – it lets you write code in C# which is then used to generate Javascript, to be deployed as usual.

It now runs real time :-)

Big thanks to the traceMonkey team for making this happen!

But with google gears localserver we can make the download cost less painful. I see the download problem as easily solved.

It’s becoming more and more obvious that the way to build web apps is going to be using a javascript framework to build all-javascript apps that connect to web services. It marries the benefits of server-hosted application code with the benefits of client-side code execution.

Let me give you an example from the iPhone. The following code:
var a = 0;
for(i=0; i<50; i++) {
ctx.strokeStyle = “red”;
ctx.save();
ctx.translate(i*10, i*10);
ctx.rotate(3.141529*2*((a + i)/10));
draw(ctx);
ctx.restore();
}
}

function draw(ctx) {
ctx.beginPath();
ctx.moveTo(0, 0);
ctx.lineTo(10, 0);
ctx.lineTo(10, 10);
ctx.lineTo(0, 10);
ctx.closePath();
ctx.stroke();
}

Which draws 50 rectangles, will run far far faster with a canvas width/height of 100×100 or 200×200 vs 400×400. The slow down does not occur during the actual canvas 2d calls. If you try to time the calls, they run very fast. The slow down comes after yielding the JS interpreter CPU (e.g. setTimeout). Whatever the browser is doing (copying offscreen buffer onto browser surface) when your drawing thread yields, it is enormously slow and scales by number of pixels.

That is, the Javascript code does the same amount of work (touches identical number of screen pixels), but using a larger canvas (most of it whitespace which is not rendered into) can slow down rendering by 4x, clearly, something is wrong with WebKit Canvas on the iPhone.

I would also like to add, that while the speed boost will encourage the size of Javascript applications to increase in scale, the Javascript language itself makes optimizing for downsize difficult, and the JITs can’t optimize away code before it is downloaded. So, the downside of the JIT performance improvements, in combination with the torpedoing of Javascript 2, effectively leaves nothing but laborious and non-standard hacks to glue together large JS applications (unless you use GWT that is)