JavaScript caching

Nao

  • Dadman with a boy
  • Posts: 16,082
JavaScript caching
« on May 10th, 2011, 06:43 PM »
Feature: JavaScript caching
Developer: Nao
Target: everyone
Status: 100% (believed to be complete.)
Comment:

Right after minifying your CSS and JS files, Wedge will cache them and gzip them. The good point is that it's smart enough to cache multiple files together, relieving the server a bit.

I'll use my script.js example again. At the time of writing, the regular script.js/theme.js duo is about 50KB in SMF2 (split over two files), less than 30KB in Wedge (with many extra functions in them), and the actual stuff you download is a single 6KB file, after minification and gzipping. Meanwhile in the wasteland, SMF2 still sends you 50KB of data. Because everyone knows all end-users absolutely need to have comments in the JavaScript code they execute.

Re: JavaScript caching
« Reply #1, on June 19th, 2011, 10:34 AM »
Why not minify and cache the single built file, rather than minifying separately and then combining and caching?  You'll probably get better perf.

Honestly, this is why I didn't use comments in the js files of olde, I figured it was way too much to run something on them to remove comments.  But, it's getting more popular now and making sense.

-[Unknown]

Re: JavaScript caching
« Reply #2, on July 1st, 2011, 02:17 PM »
Quote from [Unknown
link=msg=262640 date=1308472459]
Why not minify and cache the single built file, rather than minifying separately and then combining and caching?  You'll probably get better perf.
I originally minified everything together, but performance was not any better. Probably a bit worse IIRC. Plus, it had other issues linked to it. Once I started doing files separately, it went better.

Also, performance is not very important at the minification stage. Indeed, since everything is cached forever as long as the css files aren't modified, after a few hundred visits (encompassing all possible browser setups), the minifier will no longer be called at all.
Quote
Honestly, this is why I didn't use comments in the js files of olde, I figured it was way too much to run something on them to remove comments.  But, it's getting more popular now and making sense.
Yeah, it's a blessing, I find.
Commenting JS files should be mandatory. If only to help future developers get into the groove :)


Re: JavaScript caching
« Reply #4, on July 2nd, 2011, 08:52 PM »
Doesn't show up to guests (banned, remember? I tend not to go over there too often these days......)

Please copy & paste?

Re: JavaScript caching
« Reply #5, on July 2nd, 2011, 09:20 PM »
Well ... I am not banned there (yet  :eheh: ) but I cannot see it either.

Re: JavaScript caching
« Reply #6, on July 2nd, 2011, 09:44 PM »
Quote
An Error Has Occurred!
The topic or board you are looking for appears to be either missing or off limits to you.

Re: JavaScript caching
« Reply #7, on July 2nd, 2011, 09:46 PM »
I can't see it either, but I would probably have to re-activate my account to do so.


Re: JavaScript caching
« Reply #9, on July 2nd, 2011, 09:59 PM »
Why would I keep it? It's only another tie to the past I can do without and it means I find myself spending much less time browsing over there for stuff to laugh at - and I don't get dragged into stupid arguments with narrow-minded fools who don't really understand what's going on, and I was fed up of being labelled as a bringer of drama without due cause.

I don't need to go there, overall, except to browse for ideas for things to build for Wedge in the future, because I can. Oh, and it means that they're left to their own devices as far as security is concerned, after I called them out on a mod that allows for arbitrary iframe injection. I burned far far too much time there.

Re: JavaScript caching
« Reply #10, on July 2nd, 2011, 10:16 PM »
Quote from Arantor on July 2nd, 2011, 09:59 PM
Why would I keep it? It's only another tie to the past I can do without and it means I find myself spending much less time browsing over there for stuff to laugh at - and I don't get dragged into stupid arguments with narrow-minded fools who don't really understand what's going on, and I was fed up of being labelled as a bringer of drama without due cause.
I didn't realize you'd disabled your account as soon as SMF2 Gold was released... That was 3 weeks ago.
Of course I haven't been (much) to sm.org after that, myself... So I could hardly have noticed anything.
Still, it's a shock to see you aren't in the memberlist.

(And as always, the SMF team has yet to take your request into account. Your account can still be browsed.)
Quote
I don't need to go there, overall, except to browse for ideas for things to build for Wedge in the future, because I can. Oh, and it means that they're left to their own devices as far as security is concerned,
Which is always fun... Of course, the only one who'll ever know is you. Because if a hacker finds any way to hack into SMF, they probably won't tell. Hundreds of SMF forums, hacked, with no explanation at all... I feel bad for the users most of all.
Quote
after I called them out on a mod that allows for arbitrary iframe injection. I burned far far too much time there.
Agreed. Totally agreed.

Re: JavaScript caching
« Reply #11, on July 2nd, 2011, 10:34 PM »
The usual rule is 30 days, so it's no surprise. Though I thought they'd be glad to see the back of me to be honest.

Re: JavaScript caching
« Reply #12, on July 2nd, 2011, 11:01 PM »
They're seeing your back in every sense of the term!

Re: JavaScript caching
« Reply #13, on July 3rd, 2011, 01:55 AM »
Quote from Joshua Dickerson on March 9th, 2011, 01:30 AM
What does that have to do with this function?

It's used for the following to remove bad URLs from the indexers view. Well, if we just changed them to real, good URLs and then worked with those instead, that would make more sense and more understandable for everyone IMO.

It's not even in use everywhere. I took a look at the message index for this board:
result:
Code: [Select]
<span style="font-weight: bold;" onclick="expandPages(this, 'http://www.simplemachines.org/community/index.php?board=74.%1$d', 150, 2100, 50);" onmouseover="this.style.cursor='pointer';"> ... </span>

So, if it isn't being used there with an odd URL, shouldn't it be presenting errors or odd accesses in the logs?

It's used several times on the infocenter toggle object on the board index to add quotes around the $txt and session vars.

The following is a shining example from the display template. It is so much harder to read because of the escaping:
Code: [Select]
sTemplateBodyEdit: '\n\t\t\t\t\t\t\t\t<div id="quick_edit_body_container" style="width: 90%">\n\t\t\t\t\t\t\t\t\t<div id="error_box" style="padding: 4px;" class="error"><' + '/div>\n\t\t\t\t\t\t\t\t\t<textarea class="editor" name="message" rows="12" style="width: 100%; margin-bottom: 10px;" tabindex="5">%body%<' + '/textarea><br />\n\t\t\t\t\t\t\t\t\t<input type="hidden" name="af00a1ba031" value="c5e7963677f5827d8476125917ac76b2" />\n\t\t\t\t\t\t\t\t\t<input type="hidden" name="topic" value="382883" />\n\t\t\t\t\t\t\t\t\t<input type="hidden" name="msg" value="%msg_id%" />\n\t\t\t\t\t\t\t\t\t<div class="righttext">\n\t\t\t\t\t\t\t\t\t\t<input type="submit" name="post" value="Save" tabindex="6" onclick="return oQuickModify.modifySave(\'c5e7963677f5827d8476125917ac76b2\', \'af00a1ba031\');" accesskey="s" class="button_submit" />&nbsp;&nbsp;<input type="button" value="Spell Check" tabindex="7" onclick="spellCheck(\'quickModForm\', \'message\');" class="button_submit" />&nbsp;&nbsp;<input type="submit" name="cancel" value="Cancel" tabindex="8" onclick="return oQuickModify.modifyCancel();" class="button_submit" />\n\t\t\t\t\t\t\t\t\t<' + '/div>\n\t\t\t\t\t\t\t\t<' + '/div>',
It escaped the tabs with \\t and line breaks with \\n so they can be readable in JavaScript... but not the HTML output that anyone is actually going to read. It changed all of the closing divs... why? I don't even see any URLs here for it to escape.

I finally found one that supports what everyone is saying:
Code: [Select]
sTemplateSubjectNormal: ', JavaScriptEscape('<a href="' . $scripturl . '?topic=' . $context['current_topic'] . '.msg%msg_id%#msg%msg_id%" rel="nofollow">%subject%</a>'), ',
result:
Code: [Select]
sTemplateSubjectNormal: '<a hr'+'ef="http://www.simplemachines.org/community/index.php'+'?topic=382883.msg%msg_id%#msg%msg_id%" rel="nofollow">%subject%<' + '/a>'

How, you might ask, do I propose we fix that? Well, there are two (or even three) options.

One means that a normal, simple link is no longer created in the template. That makes the non-cached JavaScript a lot smaller.
Code: [Select]
Modify QuickModify() returning that link with the correct information. Makes a whole lot more sense that way.

Second would be to use the JavaScript var: smf_scripturl.
Code: [Select]
sTemplateSubjectNormal: \'<a href="\' + smf_scripturl \'?topic=', $context['current_topic'], '.msg%msg_id%#msg%msg_id%" rel="nofollow">%subject%</a>\'',

The last would be a URL creator function (pseudo since I'm using the browser to write all of this):
Code: [Select]
function url(base_uri = smf_scripturl, query_string, args)
{
   // see sprintf(): http://www.diveintojavascript.com/projects/javascript-sprintf
   return sprintf();
   // there are also easier replace().
}

Any way you look at that, it actually makes it easier for you to rewrite the URLs. It could still be possible to use a JS escaping function, but we should really figure out what we want to do with it and how it makes the user safer.

Re: JavaScript caching
« Reply #14, on July 3rd, 2011, 01:57 AM »
Oh, I remember that discussion now. It was about what JavaScriptEscape did, and why it was necessary to call it for URLs - because there were all kinds of bad URLs getting into Google (namely the one indicated with %msg_id% in it)

Re: JavaScript caching
« Reply #15, on July 3rd, 2011, 01:57 AM »
I just realised that can get be banned.