2012-04-13 8 views
11

Considerati gli enormi sforzi per rendere il web il più efficiente possibile, perché l'HTML (e tutti i vari altri file di testo in chiaro, ad esempio CSS, JavaScript) possono essere compilati in un'unica risorsa e inviati al di sotto del filo? (Sono a conoscenza di .chm files - queste sono le linee di questo concetto).Filosoficamente, perché i markup non possono essere dati binari? Ad esempio, perché non possiamo compilare HTML per il web?

Capisco la natura aperta del web - uno sforzo che sto dietro - ma si potrebbe concepire una specifica aperta che richiede che più risorse vengano compilate in binario. La complicazione da parte dell'utente-agente potrebbe essere richiesta dalle specifiche (questo permette alle persone di visualizzare il DOM ecc.)

Immagino di essere solo sorpreso, visto l'impegno nelle prestazioni in altre aree, stiamo ancora facendo affidamento su testo normale per spingere le pagine o sto solo sovrastimando i risparmi forniti da un formato binario?

+0

Non avere una risposta, ma +1 per una domanda davvero fantastica! –

+0

Immagino sia solo l'eredità di come il web si è sviluppato. Ma il tuo suggerimento è sicuramente interessante. – Ayusman

+0

la seconda lettera nella sigla significa testo quindi, a meno che non si ottenga hbml, sarà test, solo dicendo. – johnshen64

risposta

4

Un fattore importante per lo sviluppo del Web è stata l'estensibilità dei linguaggi web. I fornitori di browser possono supportare più funzionalità di quelle richieste dagli standard. Anche se questo è sempre stato un problema per gli sviluppatori, è ha ha aiutato il web in avanti.

Compilando le pagine Web si limitano le funzionalità al set supportato dal compilatore. Non sarebbe possibile utilizzare alcuna nuova funzionalità in alcun browser finché il compilatore non raggiungerà lo sviluppo. Ciò rallenterebbe lo sviluppo del web.

+0

Ottimo da leggere su cose che non avevo nemmeno preso in considerazione. In questo caso non c'è nulla che impedisca al compilatore di un browser di supportare qualsiasi funzionalità voluta, propiziatoria o meno. Non vedo come questo sarebbe fondamentalmente diverso da ciò che abbiamo ora. – Matt

+0

@Matt: dovresti utilizzare un singolo compilatore standard perché il concetto funzioni. Se ciascun fornitore di browser avesse il proprio compilatore, sarebbe necessario compilare il sito per tutti i diversi browser esistenti. Sarebbe molto peggio delle guerre dei browser, sarebbe stato il buio dei browser ... – Guffa

1

Spesso web "testo" Attività (HTML, CSS, JavaScript, XML, JSON) sono "binario", dal momento che sono serviti GZIPped: http://duckduckgo.com/?q=gzip+files+server difficile da ottenere più ottimizzato rispetto a quello; in grado di essere letto da un umano, mentre molto compresso.

+0

È giusto dire una rappresentazione binaria del DOM rispetto a una rappresentazione serializzata e compressa del DOM (che è ciò che HTML potrebbe essere considerato, suppongo) sono di dimensioni comparabili, tanto quanto non fa differenza? – Matt

+1

@Matt Forse una versione compilata di codice HTML di "bytecode" potrebbe essere analizzata leggermente più velocemente di un testo HTML, e forse un po 'più piccolo dei file GZIP. Può valere la pena vedere se i principali giocatori esamineranno questo. – tomByrer

+1

*** Tuttavia **, i principali attori (MicroSoft/IE, Webkit/Apple/Google, Firefox) hanno _alot_ sul loro piatto; SPDY/HTTP2, martellando e implementando HTML5, CSS3, una singola piattaforma per audio/video web (non è ancora una soluzione unica), ora dinamica che serve la corretta risoluzione dell'immagine ai dispositivi di destinazione (smartphone vs desktop vs HD iPad3 hanno tutti bisogno di immagini di dimensioni diverse , e le immagini mangiano un sacco di larghezza di banda/memoria), gli sviluppatori web hanno MOLTO nei loro piatti ora. – tomByrer

0

Ci sono stati tentativi in ​​questo senso - vedere WBXML. Tuttavia, il problema si presenta quando qualcuno cerca di estendere la definizione XML - un ID 35 corrisponde all'estensione microsoft < foo> o alla barra netscape <>?

È anche molto più difficile leggere il file binario quando stai cercando di capire quale bit HTML hai sbagliato.

Il problema principale della dimensione dei dati è stato risolto da gziping dei dati prima che lasci il server web.

Problemi correlati