The much glossed-over answer is that JavaScript and HTML just isn't a good environment for rich app development, for many reasons. One "elephant in the room" kind of issue is that JavaScript's object system is not acceptable to most programmers, and most programmers require classical OOP.
Even prototype system fanatics probably would have to admit that the current state of JavaScript doesn't work very well, with its warts like the "this" keyword behavior, and the tendency for all framework authors to role their own mutually incompatible systems.
Even Google seems to have backed off from this space recently - have you heard much mention of Chrome OS lately?
> Even Google seems to have backed off from this space recently - have you heard much mention of Chrome OS lately?
I hear about Chrome OS every single day, because I follow its development. Many hardware manufactures will be releasing Chrome OS netbooks in November / December of this year. Google doesn't generally hype things before they are available to consumers, so there's no reason to expect lots of Chrome OS discussion while it's still in development.
Google is still very hardcore about JavaScript/HTML5 development.
This is my biggest gripe about HTML5. They had the chance to really fix a lot of missteps but they made the (IMO) horrible mistake of using JavaScript as their "assembly language". Regardless of what anyone thinks about JavaScript, not everyone is going to want to program with it. Many of us will be programming in something else and compile to the base browser language.
What should have happened is that they just define a (high level) VM that we can all compile to. The browsers could have certain languages they compile to this VM language their self (e.g. JavaScribt, VBScript, etc.) and the rest of us compile to a binary file and point to that in our HTML page (e.g. <code type="vm" location="code/main.hvm"/>)
Oh dear... on paper great, but can you imagine how long it would have taken them to come to a standard? I think HTML5 is already a bit on the side of being a step too wide, but I guess we've been stuck in HTML4 (and related technologies) for so long that it was necessary. XHTML 2 was an awesome language, imho... just another case of too much meat on the fire, and so never reaching a conclusion.
Let's get a good HTML5 system now, and then we can think of adding additional scripting languages. The best is the enemy of the good. :)
>Oh dear... on paper great, but can you imagine how long it would have taken them to come to a standard?
I don't think it would have to take too long. One browser could do it and then the others could copy it. Further, the standard could be general until it's worked out more.
"The semantics of this can be tricky. At times it refers to the global object (in most places), the scope of the caller (in eval), a node in the DOM tree (when attached using an event handler HTML attribute), a newly created object (in a constructor), or some other object (if function was call()ed or apply()ed)."
The pragmatic answer is to limit its use except when absolutely required (as Google's guide suggests). The more problematic meta-problem, is that many people do think it's valuable and don't understand it and dig themselves into some subtle and insidious messes.
Avoiding something you don't understand might seem like a good idea when programming, but if it's a core part of the language you're using -- like 'this' in JavaScript -- trying to understand it and use it appropriately is actually a much better approach.
I've seen JS code that tries to avoid using 'this', and it often ends up a lot more complicated and tightly coupled than code which uses it appropriately.
The behaviour of 'this' in JavaScript is different to Java and other OO languages, but it isn't that complicated to understand.
There are some problems with HTML/Javascript but I find it reasonably good as a developer. The problems with it are all about the lack of standardized apis to native OS functions - audio, video, microphone, etc. It always seems to lag about 5 years behind the most interesting apis (eg: now I would want accelerometer apis ...)
Even prototype system fanatics probably would have to admit that the current state of JavaScript doesn't work very well, with its warts like the "this" keyword behavior, and the tendency for all framework authors to role their own mutually incompatible systems.
Even Google seems to have backed off from this space recently - have you heard much mention of Chrome OS lately?