Wednesday, May 20, 2009

RIAs powered by Dojo and javascript?

Recently I was thrown into a situation where I had to learn Dojo and javascript quickly to produce a prototype. Being fairly skilled at picking up new technologies and languages I figured how bad could it be. I was wrong! The switch from typed languages to javascript is HARD. What a terrible overall experience. I can't see how the untyped language is a good thing - so far it just lets me be lazy and not create class definitions or hard contracts (have those things really been slowing us down in the typed world?) and lets me just create functions all over the place with no clear "context" for their use. Dojo has some nice features, but it is never clear where Dojo/Dijit ends and plain javascript/Dom stuff begins. And to top it all off you need to learn at least 4 pieces of technology - javascript/dhtml, Dojo, Dijit, and css in order to be productive. This same prototype in Flex would have probably taken me just over a day to put together - instead it took me 5 days to throw some grids up on a page, populate them with data, get the layouts correct and then based upon the selection, interact with a separate flex component.

Dojo/javascript has horrible documentation and lack of good IDE support (please - don't start on Aptana or RAD - they are decent, but nowhere near as easy or helpful as Eclipse JDT, VS w/ Re#, FlexBuilder). Trying to find what the properties and methods to call on various Dojo objects was painful - the Dojo online Docs are hard to navigate - I finally resorted to grabbing the development code so I could just step through and read the comments. That should really be positioned as the primary way to figure out what's going on. Then once I found what to call, figuring out if I called it correctly was also a chore. For instance, if some function took an object that expected certain attributes, making sure I properly created it and added the correct attributes to it was mostly trial and error. Thank God for Firebug.

Now with all that bashing aside, I completely agree with the "if it looks like a webpage and talks like a webpage, then it should be a webpage" argument. Meaning, if you want your webapp to look like a web page and you have links, etc, then you should stick with the "legacy" web technologies of html/js/css, otherwise the UX suffers. When users see what look like hyperlinks they want to be able to click on them and open in new tabs, etc. They also expect that all of the other browser features, like search and bookmarks, work with their pages. That's one of the problems with Flex and Silverlight. Sometimes these types of RIAs look like what could be plain-old webpages, but as soon as you right click a link and try to open it elsewhere, or you try to bookmark something, or search for some piece of text you realize that you cannot and that can be frustrating to the user. Similarly, I think Flex/Silverlight apps that have an MDI like interface need to be careful as well. That approach basically reimplements the same functionality as browser tabs. In most cases I'd prefer to open up each doc as a separate browser tab rather than the app putting in its own top-level tab. I think moving forward it would be nice for those technologies to play a little nicer in the browser.

Hopefully I get over the the learning curve for js/Dojo soon. Most of my development in the foreseeable future will likely be using these technologies so to some extent I just need to get over it and embrace the untyped javascript world. I hope to see the light soon.

Thursday, May 7, 2009

Initial Maven v Ant observations

Let me start off by saying that I am by no means an expert in Maven, so these are my initial thoughts. Also, this is on Maven 1.x - we have some plugins that we are using that we can't use on 2.x.

So far I prefer Ant over Maven. With Maven, many things are "hidden" for you. In order to figure out what is going on you have to rely on documentation, which isn't always the best. With Ant, yes, you need to explicitly build up your targets with filesets, etc, but at least by glancing at the build targets you can tell what is going on. With Maven, it is like magic that things work - you don't necessarily know why; the reverse is also true - when things fails you also don't know why. With that said though, I have come across highly structured, templated Ant build scripts/frameworks where you have the same issue of not knowing what to call or why something fails, since many of the details have been abstracted into some main build.xml.

One argument for Maven over Ant is that if you add new projects, files, jars and if you follow the Maven conventions you don't have to update your build files. Yes that may be true, but is all of the black-magic really worth it. It doesn't really take much time at all to update your Ant files and again, you are explicitly in control and can see what is going on. The other Maven argument is dependency management. To me, unless what you are building is absolutely huge, this is entirely manageable in Ant. Worst case is that your CI build breaks because some dependency wasn't updated in your build.xml and someone has to take a few minutes to fix it. In both cases, ongoing build maintanence is required anyway - there is no build solution out there that doesn't require refactoring over time.

I guess what it all comes down to (with frameworks in general) is that there is no silver bullet. You just end up with a different set of problems. At least with Ant it is more obvious what is going on.

Friday, May 1, 2009

No, really, I hate cilantro

Prompted by colleagues, I'm going to try to update my blog on a variety of topics, both professional as well as personal. Professionally I am a software developer who has worked on everything from COM based applications back in the day, to .NET winforms apps, to Eclipse RCP apps, to Flex based RIAs, and now on Dojo/Restlet based RIAs. Personally I am a somewhat opinionated, slightly high-strung 30-something who is currently anxiously awaiting the arrival of his first child.

I had some trouble coming up with a blog name, but settled on something I have started saying over the last couple of years - I HATE CILANTRO. Why, you ask? Well at some point cilantro went from a minor ingredient that maybe offered something to the flavor of a dish to something that some restaurants are treating as a main ingredient. I'm not the only one - just google it, you'll see.