I need to write an ROI calculator as part of some demos at Nexaweb. I may as well show the process. Since this is not intended to be a robust mission critical application, I am really looking for how easy it is to go from concept to development and to iterate (since I am sure there we won't get it right the first time)

So let's start with the ROI logic in - surprise - an Excel spreadsheet. (Excel being where many of these rules and formulas are created.) .

Here is the spreadsheet.

Since Nexaweb technologies is based on declarative XML (XAL), the approach I decided to take (with the help of Fred Mikkelsen) was to use Excel itself to generate the basic XAL markup which would in turn form the basis of the Nexaweb ROI calculator (without the formulas).

So, while formulas would not be preserved, cells and tabs would be. The rest of the development then would be to implement the formulas (such as sum) and spread sheet like functionality (such as auto update when a user exits a cell) with Javascript (added to Nexaweb platform as MCO's) and Nexaweb event handling and UI update technologies.

Was Steve Jobs right?

Was he right when he dissed Java recently (setting the Java world aflutter)?

Well noone wants to bet against the Legend himself, certainly not a mere mortal like me with far fewer 0 (zero)'s in my bank account (and far fewer bank accounts I am sure), but, let me raise some ahem points:

1. What are you going to do with all those existing Java applications? We still have Fortran and Cobol.


2. Why (back to this century) isn't there room for more than 1 "rich client" technology in the browser, phones and end user devices in general? iPhone may support Javascript but can one technology be the be all and end all? (I don't care how cool - or is it hot - Ajax/JS is. It is NOT easy to build robust complex apps in. Things that are easy in Java - like avoiding name space collisions to take a simple example - is too hard in Javascript. And things that are hard in Java - like building a ui table that handles 100,000 rows - is virtually impossible in Ajax.) . Maybe a phone doesn't need to support high performance applications (yet!), but does it make sense to limit client technologies to the flavor of the month? I think not.
   


3. Wouldn't it be better to assume there will multiple client technologies? (Ajax - XML/HttpRequest this year but what about next or the next 2? ) There are too many devices. (Heck even Apple might come up with a better rendering technology for cell phones.) So Java vs Ajax vs html/dhtml vs Flex is the wrong question. Wouldn't it be better to plan for multiple uses, faces or skins for an application or for multiple client technologies? Wouldn't it be better to code the UI or at least the user interactions and page flows independent of the client technology du jour and plan for both change as well as innovation? The reality of multi-faceted, dynamic and truly reusable/extensible applications is here - or at least the potential for it is.
   

And all these changes or lack of easy change cost - in real costs, in time, in opportunities lost.

And, unlike Steve, I can't afford to waste any of my 0's.