Blog Documentation Book a Demo
Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

A tad un-needed?

ChrisGwynneChrisGwynne ✭
edited April 2007 in Vanilla 1.0 Help
<link rel="stylesheet" type="text/css" href="/community/extensions/CategoryJumper/style.css" /> <link rel="stylesheet" type="text/css" href="/community/extensions/AddOnIntegration/addon.css" /> <link rel="stylesheet" type="text/css" href="/community/extensions/LussumoBanner/style.css" /> <script type="text/javascript" src="/community/js/global.js"></script> <script type="text/javascript" src="/community/js/vanilla.js"></script> <script type="text/javascript" src="/community/js/ajax.js"></script> <script type="text/javascript" src="/community/js/ac.js"></script> <script type="text/javascript" src="/community/extensions/YellowFade/functions.js"></script> Anyone else feel, that should a load of add-ons be used that the extra markup within the header is un-necessary? Can't it be condensed at all?
«134

Comments

  • WallPhoneWallPhone
    Hmm... /me thinks a CSS/JS complier add-on would be useful here. Can also see it being handy when you have your add-ons in a different directory than the vanilla default (to ease maintaining multiple installs or security reasons)
  • DinoboffDinoboff
    I am working on it. It is almost done.
  • skubeskube
    edited March 2007
    I also think a JS library (like jQuery) should be standard with Vanilla. I know it's been talked about before, but I really do think extension developers (as well as users) would benefit if there was a standard put forth as a base library. From what I understand, Mark included Script.aculo.us and Prototype in the initial release of Vanilla, but took it out after people complained it was too large. What is too large (IMHO), is several (some times redundant) scripts being loaded when perhaps one (jQuery) could do. Also, I think the Panel should standardize on definition lists (<dl>) instead of the <h2> + <ul> combo that is currently being used. But maybe that's just a personal preference. ;)
  • WallPhoneWallPhone
    You could even do <label><ul>... or is it <caption><ul>? I can't remember.
  • TomTesterTomTester New
    I strongly agree with the request to standardize on one small library (JQ)

    Some relevant notes:

    #1 - Vanilla only includes JS files when they are actually USED
    This means that the ridiculously large auto-complete script which requires the
    even larger prototype library does not show up on the discussions overview.
    (It is however included on *every friggin page with whispers enabled*)

    #2 - The browser caches these (largish) JS files which minimizes the true impact
    after the first download. It is NOT certain that a very small JS file will be
    cached as efficiently (strange eh! I guess it depends on connections vs kBs)
    Browser behavior may depends on cache size settings as well as connectivity.

    #3 - Mod-GZip almost negates most size differences
    If your server supports sending data as gzip, a 45kB library is reduced to much
    less. In that context, actual CSS or JS pre-compression seems rather useless...

    That said, I would love to explore ways to make Vanilla even faster... and reducing
    CSS size, head-clutter and redundant-functionality libraries seems like a good thing!
  • StashStash ✭
    You can do autocomplete with jQuery. Perhaps we should look into replacing the autocomplete function with a JQuery equivalent?

    JS surce compression is an interesting beast. I'm generally for it when releasing things as not everyone DOES have GZip enabled on their servers unfortunately. However, they tend to GZip less well than the uncompressed source...

    Also, GZip doesn't help with the number of server requests that are currently pretty high once you have a bunch of extensions enabled (I assume most people do).
  • TomTesterTomTester New
    edited March 2007
    Most JS compression is based on whitespace removal and reducing length of function names
    (similar to tokenization), hence, GZIP *should* do a similar job on larger JS files... (25kb+)
    Since compressed JS is also rarely 'legible', I'd suggest/prefer GZIP *any* day...
    BTW, does Mod_GZIP bundle a complete page or does it only work on single connections?

    Somewhat related/food for thought:
    Your average set of 'fluff' images (backgrounds, user icons, etc.) easily exceed the size of all JS &
    CSS files combined    ... (and cannot be compressed by ModGzip)

    Perhaps we should focus our attention on creating an add-on to suppress big images during times
    of high-server load     as a means to guarantee zippy performance? Wachathink?
  • DinoboffDinoboff
    edited March 2007
    I am working on a js/css merger for. In my first test I just use global.js and vanilla.js: 15kb without compression, 11kb with jsmin and 4kb with gzip.

    Also the advantage of gzip is that all the scrip can be compressed, prototype can't be with jsmin.

    The merger is ready, I just need to patch the Head control. Instead of the list of external js, you will have some few js link to /js/packer.php?files=1,2,3...&minify=1.
  • y2kbgy2kbg New
    how often does the merger sript run, every time a page is called? wont that hurt performance? How does it know whitch js to merge?
  • mallow005mallow005
    edited March 2007
    Just a note, the points you should be looking to optimize is NOT the size, but the amount of HTTP Requests. There are some papers on the subject, but basically the amount of HTTP Requests are the deciding factor on site loading time and responsiveness, NOT the size of the files (of course optimizing is always nice). So, yes, a stitcher/compiler + gzip would be the best way to go. Google actually inserts all their CSS and Javascript inline in the page itself to reduce HTTP requests, and you KNOW they're optimizing as much as possible.

    @skube and Wallphone: I think the current markup is fine... why would a Definition List be better? DLs are usually best used for pairs or directly related items, whereas ULs are best for any amount of items (which I think better suits navigation items). The navigation items are not definitions of the header, the header (h2) is naming the section and then lists the options. DLs are more appropriate in forms (label-input pairs) than navigation. What I am more peeved about is that "Start a new discussion" is an H1. It is not actually a header for a section and there should only be one H1 per document (at the top).
  • y2kbgy2kbg New
    "Google actually inserts all their CSS and Javascript inline in the page itself"

    Whoa interesting you have link to an artical about that. i makes me wanto be like google
  • iternityiternity
    Dinboff, thank you for your work, I was hoping for this
  • birdmanx35birdmanx35
    Drupal went all jQuery, and jQuery rocks. I'm all for it- one of the biggest deterring factors for me was all the included Javascript libraries...
  • DinoboffDinoboff
    The head control won't have to do more works. It just have to do something like that:


    file=1,2,3 is the list of js or css file id. The files to pack. The path are saved in the db, and list is cached. It will only the db when you add an addon.

    The packer don't merge the files each, it check it has a up-to-date cache version of the requested package.
    The user will have to download the package if his cached version is not up to date.
  • TomTesterTomTester New
    edited March 2007
    @mallow: my god you're right about google! learning something new every day... thanks!

    OK, if INCLUSION is the best solution (note: I'm not convinced it is for large JS files, but hey)
    then IMHO the quickest 'fix' is to rewrite the standard functions AddStyleSheet & AddScript
    in Framework.Control.Head to INCLUDE the CSS and JS in the header.

    That should be ultra-simple... not?

    For JS you add <script><!-- before, and // --></script> after. Insert the JS file 'as is' in the middle.

    Similarly for CSS (just use <style><!-- before, and --></style> after.

    (There may be several security issues to take into account, but basically this seems straightforward?!)
  • skubeskube
    @mallow: I guess this has been debated quite thoroughly elsewhere. I do believe it basically comes down to personal preference and specific situation. Generally, I think DLs can (and should) be used in this particular situation simply because it would implicitly group items together, with minimal code, thus making CSS and DOM targeting easier. Currently each Panel is structured like so :
    ul -> li -> h2, ul -> li
    Where it could be instead:
    dl -> dt -> dd
    My belief is less nests, less mess. Also, I totally agree with your point about the H1 usage (which further supports my thoughts regarding H2s). I think a good test is to always check how a page renders without any styling. If it still makes sense, then you've got it correct.
  • WallPhoneWallPhone
    inline-Inclusion works for Google because they have relatively lightweight page designs and they design to send the user away after 1-3 page views. A forum with a dozen extensions is hardly lightweight, and a forum's visitors visit several pages in a session, so I think the compiled separate result cached on the browser would be best.
  • iternityiternity
    skube, who could do that and hand it over to mark?
  • skubeskube
    It would be quite easy to do, conceptually. The problem is that everything else (styles, themes, extensions) are all based on the current structure. Maybe it's just something to keep in mind in case Vanilla 2.0 ever gets considered.
  • StashStash ✭
    WallPhone, you took the words right out of my mouth. As soon as you have a user hitting many pages, you want a cacheable file for JS and CSS. However, since the JS and CSS won't change all that often on a real forum (not a dev one obviously), bundling the many files into a few should have some tangible results.

    Skube, you going to redo it for us to give a try with? ;)
This discussion has been closed.