Fuzzy asks about options for disconnected client alternatives.
I started a reply, but it got too long so I decided to post and link instead.
I've now done this analysis a few times for a few different scenarios and as with most things, the devil is in the details. At the end of the day, although not quite so dogmatic, what usually matters most is ease of programming and that is generally driven by your server-side. It probably shouldn't be so, I'd love to say "Just put a set of RESTful services out there and I'll handle the client thanks", but in reality the separation is rarely that clean with more rich (i.e. offline) clients.
Fuzzy asks about a couple of technologies that I've worked with and others are mentioned in the comments.
I'd stay away from Tibco GI if you want to have any hope for advanced functionality like offline access, XMPP or direct socket manipulation. More rich APIs are available in XUL and AIR if you need to go there, and when I last worked with GI it was quite brutal (I.E. for development environment, no FF support, massive code base). Most of these have changed, but I feel like with something like GI, it almost doesn't matter that it's BSD licensed, you won't be able to grok or change the code anyway, it's too complicated and if you need what it does, you are almost certainly pounding a square peg into a round hole.
In the comments, Brian advocates a combination of Gears and GI - that scares me to death. Two technologies that have no knowledge of each other using the browser as a binary integration bus via JavaScript - I've yet to see that work on any effort of size and it's bound to cause some serious headaches, especially when you can't control what a user does from either side of that integration. Doesn't pass my sniff test.
Most importantly thought, I'd look at the community story there, it's not very compelling. GI strikes me as almost abandon-ware by Tibco and seeing as how they were so late to the OSS game, I have doubts about their commitment to sustain the community. Conversely, AIR has far more momentum and Adobe worked hard towards building community from the beginning.
For what it's worth, when I was talking with Tibco about these concerns and pressing them to open the code, they laughed and told me it would be really expensive. Guess I was on to something. I'll continue hammering Adobe to do the same with the Flash Player with every opportunity I get.
Having worked with XUL, I found it quite painful. The entire effort is under-documented to say the least. For Fuzzy's purpose, it obviously Mozilla-specific which may or may not be an issue. I can't say I've ever seen anyone build anything with any serious eye candy on XUL, just basic chrome and mostly tree views. If you have half an inkling that you might need some eye candy to sell your product, XUL probably isn't for you.
More importantly though, If it doesn't meet your lower-level needs for things like images or networking, be prepared to write some cross-platform C++ and COM-like IDL. You will also need to deal with version differences (i.e. XUL on FF 1.5.x is not the same as in FF 2.x). That said, if made to choose between GI and XUL, I choose XUL.
My personal bias is still for AIR. The community has good momentum, programming model is the most simple of the other options (including Sarge's Tcl comment - have fun with that return to DLL-hell). Not open though, so if you go that route make sure it's critical to your story and that open-ness is not.
Lazlo can "compile" to Flash as Mike W. mentions in Fuzzy's comments, but can also remain in AJAX/DHTML land if you so choose - Flash simply performs better. In all the testing I've done, Lazlo will not perform consistently nor render consistently if you do not transform to FVM bytecode, so those are likely not options.
One other potential option is haxe. Saw a presentation on it at OSCON a few years ago, seemed like a solid technology but hasn't really caught on in the states anyway. It's been around for several years now and people who use Neko seem to love it. Can't speak from experience with that one, but I'd give it a look.
Tuesday, November 27, 2007
Having and Eating Cake
Subscribe to:
Post Comments (Atom)
3 comments:
Perhaps you're not aware of GI's offline capabilities? Here's a GI app with offline capabilities.
http://www.remixedby.us/craigslist
This app lets you browser craigslist, then save enties and google maps offline that you want to remember for later -- or even use offline while travelling to these locations. It also lets you enter and store notes offline for the items you've saved.
This one uses dojo.storage. But there's nothing preventing GI, which runs as a standard HTML page, from running the way anyother standard webapge runs in AIR or with Gears. That's the point of AIR and Gears -- to be open to the things you can do in a browser today working with the standards of the browser to maximize extensibility. And since GI works in the browser... well, you get the point.
I do know that GI has offline storage, yes. I'm not the one advocating using Gears and GI, I'm responding to Brian W. who is advocating that on Fuzzy's blog.
I also know that dojo.storage creates a dependency on Flash as the lowest common denominator to provide that storage. If you're introducing a dependency on Flash, then you should just build your application in Flex - development time will be cut in half, the application will render more consistently than in DHTML, and it will render much faster while taking less memory. It's all about maintainability, simplicity and time to market man, not seeing how many acronyms you can cram into an application.
How do AIR and Gears work with the standards exactly (and what standards would those be?) If they were "standard" as you suggest, they would have the same API and be accessible though JavaScript on all platforms without plugins. They have their purpose, but that purpose is to address the shortcoming of the standards through proprietary extensions to the browser, just like Flash.
Good comments all around.
A few quick points …
- Use case called for independent disconnected client, which in turn brought GI to mind. The GI framework provides all the necessary widgets for disconnected use. If I have any knocks it would be support for Safari, etc.
- At the end of the day it may boil down to working with a single stack vs. integrating on the client
- Integration on the client might be limited more by the looseness of JS than anything else.
- Modifying/extending GI was pretty straightforward. The code base is very clean and understandable. Opening the code was a good thing.
At this point, I'm more interested in issues like:
- For either alternative, do users expect a web experience or a desktop one?
- How to introduce gradients in the experience in a recognizable way (given a large population of intermittent users)
- As the size of the application grows how to manage the user developed client side code base.
Post a Comment