So, I’ve been reading a lot more now and have started goofing off with mootools and mochikit. And yet, I fall back to spry. And so now I’ve got this ludicrous scheme of js include juggling to try out.
Spry is awful good at filling in data.
MooTools has compact effects.
Mochikit pwns the DOM.
But. I need all three features… I need to handle xml data rapidly and compactly (there’s a lot of data! tightly nestled in dense xml to save on transfer time), I need effects that aren’t going to kill CPU’s or require lots of includes, and I need to chuck DOM modifications out as I change the focus of the web application. :-/
It was nearly doable to put mootools into Spry and throw around some DOM hacks, but as I’ve been going through it, I have to agree… this is becoming a ton of unmaintainable code. Something that reeks of ‘google google google’ and when I did, Mochikit seems like a great solution. But, ah. That’s the crux. Should I get script crazy? Ick. Right now, I’m more or less loving mootools, but the mochikit is the straw to break the camel’s back. Either way, I’ll get back to this blog on the progress of my projects if I decide to go through with it. As you can guess already, the RSH hack simply didn’t work out. It’s for… I’m not sure… something like google mail or something the like. Otherwise, I’m just better off doing my own cheap URL anchor hacks by my own wit. I can’t bash anyone for using RSH, but it’s a pain if you don’t need the whole thing, as far as I can tell.
If I were to splurge and put everything I wanted on the page, it’d probably be about 500k of code, and about 24 k of content. :-/
So, back to chunking solutions into the air in the hopes that I find a quick fix for various things.
In the end, I’ll hopefully have a good looking comic browser of sorts for my site. You know… with chapters, page turns, searchability, and xml fetchery fu (if I see another comic that has buttons that just change a single image by reloading the whole page… again… I’ll cry). Keywords might have to wait.
