[theme-reviewers] Embedding inline JavaScript in <head>?

Wed Oct 17 13:19:41 UTC 2012

>
> And one more enqueue isn't
> going to be a perceptable difference in processing time in 99% of
> scenarios.

Disagreed. Even if the server serves the script in 1ms, with no extra 
load, it would still be one more HTTP request, which could be from 
100ms-500ms.

That's not a trivial difference.

Shinra Web Holdings wrote:
>
> I'm torn on this. On the one hand creating and hooking a function to
> invoke another function to include a file that is 1 line long just
> feels wrong. It's like the US spending a million dollars to make a pen
> that writes in space when the Russians just used pencils.
>
> On the other hand, the enqueue system is great and exists for a reason
> (plus it keeps code neater for ocd people). And one more enqueue isn't
> going to be a perceptable difference in processing time in 99% of
> scenarios.
>
> On the third hand, why allow users to print "raw" css for custom
> headers and backgrounds when this could also be wholly accomplished by
> enqueuing a bootstrapped php file with CSS headers as a style sheet?
> What's good for the goose, etc.
>
> While performance differences are trivial, they are real, and unless
> there's a compelling reason for not allowing people to include one
> line scripts directly or by hooking and anonymous function that echos
> the script (is that any better?), I think it should be up to the theme
> author.
>
> On Oct 16, 2012 12:49 PM, "Otto" <otto at ottodestruct.com
> <mailto:otto at ottodestruct.com>> wrote:
>
> On Tue, Oct 16, 2012 at 12:08 PM, Chip Bennett
> <chip at chipbennett.net <mailto:chip at chipbennett.net>> wrote:
> > Is there any particular reason that such a script can't be
> enqueued like
> > most other scripts, that would warrant such an exception?
>
> No, but I would still advocate allowing it for small scripts. Define
> "small scripts" arbitrarily. Say, less than 8 lines.
>
> The biggest reason to allow it is simply one of speed. Enqueuing
> forces you to have the script in a separate file, and adds the
> overhead of an extra HTTP request for the most common cases. For a
> single line of JS, this is a lot of unnecessary extra overhead.
> Especially when the script has no dependencies and is simply a shiv to
> do one particular thing. In this case, he's wanting to change no-js
> classes to js classes, via js, which makes sense for allowing pure CSS
> to handle the no-js case gracefully.
>
> The thinking is along the same lines as the "data URI" scheme, where
> you can include binary data like images inline to CSS or HTML as
> base64 text. For small files, the setup and teardown and data transfer
> overhead of an HTTP connection is quite a bit slower than simply
> always serving the file. You lose caching benefits in some cases, but
> at a certain point of smallness, it's worth that minor overhead to
> eliminate a larger overhead.
>
> -Otto
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> <mailto:theme-reviewers at lists.wordpress.org>
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20121017/9a0f06e5/attachment.htm>