[dokuwiki] Re: jQuery dev
- From: michael@xxxxxxxxxxxxxxxx
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Wed, 22 Jun 2011 13:44:38 +0200
Hi,
> the newsletter remembered me that DokuWiki moves to a jQuery JS
> implementation. I would have two feature requests/ideas what I already
> inserted to the issue list of the dokuwiki-jquery fork mentioned in
> the newsletter today. Hope this was the right place.
That wiki page is unfortunately quite outdated, the current jQuery
development happens in the master branch of the main repository and that
fork has been merged already. The current "refactoring" page is
http://www.dokuwiki.org/devel:jsrefactor and the DokuWiki bug tracker is
the better place to report such feature requests.
> # Please use JS Loader to insert jQuery and all other stuff [1]
>
> I would suggest to add a Javascript Loader on top. I can suggest
> Head.JS as Loader lib but there are a bunch of similar projects,
> someone may check out features and licences.
>
> Advantages:
>
> * Separation of PHP/JS logic: e.g. what script is needed when and how
> is it inserted, clear distinction between libs, plugins and
> configurations. It's also a benefit if PHP and JS components are not
> mixed and can developed separately.
What do you mean with mixed PHP and JS components? Except from the code in
js.php that merges the JS files and the small part in tpl_metaheaders()
that adds a few variables for translation and some page info I can't see
any places where the code is mixed. Plugins do provide a script.js file
that is automatically loaded, so they don't need to add anything in PHP
for the JS to be loaded.
> * Performance: JS Loaders enable several parallel requests for scripts
> (even if newer browsers here better thatn the old ones) what is good
> if a lot of Dokuwiki plugins bring own JS scripts
I think this is good if you really have a large amount of larger JS files.
I'm not sure if we reach that amount as e.g. gzip does also reduce the
size a lot normally. Furthermore many plugins will have small JS files,
using a request for each plugin does imho create a lot of overhead. E.g.
imagine you have 10 plugins installed, each of it has a small JS file, and
then you have jQuery and jQuery-ui, jQuery has 91K, jQuery-ui 200K. That
way you get 12 requests of the server of which only two transfer a
significant amount of data. If we shouldn't use jQuery-ui on all pages it
might be worth a try to load it separately and only on the pages where it
is needed, but I don't think it makes sense to simply load all plugin JS
separately, especially as it means that all plugins need to be split into
two parts: One part that checks if the JS is needed, and another one that
does the actual work.
> * Other Benefits: most JS Loaders can insert CSS what might be a good
> feature for plugin authors, or good for JS components what need
> additional CSS styles (e.g. jQuery-UI) what are senseless without JS
I'm not sure if this is good as DokuWiki has also it's own CSS loader that
combines all CSS files and does e.g. add the userstyle files after the
plugin styles so you can overwrite plugin styles without using more
specific selectors. Loading plugin styles separately does not only
increase the server load by creating more requests for normally very small
files (where the connection overhead is most probably larger than the
actual file size) but will also break the normal order of CSS declarations
unless you load the userstyle files separately. I really like that plugin
CSS files are automatically included in the main CSS file.
The jQuery-UI CSS is (uncompressed) 34K large, compressed together with
the default template and plugin styles on dokuwiki.org I get a 7.5K
gzip-compressed response. I'm not sure if this is really worth the effort,
also given that most users do use JS I think this will dramatically
decrease the performance as this means that the CSS would only be loaded
after the dom loaded event, but now it can be loaded immediately, even
before the JS has been parsed (unless you load it directly in the first
JS, but even then if you load it after the loader it will only be loaded
after the loader has been parsed, which means that images won't be loaded
as third step after the HTML (HTML, CSS, images) but as fourth or fifth
step if you count JS parsing, too).
> Disadvantages:
>
> another 5-10kb to load but this should not be a problem compared to
> jQuery+UI with around 200kb
The current JS on DokuWiki.org is 306K large, compressing it using gzip
gives me a size of 102K.
The main problem I see is that all these optimization techniques rely on
the assumption that you know when the HTML is created which JS files will
be needed or that it isn't important that the JS is loaded at load time. I
think both of these assumptions don't apply to DokuWiki:
- If fancy syntax elements like sortable tables are used on a page can
only be known if you look at the instructions or parse the HTML. Both of
these things aren't done in a normal request that is served from the cache
on the server side, so they need to be done on the client side when the
HTML has already been rendered (or need to be stored in the cache, but
then imho it becomes really ugly and not at all separated)
- Loading JS after the rendering or at least after the DOM parsing might
either create an additional delay or cause content to be displayed that
isn't in it's final form yet because the JS would modify it if it was
loaded.
As jQuery and jQuery-ui are really large compared to the rest of our JS
files, maybe adding those two files separately and maybe even using
head.js in order to load them might make sense, so that we end up with one
directly included JS file - head.js - and then 3 files that are loaded
using head.js (jQuery, jQuery-ui, the rest of the DokuWiki JS). If this
should be really faster (which is something I can imagine) this might be
worth a try. My personal opinion is that everything else creates a lot of
overhead, needs a lot of modifications from plugin authors and won't cause
any real benefits.
> # Add option to use a CDN [2]
>
> It might be a good option if a wiki admin can load jQuery+UI from
> another location like a CDN, to improve performance. Possibilities:
>
> * a simple true/false config parameter to use the Google CDN sources
> * config parameters to put own URIs in
Using a CDN for jQuery makes sense I think as these files have a
significant size, so I vote for either adding a configuration option or
adding an event so plugins could do that. This could also be perfectly
combined with the separation of the JS files I've suggested above.
Michael
--
DokuWiki mailing list - more info at
http://www.dokuwiki.org/mailinglist
Other related posts:
