> Sorry for being disorganized. The big problem I see with this is that > Javascript isn't that well standardized across browsers, especially > because they have to support all sorts of cruft from the early days.
True, which is why we need an official industry standard... somehow. :) > So it'll be hard to put Java on top. Javascript is also a lot slower > than Java but becoming faster fast. Java in it's early days was also > slow (and became faster), but both the language and the VM were > specified a lot tighter than Javascript is now. But what we might achieve through "JavaScript as universal bytecode" is the successful bootstrapping of a real™ VM. We're not there yet because people are still trying to use the traditional browser container model, even if it's riddled with interoperability problems (i.e. keyboard accelerators). The language would have to transition a la what jQuery did with the DOM, into another best-practice syntax. > Maybe the next > ECMAscript version will help there? From what I remember, Microsoft > blocked big advances the last time around (much to the chagrin of > Adobe which based it's Actionscript language on earlier drafts of > ECMAscript that then never came to be). I don't know much about that, except that Microsoft has exactly one vote in Ecma like anyone else. Obviously everyone has to see the advantage, and hopefully Microsoft will too (if indeed they don't already given the recent channelization of Silverlight from a plugin technology to the Win Mobile 6 stack). -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
