Unfortunately, JavaScript (plus its DOM interface with the outside world) is a pretty poor choice for such UVM role.
First, with its dynamic typing, prototype-based structure, it's one of the hardest languages to optimize and even next-gen JITs like V8/TM/ Nitro will not compete with Java (even with HotSpot Client) any time soon (or with Silverlight's CLR, for that matter). JS apps only look fast when they are thin layers over non-JS services like DOM, WebGL, canvas/video/audio support, etc. or when the network is the bottleneck (gmail, maps, etc.) so the user accepts delays as something natural. Any app that depends on a large amount of JS code, or contains complex, CPU-bound JS algorithms, will be a fiasco for many years to come. In the old times we'd just say "yeah whatever, let's just wait the next couple Moore's Law doublings of CPU speed", but these are the new times and CPUs are not getting faster in any significant speed, so until somebody comes up with a magic parallelization framework, language speed will matter a lot. Second, JS/web apps still lacks very important features. While the next round of progressive-rock-browsers will implement such things as accelerated 3D, I'm still waiting for such simple delicacies as support for custom right-button menus, drag&drop, clipboard integration, etc. There's also the hard reality of MSIE lagging as much as they can get away with, to support these latest enhancements, because Microsofts agenda with Silverlight competes radically with the pure-web RIA. Now MS is talking IE9 which should have a JIT-compiled JS VM with decent performance, plus some HTML5 support. But this only means that IE9, in late 2010 or 2011, will be as good as the state-of- the-art of 2008 (at best). And many corps are still dragging their feet with IE6; it's clear to me that pushing a plugin (that is compatible with old IEs) is less hard than pushing the latest browsers. If Java applets/JAWS (with or without JavaFX) fail, I On 30 nov, 10:56, Casper Bang <casper.b...@gmail.com> wrote: > People are no longer programming directly in JavaScript though, but > abstractions on top a la jQuery and GWT which shields the developer > from most of the ugliness. Google has proven time and again how they > perceive JavaScript as nothing less than a universal machine layer > opening the door for universal access (computers, phones, picture > frames etc.). I think Sun missed that opportunity when NetScape made > JavaScript the de-facto language over Java. > > /Casper > > On Nov 30, 1:04 pm, Simon Brocklehurst <si...@psynixis.com> wrote: > > > On Nov 30, 1:27 am, Josh McDonald <j...@joshmcdonald.info> wrote: > > > > 2) Stop with the applet. Seriously. The browser plugin war is over, Adobe > > > won. Years ago. And before Java 7 is ready and modularised, Google will > > > have > > > gotten V8 and (Canvas||a replacement for Canvas) up to par. It's just more > > > important to them than Java 7 and FX are to Sun (which is not how it > > > should > > > be IMO), they have more money, and they've built a nest of hackers where > > > even @dhanji isn't (always) the smartest guy in the room. The JVM is > > > *awesome*, but Tamarin is good enough for the browser. > > > That's an interesting suggestion. You might be right that this war is > > already lost. Personally, I hope not - I think JavaScript is a poor > > choice of language for building sophisticated browser-based > > applications. *If* it is lost, though, the consequences are serious, > > because it will restrict every non-browser RIA platform to a pretty > > small niche. That's because close to 100% of people have already > > decided they want 80% of the computer systems they access via a > > desktop computer to run inside a browser, -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
