Top Posts
With so many RIA options out there, many people get confused about which technology to hitch their wagon to in order to build an RIA. Unfortunatley many RIAs are built with the wrong stuff. Here are some general guidelines to help you make better choices.
- Performance is still important. Consumers are even less patient now with poorly performing web sites. Just because a lot of people have broadband-speed Internet access is no excuse for building poorly performing web sites.
- Maintainability is important. The more complex your technology the higher the risk and cost of maintainability.
- Most applications need to support multiple platforms. IE, Firefox, Safari, Opera, the iPhone, Windows, Mac, Linux - are all major market segments. Understand which platforms you ned to support.
- Accessibility is important and may be legally mandated for your RIA.
- Re-use may be important from a cost management perspective.
Taking these things into account I try to use the strategy of choosing the simplest technical solution, with the least amount of code to maintain, that works on most browsers, that will support my requirements.
My technology ladder usually looks like this:
- Plain Old Semantic HTML (POSH) + JavaScript
- Hand written DHTML / Ajax
- Flash
- Some Ajax toolkit (like Dojo, or Prototype)
- Flex
- A custom plugin (which I have never done)
Even though Flex is #5, it's sometimes the best solution for dynamic charting. Even though the toolkits like Dojo handle Ajax beautifully, I don't always want that much code to do a simple XHR. Flash is great for a lot of controls, and some charting applications.
I sometimes find that developers choose a technology merely because they are more comfortable with it. That is a compelling reason, however it doesn't lead to the best technology decisions.
So I was just thinking today, would it be possible to become a millionaire $1 at a time using the Internet? In order to answer that question, I have decided to put up this blog. Here's how you can help:
- Donate $1 to the cause by clicking on the Donate Button
- Send the link:
http://www.riaspot.com/blogs/entry/Becoming-a-Millionaire-1-at-a-Time-Using-the-Internet
to anyone that you think might be interested in participating in this experiment. - Tell your family and friends about this experiment.
I have a problem with design patterns. I know - I should be thrown out the window by the development police. Design patterns are there to help developers use tested and appropriate ways of building software which includes tasks that are common to many programs. In that respect - they are just super.
My problem is that they are often, like many technologies, inappropriately applied. I was recently reving some javascript code which did a simple Ajax call to get some JSON data and stick it into a list. The developers (and yes there were more than one) built a complex, difficult to debug MVC (Model View Controller) framework for this task.
"Oh yes," I can hear you say, "but now that component can be reused and it has a known interface...etc...etc...etc." Sure, but I could have built a reusable component that did the same thing, with a known interface, with aboout 1/10th of the code. It would be easier to maintain, and it would perform better.
I can't tell you how many conversations about Flex I've had that began with someone asking me about PureMVC or Carngorm. They are both great frameworks, but they are not meant for every Flex application.
The wrong way to apply design patterns is to look for opportunities to apply them. You can honestly figure out how to apply almost any design pattern to any problem. The one and only right way to apply a design pattern is to start with a problem and find the best way to solve that particular problem. If the design pattern is the best way - then it's good. If it can be simpler, easier to maintain, requires less code, and more performant - then fantastic.
I personally find that a lot of MVC frameworks get totally out of hand and, rather than reducing complexity, make applications more complex.
Understanding design patterns is an impotant part of a devlopers knowledge set. Knowing when to apply them is wisdom.
I tried to conenct with john by linkedIn , he told me about this place and I m very glad being here its very good implementaion of dolphin for RIA People , I belive here we could create very good place to share knowldge and get knowldge also Jobs but I will prefer freelance ;)
The cross site scripting restrictions imposed by the browsers are both very important - for security reasons, and very frustrating - for the limitations they impose. If your not familliar with the single origin restrictions on XHR (XMLHTTPRequest object - the backbone of Ajax), they basically say that all requests must go to the same domain as the page that's requesting them.
For security, this is a very good thing. Otherwise hackers could set up web pages with JavaScript that could steal all the info from sites you had logged into - such as your bank information, and the prescription for your herpes medication. Adobe's Flash Player has implemented a method of securing a domain, but opening it up to trusted domains using a cross domain policy file. Alas, no such thing exists for the browsers yet.
But let's say that there is some data you want to get to using XHR that isn't private - like search results, stock quotes, news about your favorite reality TV show. Along comes JSONP (padded JSON) to the rescue.
JSON, if you don't know is a data format for passing along well formed JavaScript objects. It happens to be very terse (tends to be smaller than XML), and much easier for the browser to parse than XML. JSONP is an unofficial standard where the JSON is sent back to the browser wrapped in a function call.
Using JavaScript, the clever coder creates a script tag node, set's the url to the service that passes back JSONP, and adds a unique tag (usually a timestamp) to prevent caching. The function call that wraps the JSONP is mapped to a callback which then cracks the data and does brilliant things with it.
It's great
I should repeat, however, that this format is not secure. It basically opens this data up to anybody - so personal or private data should NEVER be passed this way. You are also trusting the data source not to pass malicious code back to the page. You should be OK to grab search results from Yahoo or Google, but I wouldn't be pulling down script from any colleges in Russia.
I have had the unique opportunity recently to participate in several "proof of concept" tests building essentially the same application in Flex and in Silverlight. What I found were some interesting distinctions, rarely discussed, that should be helpful when choosing a technology.
One of the main advantages Silverlight has over Flex is that it is multi-threaded (note that this could be a disadvantage if you don't code properly). This means that highly performant web applications that rapidly update and receive tons of streaming data may perform better in Silverlight than in Flex.
Most web applications do not update quickly enough that this would matter, save for real time stock or news tickers.
With the same speed of data streaming in, Silverlight was able to update faster, and with less taxation on the CPU. Both Flex and Silverlight can handle a huge number of updates per second, and of course updates to the display are ultimately limited to monitor refresh rate and human perception.
One of the major advantages Flex has over Silverlight is visual display. Flex descended from Flash, an engine built for animation and graphics. It's animation smooth, graphics clean, and gradients smooth. I personally find Flash CS3 to work a lot smoother than Expression Blend 2.5 March 2008 Prieview Edition. However, Blend 2.5 is still in Beta, so I will judge when I see the release edition.
JavaFX is severely lagging behind all engines. You also have to be a Java programmer to design apps, because no good visual tools exist (although there is a declarative language for UI so one may not be far behind). However, a friend who just returned from JavaOne 2008 gave me some the lowdown on a very cool feature of JavaFX: With JavaFX, you can write an app that lives in a browser, can be torn-off onto the desktop, the browser can be closed, and the app is still running. This is a pretty impressive feat, that could have many uses. I'd like to see it in action.
I should note that Flash Player 10 has just been released in Beta. It incorporates a lot of cool things including hardware based graphic acceleration. I haven't tested it yet. Also look for the project codenamed Adobe Thermo - which will help with the design of Flex applications. It's not yet in Beta.
I'd like to start this blog with a bit of a disclaimer. I have been developing in Java for over a decade and so I was very interested when I found out that Sun was developing JavaFX as their solution for building Rich Internet Applications. With that said, I am trying to take a look at JavaFX for what it is and what it is not and not necessarily just for what I hope it will be.
In order to put JavaFX into some sort of context, let me give a brief summary of Java and its sorted client side past. Sun themselves have put together a nice web page about Java's history at (http://java.sun.com/features/1998/05/birthday.html). To summarize from that article, a team of 13 people "was chartered by Sun to anticipate and plan for the 'next wave' in computing. Their initial conclusion was that at least one significant trend would be the convergence of digitally controlled consumer devices and computers." This team of 13 called the "Green Team" came up with an "interactive, handheld home-entertainment device controller with an animated touchscreen user interface." This device, named *7 ("StarSeven"), used an entirely new language called "Oak".
After Sun was unsuccessful at finding a target market for the *7 technology, John Gage, James Gosling, Bill Joy, Patrick Naughton, Wayne Rosing, and Eric Schmidt had the idea to target the Internet with the underlying software that was used in the *7 platform and so from the ashes of Oak, Java was born. Originally the team created a Java based browser called HotJava browser and then Netscape integrated Java Applet technology into its browser and so Sun started their journey down a path to a more rich web experience.
Shortly after the Netscape integration, developers from around the world clamored to attempt to unleash this new power available to them and develop a new more interactive web. Even Microsoft jumped on the Java bandwagon and they bundled their own version of the JVM into their OS and integrated Java Applet technology with their Internet Explorer browser. Things looked very bright and shiny for Java. Unfortunately daemons were lurking in the shadows of Java ready to pounce and change the direction of this rising star.
The first problem that Java started to experience in its attempt to take over the Web was due to the fact that Java was still a relatively new and somewhat quirky technology. In addition developers were not really sure what to do with this new Java Applet technology and so many of the initial applets that were created were really not much more than eye candy or simple games and even those applets pushed the limits of the relatively new JVM and the common PC hardware of the day.
Another early problem for Java on the client side was a widening rift that was forming between Microsoft and Sun over the Java technology. Specifically Microsoft was busy adding custom extensions to their own JVM and Sun demanded that Microsoft stop making those custom extensions. Eventually Microsoft decided to stop supporting their JVM and Java Applets in Internet Explorer just at a time when applets were starting to garner more attention. This rift along with the performance issues and other bugs and quirkiness with Java Applets were causing developers to abandon their efforts to use Java Applets. At the same time as this drop in popularity for Java Applets, Java on the server side was just beginning to become more popular and so Sun decided to focus their attention to server side Java and Applets soon withered on the vine (although never exactly died out completely).
Fast forward to today. Since that possibly premature death of the Java Applet (or if not death then at least a very prolonged hibernation or near death experience) other technologies such as Flash/Flex, Ajax, Silverlight, etc. have been developed and either have or are beginning to flourish in the growing RIA space. So now Sun, not wanting to be left out of the RIA world, has decided to try to resurrect and even put a new face on its aging Java Applet technology and so JavaFX was born. Sun themselves may possibly disagree a bit with this particular point as it appears that Sun sees JavaFX not just as a new face for Applets but rather as a platform that unifies the various Java Web, Desktop, and Mobile GUI platforms but for the sake of this blog let's just focus on the JavaFX's potential to revive the Applet.
So what exactly is JavaFX. According to Sun's website at http://java.sun.com/javafx/script/index.jsp
"JavaFX Script is a highly productive scripting language that enables designers and content authors to create rich media and content for deployment in Java environments."
And
"Although JavaFX Script makes it very easy to create simple GUIs, it is designed to be capable of supporting GUIs of any size or complexity.
...
JavaFX Script optimizes the creative process of building rich and compelling graphical user interfaces (GUIs) for scripters, designers, and content authors, leveraging Java Swing, Java 2D, and Java 3D APIs. These rich interfaces and next-generation services can be proliferated across virtually any device securely and without local installation."
It is clear from this description that Sun has realized a fundamental truth in the RIA space. RIAs require involvement from designers, content authors, and developers to be truly functional and appealing. Up until fairly recently (at least in my opinion) almost all tools have been heavily weighted to either designers or developers and did not do a good job at bridging this divide.
Probably the most dominant player in the designer world is Adobe with technologies and tools like Flash, Photoshop, DreamWeaver, Illustrator, etc. In the developer world the behemoths have long been Sun with Java/J2EE technologies (and the many third party tools and technologies that are based on Java) and Microsoft with their .NET platform and their Windows based OS and development tools and technologies. Both Adobe and Microsoft have already grasped the idea that they need to bring designers, content authors, and developers together and both already have technologies to support this concept. For instance, Adobe's Flex technology is more geared to developers but is based on their already established Flash technology that has long been a favorite for designers and content authors. Microsoft too has developed Silverlight technology based on their already well established developer centric technologies in an effort to make their solutions more palatable for designers and content authors.
Sun is now attempting to follow suit by creating the more designer focused JavaFX technology which is based on its already well established Java developer focused technologies. The first thing that Sun has done to try to bridge this gap is to create the JavaFX Script language. Although JavaFX Script is somewhat similar to Java, Sun has created a new language that is attempting to mimic some of the features of JavaScript or dare I say maybe even ActionScript both of which are languages that designers and content authors typically have more familiarity with than Java. To get the sense of what the JavaFX Script language is attempting to do, take a look at this excerpt of the current version of the JavaFX Script reference as of the time that I wrote this blog which can be found at http://openjfx.java.sun.com/current-build/doc/reference/overview.html:
The JavaFX Script programming language:
* Uses a declarative syntax for specifying Graphical User Interface (GUI) components, allowing a developer's code to closely match the actual layout of the GUI.
* Uses declarative data binding and incremental evaluation, making it possible to easily create and configure individual components. Application data and GUI components are automatically synchronized.
* Is statically typed, having most of the same code structuring, reuse, and encapsulation features that make it possible to create and maintain very large programs in the Java programming language.
* Works with all major IDEs, including the NetBeans IDE, the reference implementation IDE for software development with the Java programming language.
* Is capable of supporting GUIs of any size or complexity.
* Makes it easier to use Swing.
My initial feeling was that having a language that attempts to combine some of the features of already existing designer centric technologies really seems like a good idea, but then I tried to work with the language. Now in all fairness, JavaFX technologies at this time are really in an infant stage and probably have a lot of growing up to do but since this is all that I have to evaluate at this moment I must evaluate what I see and not what I hope will be coming.
The first thing that I noticed when working with JavaFX Script was that although it does have some similarities to Java, JavaScript, and ActionScript, it is truly a new unique language that you have to learn if you want to use it. To me that is a big detriment because I already know how to program in Java, JavaScript, and ActionScript and I really don't want to learn a dramatically different language. Also many designers and content authors have already made the commitment (more out of necessity than desire) to learn either ActionScript or JavaScript and are probably even more reluctant to learn a new language because, lets face it, they are designers/content authors and not programmers. So really all that Sun has managed to do by creating this new language is to alienate designers, content authors, and developers alike. This one decision could potentially kill the acceptance of the JavaFX before it even gets off the ground.
Another issue with the current state of the JavaFX is that currently the only way to develop in this technology is to use JavaFX Script since there are no graphical tools to help create RIAs with JavaFX. Now again I should point out that the lack of tools is due to the fact that JavaFX is so new and one would very much hope that visual based tools would be coming soon, but given the fact that Sun is already late to the RIA game the lack of such visual tools is going to be a huge obstacle to acceptance. This is especially true with the designer and content author communities since typically their preferred means of developing RIAs are by using visual tools and it is usually only begrudgingly that designers and content authors will learn a language to implement the more advanced or interactive parts of the RIA.
Another extremely important issue with JavaFX is that the underlying Java platform has seriously lagged in the audio/video authoring and even more important rendering worlds. Again in fairness Sun is desperately attempting to remedy this situation as fast as it can but again I have to state that Sun is way behind the eight ball on this one.
The final issue that I will mention is the fact that because Sun is so far behind its competitors with its RIA technologies, Sun appears to be relying on independent third parties to provide core functionality to its RIA stack. For instance, it does not appear that Sun itself is not working on a scene graph/animation/timeline/effects stack(s) for JavaFX rather Sun appears to be promoting the usage of the separate Java based Project Scene Graph at https://scenegraph.dev.java.net to fulfill this need. Personally I am usually all for open third party implementations of software but those can come at a cost. For instance, other third parties could potentially branch off the code and create several incompatible implementations of the stack or could produce completely independent implementations of a similar stack. This would require that designers/content authors/developers would have to pick a particular stack and would then have to hope that whatever stack they picked would continue to evolve over time in a way that is gracefully backwards compatible. Also an issues specific to Project Scene Graph is that is appears to be designed as a Java API that happens to work with JavaFX Script but after I personally worked with Project Scene Graph in JavaFX Script I hit a few hurdles with not being able to do something with Project Scene Graph in JavaFX Script. This forces me to have to write some of my front end code in Java instead of JavaFX Script and so again I am forced to use two different languages to accomplish a single task.
In conclusion given the fact that I am primarily a Java developer I am definitely intrigued and excited about the prospect of having a RIA technology with strong roots in Java technologies but given the fact that Sun is really late to the RIA game and the fact that they have opted to create a new language for their JavaFX technology, I find my optimism and excitement for JavaFX to be tempered almost to the point of just wishful thinking and longing.