ajaxworldmagazine.com/read/333329_p.htm
Print Story How and Why AJAX, Not Java, Became the Favored Technology for RIAs Several of Bruce Tate's books focused on the flaws in Java and the need to let go of some of the ideas that haven't worked out.
And of course there's Steve Jobs now-famous quote (referring to the iPhone): "Java's not worth building in. This backlash has only been necessary because of Sun's death grip on the idea of ubiquitous, omniscient Java. It was admirable once, but a language only evolves if its designers and advocates can acknowledge problems. Pretending that a language is successful in places where it's not is just denial. Finally admitting that EJBs have cost the world enormously, the EJB3 team took lessons from Hibernate and Spring, but not enough to really fix the problem. Most people seem to find that Hibernate and Spring are still simpler and more straightforward than EJB3, so the lack of a rush back to a technology that had such a heavy cost in the past shouldn't be a surprise. Java 5 was a tacit admission that Microsoft was doing some very interesting things with C#, and proposed features in Java 7 support the idea that Java is now playing catch-up with C# 30 Competition is good, and Java is not dead. It continues to evolve, and the appearance of new languages built on the JVM, like JRuby, Scala and Groovy, is a sign of vitality in the world of Java. The Web is a Mess Seeing possibilities is great, but the downside is that it can be hard to acknowledge when something isn't working. The concept of the web was visionary, but much of the web is a failure. In particular, applications of any complexity using HTML, CSS and JavaScript are difficult and expensive to develop, and it seems virtually impossible to get identical appearances across browsers. Even simple pages look different because of font issues. If you use Firefox, how many sites do you visit that are at least partially unreadable because they've been created only for Internet Explorer (IE)? to the point that I'm seriously considering going back to IE. After years, it's still implemented inconsistently across browsers. As long as you're using HTML and CSS, you'll always wonder if what you've created is going to produce an unpleasant effect on different browsers. Browsers other than IE or Firefox can often get it even worse. JavaScript has been around since, effectively, the beginning of the Web, but the browser wars made JavaScript inconsistent and thus painful to use. A key part of Ajax is that someone has gone to the trouble of figuring out cross-platform JavaScript issues so you can ignore the often radical inconsistencies between different browsers. The first is that JavaScript is limited in what it can do. Although Ajax is an excellent hack that gets the last bit of mileage from JavaScript, it is nonetheless a hack, and the end is in sight. The second problem is that you are relying on Ajax libraries to handle cross-browser issues. If you want to write your own code, you must become an expert on those issues, and at that point much of the leverage of Ajax goes away. Ajax improves the experience a lot, but it has limits and I suspect we've already seen most of the tricks that Ajax is going to offer. Even more impressive is the Google Web Toolkit (GWT) which translates type-checked Java into cross-platform JavaScript in order to speed the development process. You write code in Java, and GWT compiles it into cross-browser JavaScript. JavaScript, then, becomes the intermediate code that will run on all platforms. But it took Google's brain trust to solve the problems that shouldn't have happened in the first place. And if the library you need isn't there, you must, again, be a cross-platform JavaScript expert in order to write new code. As brilliant as GWT is, I think it will still run out of gas due to the inherent limitations of JavaScript and browsers. We do see relatively amazing Ajax-based tools like GMail and the other Google tools which are slowly seducing me (but I repeat: it took Google to create those, not Joe garage-programmer). Very nice, but is this the best you ever want to see on the web? You're seeing, if not the limit, then very close to it in those applications, and even then they don't work consistently (yes, I know Google tools are "still in beta"). In GMail, for example, you're supposed to be able to press keys like r' to reply to a message. Sometimes this works, often it doesn't, to the point where it's maddening. And more and more often, when I use web applications like GMail, my "control-c" copy operation stops working. It could be Windows, Firefox, JavaScript or something else but it seems to be associated with web apps and it's been happening for at least a year. And frankly I don't care why it's happening, and neither does any other consumer. When things this simple are broken, the outlook is not promising. How much effort must we expend to compensate for the long sequence of misguided decisions that has produced today's web? Rich Internet Applications At some point we must ask why Java applets haven't become ubiquitous on the internet as the client-side standard for RIAs (Rich Internet Applications). This is an especially poignant question because Gosling and team justified rushing Java out the door (thus casting in stone many poorly-considered decisions) so that it could enable the internet revolution. That's why the AWT and Applets were thrown in at the last second, reportedly taking a month from conception to completion.
Bill Venners quotes Patrick Naughton as saying: "It was a timing issue, there was only about a three-month window in which the whole Java phenomenon could have happened.
and this attitude always seems to be a mistake when building programming languages. You're creating the fundamental architecture that you hope people will adopt and use for many years. This is the place that requires careful thought, not rushing. I can see why the Green Team took this attitude: it's the Microsoft Way. Throw a product out there in order to get your foot in the window. Over time, you can fix up any flaws that occurred from rushing the thing out. One of the most popular languages ever, Visual Basic, has evolved over the years. Python has fixed some things that would even break old code, in order to clean up the language. But for static languages with a large code base (verbose languages in particular), fixing things up doesn't seem to work so well. All the code must be recompiled and possibly changed--although I would argue that Java could have taken the Python approach: just don't upgrade if you don't want to change. There are lots of companies that don't upgrade to newer Java versions, anyway. The Installation Problem So Java has been around for 10 years and applets are not the primary way that we interact with the web. I think the main reason for this is the installation problem, another area of Java that wasn't well thought-out. It's clearly not because JavaScript is so easy to work with--JavaScript cross-platform problems are the reason people have avoided it in the past. Ajax is popular because we know that the necessary software for the client side is already installed. Someone had to figure out how to deal with the cross-platform issues for JavaScript first, but if JRE installation was trivial, everyone might have just created Java applets. But they didn't, applets are not ubiquitous, and everyone got excited about Ajax instead. Although it's gotten significantly better with ECMAScript standardization, I would still rather program with Java than JavaScript, the main reason being inconsistency. Maybe in eight years the current version of ECMAScript will be standard across almost all browsers. But the current version of JavaScript, despite the random implementations, is already available, and there are zero installation issues. I think that's a fairly good proof that the reason Java hasn't taken over as the RIA language of choice is the installation problem. Various fixes have been attempted for Java over the years, but I think the basic issue is that whoever is trying to solve the installation problem is someone who has a more inward technical focus r...
|