HTML5_Logo_2561

Developers should not believe the HTML5 hype

As an Architect and Lead developer, I have to sit down with the non-techie and convince them why I think a technology or framework is the right one for a project and then I build my team to deliver the solution. The past two years or so, the marketing engine of technology companies have been spinning at full throttle. HTML5 is a the future, everything will run in the browser and more blah blah blah.
Don’t get me wrong, HTML5 brings some good technologies to the web application developer. Nevertheless, I think there is a lot of hype as HTML5 doesn’t really bring anything new to the table.
First of all, there are multiple type of applications that we are all well-aware of;

  • Consumer
  • Business
  • Enterprise

Consumer Application

If you are building a consumer oriented application which doesn’t use any of the native functionality of OS, then I would recommend the application to be built in HTML5 and all the RIA fanfare that comes with it. You can best view this in the mobile space where developers build either native or web apps depending on the application requirement. Remember that web application (HTML5 ) do not have direct access to printers, USB port or any other hardware such as Bluetooth and network services. Simple word processing application that can be developed in HTML5 such as Google Doc (where this blog is typed from). I haven’t come across any serious application written in HTML5 or the likes yet (JavaFX, Flash and Silverlight are not HTML5).

Business Application

Critical business application such as POS which requires access to barcode scanner as an example can’t be written using HTML5. You can have a native application delivered through the browser such as Java Applets ( or JavaFX) using webstart. Java applets can access OS features and hardware and provides another layer of security. Business application are delivered in controlled environments, for example, the application can be deployed on Linux desktop in company “a” environment only. For as much “fanfare” one might create around HTML5, these type of application will not cease to exist.

Enterprise Application

Enterprise applications come in various forms, from desktop to servers. As this is a comparison to HTML5, I will only focus on desktop application. First, let take a financial company such as a stock brokerage firm. There is a reason why stock trading application run as closely to the OS as possible ( and also to the exchange), in one word, PERFORMANCE. Web browsers performance sucks regardless of which one you are using, JavaScript is just too slow to implement some of the logic. In the trading business, a millisecond is all that is required to lose millions of £. Can you for one second imagine building a Bloomberg trading platform using web technologies, that’s laughable. There is a reason why the finance industry are still using Java Swing as their desktop technology of choice.

Conclusion

HTML5 is a promising step in the right direction to building scalable robust web application but it will not obliterate desktop applications, not today, not tomorrow, not ever (really!?). We can already see it in the mobile space where developers rather write native application so that they can utilize OS features and hardware. Web applications cannot access you local files directory (I am not talking uploading a file to a site) to read or write.  A simple operation such as reading available space in a directory or writing a log to a local directory is not possible (again I am not talking about downloading or saving a page). Therefore, developers should not believe the hype. HTML5 is not the silver bullet and it is a shame when companies such as Adobe sends mix-messages by discontinuing their Flex offering. Anyway, Adobe has never been a big player in the enterprise desktop application market.

If you disagree with my points, feel free to share your thoughts.

happy20101

Happy New Year Techies!!!

I just wanted to say happy new year to the community, without you guys, we would still be living in the dark ages. Here are a few that I am looking forward to in the new year:

  1. Oracle Sun merger:- The untold future of NetBeans, MySQL, Swing and every open source that Sun has been working on in the past. What would happen to Sun Open Source (SOS!!!) Movement.
  2. Looking forward to JavaFX1.3 release, Authoring tool and improved Composer plugin.
  3. Android uprise against iPhone (not because I can easily write Android based application) and hopefully with Visual XML builder to build Android UI. JavaFX running on Android, anybody????
  4.  Looking forward to seeing real-world JavaFX application and possibly a showcase linked to the JavaFX.com site.
  5. Java EE 6 support in Google App Engine
  6. Google Wave open to the public and how well it does against Twitter and Facebook
  7. Java Store open to Europe (well this is where I am based and want to sell applications not just provide free).
  8. My new video blog ( well that’s me trying to be more Armel 2.0 – the sequel) to better engage with the community.
  9. looking forward to networking with fellow developers and techies.
  10. looking forward to the new buzzwords (old technology, new name)

Well, 2009 is was good year for Java and tech scene. I hope that you all enjoyed the year as much as I did. Why not share what wish list with me (comment box). Subscribe to follow my blog as I will try to bring more interesting articles in the new year.

Happy 2010 New Year, wish you all; success, properity, fame (yup) and fortune. Don’t forget, if you need a server-side, UI, Android or JavaFx developer, just mail me.

4190189872_6bb23523e5

JavaFX Composer RAD Tool – First Review

Just over a week ago, Sun announced a RAD tool for JavaFx built on the Matisse framework, I believe. I was very critical of JavaFx for its lack of tool for building UI and I think this is a step in the right direction. The tool was made available through the NetBeans Update Center on the 14/12/2009. OK, so I have installed the plugin and here are my views; not just on the tools but also on other stuff I think would benefit the JavaFx community:

When comparing something, it only makes sense when we use a benchmark; here my benchmark will be Adobe Flash Builder (formerly known as Flex Builder). Over the years, Adobe had made it easy for the designer to build impressive user interface with minimal coding. Sun, in the other hand, made it easier for developers to build application, yes I am aware of some nice UI in Java but they still do not compare to the eye candy of Flash/ Flex.

I am going to look at the tools; Flash Builder and JavaFx Composer plugin, from a developer perspective.

Components:
A key feature of RAD tools is the amount of components they make available to developers without having to write too many codes. I understand the plugin is at a “preview” stage, whatever that mean (alpha?), but there are alot of missing components; as an example, this release version was meant to be a “preview” of what to look forward to but I cannot drag a “combox” from the components palette into my form, no data grid, no chart, no menu bar, no date components and can’t even draw a rectangle which is possible but only through coding. I hope the JavaFx team add all the components available in JavaFx plugin to the Composer.

moz-screenshot-2NetBeans JavaFx UI Composer

moz-screenshot-4Adobe Flex/ Flash Builder

Round-trip code update
One thing I dislike with Java IDE’s (or most of them) is the inability to change the generated code without requiring you to write more code. The Adobe team actually made a good job in giving more freedom to the developer. In Flash Builder, you can design your UI through drag-n-drop but also customise it directly through the XML file (MXML). This feature was not available in NetBeans Matisse, I could be wrong, but and again Matisse was not really used in large project (no comments, thanks), at least not were I worked. Why all the fuss, you might ask? Try to create a simple interface and add a “rectangle” object to it which you will use as a toolbar and tell me how simple that was.

The coding style in JavaFx is very similar to Flex/ Flash ActionScript (so why the “V”oid instead of void, but that’s another issue) and very easy to learn. So far, I found it easier to actually code the canvas then using the Composer plugin. Another thing, when inspecting object properties; not all properties are available, for example: the gradient properties are not available, which will require you to write more lines of code.

UI Preview Panel
Again, a feature which Adobe Flex/ Flash builder excels at (I feel like I am starting to sound like an Adobe salesman) is the synchronize preview of codes. This is not a due to JavaFx Composer plugin but this seems as a bug as sometimes, you might have to restart the IDE in order for the UI Preview panel to start working again. Hopefully the introduction of the RAD (or not so much RAD) tool, will fix this issue.

Conclusion
You might feel that I was on a JavaFx bashing quest but this is not the case. JavaFx might not have a large components set (well what about all the SWING components available which you can use? You might not be able to “skin” them to your application look and feel but they still availabe to you) but I still think it has a good future. If you take a look at the screenshot below which was built with Adobe Flex, it took me less than five (5) minutes to build. Now time to synchronize your watches and tell me how fast it will take you to build the same interface using JavaFx Composer plugin. It will probably take me less than five (5) minutes if I was designing it with Matisse. My point is; a RAD tool is supposed to promote productivity and YES!!! I have realized this is a “PREVIEW” release but can you actually use it? I know I will still be coding JavaFx for the foreseable future and I would love it to succeed. If you are going to call a tool “a RAD tool for building Form-based JavaFx UI” then I suggest that you provide most of the form components.

Should JavaFx UI RAD tools be based on XML like Android and Adobe Flash Builder?

moz-screenshot-5

5 components I like to have on JavaFx

  1. Menu and tool bar (come on guys, this was there in previous release)
  2. Grids (even just a simple table will do. For now I use JTable)
  3. Date picker, Rich Text and Navigator components
  4. HTML panel (something that display HTML and can also be used as iFrames)
  5. Panels similar to JInternalFrame (this will be useful in portlet-like applications)

I know it’s not really 5 things but they will make a difference. Thanks for reading and tell me what you think about JavaFx and its UI Composer.

pixy

JavaFX vs GWT – A developer dilemma in building a RIA application

For the past few days, I have been working on a simple proof of concept; a web based stock streaming application with a community theme to it. I set myself to building the backend first. As you can guess, I am developing in Java and here are some of the requirements that I have to meet, at least:

  1. The application shall allow the user to query a stock (quotes) either using the stock ticker or the company name and display the following: stream stock price with basic info, stock historical price; tabular view and financial chart analysis.
  2. The ability to rate, comments and share stock information.
  3. provide a real-time chat features for users of the application to interact together.
  4. single sign-on integration with OpenSocial, OpenID and Facebook connect.

The above are some basic features in order for people to actually use the site. As you can see, they are mostly front-end requirements. Here is another important requirement:

  • The application will be hosted on a Cloud-based service, the application shall keep to a minimum the load on the server as CPU and memory use will be charged per request.

I believe that last requirement was the key decision factor. I needed something that will make use of the user resources instead of stressing the server. Something that would execute on the browser, client-side. Being a Java developer, it is only normal for me to look for something that I can grasp easily and freely available on the market. I looked at a few RIA frameworks and tools but I needed something that can integrate within my development environment without the need switch between IDEs.

I had a look at JavaFX and GWT. Having worked on GWT in the past, I found that I could implement most of the requirements. GWT has a rich api and components sets (widgets). I could use the Google search, map, visualization… to build the front-end and implement the client side code.

It took me about two days to implement the basic front-end and back-end features; mostly concentrating requirements 1 and the last. But then I hit a brick wall, something that all Javascript developers already knew but I just came across:

The application is a mashup of different services from around the net. Some of those services were available for free and others were not available at all but I will still be connecting and parsing the relevant data to displayed on the screen. As requirement “1” was working fine, there was a disaster about to happen. Here is the basic architecture:

  • when a user queries a stock, the data is sent to the back-end services.
  • the back-end services queries a third-party web service which I do not have control over. ZERO.
  • when the third-party web service returns, the data is then parsed into a format understood by the front-end and sent to the front-end services to display. 

The services was working fine until I had about 12 stocks displayed on my screen for testing purpose. The data was being streamed with a 1 minute interval. After about 30minutes later (and 360 requests = 12 *1 pm * 36m), I have noticed that the stock data was not being updated anymore and some screens were blank. No errors were logged and some other queries were still working such as the historical data. As I could not see the errrors from my debugging session, I therefore decided to query the third-party service manually through Firefox and IE and VOILA! The service provider had put a temporary ban on my IP address for making too many requests, it says. This was a major blocker as it seems that I could not access my primary data anymore. This left me questioning the feasibility of the project.

If a single user gets banned for tracking 12 stocks, what would happen when 100 or more users start watching their stocks?

OK, so I did not give up, at least not without a fight!

I looked at the problem from another perspective, the third-party view. How do they track my request as I do not have to register or sign-in? The obvious answer is my IP. So I thought, instead of making the request to their services from the back-end, I should send the request directly from the front-end. If each users make the same request, the third-party services would register different IP addresses for each one of them. Correct indeed but one big problem:

The front-end code is written in GWT which is then compiled to Javascript. Being a Java developer, I was not aware of the limitation of using AJAX in a mashup such as mine. After making the necessary changes, I then run the app just to get hit with another blocker – SOP (Javascript Same Origin Policy). What’s in a monkey name was this all about? So after researching it – Google and Wikipedia, I knew what I was dealing with and I am sure all Javascript developers already knew that but not me :(. I never give up, it is not part of my nature, therefore I decided to look for ways around it and came across a tutorial on GWT site that shows you how to implement a workaround. Did the tutorial, implemented some basic methods and that worked fine but implementing the third-party service, did not work :(. The problem was simple, the workaround needs to be in JSON format which I coded but the third-party service needs to be able to send the request back to a “callback” method. This is it!!! Remember that I mentioned that I had ZERO control over the thrid-party service and therefore I could not implement this feature.

Remember, I never give up; when there’s a will there’s a way. So I hit a major blocker due to the technology, in this case it was Javascript. I know that if I was working on a pure java front-end GUI, this would have never occurred and Flex allows you to query other third-party services but I have no knowledge of ActionScript. I decided to go for JavaFX just because it is Java and allows me to connect and get my data (actually it’s not mine). My options were Webstart, Applet and JavaFX. First of all, it has to be part of the site so my real options were Applet and JavaFX. Applet do not have a rich set of tools such as Map, Chart and everything else that JavaFX provides and I do not want to waste time coding them.

So same adventure but different episode; I am currently looking to implement the JavaFX UI so stay tune for the sequel and screenshot. I could have never anticipated those problems with the third-party and then Javascript but believe me it was a good experience and my Javascript just went +1.