So, Google built GWT as an abstraction layer over JavaScript which has, fairly effectively (I do a lot of GWT work), made JS little more than a really poorly purposed intermediate form akin to Java bytecode. GWT's pretty fast, but it's certainly limited by the need to express its compiled form in a language designed for humans. It also, interestingly, has a facility for breaking apart a codebase into multiple components for loading in the background.
Now, enter Google's Native Client... It allows a program to be expressed in a very low-level representation (a subset of the x86 instruction set) and interact with the DOM/Event model just as does JavaScript (please fact check this). The Google folks are now working on using LLVM inside the Native Client so that programs downloaded over the web may be expressed in its bit code as a means of platform independence. Hmmmm....so what's the difference between a bunch of bit code and a bunch of machine generated and optimized Javascript? Still a lot, but we're getting pretty close. One would have to send his own infrastructure (garbage collector, etc.) along for the ride with the LLVM Native Client scheme, but that seems like a surmountable problem. There's even a project to build a JVM/CLI impl on top of LLVM (http://vmkit.llvm.org/).
Google seems to be working toward making the browser into a sort of X server, and they're attacking the problem from both ends...a SDK with a community around it in a widely-used language (GWT), and a sandboxed, platform agnostic runtime which will allow for a wide variety of languages/ecosystems to run upon it. With the exception of bleeding-edge games, whatever remaining value native applications for 95% of users will be entirely eroded. We can also observe Google's web printing initiative as yet another means of decoupling most people's computing needs from any particular full-fledged operating system.
What I don't understand is how Google will manage to get this scheme adopted as a standard. I believe Mozilla said they aren't in favor of it. And, Microsoft certainly won't play along until they risk having no browser marketshare without it. End users don't care that their computing experience involves DOM and JS -- they just care that it's secure and works well. As a developer, I'd love the freedom of building apps in a language of my choice (presuming it can compile down to the LLVM and run in the browser/Native Client sandbox.
Do people on HN think I'm nuts? Is the endgame of the web a universal application "player" as Microsoft has surely feared for over a decade? What is there to lose in such a scheme? One downside for Google would be that machine-readable content is required for search. But, search is so important for app/site developers that all involved would be willing to make accommodations (see Google's published scheme for allowing GWT/AJAX-y apps to be made crawlable).
You've received several votes for your comment, and I respect that.
But I also respect those who prefer a language which offers type safety. One which does not lay traps of unexpected coercion and unfathomably unusual truth tables. I respect a language which can guarantee and enforce immutability at compile time. I respect a language which has had a sensible packaging system from the outset. One which served as the foundation for many as an introduction to object-oriented programming. A language whose primary implementation is based upon a powerful, performant virtual machine, and one which has had excellent support for concurrent execution of programs and components thereof for nearly a decade. I respect a language whose implementations are not wildly divergent. I am fortunate enough to work with a language whose underlying implementation is flexible enough to host dozens of both static and dynamic languages - including JavaScript itself.
What I do not respect are blanket unqualified absolutist statements and fundamentalisms. I understand that you may have found yourself frustrated at points during which you've written Java in the past. I would like to hear about these, and understand them better. But I'd also encourage you to avoid such totalizing statements, as for a variety of reasons, many may have very good reasons for enjoying things you do not.
Javascript and Java manifest their defects differently. Javascript has its own special deployment problems (largely due to history not just intrinsic problems) but for the most part its defects surface as surprising behavior in certain specific cases (unusual truth tables to be sure, but hardly unfathomable), these can bite you but once known they can be avoided and worked around. Java's faults generally manifest as limitations to what you can do. This makes Java seem more polished but the result in practice has been the generation of quite a lot of ugly and cumbersome code to work around those limitations, this is not a good thing.
Java is not a bad language, but its limitations have led to a lot of bad engineering. Javascript is far from perfect, but its core elegance has led to increasingly sophisticated and increasingly powerful uses of the language. In another, say, 10 years the state of Java development will almost certainly continue the status quo of today, whereas the state of javascript development is likely to have considerably advanced.
JavaScript's standard stalled after ECMA-262 3rd Edition, but that was pretty much because of the IE monopoly and the death of Netscape. All web standards stalled, or went off to XML la-la land.
That was then (1999-2004). Since Firefox restarted browser competition in 2004; then with Safari, the iPhone, etc.; and since 2008 with Google Chrome, which clearly provoked major work in IE9; things are moving again, and standards bodies (still dysfunctional in some hard-to-fix ways) are more balanced than ever in terms vendor representation.
So yeah, the next ten years seem likely to be be different from the last ten.
Not only due to browser competition, but also from the Bell's Law device shift to always-connected, instant-on mobile and away from desktop, indicated above via "Safari, the iPhone, etc."
Some fear this shift means non-interoperable, siloed apps and closed app-stores will dominate, but my money is still on the Web. The Web can evolve to have better apps and stores too, provided browser and Web platform markets remain competitive.
I realized after making this comment that some people, swannodette included, were not aware of ES5, which my pointing to Harmony overlooked. ES5 support is almost there in the latest browsers:
It does not fill some of the big gaps left in JS (no module system, that's coming in Harmony), but it helps and it got the standards committee back together (sans Adobe).
I fear this shift means non-interoperable siloed apps which happen to be written in JavaScript and deployed via HTTP. The open web of repurposable semantic markup that lives at a permanent URL is eroding.
Huh? What are these uses of JavaScript that are increasingly sophisticated and powerful?
Uh, any web app? Gmail? Google Maps? The one I'm working on? Surely we don't need to make a list.
If JavaScript continues to advance at the lightning pace it's been advancing these past ten years we'll be in exactly the same spot we are now!
That's incorrect. The language didn't need to change much. The two things that have changed are so major they couldn't be majorer: (1) it took people 10 years to actually figure out what they had in JS; (2) the implementations needed to catch up. While 1 may be more or less done, 2 is still in full swing. This will enable further innovation. It's not even clear we need major changes to the language itself. I'd be much more excited if the VMs were opened up to apps.
I'm not in love with GWT becaue it's Java although I probably am below average among HNers in my dislike of the Java language.
It has been rare that Google has introduced some piece of technology to the world where, even if it first seemed to be some one-off oddity, was not part of some grander plan which had yet to emerge. Take GOOG411 as an example -- it was a cheap way to mileage on voice recognition tools for Android. Take Google Maps, Android, and GOOG411 all in isolation, and the company seems a bit nutty. But, once it became clear that they were all part of a strategy for location-based advertising, everything began to make sense.
I look at GWT, the Native Client project, and Web Printing as a couple of similar data points. Clearly, Google is positioned to come out ahead as the Windows desktop loses prominence. So, what might we infer about Google's intentions given the historical cohesiveness of its technology strategies coupled with the existence of these projects? The point of my post was not to argue the merits of GWT but to ask whether it is logical to presume Google's intent is to replace JavaScript as the sole means of programatic expression on the client.
I love that most of the Google Collections stuff can be used in GWT. Sadly, its predicates and transformers would benefit from the closures found in Javascript.
It's more accurate to say Google wants to make the browser into a Sun NeWS server, which did exactly as you describe, but with PostScript, not JavaScript. Sun also had a project to do this with Tcl/Tk. And really, that was one of the early visions for Java too. So Sun had three tries at this, and it never caught on. Perhaps Google will have more luck... Or perhaps it's a wild goose chase.
So, Google built GWT as an abstraction layer over JavaScript which has, fairly effectively (I do a lot of GWT work), made JS little more than a really poorly purposed intermediate form akin to Java bytecode. GWT's pretty fast, but it's certainly limited by the need to express its compiled form in a language designed for humans. It also, interestingly, has a facility for breaking apart a codebase into multiple components for loading in the background.
Now, enter Google's Native Client... It allows a program to be expressed in a very low-level representation (a subset of the x86 instruction set) and interact with the DOM/Event model just as does JavaScript (please fact check this). The Google folks are now working on using LLVM inside the Native Client so that programs downloaded over the web may be expressed in its bit code as a means of platform independence. Hmmmm....so what's the difference between a bunch of bit code and a bunch of machine generated and optimized Javascript? Still a lot, but we're getting pretty close. One would have to send his own infrastructure (garbage collector, etc.) along for the ride with the LLVM Native Client scheme, but that seems like a surmountable problem. There's even a project to build a JVM/CLI impl on top of LLVM (http://vmkit.llvm.org/).
Google seems to be working toward making the browser into a sort of X server, and they're attacking the problem from both ends...a SDK with a community around it in a widely-used language (GWT), and a sandboxed, platform agnostic runtime which will allow for a wide variety of languages/ecosystems to run upon it. With the exception of bleeding-edge games, whatever remaining value native applications for 95% of users will be entirely eroded. We can also observe Google's web printing initiative as yet another means of decoupling most people's computing needs from any particular full-fledged operating system.
What I don't understand is how Google will manage to get this scheme adopted as a standard. I believe Mozilla said they aren't in favor of it. And, Microsoft certainly won't play along until they risk having no browser marketshare without it. End users don't care that their computing experience involves DOM and JS -- they just care that it's secure and works well. As a developer, I'd love the freedom of building apps in a language of my choice (presuming it can compile down to the LLVM and run in the browser/Native Client sandbox.
Do people on HN think I'm nuts? Is the endgame of the web a universal application "player" as Microsoft has surely feared for over a decade? What is there to lose in such a scheme? One downside for Google would be that machine-readable content is required for search. But, search is so important for app/site developers that all involved would be willing to make accommodations (see Google's published scheme for allowing GWT/AJAX-y apps to be made crawlable).