Architettura, strumenti, compatibilità e insidie JavaScript

1. Come diceva Mike, le richieste HTTP sono costose e un modo semplice per minimizzarle è di minimizzare il numero di file. Di solito, c'è un file "personalizzato" e un link a una libreria, come jQuery. Idealmente, la libreria è collegata da un CDN, come il repository delle librerie Javascript di Google, che consente ai browser di memorizzare una sola volta la libreria e utilizzarla su più siti.
   Inoltre, come ha detto Wyatt, "un enorme file" è spesso più file in fase di sviluppo, che vengono poi combinati e ridotti alla produzione.

2. È considerato un cattivo design per unire codice e markup (oltre a markup e styling), indipendentemente dalle lingue. La separazione di questi aspetti rende la manutenzione molto più semplice per tutta una serie di motivi. Per ulteriori informazioni, controlla il pattern MVC e perché è così popolare.

3. jQuery è probabilmente uno dei framework più popolari là fuori, tuttavia, YUI è anche abbastanza popolare, come MooTools. Ci sarebbe una tonnellata da confrontare, quindi non posso parlarne qui, ma Wikipedia ha una tabella di funzioni per loro e diversi altri quadri . Personalmente andrei con jQuery o MooTools, se non altro per il fatto che sono in sviluppo attivo e aggiornati di recente, il che suggerisce che sono al passo con gli ultimi standard e problemi di compatibilità.

4. La compatibilità è qualcosa su cui dovresti assolutamente preoccuparti, specialmente quando fai cose JS personalizzate. L'utilizzo di un framework come jQuery o MooTools lo rende molto più semplice, poiché si occupano di molti dei problemi di compatibilità di base che potrebbero sorgere. È comunque necessario testare nei browser di destinazione, per assicurarsi che non ci siano comportamenti imprevisti. Il modo più semplice per testare i browser è aprire il tuo progetto in qualunque cosa tu possa ottenere. Tutti i principali browser hanno a disposizione strumenti di sviluppo che possono aiutarti in tutte le fasi del debug.

In generale, non c'è un solo modo per fare javascript. È davvero una bellezza in realtà.

1) Sì e no. In molti casi, "un enorme javascript" è in realtà un mucchio di file in fase di sviluppo che vengono combinati per le effusioni nella consegna.

2) Certo, funzionano bene? In realtà questa decisione dipende da alcuni problemi di pubblicazione / consegna. Devi avere i byte in qualche modo, ma quello che fa meno male.

3) Lotti. Probabilmente di più ora che è praticamente cotto in ASP.NET MVC. E in realtà, penso che stiamo iniziando a vedere una reazione contro questi "helper del browser", una sorta di framework, dal momento che il supporto del browser sta migliorando direttamente e la gente gira di più JS.

4) Il test è il grande incubo con javascript IMHO. Esistono alcuni framework di test unitari, ma quelli tendono a cadere in parte in una certa misura in quanto il vero problema non sono i bit testabili unitamente, ma piuttosto le strane interazioni tra browser, utente e rete che sono difficili da definire senza sedersi e guardare sopra la spalla di qualcuno mentre usano il tuo sito in un 486dx del 1992 con un browser homebrew scritto dal loro cugino di secondo grado. In ogni caso, forse lo strumento migliore nel tuo arsenale è selenio in quanto consente almeno di eseguire test automatici con uno stack javascript completo e un browser completo.

1. HTTP ha un sacco di spese generali. Il caricamento di un file di grandi dimensioni è quasi sempre più efficiente rispetto al caricamento di diversi file di piccole dimensioni. Ma con JavaScript, il lato negativo è che rende più difficile mantenere il codice organizzato e debuggarlo. Su un progetto al quale sto lavorando proprio ora, l'ho impostato in modo che la pagina possa essere caricata in modalità produzione o debug: in modalità debug, tutti i file .js vengono caricati individualmente, proprio come li ho scritti io . Nella modalità di produzione, sono tutti gestiti attraverso YUI Compressor , quindi concatenati in un unico file di grandi dimensioni.

2. In generale, è un cattivo design. Dovresti cercare di mantenere tutto modulare, altrimenti ti ritroverai con un groviglio gigantesco che nessuno capisce. Un'altra cosa: se si incorporano JavaScript o CSS in una pagina Web generata dinamicamente, il browser non sarà in grado di memorizzarli nella cache.

3. JQuery è ancora piuttosto popolare e in fase di sviluppo attivo. Ma non cercherò di confrontarlo con le altre librerie concorrenti, perché non ne so abbastanza su di loro.

4. Siate preoccupati. Sii molto preoccupato.