2012-04-13 5 views
11

Teniendo en cuenta los enormes esfuerzos para hacer que la web sea lo más eficiente posible, ¿por qué no se puede compilar HTML (y todos los demás archivos de texto sin formato, por ejemplo, CSS, JavaScript) en un solo recurso y enviarlo por cable? (Estoy al tanto de .chm files - estas son las líneas de este concepto).Filosóficamente, ¿por qué los márgenes no pueden ser datos binarios? es decir, ¿por qué no podemos compilar HTML para la web?

Entiendo la naturaleza abierta de la web, un esfuerzo que defiendo, pero se podría concebir una especificación abierta que requiera la compilación de múltiples recursos en formato binario. La especificación podría requerir la simplificación por parte del usuario-agente (esto permite que los usuarios vean el DOM, etc.)

Supongo que estoy sorprendido, dados los esfuerzos de rendimiento en otras áreas, todavía confiamos en texto simple para pasar páginas, ¿o estoy sobreestimando los ahorros que un formato binario proporcionaría?

+0

¡No tengo una respuesta, pero +1 para una pregunta realmente genial! –

+0

Supongo que es solo el legado de cómo se desarrolló la web. Pero tu sugerencia es ciertamente interesante. – Ayusman

+0

la segunda letra de la abreviatura significa texto, así que, a menos que obtengamos hbml, se pondrá a prueba, simplemente diciendo. – johnshen64

Respuesta

4

Un factor importante para el desarrollo de la web ha sido la extensibilidad de los lenguajes web. Los proveedores de navegadores pueden admitir más funcionalidades de las requeridas por los estándares. Aunque esto siempre ha sido una molestia para los desarrolladores, tiene ayudó a la web a avanzar.

Al compilar las páginas web, limitaría las capacidades al conjunto que admite el compilador. No sería posible usar ninguna característica nueva en ningún navegador hasta que el compilador se ponga al día con el desarrollo. Esto ralentizaría el desarrollo de la web.

+0

Genial para leer sobre cosas que ni siquiera había considerado. En este caso, no hay nada que impida que el compilador de un proveedor de navegador admita la funcionalidad que desee, propiciatoria o no. No veo cómo esto sería fundamentalmente diferente de lo que tenemos ahora. – Matt

+0

@Matt: Tendría que usar un único compilador estándar para que el concepto funcione. Si cada proveedor de navegador tuviera su propio compilador, entonces tendría que compilar el sitio para todos los navegadores diferentes que existen. Eso sería mucho peor que las guerras de los navegadores, serían las edades oscuras de los navegadores ... – Guffa

1

menudo web de "texto" activos (HTML, CSS, JavaScript, XML, JSON) son "binario", ya que se sirven gzipped: http://duckduckgo.com/?q=gzip+files+server difícil conseguir más optimizado que eso; capaz de ser leído por un humano, mientras está muy comprimido.

+0

¿Es justo decir una representación binaria del DOM frente a una representación comprimida y serializada del DOM (que es lo que HTML podría considerarse, supongo) son de tamaño comparable, tanto como no hace ninguna diferencia? – Matt

+1

@Matt Tal vez una versión compilada de "código de bytes" de HTML, etc. podría analizarse un poco más rápido que un HTML de texto, y tal vez un poco más pequeño que los archivos GZIPped. Puede valer la pena ver si los principales jugadores investigarían esto. – tomByrer

+1

*** Sin embargo **, los jugadores principales (MicroSoft/IE, Webkit/Apple/Google, Firefox) tienen _alot_ en su plato; SPDY/HTTP2, perfeccionando e implementando HTML5, CSS3, una plataforma única para audio/video web (todavía no es una solución única), ahora dinámico que brinda la resolución de imagen adecuada para los dispositivos de destino (teléfonos inteligentes vs escritorio vs HD iPad3 todos necesitan imágenes de diferentes tamaños , y las imágenes consumen mucho ancho de banda/memoria), los desarrolladores web tienen MUCHO en sus placas ahora. – tomByrer

0

Ha habido intentos de esto - vea WBXML. Sin embargo, el problema surge cuando alguien intenta extender la definición de XML: ¿una identificación de 35 corresponde a la extensión de Microsoft < foo>, o la barra de Netscape <?

También es mucho más difícil de leer el binario cuando intenta averiguar qué parte del HTML se equivocó.

El problema principal del tamaño de los datos se solucionó al actualizar los datos antes de que abandonen el servidor web.

Cuestiones relacionadas