Flash Wasn’t
Sun’s Java Applet technology was 20 years early, but Flash wasn’t. Two years after the Java Applet technology first appeared, which enabled Java bytecode to run directly in the browser, Macromedia came in with Flash (technically one year before but they bought it and then re-released it as version 2 under the Flash name).
[ad#google]When Flash came out, unlike Java, it only featured very basic functionalities. It even took until 1998 before Flash could support any kind of scripts to customize interactivity. But that was all it took to fire it up for the web. It was small and quick, unlike Java which was quite the beast, and solved the purpose of achieving richer content on a web which at the time wasn’t even fast enough for streaming video.
Simply said, Java’s power wasn’t needed on the web. Even today, Java is still a bit too powerful for what people are looking for on the web, which is why applets are 20 years early, not 15 years early.
And so, Flash rose and was eventually bought by Adobe right along the introduction of video capabilities, which helped YouTube make streaming video on the web something everyone takes for granted just a few years later.
The Rise of the RIA Frameworks
In 2004, all the rave was about Web 2.0. YouTube was on the verge of being launched, Google Docs’ first iterations were right around the corner and the push for web standards was the brand new thing with Firefox. Thus, companies started to make bets on the technologies that would power Web 2.0. Adobe bought Flash and created Flex and Air, while the W3C thought about XHTML 2.0 to re-invent the web, and Google and company placed their bets on AJAX and HTML 5 to power their rich internet applications.
Make no mistake, HTML 5 is a much a contender in the RIA race than Flex is. Afterall, RIA means Rich Internet Application. This means rich media, like HD videos, and rich functionality, like editing documents in the browser. Both Flash and HTML 5 allow this as a platform.
Somewhat late to the game, Microsoft came in with Silverlight and Sun with JavaFX. Now, from the perspective of a web rich in web, Silverlight’s effort at making video and audio capabilities at the center of its aplication is intelligent, despite being late, but Sun’s JavaFX seems a bit incomprehensive and again, too much of a dog for the application its supposedely meant for.
RIA vs HTML 5
Unfortunately for Adobe, Microsoft and Sun, the web industry is moving away from plugins. Native is considered the new king and Google is leading the way with the fastest JavaScript interpreters ever seen and advanced HTML 5 features being used in Google Docs and even more so in Google Wave, making slow-to-adapt browsers like Internet Explorer irrelevant for the future.
The future of the web is as a platform, and a platform has to be capable to run applications on its own. With the release of the Google’s Go language and the impeding one of Chrome OS, the step towards pure cloud computing is even closer.
You can often hear a lot of people argumenting that Silverlight is incomplete because it does not offer a desktop alternative like Adobe does with Air. But Air is irrelevant; we live in a evermore cloud-based world and the future of desktop applications is bleak. This is something Microsoft might have surprisingly understood with Silverlight; that there is no point for Silverlight’s developement to enable it to go off the browser. It would be lost effort since the real future is in the cloud and on the browser as the new platform, not on the operating system. But because Microsoft makes Silverlight part of the whole .NET family, and WPF (Windows Presentation Foundation) largely serves as Silverlight for the desktop, but on Windows-only, obviously, you could suppose that Microsoft’s disregard of offline capability with Silverlight is but a coincidence along the way.
Wether there is a place for RIA frameworks based on plugins in the near future is to see, but a native approach, say the ability to run Google Go compiled apps directly in the Chrome browser, and Chrome OS as well, without a plugin, is very enticing, especially on the performance front.
The Need for Speed
JavaScript is already dead. It’s not fast enough, nor is it complex enough to handle complex applications with ease (see Object-Oriented Programming). Although Google seems not to think so, I’d rather think Google thinks exactly the same thing. The impending Google Chrome OS and their seemingly out of the blues move with the Go programming language is not a coincidence, it’s exactly what Lary Page and Sergey Brin are so obessed about: making the world more efficient.
Since the web, and more specifically Google, is moving towards open standards and ways to develop RIAs without plugins, nothing makes more sense for Google than to develop a compiled OOP alternative to JavaScript that would run natively in the browser.
But what’s more important is the emphasis on the need for speed. For today’s current web apps, JavaScript is plenty sufficient. More sophisitcated web apps like Aviary’s image editing suite don’t find enough there so they go to RIA frameworks like the Flash Platform. But then again, those platforms are too slow and too media oriented.
The need for speed might not be apparent today, but it will be in 2015, 5 years after the Chrome OS launches. 5 years is what it took for Firefox to completely change the landscape of web standards on the web. With technology evolving even faster than before, imagine what Chrome OS could bring as a change in the next 5 years.
Take Adobe Photoshop or Autodesk Maya or even games for example. Since all of these are high performance applications, it’s unimaginable to see them as real competitors in the form of web applications today. Software that applies to the professional creative market is still thought to be king on the desktop, but this is bound to change in the years to come as the need for cloud computing increases, and it makes the need for speed all the more present.
Adobe Flash and Microsoft Silveright might make very cool rich media apps, but their performance and capabilities, especially the sandbox restrictions, are not enough for the this future.
High Performance Applications are not gimmicks
For a lot of people, the lack of ease of GUI design in JavaFX makes it stucks a lot in comparison to Flash and Silverlight, which both comprehend complex and complete suites of design tools to aid in the process. But when it comes to high performance applications like Photoshop, nobody cares about GUI design tools or how well you can do stuff without having to code.
Actually, nobody wants it because it impedes on capabilities and performance capabilities. When it comes to developing software that requires amazing amounts of computing power, the last thing you want is for a framework of some sort to impede on your development. The GUI comes afterwards, and is an easy thing for experienced developers to integrate. These applications are not made on super quick schedules by three fresh out-of-college students with their small web site production start-up.
Hence, these applications are still developed with C++ as we speak. In fact, even applications that don’t require much of that performance, like Google Chrome, are even developed with some parts in Assembly code to make it really faster. We’re talking Native. The developers of these applications have no interest in faster development, they want their software to be faster and more capable, something achieved with more efforts, not smarter but lower-performing code.
Java is powerful but nobody knows
JavaFX and Java Applets are just about the same thing. They only differ in that JavaFX uses a new script that is a little bit less do-it-all than true Java and a bit more RIA-oriented, along the likes of ActionScript 3. But like Applets, it runs on Java.
When it comes to JavaFX though, I often hear, and I said so myself before, that it sucks because there’s not enough graphics tools. Not enough support for video and multimedia, etc. I often hear that it sucks because it takes too long to load, because it’s allows to much and can’t run without asking the user for permissions.
In other words, JavaFX, as well as Applets, can’t be logically used on a web site to power regular video streaming, interactive advertising banners or other similar small tidbits you might want to add in Flash or Silverlight on your site, like a really cool animated menu.
If you come to the conclusion that Java on the web is dead because of this, you’re far off what Java could potentially really power. Java is more powerful because for one, it is more performant. Java has access to tons of libraries, like OpenGL, which can allow sophisticated 3D games to run directly in the browser as well as all sorts of other high computing power software.
Take Photoshop for example. It’s not instantaneous piece of software to boot, and nobody expects it to be. When you open Photoshop, you’re usually going to use it for quite a bit of time. The time to boot the software then becomes irrelevant and you also need to install it first, which also requires you to accept that Photoshop might harm your computer by having more access to it for the sake of making the piece of software more useful.
You wouldn’t distribute news through PSDs (Photoshop’s file format), would you? Well saying you’re going to make a news site with Java Applets or JavaFX is pretty much the equivalent. You just don’t do that. And that’s where everybody gets JavaFX wrong.
Just look at the way JavaFX apps need your permission to run because they require more access to your computer. Sounds familiar? It should. That’s exactly what a desktop application does and that’s exactly what JavaFX is doing. It’s empowering you with all the power of Java inside a browser, under a new brand of Applets, to make high performance applications, or RIAs, possible on the web.
5 Years Early; JavaFX
Essentially, JavaFX is a move by Sun that recognizes Applets weren’t at their time. Whether JavaFX was really meant as a competitor to Flash-class applications is unknown to me, but I can assure you JavaFX and Java in general pose a real threat to any future competitor in the field of cloud-based high performance applications.
In fact, it doesn’t even pose a threat, because no one has yet to create an equivalent platform. Google might do it, but as far as it goes, it looks like Go will be remain on NaCl (Native Client), which is a plugin too, and has nowhere near the support and community of developers that Java does, not to mention libraries and stuff.
If Google is to make Go native on their browser, they still have ways to go to make developers accept it. Reactions to the Go language were largely negative on most parts, with most developers affirming that if Go was to be a compiled JavaScript, that it would need to be developed by the community and not as a Google product.
The game of developement platforms is played on two parts; developers and platform-makers. Developers are a very powerful croud. They can push web browsers to near ridicule around the globe and they can decide whether your platform succeeds since the platform utimlately relies on developers making software for it. On the other hand, market forces can trump a developer’s will. For example, the ability of Apple to sell the iPhone with key apps on its first iteration and rapidly gain market share made it a no-brainer for developers. If you want to rake in the cash on mobile apps, the iPhone is the way to go. The same applies to Windows with video games. You don’t see much video games being developed exclusively for Mac OS X or Linux.
Google is unfortunately not in a position where its new platform could grant it power. Even worse, the web industry is extremely fearful of the past and will run away from any solution that doesn’t promess to be cross-platform. For example, if Microsoft was to make C# apps native on Internet Explorer a-la-VBScript, people would start throwing rocks at them. If Google is to start a native non-plugin approach with Chrome and Go, it has a seriously hard challenge ahead and better make all the efforts possible to make this technology available plugin-less with the rest of the Linux community, which means Firefox and Safari, and somewhat Opera since it is a very standards-oriented browser well respected among web developers.
If it is to be a plugin, developers will also refuse it. Remember the movers of the web developement community are trying to push away from plugins and away from Flash. Silverlight might be used commercially, but it has largely been ignored by the rest of the world. Flash is already everywhere, why go all the trouble with Silverlight.
And that’s where Java comes in
Java is everywhere too. Java is even more everywhere than Flash as it is an open technology. Yes, contrary to both Flash and Silverlight, Java is open source, and it’s included on every Mac and Linux machine, which incidentally also means Chrome OS. Java is also easily downloable on Windows and most often pre-installed on OEM PCs and business PCs given to government and enterprise users.
In fact, a computer without Java is bound to ecounter some compatibility issues while surfing the web or installing applications. Much like Flash, Java is considered an essential peice of software to have on one’s computer.
When it comes to developing high performance web apps, remember the time to boot won’t matter much, so JavaFX or Java Applets are perfect for the performance benefits gained afterwards. The same goes for games.
Java is also an incredibly vast platform. It includes everything from server to desktop to the web browser plugin. One developer could learn Java and theoretically be able to program for all of these different platforms to make a wonderful all-in-one piece for a web app project. No need to learn the awkward marriage between Flash and PHP, which is by the way also pretty slow, and no need to learn a platform of which you don’t have access to the inner pinnings because it is proprietary like .NET and Silverlight.
Java can power your server-side and your client-side and talk to all of its pieces in wonderful harmony. But what’s especially important in Java, besides its librairies, is that once it’s bytecode, it does not matter where it came from. Program in Scala, Ruby, Python or anything you like; it does not matter. The JVM takes it all, client and server-side.
So while Java might not be the utlimate solution for small web page stuff, it’s quite the solution for future cloud-based professional applications. You might not see the future versions of Office in Java, but I can bet that if Google doesn’t trump it with Go, it will be a major platform for these types of software. And even if Google does trump it, it pays to start developing now because you’ll be first to market and you can be garanteed it will work on Chrome and Chrome OS. Java is a requirement for any computer, and I’m sure Chrome OS will not be of exception. It would be like Chrome OS without Flash if they were not to include it, so Java is far from dead.
Pingback: 12/5/2009 Update « Go Code
Thanks for the history lesson on Java I found it very interesting. I think Java on mobile devices will be the future of the platforms.
Indeed. Just take a look at Android and you’ve got your answer. The whole development there is already happening in Java and Symbian has always had strong support for it.