Posted by ^reaper^ on 11/22/35 11:23

While sipping absinthe, Onideus Mad Hatter heard a loud sucking noise
coming from alt.2600, and hastily inscribed the following unintelligible
Sanskrit in <news:63mbf1l3sdp0acmifrku4783f5hq1bbara@4ax.com>:

> On Sun, 07 Aug 2005 02:38:51 -0700, Onideus Mad Hatter
> <usenet@backwater-productions.net> wrote:
>
>>On Sun, 7 Aug 2005 02:06:57 -0700, "^reaper^" <knocking@deaths.door>
>>wrote:
>>
>>>While sipping absinthe, Onideus Mad Hatter heard a loud sucking noise
>>>coming from alt.2600, and hastily inscribed the following unintelligible
>>>Sanskrit in <news:cqd5f1l9hg975qghcrk4i46ui7nli9gp1f@4ax.com>:
>>>
>>>> Hatter Blog, yo! Version 1.0!
>>>> http://www.backwater-productions.net/hatter-blog/
>>>
>>>fix0red yore code furrier.
>>>
>>> http://www.spyderware.net/source/fix0red.css
>>> http://www.spyderware.net/source/hattercss.inc
>>>
>>> http://www.spyderware.net/source/fix0red.js
>>> http://www.spyderware.net/source/hatterobjs.inc
>>>
>>> http://www.spyderware.net/source/hatterdb.inc
>>>
>>>Total lines of code: 127
>>>Size: 5K
>>
>>Yeah but how much of a slow down does it cause for the end user? If
>>it's even a second on dialup then your implimentation is actually 1 to
>>2 K larger in effect. *shrugs*

It shouldn't cause any slowdown bc it's all created serverside. And from
the server pov, it's fairly simplistic code (e.g., no computation, jumping
through hoops, etc).

>>Perfect code...doesn't make for perfect sites. See that other post in
>>which I pinged you.

Pffft. I wouldn't say the above examples are perfect. Far from it, in fact.
Just another approach for you to consider. The primary reason I decided to
throw it together is bc I noticed you are in-lining your styles and jumping
through a lot of hoops to determine your layout. In fact, that's where most
of your code bloat comes from. You can take care of all of this server side
bc you already know what browser your user is using (simply gen the css
file contain the correct styles).

> Slight correction, teh current version is 30K, so if it's 6 seconds
> slower than the current version then there's no real difference,
> anything more than that and there's no reason to switch. I'll test
> your implementation tomorrow evening to see how well it fares. In my
> experience however it's better to saturate the connection end than the
> end users system...especially since the ratio of high speed
> connections is greater than the ratio of high speed systems...not to
> mention that code which relies too heavily on teh end users resources
> can lead to a lot of problems if they're not using high grade memory
> and processors. Teh code might look pretty, but it'll just be CRASH,
> CRASH, CRASH for most end users.

Sure. That's the major problem with going fully js. That's why the examples
I provided do everything serverside (e.g., gen the js/css on the server).
The only thing they do not do atm is to create static files to reduce the
need for gen'ing code by checking created dates (e.g., they just spit the
code over to the user).

The obvious thing (if you want to stay w/js) is to use those to create
files on your server, and simply have your htm file include the static
files (or call the autogen based upon file created dates and last updated
dates in the db).

Oh and. Yes, I fully agree. Smaller is not always better, for a number of
reasons, the least being compute overhead and added complexity. Even so,
bulky code can quickly become cumbersome. Just wait until you decide you
want to add some new neat feature... or you want to change the layout. From
what I can tell, the direction you're going will guarantee a rewrite in the
future. And sure, that might be easy, but why not let the puter do your
work for you? Again, that's where the whole serverside db bit comes in.
Ymmv, of course.

--
"We live in a primitive society, don't we? Neither savage nor wise. Any
rational society would either kill me or put me to some use." -- Hannibal
Lecter, Red Dragon, Thomas Harris

[Back to original message]