[Kss-devel] Why not to use KSS?

[Jeroen Vloothuis]

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.

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.

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


Solution?

Of these problems the file size is obviously the biggest issue. More 
than one person has complained about this on different occasions. 
Although work has been done on compacting KSS it still is quite heavy 
and will probably remain so (correct me if I am wrong) until some more 
drastic measures are taken.

One of the options Martijn and I discussed was replacing the current 
protocol and runtime for something simpler. I may have missed some 
critical points about the current design so please do not be offended by 
this (it was just a brain storm).

If we would do away with the whole command system and replace it with 
direct calls to Javascript we could save some bandwidth. It would also 
allow us to remove the runtime. A final bonus would be that it quires no 
integration code to work.

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>");

This example assumes you have JQuery installed. It immediately brings us 
to the problem this solution imposes. At the moment KSS tries to be 
library agnostic by wrapping everything in custom Javascript code. This 
means more code on the client and more Javascript in general to maintain.

The new system would mean that the server side components need to be 
specific to the client's libraries. I do not think this will be a big 
problem. The largest downside to this is the client side actions. These 
will become library specific as well. The server side code is easy 
enough to wrap in a library agnostic way. Client side actions will not 
be possible to wrap (otherwise we will be back at square one). One 
possible solution to this is to compile the KSS files to Javascript 
code. This could even be done runtime. Using compiled Javascript for 
binding would mean we could also drop the client side KSS parsing.

This idea would change a lot for KSS. It would stop wrapping functions 
and provide only the KSS syntax for binding events etc. All document 
manipulation will be done by directly executing Javascript code. This 
will cut down on the code needed, make it less of a framework (more a 
helper system).

The overall feel for the developer of a KSS application could remain the 
same. She would still write KSS files (these will get compiled) and use 
something like the current commandsets (which just generate something 
different than HTML/XML).

Conclusion:

With this post I just want to open some discussion on why KSS works as 
it is and what its limits are. I did not invent KSS, nor was I part of 
any of the design discussions. My hope is that this post can act as 
starting point to discuss the merits and the cons of the current system, 
nothing more.