[xwiki-devs] [proposal] JS and CSS improvements

[Sergiu Dumitriu]

Sachin Mittal wrote:
> Hi,
> I read that posting.
> I have a doubt though, how would having a separate extension class would
> solve the purpose of faster loading of static content.
> Over the time I can add lot of css and js files to be loaded by these
> extension classes thus brining back to square 1.
> Alternately in current javascript.vm and stylesheets.vm I can have a
> conditional load by calling few needed files only based on xwiki action,
> thus making the page load faster.
> 
> The problem is that the css and js code is very fragmented which makes it
> difficult to collect place the static content in say web server.
> Next many time css and js code needs to be parsed by velocity context to
> evaluate certain variables which in most case refer to the image url. We
> cannot put these dynamic files into web container and I believe loading such
> files (static but dynamic) also increases the page load time.
> Thus collecting all the js, css and images files and placing them into three
> separate pre determined directories would avoid use of velocity code inside
> the static content.
> This then can be moved to web server thus achieving the desired result.
> 
> Also when the files are same type are grouped together, it is lot easy to
> manage and make further improvements on it.

This is true for a static XWiki installation, when you know what 
features you have in the site. This is the old way of doing things, and 
it worked almost fine with the previous XWiki-one-big-product-0.9. Now, 
we're turning XWiki into a platform with lots of modules on it. Still, 
we are far from there, since now we managed to separate the products 
from the platform pretty well, but we're just starting to separate 
applications from the products/platform. And this step is hard and slow 
because the platform is not extensible enough. Sure, it is easy to write 
applications that just require some wiki documents, but it becomes 
almost impossible when they require some javascript, some CSS and 
modifying some parts of the interface.

The future XWiki will be more like Gecko/Firefox, a strong platform with 
very few features, but many extension points, on which you can put lots 
of apps and extensions and get a powerful product like XWiki Workspaces. 
And with a few click on the Administration interface, you can turn it 
into Watch. Or into XWits. Or into Spawn. Or into all of them together. 
Without restarting the server, downloading and importing xars, changing 
configuration files, installing plugins and other hard work. It will be 
easier than installing a Firefox addon. Firefox is so popular and 
because they decided to go the XUL+overlay way, without limiting what 
you can do with the browser. There are hundreds (thousands?) of 
extensions for Firefox, especially because it is simple and 
unrestrictive to write "the extensions of your dreams". Can we say that 
about XWiki right now? No. But I'd like to be able to say that. And for 
that we need to balance the performace/features ratio. If you want the 
most performant site, just write plain HTML and put it in a HTTPD + 
Squid cluster. Want to be as extensible as Facebook or iGoogle? Well, 
you have to give up some of the performance.

And the simple decisions that you would like to put in javascript.vm are 
maybe simple for the moment, when we have less than 20 js files for 
which we know where and when are used, but they are increasing.


However, once you decided how your site looks like, we could have a 
"Statify" tool that exports all the cacheable js/css content into some 
static resources.

> Thanks
> Sachin
> 
> 
> 
> Sergiu Dumitriu-2 wrote:
>> You should read http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions
>>
>>

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/