Perché tutti scelgono JSON Over XML per jQuery?

Pensavo che XML fosse altamente portatile e potesse essere usato come mini database. Ho visto l’XML usato ovunque. Vedo persino le 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 object, record, struct, dizionario, tabella hash, elenco con chiave o array associativo.
  • Un elenco ordinato di valori. Nella maggior parte delle lingue, questo è realizzato come una matrice, vettore, lista o sequenza.

XML non inizia a brillare fino a quando non inizi a mischiare schemi diversi con nomi diversi. Poi 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 è che non devo decidere come formattare i dati. Come alcuni hanno mostrato, ci sono molti modi per fare anche semplici strutture dati in XML – come elementi, come valori di attributi, ecc. Quindi devi documentarlo, scrivere XML Schema o Relax NG o qualche altra schifezza … È un casino.

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 mancata corrispondenza dell’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, vorrei creare un dizionario come segue:

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 viene tradotto tramite JSON (usando una libreria come “simplejson” per Python), la struttura JSON risultante sembra quasi identica (eccetto in JSON, i booleani sono di tipo lower-case).

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

Se scrivessi XML, dovrei decidere se fare elementi o attributi. Entrambe le seguenti sono valide:

  5 8.5 yes deep and steep!   deep and steep!  

Quindi non solo devo pensare ai dati che potrei voler inviare al cliente, devo pensare a come formattarlo. XML, pur essendo più semplice del semplice SGML essendo più severo con le sue regole, offre ancora troppi modi per pensare a quei dati. Quindi dovrei andare a generarlo. Non potevo semplicemente prendere un dizionario Python (o un’altra semplice struttura dati) e dire “vai a farti nel mio XML”. Non ho potuto ricevere un documento XML e dire subito “vai a trasformarti in oggetti e strutture dati” senza scrivere un parser personalizzato, o senza richiedere il sovraccarico aggiuntivo di XML Schema / Relax NG e altri problemi simili.

In poche parole, è molto più semplice e molto più diretto codificare e decodificare i dati su JSON, soprattutto per gli scambi rapidi. Questo potrebbe applicarsi di più alle persone che provengono da uno sfondo di lingua dynamic, poiché i tipi di dati di base (elenchi, dizionari, ecc.) Incorporati in JavaScript / JSON mappano direttamente allo stesso tipo o tipi di dati simili 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 a nido profondo … ti imbatterai in]]]}], il che rende difficile il debug

È leggero rispetto all’XML. Se hai bisogno di ridimensionare, riduci 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:

    red #f00   green #0f0   blue #00f   cyan #0ff   magenta #f0f   yellow #ff0   black #000   

Solo un aneddoto della mia esperienza personale:

Ho scritto una piccola directory Javascript, prima con i dati in XML, e poi l’ho adattata 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 rispetto a 1200-1300 ms per visualizzare tutti i dati). Inoltre, come altri hanno notato, il JSON è molto più facile per gli occhi e le dimensioni del file sono ridotte del 25% a causa del markup più snello.

           

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

Il semplice consumo di JavaScript può essere uno dei motivi.

JSON è il migliore per il consumo di dati nelle applicazioni Web da servizi Web per le sue dimensioni e facilità d’uso, soprattutto grazie al supporto integrato in JavaScript . Immagina il sovraccarico del calcolo per analizzare un frammento xml rispetto alla ricerca istantanea in JSON.

Un ottimo esempio è JSON-P. Puoi recuperare i dati da un servizio my_callback({"color": "blue", "shape":"square"}); in una chiamata di funzione callback, come my_callback({"color": "blue", "shape":"square"}); all’interno di un tag generato dynamicmente in modo che i dati possano essere direttamente utilizzati nella funzione my_callback() . Non c'è modo di avvicinarsi a questa comodità usando XML.

XML sarebbe il formato di scelta per i documenti di grandi dimensioni, in cui è disponibile una struttura di rendering delle 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 dell’XML: le regole di convalida (DTD, XSD). Le mie conclusioni, avendo usato entrambi:

  • JSON è perfetto per ajax, specialmente se sviluppi te stesso lato server e client. Fondamentalmente crei oggetti js direttamente nello script del tuo server!
  • L’XML risplende negli ambienti aziendali, quando devi impostare standard di scambio dati tra le grandi organizzazioni burocratiche. Spesso, una parte sviluppa la sua parte alcuni mesi prima di un’altra, quindi beneficia realmente della convalida delle sue richieste rispetto all’XSD concordato. Inoltre, nelle grandi aziende, il trasferimento dei dati è spesso tradotto tra diversi sistemi. Questo è anche il punto di forza di XML, pensa XSLT. Esempio: conversione senza codice in JSON: p

Naturalmente, lo schema di JSON è in fase di sviluppo, ma non troverete alcun supporto integrato per questo.

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

Ora che ci sono codificatori e decodificatori JSON per la maggior parte dei linguaggi, non c’è ragione di NON usare JSON per gli usi in cui ha senso (e questo è probabilmente il 90% dei casi d’uso per XML).

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

Abbastanza onestamente, non c’è tanto differenza tra JSON e XML nel fatto che possano rappresentare tutti i tipi di dati. Tuttavia, XML è sintatticamente più grande di JSON e questo lo rende più pesante di JSON.

JSON non ha mancata corrispondenza dell’impedenza con la programmazione JavaScript. JSON può contenere numeri interi, stringhe, liste, matrici. XML è solo elementi e nodes che devono essere analizzati in interi e così via prima che possa essere consumato.

Entrambi sono grandi e molto portabili. 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 syntax dell’object JavaScript può essere direttamente tradotto in un object in memoria che rende Ajax molto più facile strumento.

XML è ancora grande. JSON è solo “l’ultimo e il più grande” rispetto all’XML.

Facilmente analizzato 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 è ansible eseguire l’eval (aJsonString) direttamente in un object JavaScript. All’interno di un browser è un gioco da ragazzi JSON è perfettamente adatto per JavaScript. Allo stesso tempo, JavaScript è un linguaggio dinamico molto liberamente tipizzato e non può sfruttare in modo nativo tutte le informazioni di tipo specifico disponibili contenute in un documento Xml / Xsd. Questo extra metadata (che è ottimo per l’interoperabilità) è un ostacolo in JavaScript che lo rende più noioso e laborioso con cui lavorare.

Dimensioni vs prestazioni

Se sei in un browser, JSON è più veloce da serializzare / deserializzare in quanto è più semplice, più compatto e più importante supportato in modo nativo. Ho alcuni benchmark del database nordovale disponibili confrontando le dimensioni e la velocità tra i diversi serializzatori disponibili. Nella libreria di classi base Il serializzatore XML DataContract di Microsoft è più veloce del 30% rispetto a quello JSON. Anche se questo ha più a che fare con lo sforzo che Microsoft ha messo nel loro serializzatore XML perché 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 abbia all’incirca più di due volte la dimensione di JSON. Tuttavia questo può esplodere rapidamente se il payload XML utilizza molti namespace diversi all’interno dello stesso documento.

XML è un olio di serpente gonfio nella maggior parte delle situazioni. JSON ti dà la maggior parte dei benefici senza il gonfio.

Uno dei principali vantaggi oltre a quelli menzionati qui. Per gli stessi dati, ci sono molti modi per rappresentarlo come un file XML, ma solo in un modo con JSON, rimuove l’ambiguità 🙂

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

Quando si dispone di grandi quantità di dati, in genere, si desidera segnalare tali dati. E XML non è una grande fonte per la segnalazione. Nel grande schema delle cose, sembra che un database transazionale sia più facile da segnalare / cercare rispetto all’XML.

Ha senso ciò? Come ho detto sopra, non sono esperto ma dalla mia esperienza sembra essere il caso. Inoltre, credo che Microsoft supporti JSON integrato a causa dell’ondata di sviluppatori che si spostano verso azioni client o script per migliorare la grafica dell’interfaccia utente ( Ajax ) e l’Ajax di Microsoft non è stato usato tanto quanto altre librerie come jQuery e MooTools ( Yahoo YUI è anche in questo mix) grazie alla loro bella integrazione di oggetti serializzabili usando JSON.

Mi trovo a scrivere codice ora implementando il serializzatore JSON nel mio codice VB. È troppo facile e da un punto di vista di aggiornamento / modifica, non puoi batterlo. È il modo in cui Microsoft ci tiene dipendenti da VS, immagino. Ho recentemente convertito un’applicazione enterprise in Ajax (tramite jQuery) e in formato JSON. Ci sono voluti circa 2 settimane per farlo. In realtà ringrazio Microsoft per averlo integrato perché senza di esso, avrei dovuto scrivere un bel po ‘di codice in più.