[Kss-devel] Why not to use KSS?

[Alec Mitchell]

The following are my thoughts on these objections, they are all
reasonable and vaild.  However, I think the problems are perhaps not
all quite as serious as they might seem.  My perspective is that of
someone who has been using the system extensively, but is not involved
in its development or design.

On 5/25/07, Jeroen Vloothuis <jeroen.vloothuis at xs4all.nl> wrote:
> During a chat session with Martijn we came to the following list of
> problems with the current state of KSS. Note that these are my
> interpertations of his objections. Anything might be misrepresented by
> me (so don't blame him ;-).
>
> Problem descriptions:
>
> Problem number one is the filesize. KSS is easily on of the biggest JS
> frameworks out there. Compared to libraries such as JQuery etc. it is
> massive. To make matters even worse you actually need extra libraries if
> you want effects or anything similar.

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.

> 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.

> 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.
>
> And the framework point brings us nicely to the final point in that KSS
> is not flexible enough. Martijn gave some examples of applications in
> which he wanted more done on the client (on example was filtering a list
> of options based on some selects etc.). This could be done with KSS but
> the overhead of writing plugins etc. did not outweigh any advantages
> (especially not since he wanted less bloated server communication as well).

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.  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 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.

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.  The
benefit is that, once written, such a plugin can be used by people who
don't write js to do completely different things.

> Solution?

...

> Let's say a KSS request would return some commands to replace some HTML.
> This can be changed to something like this:
>
> $("div").html("<b>new stuff</b>");

I have wished at times to be able to call a specific js method on some
data from the server side.  But I don't know if it would be worth
ditching the xml, which is quite easy to debug (maybe because if its
inherent limitations).  I think this would be a hard sell for the KSS
folks, because the command language is a big part of what it's all
about IMO, but this is an interesting idea to consider for making the
server side more flexible, and the runtime and protocol lighter.

...

My 2 cents,
Alec