[JS Disc.] window.name misbruiken?

[BtM909]

Ik kwam een paar dagen geleden de volgende release tegen: quipt^beta.

Wat doet dit wonderlijk stukje software
qUIpt is a small library that is capable of caching Javascript files inside the users browser - even if SSL is active. qUIpt helps the site owner by reducing traffic costs and the user with faster page loading.

Werkt het? En hoe?
[ul]
• Quite simple
• It checks for the contents of window.name while your page is being loaded.
• If there's nothing inside the window.name cache the JS files defined by you are fetched via XHR
• The same happens if the users enters your site for the first time of his current browser session or if document.referrer is off-domain or empty
• After that the contents of window.name are being evaluated
• If the user requests the next page on your domain the JS files are directly taken from window.name - no more requests necessary


Is het secure?
[ul]
• Yep - if the user enters your site the first time the JS files are requested - no matter what's already inside window.name
• An attacker can't set window.name from other tabs the user might surf on parallely


source: http://quipt.googlecode.com/svn/trunk/lib/
demos: http://quipt.googlecode.com/svn/trunk/example/ (alhoewel 1 demo )

De techniek ken ik al iets langer, maar ik vraag me af of je hier enige kanttekeningen bij zou moeten plaatsen; vandaar deze mogelijke discussie

Wat denken jullie? Is het wel zo secure als het lijkt? Heeft deze vorm van caching voordelen tov. standaard manieren? Kan je zo cookie size problemen omzeilen (mits alleen benodigd voor de huidige sessie)? Is het verstandig om 150kb aan JS in je global name space te dumpen?

[TeeDee]

Zo even gauw gelezen (testen e.d. moet ik nog doen), maar wat is de absolute meerwaarde van quipt ten opzichte van client-side cache in combinatie met bijvoorbeeld gzip?

[Johnny]

Je kan het niet als vervanger voor een (session) cookie gebruiken want andere websites die in hetzelfde venster worden geladen kunnen de gegevens uitlezen. Om het voor caching te gebruiken vind ik een beetje idioot, want dat iedere degelijke browser standaard al, ook al zou het sneller zijn dan is het effect te verwaarlozen terwijl je wel complexiteit aan je code toevoegd en afhankelijk bent van een niet standaard en ongedocumenteerde browser feature die op ieder moment kan breken.

[glashio]

Leuke vinding

Alleen de voordelen :

reducing traffic costs and the user with faster page loading

zijn er niet echt.

Want nu al, zal
1. Een niet gewijzigde .js file een http status 304 terug krijgen (dus geen nieuwe download van de content)
2. Het laden/parsen van de pagina kan al versneld worden door de attribuut defer toe te voegen aan je script tag.

En 1 nadeel, een refresh (F5) heeft niet meer de behauvior om alles (dus ook de .js files) geforceerd te refreshen.

[ Voor 0% gewijzigd door glashio op 08-07-2008 14:33 . Reden: typo refer=defer ]

[Juup]

Beetje vaag verhaal om het in window.name te stoppen. Waarom niet gewoon in globalStorage/userdata opslaan? Dat kan iig niet gelezen worden door een volgende externe pagina die in datzelfde window geopend wordt.

[ Voor 13% gewijzigd door Juup op 08-07-2008 23:05 ]

[crisp]

Test: 2 js files van elk zo'n 50KB van localhost inladen:

Met quipt:
- lege cache: 170ms
- soft refresh: 100ms

Zonder quipt:
- lege cache: 80ms
- soft refresh: 60ms

compleet nutteloos dus, plus het feit dat je geen JS files van een ander domein kan fetchen. Daarbij is het ook veel fragieler dan gewoon simpel door de browser laten afhandelen.

[LauPro]

Volgens mij heeft dit alleen maar nut als je heel veel javascript-referenties hebt (zeg meer dan 10) en per pagina steeds verschillende gebruikt.

[Juup]

crisp schreef op dinsdag 08 juli 2008 @ 23:41:
Test: 2 js files van elk zo'n 50KB van localhost inladen:

Met quipt:
- lege cache: 170ms
- soft refresh: 100ms

Zonder quipt:
- lege cache: 80ms
- soft refresh: 60ms

Okee dat is dus de test voor een snelle verbinding. Ik neem aan dat het voor real-world sites (tragere verbinding) de balans iets meer naar quipt doorslaat.

[crisp]

Juup schreef op woensdag 09 juli 2008 @ 00:09:
[...]

Okee dat is dus de test voor een snelle verbinding. Ik neem aan dat het voor real-world sites (tragere verbinding) de balans iets meer naar quipt doorslaat.

Nee, natuurlijk niet. Quipt moet het dan bij de eerste hit ook zelf nog van de trage(re) server ophalen en vervolgens evallen. Bij volgende hits komen die files gewoon uit de browsercache (tenzij je een knurft van een sysadmin hebt/bent en geen cacheing headers meestuurt met je statische files, maar dan is quipt symptoombestrijding en geen oplossing).

[Johnny]

Maar dan nog, wanneer heb je ooit een situatie waarbij de snelheid waarop externe javascriptbestanden die gecached worden een dusdanig beperkende factor is waarbij het inkorten van die tijd een factor van enig belang is in het correct functioneren, of een betere gebruikerservaring van de website?

[crisp]

LauPro schreef op dinsdag 08 juli 2008 @ 23:56:
Volgens mij heeft dit alleen maar nut als je heel veel javascript-referenties hebt (zeg meer dan 10) en per pagina steeds verschillende gebruikt.

Ook niet. Quipt biedt geen ondersteuning voor incremental toevoegingen van script aan window.name. Als je op pagina 1 a.js en b.js inlaadt via quipt, en op pagina 2 met een andere quipt-config c.js wilt inladen dan heb je pech: window.name is al gevuld en quipt gaat meteen door met evallen.

Aan de andere kant, als quipt in dat geval c.js wel zou inladen en toevoegen aan window.name dan doet hij vervolgens een eval() van a.js + b.js + c.js terwijl je mogelijk op die pagina alleen c.js nodig hebt.
eval() is gewoon een dure operatie; vele malen duurder dan het inline parsen van een javascript file.

Dus:
- je voegt uiteindelijk een extra script (en dus een extra request - namelijk quipt.js zelf) toe
- je krijgt daar geen extra tijdswinst voor terug (integendeel)
- je kan geen scripts van een ander domein inladen
- geen mogelijkheid tot inladen van extra scripts op volgpagina's - het is alles of niets de eerste keer
- scripts zijn niet meteen inline in je pagina beschikbaar aangezien het laden asynchroon gebeurd
- afhankelijkheid van XHR en daarmee minder betrouwbaar dan de ingebouwde parser van de browser zelf
- bij een niet-ok HTTP status op 1 file is er geen enkele JS beschikbaar, ook niet uit wel goed ingeladen files (eval() wordt dan nooit getriggered)
- etcetera...

[Johnny]

Het is dus een slechte oplossing die niet werkt voor een probleem wat niet bestaat.

Dit is eigenlijk niks meer dan een browserbug die XSS toestaat, hopelijk breekt een browser zo snel mogelijk deze functionaliteit door bijvoorbeeld de hoeveelheid toegestane karakters te verminderen voordat er slimmerikken zijn die er persoonlijke informatie in gaan steken, die vervolgens wordt gestolen.

[crisp]

Johnny schreef op woensdag 09 juli 2008 @ 00:16:
Maar dan nog, wanneer heb je ooit een situatie waarbij de snelheid waarop externe javascriptbestanden die gecached worden een dusdanig beperkende factor is waarbij het inkorten van die tijd een factor van enig belang is in het correct functioneren, of een betere gebruikerservaring van de website?

Als dat zo is dan kan je beter je JS bestanden minificeren, gzipped serveren en zoveel mogelijk combineren om HTTP requests uit te sparen. Scripts die inline niet benodigd zijn zet je dan vlak voor de </body> ipv in de <head>.

Het is evident dat een tool die uiteindelijk precies hetzelfde moet doen als wanneer je de scripts gewoon in <script> tags refereert in je document, maar daar nog een dure eval() aan toevoegt gewoonweg haast niet sneller kan zijn (tenzij de browser het van een wel erg trage disk moet lezen, maar over het algemeen zal de cache gewoon uit memory komen).