Is the Javascript bet a loser or a winner one?

Recently I had the the sensation that the world is trying to port *every* existing application in HTML5. The proliferation of Javascript API meant to cover almost every programmer's need is the tangible proof. There's an API for every taste: graphics (2D/3D), audio, video, realtime communication, filesystem access, permanent storage, database, connectivity and many more. Everythings seems really nice, but the shame is that at the basis we have Javascript.

Now, I cannot say that I'm a real every-day Javascript programmer, and I don't know anyone like that, that's why my experience is not so meaningful, but in the last time I found myself writing some prototypes to see which can be the limit of HTML5. The outcome for me has been discouraging. I find that the language itself, when writing something more complicated than dealing whith some DOM manipulation and event-handling, is not *handy* (read: maintainable, readable, sharable, ..). But the real problem is not the sytax which may be a matter of taste, but the fact that I see there is a stubborness of people trying to make a *universal* language out of Javascript, with the browser acting as a sort of a Virtual Machine, which, as a matter of fact, is not and never(?) will be.

The availability of new APIs certainly creates many possibilities, and developers are trying to take advantage of them, but at the end they may eventually fight against the inevitable and intrinsic slowness of the language. A slow language, even with every possible shiny feature, remains a slow language, and in some cases this is a true limit.

In the past 5/6 years we have seen really huge improvements in Javascript enginges, but today Javascript is still a slow language, and I have the feeling that there is no more room for great improvement in this.

So, what now?

With GWT (that I think has already reached its top), Google wanted to simplify the developers' life, taking Javascript away from them, and offering every kind of optimization to squeeze Javascript at its limit.

Then Google created a new language, [dart][1], with its own Virtual Machine running on a browser ([Dartium]), and which aspires to completly replace Javascript from every browser; in the meanwhile you can always compile it into Javascript (as GWT does).

Mozilla has created [asm.js][2] where (if I get it right), one can write applications in C/C++, compile the code with clang obtaining LLVM bitcode, which can be compiled again in (a small subset) of Javascript, which, if executed in a special version of Firefox, it can reach great performance.

Now, as a programmer, I find myself writing a real HTML5 program, where I have to fight against the Javascript poor performance, and I see that the world is puzzling trying to find exotic ways to overcome the problem, and I ask myself: would it be such a bad thing to keep Flash (or equivalent technologies) alive?
Isn't this Javascript *hype* (I'm exaggerating here..) just trying to make it behave different from what it actually is?
Am I the only one seeing this trend?



There is another interesting

There is another interesting trend.
You have pointed to current Javascript alternatives for client programming (hiding or replacing javascript, GWT and Dart) but there are also frameworks like Vaadin and Echo3.
With those framework you are going to program the web application like a desktop application, eliminating the client-server decoupling. One less layer, one less state, no javascript.
These solutions look well suited for business web applications and for a limited user base but I think this is the 90% of web applications out there.
Yeha, developing only on the server side, looks great,

your opinion, have you tried them?

I've never used Echo3 (which

I've never used Echo3 (which I've never heard of before!) nor Vaadin. But I worked with JSF/Richfaces, which I think share the same philosophy, but I might be wrong.
I don't like this kind of approach; programming both the client and the server side in a "semi" transparent way, without having to worry (until something goes wrong) about javascript, DOM, Ajax calls, or restful services, looks good. But everything is good until something doesn't work as expected. And this happened too many times for me in the past, and debugging a system where everything is hidden from the developer is really hard. Sometimes the problem was the misuse of the tool, some other was some hidden remote bug of an unkown javascpt library which no one knows what it really does.
Things get worse when your system has to integrate with other system or if you need to do something not supported by the framework. Yes you can build a plugin, or an extension, but how many really wants to do it?
Finally, the problem with these system is the scalability. Since the UI state is built and mantained in the Server along each user session, when you have too many user, the server will suffer too much. Yes you can always build a cluster, but the complexity increases. The same load could easily be managed by a single server with RESTful services and a rich javascript application.
But remember that these opinions are based on my experience with JSF/Richfaces, which may be slightly different from Vaadin and Echo3..