Open Source Client Side Libraries - What Could Go Wrong?
Reader Ken Auenson made some insightful comments on my previous post regarding "Scorpio" - the upcoming ColdFusion 8 release. Regarding my concern about keeping client side code up to date with the latest browser compatible version he said the following:
"...Adobe is utilizing open source products can that can be directly edited as non-encrypted files. He [Ben Forta] actually mentioned that the calendar widget was taken from the Yahoo UI API and it would be possible to modify it yourself if you needed additional functionality. I took this to mean that we would upgrade/enhance them as we want/need to, so we shouldn't have to rely on CF putting out an upgrade to CF when new versions of these products are turned out."
I starting writing a response but it turned out to be lengthy so I decided a follow up post is in order. I certainly don't disagree with Ken's take in the short run, and I got the same impression from Adam's presentation. Still, although this might seem like a free pass to the zoo, it is actually a double edged sword.
Let's say throw I update my calendar widget to fix X Y or Z and then throw in some customization for good measure. Two weeks later, Adobe follows up with it's own hot fix for the same problem. What happens then? Will my customizations be lost? Will my code throw errors because the fix I implemented is different than the fix they implemented? Should I forgo any hot fixes related to client side code?
This is, in fact, the same issue you often run into when you download and install open source products or commercial products that lend themselves to customization - how do I keep the versioned code in synch with my "customizations" and "work arounds". Open source is great - but it also means no more single source vendor control. That sounds like a good thing.... but it has it's disadvantages too. It kind of reminds me of a story my dad used to tell.
A man drove to work each day using the same route. At a particular section of road a huge Great Dane would lumber out and chase his car every day - barking furiously. The dog was voracious and loud and gave the man a jolt almost every day - even when he was prepared for him. The dog was fast too and often came quite close to the rear bumper of the car.
One day the man decided he was quite fed up with the galloping canine and decided to teach him a lesson. When the dog came out to chase him he waited till it was quite close to the rear of the car and then he slammed on his breaks. The dog skittered and slid into the car and planted his big mug squarely on the bumper with a yelp of pain and surprise.
The man got out of the car and walked back to the where the dog was panting and looking sheepish. "Well," he said, "now that you got it, what are you going to do with it?"
Can I say this to my fellow developers whom I love and appreciate? Open source software is not a panacea. Now that you are seeing it in your favorite platform you will have to figure out what to do with it. Everybody yammers about open source like it was the next penicillin. Meanwhile we are all making far more money off of non open source. We mostly use more proprietary products and commercial products than we do open source products. Now I know there is some guy in his basement out there that is going to comment and give me a litany of all the hoops he jumps through to keep his entire development effort from IDE to server open source. Don't bother. We all know that is the exception (and that that guy needs a date in the worst way).
It's true that including open source in this code base will solve some problems. But it is equally true that it will introduce other problems. I have great faith in Tim Buntel and Ben Forta and all the folks at Allaireobemedia to add tremendous value to the Coldfusion platform. I think their track record speaks for itself. Each version of CF has contained excellent features that have had an immediate impact on my own development. I will adopt a wait and see attitude regarding the client side code effort that is forthcoming.
It may well turn out that I'm completely off base - like that time I thought Michael Jackson was black. In which case I will be first in line to admit it and toast their success. Still, it won't surprise me if it turns out to not fulfill every promise it has made and instead just be another serviceable approach to dynamically generated client side code.
5 Comments
-
Wow! Excellent points, and A+ for your story telling ability! -
I'll have you know that I don't live in a basement! I love the post though. -
I had a long reply written then a wrong click lost it all. Bah.
Mark, you're way off base here.
Adobe is not embracing open-source, which would make your scenario tangible. Instead, they're just releasing some parts of CFMX8 in source format because they can't do otherwise - browsers don't (AFAIK) support compiled Javascript so if you bundle Javascript with your project it is by its very nature in source format; for comparison, the reporting engine is based on another open-source system called Jasper, which they *do* only bundle as a binary.
Your story is amusing but true of anything. Just because you have a tool doesn't mean you're going to a) know how to use it, b) put the knowledge to good use.
Your comments on the geek-in-the-basement are very ignorant and immature, and you've dug yourself down to the same level as the Java/dotNET heads who slag off ColdFusion for being a child's language for playing with toys (amongst other slander and name-calling). You're doing yourself no favors with this. -
Good points! I have a similar fear about some of the new ajax/js related tags. Namely that anyone who is savvy enough to implement many of them would rather do it their own way and have full control. The cfform js helpers have been a failure from what I've seen, mostly because of the difficulty in extending them. Sure you can script XML form skins in XSL, but that's not exactly the easiest solution.
But as far as the "should i update if i've modified the libraries" question, I imagine they'll do something like they did with cfform for this. There's that "scriptsrc" attribute where you can specify a path to the js folder you'll use. If you modify/upgrade the open source scripts outside of CF Updates, you could do so in a local folder, then when there's an update try removing that tag to see if everything still works (or if the cf update version is the same no need).
That being said, it is a lot of work to keep those things in sync. Open source doesn't have rules for backwards compatibility. The question is though, are these scripts being used as is, or is Adobe creating their own version of the open source scripts and packaging those instead, in which case they could attempt to keep them backwards compatible and we'd get the best of both worlds. -
Just a note to say thanks for the comments (even the negative ones :).
Adam, I like that idea of the script dir. and I had forgotten that. It solves the problem of updates to the current source breaking your code ... but still doesn't give a nice smooth update path.
As for adobe attempting to keep them backward compatible - I fear it would difficult to do and still keep them extensible and customizable. As in so many areas in this field you have to make trade offs I guess.
Not to worry - there was plenty to crow about in CF 8 without hanging my hat on client side code if it turns out to be a bust.
Sites to Watch
Aggregators
RSS
