It's the latest rage, you know. It seems like everyone is offering "badges" for bloggers, web-site folks, or really anyone to toss up onto their pages. For those that don't know, badges are little bits of javascript that you can add to your pages.
A few words about that:
1. Javascript sucks. Well, to be accurate, it sucks CPU. To be even MORE accurate, it halts page loads while it goes and fetches the script content and gets executed. This makes sense from a browser/DOM/DHTML sense since the very page you're looking at is about to become RADICALLY different. That's the reason all the web page design speed freaks out there tell you to load CSS at the top of your document, and Javascript at the bottom. (i cheat and put the javascript in the side bars that load up last anyway and then use CSS to move them into place.)
2. Their problems are your problems. Remember, if their site is overloaded, or hung, or taking a nap, your page loads will too. (See #1)
3. Other Reasons. There are other reasons too. Some depend on the thickness of the crainial foil, but there's good reason none the less.
Still, if you're not a programming whiz, they're darn handy none the less.
Fortunately, i am. You'll note that the MyWeb 2.0 list to the right doesn't look like the normal badged version. That's because i've got a nifty script that goes out and fetches that list every so often. It stores it and loads it up as needed. i get more flexibility with what goes on it and how it's displayed.
Mind you, the flickr badge on the left is a real javascript badge. That's because it's literally the last thing on the page and by the time it shows up, you're usually pretty far down the article. (ooh, magic!). Plus i didn't feel like rebuilding it.
Still, the stupid thing is that as much as i don't like badges, i definitely see their use. Still, i wish that there were some way to display content on a page without a) risking your cookies b) slogging your pages and c) being difficult.
Lo and behold, guess what Y!Developer just came out with?
If you guess PHP native interfaces, you get a cookie.
Yep, the hack i was planning on offering soon is now reality as you can code up quicky plugins for any PHP app (wordpress anyone?) to use Yahoo! stuff. You can now write caching versions of whatever service you'd like to create. Wanna build a plugin that tracks the price history of flights from San Francisco to Washington DC? Now you can, and you can use native PHP to do it.
Yay!
Cripes, with this and the Javascript UI elements, there's ALL SORTS of crap you can do. To clone Mr. Winer's suggestion to clone the Google API, why the heck would i want to restrict myself to that?
Okay. The PHP interface is cool. But when I go to that page, all I see is a bunch of links to other stuff. Yes, I know it's cool, but whoever owns that page should tell me so. Don't just deluge me with a bunch of links that I looked at and said to myself "I don't have time for this now". Give me a quick tutorial. Or give me the exposition part of the chapter from Inside Mac.
I'm also seriously tired (after starting a new job back in December) of people who use acronyms without defining them on the first use. REST? APC? JSON? The welcome page made me feel anything but, and I'm just the kind of geek who should be digging this stuff.
Well, I'll agree that some judicial use of the <acronym> tag might help out a bit with the TLA's, I think the balanace of content to link is just peachy. There are documents about how to use the calls in PHP, samples of what to do for those that only read code, and links to external resources if you want to do more. That's what an introduction page should do, right? Otherwise, it just kind of scrolls on forever, folks glaze over, and make snarky comments about how a web company hasn't figured out how to do links.
Save This Page
I guess this is why when I rebuilt my site, I put all the javascript badge stuff on one page:
http://www.magical-girl.com/more-javascript-than-you-can-shake-a-stick-at/