Perché tutti scelgono JSON su XML per jQuery? [chiuso]

Pensavo che XML fosse altamente portatile e potesse essere usato come mini database. Ho visto XML usato ovunque. Vedo persino grandi aziende passare a JSON . Anche Microsoft ha integrato il supporto per JSON. Qual è l'hype su JSON?

Fondamentalmente perché JSON è riconosciuto nativamente da JavaScript, è davvero leggero, minimalista e altamente portatile perché si basa solo su due strutture fondamentali:

• Una raccolta di coppie nome / valore. In varie lingue, questo viene realizzato come oggetto, record, struct, dizionario, tabella hash, elenco con chiave o array associativo.
• Un elenco ordinato di valori. Nella maggior parte delle lingue, questo viene realizzato come una matrice, un vettore, un elenco o una sequenza.

L'XML non inizia davvero a brillare fino a quando non inizi a mescolare insieme diversi schemi spaziali. Quindi vedi che JSON inizia a cadere, ma se hai solo bisogno di un formato di serializzazione per i tuoi dati, JSON è più piccolo, più leggero, più leggibile dall'uomo e generalmente più veloce di XML.

Trovo che un grande vantaggio di JSON su XML sia che non devo decidere come formattare i dati. Come alcuni hanno dimostrato, ci sono numerosi modi per fare anche semplici strutture di dati in XML - come elementi, come valori di attributo, ecc. Quindi devi documentarlo, scrivere XML Schema o Relax NG o qualche altra schifezza ... È un casino.

L'XML può avere i suoi meriti, ma per lo scambio di dati di base, JSON è molto più compatto e diretto. Come sviluppatore Python, non vi è alcuna discrepanza di impedenza tra i tipi di dati semplici in JSON e in Python. Quindi, se stavo scrivendo un gestore lato server per una query AJAX che chiedeva informazioni sulle condizioni della neve per un determinato comprensorio sciistico, avrei creato un dizionario come il seguente:

conditions = {
    'new_snow_24': 5.0,
    'new_snow_48': 8.5,
    'base_depth': 88.0,
    'comments': 'Deep and steep!',
    'chains_required': True,
}
return simplejson.dumps(conditions)   # Encode and dump `conditions` as a JSON string

Quando tradotto tramite JSON (usando una libreria come 'simplejson' per Python), la struttura JSON risultante sembra quasi identica (tranne che in JSON, i booleani sono in minuscolo).

La decodifica di tale struttura richiede solo un parser JSON, sia esso per Javascript o Objective-C per un'app iPhone nativa o C # o un client Python. I float verrebbero interpretati come float, le stringhe come stringhe e booleani come booleani. Usando la libreria "simplejson" in Python, simplejson.loads(some_json_string)un'istruzione mi restituirebbe una struttura di dati completa come ho appena fatto nell'esempio sopra.

Se avessi scritto XML, avrei dovuto decidere se fare elementi o attributi. Sono validi entrambi i seguenti:

<conditions>
    <new-snow-24>5</new-snow-24>
    <new-snow-48>8.5</new-snow-48>
    <chains-required>yes</chains-required>
    <comments>deep and steep!</comments>
</conditions>

<conditions newSnow24="5" newSnow48="8.5" chainsRequired="yes">
   <comments>deep and steep!</comments>
</conditions>

Quindi non solo devo pensare ai dati che potrei voler inviare al client, ma devo pensare a come formattarli. XML, sebbene più semplice del semplice SGML essendo più rigoroso con le sue regole, fornisce ancora troppi modi per pensare a quei dati. Quindi dovrei fare per generarlo. Non potevo semplicemente prendere un dizionario Python (o altra semplice struttura di dati) e dire "vai a farti nel mio XML". Non ho potuto ricevere un documento XML e dire immediatamente "vai a trasformarti in oggetti e strutture di dati" senza scrivere un parser personalizzato o senza richiedere l'overhead aggiuntivo di XML Schema / Relax NG e altri problemi simili.

Il fatto è che è molto più semplice e molto più diretto codificare e decodificare i dati in JSON, specialmente per gli scambi rapidi. Ciò può valere di più per le persone che provengono da un background linguistico dinamico, poiché i tipi di dati di base (elenchi, dizionari, ecc.) Incorporati in JavaScript / JSON vengono mappati direttamente sugli stessi o simili tipi di dati in Python, Perl, Ruby, ecc.

Le prestazioni di JSON non sono molto diverse dall'XML per la maggior parte dei casi d'uso, JSON non è adatto e leggibile per strutture profondamente annidate ... ti imbatterai in]]]}], il che rende difficile il debug

È leggero rispetto a XML. Se è necessario ridimensionare, ridurre i requisiti di larghezza di banda!

Confronta JSON

 [
      {
           color: "red",
           value: "#f00"
      },
      {
           color: "green",
           value: "#0f0"
      },
      {
           color: "blue",
           value: "#00f"
      },
      {
           color: "cyan",
           value: "#0ff"
      },
      {
           color: "magenta",
           value: "#f0f"
      },
      {
           color: "yellow",
           value: "#ff0"
      },
      {
           color: "black",
           value: "#000"
      }
 ]

in XML:

 <colors>
      <color >
           <name>red</name>
           <value>#f00</value>
      </color>
      <color >
           <name>green</name>
           <value>#0f0</value>
      </color>
      <color >
           <name>blue</name>
           <value>#00f</value>
      </color>
      <color >
           <name>cyan</name>
           <value>#0ff</value>
      </color>
      <color >
           <name>magenta</name>
           <value>#f0f</value>
      </color>
      <color >
           <name>yellow</name>
           <value>#ff0</value>
      </color>
      <color >
           <name>black</name>
           <value>#000</value>
      </color>
 </colors>

Solo un aneddoto dalla mia esperienza personale:

Ho scritto una piccola directory Javascript, prima con i dati in XML, e poi l'ho adattato per usare JSON in modo da poterli eseguire fianco a fianco e confrontare le velocità con Firebug. Il JSON ha finito per essere circa 3 volte più veloce (350-400 ms contro 1200-1300 ms per visualizzare tutti i dati). Inoltre, come altri hanno notato, il JSON è molto più semplice per gli occhi e la dimensione del file era del 25% più piccola a causa del markup più magro.

 <colors>
      <color name='red'     value='#f00'/>
      <color name='green'   value='#0f0'/>
      <color name='blue'    value='#00f'/>
      <color name='cyan'    value='#0ff'/>
      <color name='magenta' value='#f0f'/>
      <color name='yellow'  value='#ff0'/>
      <color name='black'   value='#000'/>
 </colors>

Con gli attributi, XML è carino. Ma per qualche ragione, l'XML fatto in casa è generalmente composto al 100% da elementi e brutto.

Il facile consumo da parte di JavaScript può essere uno dei motivi.

JSON è il migliore per il consumo di dati nelle applicazioni Web dai servizi Web per le sue dimensioni e facilità d'uso, soprattutto grazie al supporto integrato in JavaScript . Immagina il sovraccarico di calcolo per l'analisi di un frammento XML rispetto alla ricerca istantanea in JSON.

Un ottimo esempio è JSON-P. È possibile recuperare i dati da un servizio Web racchiuso in una chiamata della funzione di richiamata, come my_callback({"color": "blue", "shape":"square"});all'interno di un <script>tag generato dinamicamente in modo che i dati possano essere consumati direttamente nella funzione my_callback(). Non c'è modo di avvicinarsi a questa comodità utilizzando XML.

XML sarebbe il formato di scelta per documenti di grandi dimensioni, in cui si dispone di un framework per il rendering di pagine di dati in più formati utilizzando XSLT. XML può anche essere utilizzato con i file di configurazione dell'applicazione per la leggibilità tra molti altri usi.

Nessuno qui ha menzionato il vantaggio principale di XML: regole di validazione (DTD, XSD). Le mie conclusioni, avendo usato entrambi:

• JSON è perfetto per Ajax, soprattutto se sviluppi tu stesso server e client. Fondamentalmente crei oggetti js direttamente nello script del tuo server!
• XML brilla negli ambienti aziendali, quando è necessario stabilire standard di scambio di dati tra grandi organizzazioni burocratiche. Spesso una parte sviluppa la sua parte mesi prima di un'altra, quindi beneficia davvero della convalida delle sue richieste rispetto all'XSD concordato. Inoltre, nelle grandi aziende, il trasferimento dei dati viene spesso tradotto tra sistemi diversi. Questo è anche il punto di forza di XML, pensa XSLT. Esempio: conversione senza codice in JSON: p

Ovviamente, c'è json-schema in fase di sviluppo, ma non troverai supporto integrato da nessuna parte.

Sono un fan di entrambi, hanno solo punti di forza diversi.

Ora che ci sono codificatori e decodificatori JSON per la maggior parte delle lingue, non c'è motivo di NON utilizzare JSON per usi dove ha senso (e questo è probabilmente il 90% dei casi d'uso per XML).

Ho anche sentito parlare di stringhe JSON utilizzate in grandi database SQL per facilitare le modifiche allo schema.

Onestamente, non c'è molto di diverso tra JSON e XML nel fatto che possono rappresentare tutti i tipi di dati. Tuttavia, XML è sintatticamente più grande di JSON e questo lo rende più pesante di JSON.

JSON non ha disallineamenti di impedenza con la programmazione JavaScript. JSON può contenere numeri interi, stringhe, elenchi, matrici. XML è solo elementi e nodi che devono essere analizzati in numeri interi e così via prima di poter essere utilizzati.

Entrambi sono fantastici e molto portatili. Tuttavia, JSON sta guadagnando popolarità poiché si serializza in meno caratteri nella maggior parte dei casi (il che si traduce in un tempo di consegna più veloce) e poiché corrisponde alla sintassi dell'oggetto JavaScript, può essere tradotto direttamente in un oggetto in memoria che rende Ajax molto più facile da strumento.

XML è ancora eccezionale. JSON è solo il "più recente e il più grande" rispetto a XML.

Analizzato facilmente da JavaScript ed è leggero (un documento in JSON è più piccolo di un documento XML che contiene gli stessi dati.)

JSON è efficacemente serializzato JavaScript in quanto è possibile eseguire la valutazione (aJsonString) direttamente in un oggetto JavaScript. All'interno di un browser è un gioco da ragazzi JSON che si adatta perfettamente a JavaScript. Allo stesso tempo, JavaScript è un linguaggio dinamico tipicamente impreciso e non può sfruttare in modo nativo tutte le informazioni specifiche sul tipo disponibili in un documento Xml / Xsd. Questi metadati extra (che sono ottimi per l'interoperabilità) sono un ostacolo in JavaScript che rende più noioso e noioso lavorare con.

Dimensioni vs prestazioni

Se sei in un browser, JSON è più veloce da serializzare / deserializzare in quanto è più semplice, più compatto e soprattutto supportato in modo nativo. Ho alcuni benchmark di database Northwind disponibili che confrontano le dimensioni e la velocità tra i diversi serializzatori disponibili. Nella libreria di classi di base il serializzatore XML DataContract di Microsoft è oltre il 30% più veloce di quello JSON. Anche se questo ha più a che fare con lo sforzo che Microsoft ha messo nel loro serializzatore XML poiché sono stato in grado di sviluppare un JsonSerializer che è più di 2,6 volte più veloce di quello XML. Per quanto riguarda i payload basati sui benchmark, sembra che XML sia all'incirca più di 2xle dimensioni di JSON. Tuttavia, ciò può esplodere rapidamente se il payload XML utilizza molti spazi dei nomi diversi all'interno dello stesso documento.

XML è olio di serpente gonfio nella maggior parte delle situazioni. JSON ti offre la maggior parte dei vantaggi senza il gonfiore.

Un grande vantaggio diverso da quelli menzionati qui. Per gli stessi dati, ci sono diversi modi per rappresentarlo come file XML ma solo un modo con JSON, rimuove l'ambiguità :)

Di gran lunga non sono un esperto, ma dalle varie società per cui ho lavorato usiamo generalmente XML in piccoli ambienti di dati o valori di configurazione (web.config è un ottimo esempio).

Quando si dispone di grandi quantità di dati, in genere, si consiglia di riferire su tali dati. E XML non è un'ottima fonte di reportistica. Nel grande schema delle cose, sembra che un database transazionale sia più facile da segnalare / cercare rispetto a XML.

Questo ha senso? Come ho detto sopra, non sono un esperto, ma dalla mia esperienza questo sembra essere il caso. Inoltre, credo che Microsoft abbia integrato il supporto JSON a causa dell'ondata di sviluppatori che si sono spostati sul lato client o con azioni di script per migliorare la visualizzazione dell'interfaccia utente ( Ajax ) e l'Ajax di Microsoft non è stato utilizzato tanto quanto altre librerie come jQuery e MooTools ( Anche YUI di Yahoo è in quel mix) grazie alla loro meravigliosa integrazione di oggetti serializzabili usando JSON.

Mi ritrovo a scrivere il codice ora implementando il serializzatore JSON nel mio codice VB. È troppo facile e dal punto di vista dell'aggiornamento / modifica, non puoi batterlo. Immagino sia il modo in cui Microsoft ci rende dipendenti da VS. Di recente ho convertito un'applicazione enterprise in Ajax (tramite jQuery) e in formato JSON. Ci sono volute circa 2 settimane per farlo. In realtà ringrazio Microsoft per averlo integrato perché senza di esso avrei dovuto scrivere un po 'di codice extra.