[Kss-devel] Why not to use KSS?

[Jeroen Vloothuis]

Alec Mitchell wrote:
>> Problem number one is the filesize.
> 
> I've been running in production with gzipped js (using mod_deflate).
> While the total amount of js is certainly larger since I started
> depending on kss, it's still inder 80 Kb for all of the plone js
> including KSS (though without prototype, mochikit, and effects.js,
> which I don't currently use).  For me, this makes the bandwidth issue
> relativley negligable.

80Kb for the whole of Plone seems reasonable to me as well. One of the 
problems I have with comments like it is to big is that there is no 
clear goal for how big something should be. Smaller is always better but 
for something like this (that is cached) it depends a lot on the use 
case. Good to know that using mod_deflate makes such a difference though.

>> The second problem is that KSS adds an extra runtime to the browser.
>> This directly relates to problem one in that it makes the client load
>> greater.
> 
> Indeed, but doesn't any js library suffer from this issue?  I haven't
> noticed much delay except of course when there are kss actions to
> process.  The time it takes to bind the actions can be significant,
> but this seems mostly due to cssQuery and the way it is called.  The
> top 4 calls during page load are calls in cssQuery (all to toString
> and thisElement) and they take up 86% of the total js load time (1.5
> secs, with js profling and all logging on).  It's the 151 calls to
> toString which really kill performance, they account for 70% of the
> time (the 10815 calls to thisElement only take 15% of the time, which
> may also be worth optimizing).  The kicker is that the median call to
> to toString is quite fast (a few ms as one would expect), but one of
> the calls to it takes 0.84 sec.  This implies that some tremendously
> large object is being passed by cssQuery into toString, and this seems
> like something quite fixable (if perhaps hard to track down).  This
> may be an issue with the way kss uses cssQuery (which I know nothing
> about), or a fundamental issue with cssQuery (which Plone has depended
> on for some time).
> 
> Removing logging from production seems to help a bit, but obviously
> there are still performance problems.

Are you experiencing any serious issues or is this more in line with 
faster is (always) better?

>> A third problem is that KSS is more of a framework than a library. This
>> means you have to drink the cool-aid in order to use it.
> 
> I think anything that does AJAX requires a good amount of buy-in, at
> least in my experience (using raw sarissa and mochiKit).  However, the
> amount of really nice functionality I've been able to get without
> writing a single line of js, and with fairly little straightforward
> python on the server side.  

I think there may also be some conceptual difference on how to do Ajax. 
KSS is pretty much a what you see is what you get approach. It is aimed 
and working on the DOM.

Some people may prefer a different approach in which they make the 
browser something more of a client application. In this case you only 
want to transfer data and do all coding on the client.

> The protocol bloat is a slight issue
> (though only with the response), but gzipping output helps this a bit,
> and the transparency of the format is really nice to have when
> debugging issues.

I think using something like JSON instead of the current HTML/XML could 
help here as well. You would basically still keep the same structure but 
safe some of the verboseness.

This may not make a big difference though. Because in most KSS usage you 
would send quite a bit of HTML for replacement operations as well.

Again your suggestion of gzipping would solve it transparently.

> I agree that the overhead of writing a client side plugin seems higher
> than the advantages gained.  But, in the end making a client side
> plugin is generally only a couple extra lines wrapping whatever
> existing js you're using to register it as a plugin and pass it the
> expected parameters.  There's nothing to stop you from using whatever
> client side scripting you want, and then wrapping it only when you
> want to start applying it generally based on KSS rules or when you
> want to make it available publicly.  This isn't AJAX though.

I hope that with some more documentation we can lower the barrier so 
that anyone can easily what to do to create a plugin. In most cases 
plugins should not be needed though due to way KSS works.

It may be good to have some smallish (semi) real life examples of how to 
  do certain things with KSS. This would help with explaining the usage 
of kss attributes etc.

> The big issue is that the plugins available from the server side are
> limited.  So far they meet my needs, even if it means I need to send a
> bigger chunk of html than is strictly necessary (again, this is partly
> remedied by gzipping).  And I imagine writing a plugin t handle data
> from the server side is daunting (I haven't needed to), and the
> immediate benefit, vs writing custom handling in js is nil.

Have you looked at the recent tutorials on this subject? I would 
appreciate any feedback on these if they are in any way unclear.

> I have wished at times to be able to call a specific js method on some
> data from the server side.

It should be possible to create a plugin which will in effect evaluate 
any data passed in. This may make a useful addition to the core set. By 
having such a command we can ease the learning curve a bit. It would 
also allow you to recycle existing knowledge.

Thanks for your thoughts and feedback :-)