The web browser is one of the great equalizers of the world. It's why Microsoft feared Netscape. If something runs in the browser, it doesn't matter where it came from. HTML, JavaScript, CSS are agnostic of the technology used to generate them. Don't get me wrong, browsers have their "quirks" and certain technologies make use of these quirks more readily than others, but these things aren't coupled. I can create an XHTML compliant application using ASP.NET and C# just as easily as I can create an app that uses lots of IE-only HTML and JavaScript using PHP.
There is an exception to this uniformity and that comes from browser extensions/plug-ins. These are capable of doing more proprietary communication with back-end servers. In a world where a new rich internet application framework is being introduced by some multi-billion dollar software company each month, one could easily imagine a tight coupling between such frameworks and the server technologies that feed them.
Of course the mother of these new frameworks is Flex, Adobe's application platform built on top of Flash. One of the common companions to Flex is Flex Data Services. This is actually an Enterprise Java application for accessing enterprise resources (like databases) and serving up data to Flex clients. One would guess that you could do the same thing on your own, and not just in Java. Your Flex client makes gets/posts to a URL and parses the response for a data model. You could even use SOAP for all this, if you were a masochist.
The design behind Silverlight seems very similar. The quick start tutorials from Microsoft show a Silverlight client connecting to a web service. Thus it should not be too hard to build a Silverlight application that talks to a Java or PHP server. On a side note, I had one interesting realization from reading through some of the Silverlight tutorials. They make a big deal distinguishing between client-side Silverlight code written in managed CLR (i.e. C# or VB.NET) as opposed to code written in a scripting language such as JavaScript or Iron Python. My understanding of the CLR was that everything was compiled into Intermediate Language (IL.) It sounds like if you use C# for your Silverlight project, then this is the case, but not if you use Python. This seems ... odd. One approach I thought they might try was to compile everything into JavaScript and let IE's runtime handle it ... but then I remembered that they are providing Silverlight for Firefox and Safari.
So my plan now is to take the Stocks application I wrote for the GWT tutorial (part is out next week, by the way) and create a Flex and Silverlight version of the same thing. I might cheat and re-use the servlet that GWT creates, or I might create a REST servlet. Too bad there are JSR 311 implementations yet.
Oh yeah, and then there's JavaFX. There is a fair amount of JavaFX documentation and examples. However, I'm not really sure if JFX will use a similar mechanism as Flex and Silverlight. It seems like it has to. The example I've seen usually create all the JFX on the server and then ship it to the client for rendering. That approach seems kind of primitive and something that would be difficult for an interactive application (like the the stock application.) Maybe by the time I'm done with the Flex and Silverlight versions of things, it will be more obvious how to do the same thing with JFX.
No comments:
Post a Comment