Web GUI tools – Not as different as they seem

Enough already, what are my preferences?

Given that you’re probably going to use JACXX no matter which tools or platform you choose, as always, I don’t think it really matters which one you choose – pick one and go. My preferences bend to the following factors but of course the weight that you assign to each factor will differ from mine.

• I like a robust IDE. The more I can do within a single IDE for all of my needs the better. I like a single, robust IDE so that I can completely control all factors of the development from the UI through to database management, configuration files, debugging, and deployment. In this area, I use Visual Studio for .NET development. I was OK with Flex Builder but thought it was a little pale compared to VS. And for PHP I like NetBeans. (I haven’t used NetBeans for Java yet but I’m sure that would be my first choice as well.)
• I like a full debugger where I can run code and then watch as each line executes. I get very frustrated running a batch of code and then trying to figure out why it didn’t work. Since JACXX development relies heavily on JavaScript, a good JS debugger is essential. Visual Studio 2008 has an excellent JavaScript debugger – most others, including the basic script editor/debugger from Microsoft are just plain awful. Recommendations are welcome.
• I like a WYSIWYG screen that allows for drag-n-drop, renders the XML controls visually, and allows finite manipulation by moving them around and changing settings through property pages. This is all present with IDE tools but you only get this with the libraries that make use of XML (JACXX), not the code-only JACX libraries. I’m not one of those people who drop a component on a form without any idea of what the underlying code looks like or how it functions. Knowing your craft requires an understanding of what’s happening when you move between the GUI RAD IDE (which I call the Gooey Rahdiday) and the code. I like the visualization capabilities, but I don’t rely on them completely. Sometimes screens are simply too complex for the visualizer to get it right, and WYSINWYG (what you see is Not what you get), and other times when controls are rendered at runtime based on user input, you’ll never be able to see in the IDE exactly what the user will see, unless you run the code and try it for yourself.

If I don’t see these options for a tool that I’m planning to use for GUI development, I’m likely to look elsewhere. I don’t completely write-off tools that don’t have the XML WYSIWYG aspect. For example, in a site I’m working on now I’m sure we’ll use a combination of WYSIWYG components plus some YUI or ExtJS where it seems appropriate. But I don’t think I’d ever write a whole site with all JACX and no JACXX.

These days I’m also inclined toward tools that allow one set of code to run in both thick and thin client. There aren’t too many of these but the various options are getting better. For example, your Flex code can also run in the AIR application on the desktop. Flash doesn’t run on iPhone but now Silverlight does, so if you learn how to create a Silverlight UI, your experience translates to both browser and iPhone. It’s commonly understood that Silverlight is a browser technology and not for thick-clients, but Silverlight is really a subset of the full WPF library which is specifically for thick client. So in short, Silverlight isn’t for thick clients but the code should be portable to thick client. Again, this situation should improve over time, and your investment in the technology ports to other environments.

So which one do you choose?

• My recommendation is that if it doesn’t have a full IDE, full debugger, full WYSIWYG, and at least potential for cross-thick/thin use in the future, then you should at least keep your mind open to other options.
• If your currently considering a non-JACXX or non-JACX solution, then I encourage you to reconsider. Just look at what everyone else is doing out there. Pick something that’s standard at least at this JACXX level so that shifting to a different technology (if desired or necessary) won’t be so gut-wrenching.
• What I don’t like is that all of these options have different JavaScript functions, and different XML schemas, so you can’t easily port from one to another. So find something that is well supported, perhaps with corporate backing as well as a strong community. It should be well documented, easy to get started, and tutorials should be abundant. Look through community forums and see how many complaints there are about stuff not working. Look to see how fast issues are resolved and how frequently new releases are published.
• As always, try to keep your business rules separate from your data access and keep those separate from your UI code. This is the Model-View-Controller design pattern, and MVC is so popular these days that entire frameworks have sprung up and developers seem to be flocking to the pattern of component separation. This is important so that it will be easier for you to shift to a different tool in a couple years – and no matter what you’re using, it’s unfortunate, but chances are fairly good that you’ll be shifting every couple years.

Addendum

This was a long piece, occasionally opinionated, and sparse on some details. I’m trying to convey a number of ideas and preferences. There are no absolutes. Everyone’s choices are different. If you can spot some of the holes in my arguments, please understand that I can’t go down every rabbit hole in a blog like this – and if you recognize the holes then this blog entry wasn’t really targeted to you. If you spot really big errors, please let me know. This was intended to help people on the fence to understand their options. I can’t present all details of all options but I do want what I’ve covered here to be accurate.