Visualizzazione dei risultati da 1 a 10 su 10
  1. #1

    [prototype] peso (kb) della libreria

    Premetto che mi è molto piacevole scrivere codice utilizzando questa libreria; la uso spesso, ma non sempre, dipende dalle effettive necessità, quando posso (a seconda dei tempi di sviluppo disponibili) ne faccio a meno, scrivendo tutto a manina...

    comunque vengo al punto: ogni tanto do un'occhiatina alle nuove versioni di prototype, alle nuove funzionalità introdotte e alla risoluzione di eventuali bug, e magari se conveninete aggiorno gli script dei siti realizzati con le precedenti versioni.
    così ho fatto un confronto tra la versione 1.5.0 e la 1.5.1:deludente sorpresa il peso è passato da 69 a 94 kb!
    Ora non voglio discutere in merito dell'uso di una piuttosto che dell'altra versione, ma mi chiedo dove vogliano andare a finire: evidentemente gli sviluppatori non tengono in adeguato conto la leggerezza in termini di kb del loro framework.
    100 kb per una libreria js sono veramente troppi a mio avviso; considerando anche il fatto che spesso si accoppia a prototype anche l'uso di scriptacolous, per implementare effetti visuali, autocompleter, drag&drop e altre finezze, siamo fuori con l'accuso.

    Mi piacerebbe sentire qualche parere al riguardo, fermo restando che non è mia intenzione scatenere flame su quale framework è migliore, ognuno è libero di usare quello che preferisce.

  2. #2
    già che l'ho appena pubblicato ... con questo servizio la versione 1.6 da 120Kb diventa pesante circa 22Kb

    http://packed.it/

    Se lo userai sarai il primo, dopo di me (c'ho creato JS e CSS del sito in esame)

    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  3. #3
    ti rispondo prima di cliccare sul link e visionare il tuo lavoro: ho già provato in passato alcune versioni compresse di prototype, funzionavano su tutti i browser, mentre mi davano problemi con safari...


    p.s.
    comunque ci metto la mano sul fuoco che sarò il primo ad usarlo, dopo di te...

  4. #4
    Originariamente inviato da buribus
    ti rispondo prima di cliccare sul link e visionare il tuo lavoro: ho già provato in passato alcune versioni compresse di prototype, funzionavano su tutti i browser, mentre mi davano problemi con safari...
    questo servizio è nuovo e non usa niente di quello che hai già provato in passato.

    Comunque tutto è possibile, se avrai problemi con Safari sei pregato di farmelo sapere perchè io o già testato prototype, che era incompatibile con i compressori che conosci, e non mi ha dato un problema che è uno
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  5. #5
    una cosa non mi è chiara riguardo alla compressione del css insieme al javascript: mettiamo che io ho un default.css che sono gli stili del sito, credo non mi convenga comprimerlo includendolo nel progetto di packed.it, ma lo lascio così com'è, per gli utenti con javascript disabilitato, sarebbe il basic.css del tuo esempio.
    Nei file da comprimere invece ci metto oltre ai js anche i css dei vari lightbox, niftycorner, carousel, etc.

    comunque veramente veramente complimenti

  6. #6
    allora, se hai un solo css, magari leggero, puoi comprimere solo il javascript ed usare quel css per chi ha javascript e chi no.

    In teoria, puoi comprimere javascript e css separatamente, devi cambiare i nomi dei files (uno packed.js.php, l'altro packed.css.php ... per esempio) e usare la compressione client per JavaScript e niente compressione client per il css.

    In questo modo:
    - gli utenti compatibili JavaScript scaricheranno la versione client compressa in gzip solo la prima volta, oppure la versione client senza compressione ... ma sempre solo la prima volta, guadagni spazio e velocizzi il tutto a prescindere che il browser supporti gzip o meno

    - gli utenti non compatibili con JavaScript, ma anche quelli compatibili, scaricheranno la versione gzip, se compatibili o quella normale ma minimizzata, senza usare il javascript, ergo a prescindere che abbiano JS abilitato o meno e che siano compatibili gzip o meno, prenderanno la versione migliore solo la prima volta, poi lavora il file server e gestisce la cache


    Detto questo, il tuo file CSS base, se non è un CSS dedicato per i soli browsers che non supportano JavaScript, devi includerlo comunque nel progetto ... come io ho incluso il basic.css in packed.it ... questo sia per ottimizzare anche quel file, sia perchè il tag link serve come alternativa ma se un browser è compatibile con javascript non si accorgerà di quel tag, ergo rischi di non avere i CSS basilari del tuo sito.

    Quindi, in poche parole, se fai un progetto includendo i CSS per le lib che mi hai detto, devi metterci anche il CSS del sito o questo non si vedrà ... e specificare nel tag link immediatamente dopo quello script il CSS base del sito.

    Questo NON significa che chi ha JS scaricherà due volte quel file, il bello è proprio questo, se hai JS non scarichi quel CSS, non arriva proprio la chiamata al server, se non hai JS non scarichi il JS e vedi quel CSS, non arriva la chiamata al server per il JS ma solo per il CSS ... e per concludere puoi fare un progetto con tutto, JS e CSS ed ottimizzare il CSS per gli utenti senza JavaScript a parte senza usare la compressione client così a prescindere da chi è, utilizzerai meno banda possibile e l'utente navigherà sempre veloce in qualunque situazione.

    Spero di aver spiegato meglio il tutto e grazie per i complimenti
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  7. #7
    avrei un'altra domandina sto per terminare un progetto e ho intenzione di sottoporne i css e i javascript alla tua cura...

    il quesito riguarda i collegamenti src dei tag <img /> e degli attributi background degli stili: dai miei test credo sia necessario usare i collegamenti assoluti.

    esempio css
    Codice PHP:
    #previous {background:url([url]http://www.mysite.com/images/up.gif[/url]) right top no-repeat } 
    oppure
    Codice PHP:
    #previous {background:url(/images/up.gif) right top no-repeat } 

  8. #8
    il path può anche essere relativo ... assoluto diciamo che è meglio e non ti preoccupare del peso, sia la compressione client che quella server ridurranno drasticamente ogni link assoluto.

    In generale però può anche essere relativo, ovvero se includi il file packed.it.php (o quello che è) la directory di partenza sarà quella ... se hai una cartella images nella root ed il file packed.it.php stà nella root ti basta mettere images/nomefile
    se invece packed.it sta da un'altra parte, e con esso anche la cartella packed.it salvo modifica del file packed.it.php e della variabile path, puoi usare ../images/nomefile

    Come ti ho detto con un path assoluto vivi più sereno ma se fai un paio di tests e non esci dal sito packed.it puoi modificare il css direttamente nella textarea e ritentare, insomma vedi tu come può essere più comodo per le tue esigenze

    P.S. ricorda che il CSS alternativo, quello base per gli utenti senza JavaSript, deve rispettare le stesse regole se presente nella stessa dir del file packed.it.php (più facile mostrare/testare il tutto che descriverlo)
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  9. #9
    E' stupendo vedere quanto funziona la tua cura dimagrante per script e css!!! Packed sarà implementato su tutti i miei nuovi progetti.

    Mi piacerebbe sottoporti il risultato delle mie e delle tue fatiche, powered by packed, un po' ritardo in quanto ho avuto dei problemi coi dns e non lo potevo pubblicare: il sito, modesto sul lato server (in asp perchè avevano un server windows, non mi ricordo se il db ha 4 o 5 tabelle ), nel javascript rappresenta il massimo dell' espressione delle mie possibilità attuali. eccolo: http://www.cicosrl.com

    tra css e js se mi ricordo bene è passato da poco meno di 200kb (praticamente inusabili prototype e scriptaculous senza packed!!!) a incredibili 30 kb, più o meno: uno spettacolo.
    Ho usato collegamenti assoluti nelle img, in quanto su firefox andava ok ma su ie non si vedevano, era comunque un problema mio di percorsi tra le directory, per sbrigarmi ho tagliato la testa al toro....

    un'altra domandina banale ce l'avrei riguarda IE5 e replace.js: dalle stats dei miei siti IE5 rappresenta lo 0,7% del totale (la versione 6 e 7 insieme fanno circa l'85%), bisogna ancora tenerlo in conto???

  10. #10
    Ciao buribus, mi fa piacere tu abbia scelto la soluzione packed.it

    Purtroppo questa non è la sezione adatta per ricevere pareri sui siti quindi risponderò brevemente: mi piace!

    Semplice ed efficace con i giusti contrasti e tecnicamente accessibile.
    Anche la soluzione in fade tra sezioni mi ricorda un pò packed.it

    L'unico appunto che vorrei farti, inerente il JavaScript, è aggiungere un this.blur() sull'evento di ogni link per evitare quel "brutto" contorno derivato dalle varie liste di links (perlomeno in FireFox lo vedo bene sia sui links sopra che su quelli sotto)

    In ultimo, come ho scritto anche tra i commenti di Ajaxian, a breve packed.it sarà disponibile off-line, ovvero si potrà inserire nel proprio server aumentando la semplicità del sistema e rendendolo più comodo da sfruttare ma per quel che ho visto, nel tuo caso, il server supporta non ASP Classic ma ASP.NET (packed.aspx è in C# per MONO o .NET) quindi ti manca solo di abbandonare il vecchio asp e passare a qualcosa di più serio

    Per le immagini, considera che un path assoluto pesa praticamente zero una volta passato in packed.it poichè qualunque immagine lo utilizza sfrutterà il doppio sistema compressione client + deflate (o gzip) ergo una manciata di bytes per l'utente finale, nulla di più ... ma volendo poi usare anche percorsi relativi purchè questi partano dalla cartella della pagina che sfrutta il sistema, nel tuo caso la root dello stesso.



    [edit]
    Riguardo IE5 ... quel tag scritto in quel modo
    non comporta alcuno stress per il server e nessun download per il client ... o meglio, solo lo 0.7% riconoscerà quel tag e scaricherà quel file quindi non ti preoccupare, un piccolissimo plus che potrà garantire maggiore visibilità al sito ... certo è che se la libreria sotto (Prototype + Scriptacuolus) non supporta IE5 quel tag diventa praticamente superfluo
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.