javascript link - Da dove viene inclusa la libreria jQuery? Google JSAPI? CDN?




download last (14)

Ecco alcune risorse utili, la speranza può aiutarti a scegliere il tuo CDN. Di recente MS ha aggiunto un nuovo dominio per le librerie di consegna attraverso il proprio CDN.

Vecchio formato: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js Nuovo formato: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

Questo non dovrebbe inviare tutti i cookie per microsoft.com. http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Ecco alcune statistiche sulla tecnologia più diffusa utilizzata sul web in tutta la tecnologia. http://trends.builtwith.com/

La speranza può aiutarti a scegliere.

Ci sono alcuni modi per includere jQuery e jQuery UI e mi chiedo che cosa stanno usando le persone?

  • Google JSAPI
  • Il sito di jQuery
  • il tuo sito / server
  • un altro CDN

Recentemente ho utilizzato Google JSAPI, ma ho scoperto che è necessario molto tempo per impostare una connessione SSL o anche solo per risolvere google.com. Ho usato il seguente per Google:

<script src="https://www.google.com/jsapi"></script>
<script>
google.load('jquery', '1.3.1');
</script>

Mi piace l'idea di utilizzare Google, quindi è memorizzato nella cache quando visito altri siti e per risparmiare larghezza di banda dal nostro server, ma se continua a essere la parte lenta del sito, posso cambiare l'inclusione.

Cosa usi? Hai avuto problemi?

Modifica: visitato il sito di jQuery e usano il seguente metodo:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>

Edit2: Ecco come ho incluso jQuery senza problemi nell'ultimo anno:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>

La differenza è la rimozione di http: Rimuovendo questo, non è necessario preoccuparsi di passare tra http e https.


Oltre alle persone che consigliavano di ospitarla sul proprio server, avevo proposto di tenerlo su un dominio separato (ad esempio, static.website.com) per consentire ai browser di caricarlo in un altro thread di contenuto. Questo suggerimento funziona anche per tutte le cose statiche, ad esempio immagini e css.


Lo aggiungerò come motivo per ospitare localmente questi file.

Recentemente un nodo nel sud della California su TWC non è stato in grado di risolvere il dominio ajax.googleapis.com (solo per gli utenti con IPv4), quindi non stiamo ottenendo i file esterni. Questo è stato intermittente fino a ieri (ora è persistente). Poiché era intermittente, avevo un sacco di problemi nella risoluzione dei problemi degli utenti SaaS. Ho trascorso molte ore a cercare di rintracciare il motivo per cui alcuni utenti non avevano problemi con il software, e altri stavano facendo tank. Nel mio solito processo di debug non ho l'abitudine di chiedere a un utente se hanno IPv6 spento.

Mi sono imbattuto nel problema perché io stesso stavo usando questo particolare "percorso" al file e sto usando solo IPV4. Ho scoperto il problema con gli strumenti degli sviluppatori che mi dicevano che jquery non si stava caricando, quindi ho iniziato a fare traceroutes, ecc ... per trovare il vero problema.

Dopo questo, molto probabilmente non tornerò mai ai file ospitati esternamente perché: google non deve andare giù perché questo diventi un problema, e ... uno di questi nodi può essere compromesso con il dirottamento del DNS e fornire js dannosi invece del file attuale. Ho sempre pensato che ero sicuro che un dominio google non sarebbe mai andato giù, ora so che qualsiasi nodo tra un utente e l'host può essere un punto di errore.


Non vorrei che nessun sito pubblico che sviluppassi dipendesse da nessun sito esterno, e quindi avrei ospitato io stesso jQuery.

Sei disposto ad avere un'interruzione sul tuo sito quando l'altro (Google, jquery.com, ecc.) Va giù? Meno dipendenze è la chiave.


jQuery 1.3.1 min ha solo 18k di dimensione. Non penso che sia un colpo da chiedere sul caricamento iniziale della pagina. Dopo di che verrà memorizzato nella cache. Di conseguenza, lo ospita da solo.


Ci sono alcuni problemi qui. Innanzitutto, il metodo di caricamento asincrono specificato:

<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load('jquery', '1.3.1');
  google.setOnLoadCallback(function() {
    // do stuff
  });
</script>

ha un paio di problemi. I tag di script sospendono il caricamento della pagina mentre vengono recuperati (se necessario). Ora, se sono lenti a caricare, ciò è negativo, ma jQuery è piccolo. Il vero problema con il metodo di cui sopra è che poiché il caricamento di jquery.js avviene in modo indipendente per molte pagine, finiranno il caricamento e il rendering prima che jquery sia caricato, quindi qualsiasi stile jquery che farai sarà una modifica visibile per l'utente .

L'altro modo è:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Prova alcuni semplici esempi come, avere una tabella semplice e cambiare lo sfondo delle celle in giallo con il metodo setOnLoadCallback () vs $ (document) .ready () con un carico jquery.min.js statico. Il secondo metodo non avrà uno sfarfallio evidente. La prima volontà. Personalmente penso che non sia una buona esperienza utente.

Ad esempio, esegui questo:

<html>
<head>
  <title>Layout</title>
  <style type="text/css">
    .odd { background-color: yellow; }
  </style>
</head>
<body>
<table>
  <tr><th>One</th><th>Two</th></tr>
  <tr><td>Three</td><td>Four</td></tr>
  <tr><td>Five</td><td>Six</td></tr>
  <tr><td>Seven</td><td>Nine</td></tr>
  <tr><td>Nine</td><td>Ten</td></tr>
</table> 
<script src="http://www.google.com/jsapi"></script>
<script>
  google.load("jquery", "1.3.1");
  google.setOnLoadCallback(function() {
    $(function() {
      $("tr:odd").addClass("odd");
    });
  });
</script>
</body>
</html>

Si dovrebbe (dovrebbe) vedere la tabella e quindi le righe diventano gialle.

Il secondo problema con il metodo google.load () è che ospita solo un numero limitato di file. Questo è un problema per jquery poiché è estremamente dipendente dal plug-in. Se provi a includere un plug-in jquery con <script src="..."> tag e google.load() il plug-in probabilmente fallirà con i messaggi di "jQuery non è definito" perché non è ancora stato caricato . Non vedo davvero un modo per aggirare questo.

Il terzo problema (con entrambi i metodi) è che sono un carico esterno. Supponendo che tu abbia alcuni plugin e il tuo codice Javascript sei al minimo di due richieste esterne per caricare il tuo Javascript. Probabilmente stai meglio con jquery, tutti i plug-in e il tuo codice e inseriscilo in un file miniato.

Dovresti utilizzare l'API delle librerie Ajax di Google per l'hosting? :

Per quanto riguarda i tempi di caricamento, in realtà stai caricando due script: lo script jsapi e lo script mootools (la versione compressa da sopra). Quindi ci sono due connessioni, piuttosto che una. Nella mia esperienza, ho riscontrato che il tempo di caricamento era in realtà 2-3 volte più lento del caricamento dal mio server condiviso personale, anche se proveniva da Google, e la mia versione del file compresso era di un paio di K più grande di quella di Google. Questo, anche dopo che il file è stato caricato e (presumibilmente) memorizzato nella cache. Quindi per me, dal momento che la larghezza di banda non importa molto, non ha importanza.

Infine, hai il potenziale problema di un browser paranoico che segnala la richiesta come una sorta di tentativo XSS. Solitamente non si tratta di un problema con le impostazioni predefinite, ma su reti aziendali in cui l'utente potrebbe non avere il controllo su quale browser utilizzare, per non parlare delle impostazioni di sicurezza che potrebbero avere un problema.

Quindi alla fine non riesco davvero a vedermi utilizzare l'API AJAX di Google per jQuery almeno (più le API "complete" sono in qualche modo una storia diversa) molto meno che pubblicare esempi qui.


Pro: Host su Google ha vantaggi

  • Probabilmente più veloce (i loro server sono più ottimizzati)
  • Gestiscono correttamente la cache - 1 anno (facciamo fatica ad avere il permesso di apportare le modifiche per ottenere le intestazioni direttamente sui nostri server)
  • Gli utenti che hanno già un link alla versione ospitata da Google su un altro dominio hanno già il file nella loro cache

Contro:

  • Alcuni browser potrebbero vederlo come XSS cross-domain e disabilitare il file.
  • In particolare gli utenti che eseguono il plugin NoScript per Firefox

Mi chiedo se è possibile INCLUDERE da Google, quindi verificare la presenza di alcune variabili globali o somesuch e se l'assenza viene caricata dal proprio server?


Devo votare -1 per le biblioteche ospitate su Google. Stanno raccogliendo dati, stile google analytics, con i loro wrapper attorno a queste librerie. Come minimo, non voglio che un browser client faccia più di quanto gli chiedo di fare, tanto meno qualsiasi altra cosa sulla pagina. Nel peggiore dei casi, questa è la "nuova versione" di Google di non essere malvagie - utilizzando un javascript non invadente per raccogliere più dati di utilizzo.

Nota: se hanno cambiato questa pratica, super. Ma l'ultima volta che ho preso in considerazione l'utilizzo delle loro librerie ospitate, ho monitorato il traffico http in uscita sul mio sito e le chiamate periodiche ai server di Google non erano qualcosa che mi aspettavo di vedere.


Sicuramente scelgo di avere JQuery servito dai server API di Google. Non sono andato con il metodo jsapi dato che non ho sfruttato altre API di Google, tuttavia, se fosse mai cambiato, lo considererei ...

Primo: i server di Google API sono distribuiti in tutto il mondo anziché nella mia posizione su server singolo: i server più vicini di solito significano tempi di risposta più rapidi per il visitatore.

Secondo: molte persone scelgono di avere JQuery ospitato su Google, quindi quando un visitatore arriva al mio sito potrebbero già avere lo script JQuery nella loro cache locale. Il contenuto pre-memorizzato nella cache di solito significa tempi di caricamento più rapidi per il visitatore.

Terzo: la mia società di web hosting mi addebita la larghezza di banda utilizzata. Non ha senso consumare 18k per sessione utente se il visitatore può ottenere lo stesso file altrove.

Comprendo di mettere una parte della fiducia su Google per pubblicare il file di script corretto e di essere online e disponibile. Fino a questo punto non sono stato deluso dall'uso di Google e continuerò questa configurazione finché non avrà senso non farlo.

Una cosa che vale la pena sottolineare ... Se nel tuo sito hai una serie di pagine sicure e non sicure potresti voler cambiare dinamicamente la sorgente di Google per evitare il solito avviso che vedi quando carichi contenuti non protetti in una pagina sicura:

Ecco cosa mi è venuto in mente:

<script type="text/javascript">
    document.write([
        "\<script src='",
        ("https:" == document.location.protocol) ? "https://" : "http://",
        "ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>" 
    ].join(''));
</script>

AGGIORNAMENTO 9/8/2010 - Alcuni suggerimenti sono stati fatti per ridurre la complessità del codice rimuovendo HTTP e HTTPS e semplicemente usando la seguente sintassi:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

Inoltre, è possibile modificare l'URL in modo che rifletta il numero principale di jQuery se si desidera assicurarsi che sia caricata l'ultima versione principale delle librerie jQuery:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

Infine, se non si desidera utilizzare Google e si preferirebbe jQuery, è possibile utilizzare il seguente percorso di origine (tenere presente che jQuery non supporta le connessioni SSL):

<script type="text/javascript">
    document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>

Un motivo per cui si potrebbe voler ospitare su un server esterno è quello di aggirare le limitazioni del browser delle connessioni concurenti a un particolare server.

Tuttavia, dato che il file jQuery che si sta utilizzando non cambierà molto spesso, la cache del browser si avvierà e renderà il punto discutibile per la maggior parte.

Il secondo motivo per ospitarla su un server esterno è quello di ridurre il traffico sul proprio server.

Tuttavia, data la dimensione di jQuery, è probabile che sarà una piccola parte del tuo traffico. Probabilmente dovresti cercare di ottimizzare il tuo contenuto reale.


In testa:

  (function() {
    var jsapi = document.createElement('script'); jsapi.type = 'text/javascript'; jsapi.async = true;
    jsapi.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google.com/jsapi?key=YOUR KEY';
    (document.getElementsByTagName('head')[0] || document.getElementsByTagName('head')[0]).appendChild(jsapi);
  })();

Fine del corpo:

<script type="text/javascript">
google.load("jquery", "version");
</script>

Potrei essere una vecchia scuola per questo, ma continuo a disapprovare il collegamento a caldo. Forse Google è l'eccezione, ma in generale, è davvero solo buone maniere ospitare i file sul tuo server.


Ho appena incluso l'ultima versione dal sito jQuery: http://code.jquery.com/jquery-latest.pack.js Si adatta alle mie esigenze e non devo mai preoccuparmi dell'aggiornamento.

EDIT: per una grande applicazione web, certamente controllarlo; scaricalo e servilo da solo. Ma per il mio sito personale, non me ne potrebbe importare di meno. Le cose non scompaiono magicamente, di solito sono deprecate per prime. Continuo abbastanza per sapere cosa cambiare per le versioni future.


prima cosa - non dovresti includerli in un ordine diverso?

qualcosa del genere dovrebbe funzionare:

<script src="http://ajax.aspnetcdn.com/ajax/jquery.validate/1.7/jquery.validate.min.js"></script>
<script src="http://ajax.aspnetcdn.com/ajax/mvc/3.0/jquery.validate.unobtrusive.min.js"></script>
<script>jQuery.fn.validate || document.write('<script src="js/jquery.validate.min.js">\x3C/script><script src="js/jquery.validate.unobtrusive.min.js">\x3C/script>'</script>

quello che sto facendo qui è semplicemente controllare se il primo plugin (jQ validate) è stato caricato. controllando una funzione di validate statica sull'oggetto jQuery.fn. Non riesco a controllare il secondo script allo stesso modo, perché non aggiunge nulla, basta fare il proxy dei metodi esistenti, quindi è più facile supporre che se il primo funziona, anche il secondo funzionerà - dopotutto, sono forniti dal stesso CDN.





javascript jquery ssl google-ajax-libraries