I am not an experienced web designer, but I have used a handful of WYSIWYG design tools (iWeb, SandVox and most recently, Sparkle.)
I noticed that using some of these tools, if I changed the design considerably, or went in another direction with some structure, the underlining code and sometimes the file-structure wouldn’t re-optimize for the new structure. Meaning, there was a lot of residue or unnecessary nesting of formats in the final result. It slowed the loading of the site down, along with often having artifacts while loading, but finally disappearing once totally loaded. This occurred to some extent on every WYSIWYG website design tool. (You can see it happen on hybrid tools when looking at the underlining code.)
Okay, here’s my question. How does Sparkle deal with this HouseKeeping and re-optimization of the code? Or if I am changing the structure considerably, do people recommend that I start the site from scratch, like I have needed to do with other applications?
duncan, I do understand that Sparkle takes care of everything, as did the other programs I spoke of, however, that does not mean that the code is exactly as it would be if you started from scratch. Equal output does not mean equal underlining code, especially code that tries to interact with multiple pages and does auto-menus, etc.
I can tell Sparkle creates quite clean code, especially when compared to other WYSIWYG applications. And that Sparkle handles changes taking care of what needs to be done. What I am wondering about is re-optimization of code when drastically changing the format of a web page design. I know I can change the format drastically, but often this can lead to un-optimized results where residue remains (even though the residue is not experienced on the final result.)
I think the underlying assumption in your question is that Sparkle works with HTML internally, and that multiple manipulations of the code would somehow drift away from the optimal.
That’s not the case: Sparkle always recreates all code from scratch from an internal representation of the site, and the generated code is always optimal.
There’s no re-optimization necessary as it’s never un-optimized.
Furthermore, when we improve Sparkle’s code generation, you only need to re-publish to make use of that.
That’s exactly what I thought Sparkle was “doing” when generating code, but I couldn’t quite explain it and wasn’t really absolutely sure. Now we know.
Yes, that was exactly my assumption, that it was creating and upon making certain changes, modifying the html code that had been generated, else how do you get the instantaneous preview to be so snappy? Pretty nifty!
Yes, turns out generating the code is instantaneous, images take a little more time but we generate them only on demand and the browser caches them most of the time.
and virtually give Duncan & Team a big hug for their forward thinking approach with Sparkle!!!