[RFC] script.php
Re: [RFC] script.php
I think the best approach for 3.2 is to require PHP 5.3 and use assetic.
Re: [RFC] script.php
For the record, agree.naderman wrote:I think the best approach for 3.2 is to require PHP 5.3 and use assetic.
- bantu
- 3.0 Release Manager
- Posts: 557
- Joined: Thu Sep 07, 2006 11:22 am
- Location: Karlsruhe, Germany
- Contact:
Re: [RFC] script.php
If I remember correctly, this topic as never meant to be about 3.2. It was meant to be for 3.1, but that RFC forum does not accept new RFCs. So the question is: Is such a mechanism also required for 3.1?
- callumacrae
- Former Team Member
- Posts: 1046
- Joined: Tue Apr 27, 2010 9:37 am
- Location: England
- Contact:
Re: [RFC] script.php
Yeah, that's correct. I think something is required for 3.1, if only to reduce number of HTTP requests.bantu wrote:If I remember correctly, this topic as never meant to be about 3.2. It was meant to be for 3.1, but that RFC forum does not accept new RFCs. So the question is: Is such a mechanism also required for 3.1?
Re: [RFC] script.php
If the concern is about reducing HTTP requests, then look at image sprites instead of javascript.
Reducing 2 or 3 javascript requests down to one is tiny compared to the number of image HTTP requests.
PS: Assetic looks interesting, but the fact that it requires php 5.3 means we should wait on that until 3.2. The fact is a lot of people are still stuck on 5.2 because of their hosts, and waiting for 3.2 will ensure enough time passes that hopefully 5.3 will be the norm by then.
Reducing 2 or 3 javascript requests down to one is tiny compared to the number of image HTTP requests.
PS: Assetic looks interesting, but the fact that it requires php 5.3 means we should wait on that until 3.2. The fact is a lot of people are still stuck on 5.2 because of their hosts, and waiting for 3.2 will ensure enough time passes that hopefully 5.3 will be the norm by then.
Has an irascible disposition.
- callumacrae
- Former Team Member
- Posts: 1046
- Joined: Tue Apr 27, 2010 9:37 am
- Location: England
- Contact:
Re: [RFC] script.php
Firstly, that isn't my areaVSE+ wrote:If the concern is about reducing HTTP requests, then look at image sprites instead of javascript.
Reducing 2 or 3 javascript requests down to one is tiny compared to the number of image HTTP requests.
Images are loaded asynchronously, scripts are loads synchronously. Therefore, a delay on an image isn't as important as a delay on a script.
Two random images:
The first shows that the majority of the request time is latency, and therefore files can afford to be bigger in order to save HTTP requests. The second is just proving your point Stylesheets have also increased in time hugely since they were seperated. style.php was bad, but better than the alternative.
It's definitely for 3.2VSE+ wrote:PS: Assetic looks interesting, but the fact that it requires php 5.3 means we should wait on that until 3.2. The fact is a lot of people are still stuck on 5.2 because of their hosts, and waiting for 3.2 will ensure enough time passes that hopefully 5.3 will be the norm by then.
Re: [RFC] script.php
It sounds like what you want can be accomplished with http://yepnopejs.com/
Has an irascible disposition.
- callumacrae
- Former Team Member
- Posts: 1046
- Joined: Tue Apr 27, 2010 9:37 am
- Location: England
- Contact:
Re: [RFC] script.php
Not really.VSE+ wrote:It sounds like what you want can be accomplished with http://yepnopejs.com/
Re: [RFC] script.php
I say we use the async and defer attributes.
According to the HTML5 spec, they are no longer optional to follow, they are now obligatory to follow. So if we do something like this:
<script type="text/javascript" defer async src="somejsFile.js">
The browser must download it asynchronosly, just like and image is.
At the moment Opera ignores these 2 but it's their problem for not following the spec, not ours. The worse thing of not following the spec is to have bigger loading times when it's time to load the js (as it is now).
By using these attributes we use something native with no need of extra stuff or hacks or wharever. If we also use the cache-control header for 1 week cache (or even more!) we can even reduce, not only the traffic (usage of:if-modified-since) but also remove the need to send a request checking if that file has changed.
If we use that script.php the browser would have to download it every single time (I don't know a way to check if it was modified) and I don't even know if cache-control is possible as it does not depend on the url from where the file was called.
I think script.php is not the good option we are looking for. We do should reduce the size, and most importantly, the number of .js files when possible but having the server to process again and again and again the same thing.....
According to the HTML5 spec, they are no longer optional to follow, they are now obligatory to follow. So if we do something like this:
<script type="text/javascript" defer async src="somejsFile.js">
The browser must download it asynchronosly, just like and image is.
At the moment Opera ignores these 2 but it's their problem for not following the spec, not ours. The worse thing of not following the spec is to have bigger loading times when it's time to load the js (as it is now).
By using these attributes we use something native with no need of extra stuff or hacks or wharever. If we also use the cache-control header for 1 week cache (or even more!) we can even reduce, not only the traffic (usage of:if-modified-since) but also remove the need to send a request checking if that file has changed.
If we use that script.php the browser would have to download it every single time (I don't know a way to check if it was modified) and I don't even know if cache-control is possible as it does not depend on the url from where the file was called.
I think script.php is not the good option we are looking for. We do should reduce the size, and most importantly, the number of .js files when possible but having the server to process again and again and again the same thing.....