¿Por qué Internet no cambia a JSON en lugar de HTML?

La dificultad de cambiar los formatos de comunicación estándar es que deben ser compatibles con versiones anteriores.

HTML5 fue solo una evolución. CSS3 fue una evolución. Los navegadores más antiguos no admiten los cambios, pero aún pueden mostrar algo similar a la imagen deseada.

No hay término medio entre json y html. Podría suceder que los servidores proporcionen múltiples formatos de archivo, lo que permite que los navegadores más nuevos soliciten el formato json. Pero esto es mucho trabajo.

Los estándares necesitarían estar escritos. Deberían pensarse los métodos para manejar cosas que no se ajustan a json. Crear un nuevo estándar para reemplazar html en el que todos los principales navegadores estarían de acuerdo tomaría años.

Si se decidiera crear algo nuevo, dudo que los navegadores se apeguen al mismo concepto de enviar marcado y luego renderizar. Tal vez se desearía un concepto de aplicaciones de transmisión alojadas. Creo que a muchos les gustaría poder enviar un archivo compilado al cliente.

Un gran cambio requiere un acuerdo masivo. Invita a cambios más grandes. En otras palabras, pequeños cambios en el status quo son la mejor manera de evolucionar la web.

Pregunta interesante, pero no estoy seguro de que esto pueda funcionar. HTML es un lenguaje de marcado que se utiliza para representar prácticamente todo el contenido que puede ver en un navegador. JSON es una forma de almacenar información en forma de objeto. Ambas son cosas completamente diferentes y son compatibles entre sí a través de JavaScript.

Supongo que podría recrear HTML en formato JSON, lo que proporcionaría mucha más estructura. Pero, sería mucho más difícil de leer. Todos los principales navegadores tendrían que reescribirse no solo para admitir esto, sino también para admitir HTML antiguo. Todo tiene que ser compatible con versiones anteriores, porque no todas las personas cambiarían a este nuevo sistema JSON. Esto llevaría a que la mitad de la web conozca un idioma y la otra mitad sepa otro. Las cosas no terminarían bien.

Microsoft intentó hacer algo como esto antes agregando algunas etiquetas adicionales a su versión de HTML para Internet Explorer. No terminó bien.

Principalmente razones históricas.

A diferencia de muchas otras estructuras de datos, el formato HTML relacionado con XML es en realidad más fácil, tiene una estructura de datos algo arbitraria que contiene atributos de estilo (clase CSS, la etiqueta en sí), texto, atributos de datos y posiblemente elementos en línea de otros idiomas en un de manera razonablemente legible y resistente a errores. Incluso ocupa menos espacio que la misma estructura en alguna posible representación de Json.

El HTML basado en XML es más fácil de hacer resistente a los errores, especialmente cuando se trata de no cerrar etiquetas.

Bla bla

Un párrafo …
… Que olvidé cerrar

El navegador cierra la etiqueta

un poco más tarde de lo que pretendía el webmaster, pero la cierra porque puede emparejar

y

fácilmente.

[
{
“tag”: “div”,
“contenido”: [
{
“etiqueta”: “p”
“contenido”: [
{
“etiqueta”: nulo,
“content”: “Un praragraph …”
]
},
{
“etiqueta”: nulo,
“content”: “… Olvidé cerrar el párrafo anterior y Json no me salvará, esta \” página \ “no funcionará en absoluto”
}
]
},
{
“tag”: “script”,
“type”: “text / javascript”,
“content”: “alert (\” Hello \ “); \ nconsole.log (\” Oh Dios, ¿por qué me hiciste escapar de todas las citas? \ “);”
}
]

Están diseñados para diferentes propósitos. JSON es una estructura de datos orientada a objetos, y HTML es un lenguaje de documentos jerárquico. JSON no reemplaza HTML …

Como se veria eso? ¿Cómo se vería un documento en JSON? Responda eso completamente y creo que entenderá por qué JSON realmente no puede reemplazar HTML.

Probablemente podría diseñar algún tipo de marco para mostrar documentos codificados en objetos JSON, y probablemente ya esté hecho, pero eso sería como clavar clavos con un zapato. Funciona, pero no es la mejor herramienta para el trabajo. Entonces, es menos un caso de “no puedo” y más un caso de “no debería”

De hecho, me gusta mucho esta idea, y muchas de las respuestas que dicen “son completamente diferentes” son, creo, malinterpretan el espíritu de la pregunta.

HTML es un especialista de XML, y ese XML y JSON tienen mucho en común. No hay razón para que no haya una especificación HTJSON. Probablemente sería mucho mejor en términos de mantener el aspecto “descriptivo” de los documentos HT separados del aspecto de “estilo”, y los codificadores se verían obligados a aprender sobre cómo debe estructurarse un documento antes de comenzar a juntar un documento. La respuesta que hace referencia a esto:

Bla bla

Un párrafo …
… Que olvidé cerrar

El equivalente JSON no tiene que ser tan detallado. Algo como esto probablemente estaría más cerca de lo que requeriría la especificación:

{
“class”: “lookNicePlease”,
“contenido”:[
“bla, bla”,
“Un párrafo … que olvidé cerrar
]
}

Se podría hacer que los navegadores manejen errores similares a la forma en que manejan los errores con HTML, y JSON evita la necesidad de etiquetas como “p” o “div” por completo.

CSS dictaría cómo se muestran los elementos, y la especificación definiría los estilos de clase predeterminados para que una {“clase”: “h1”, “contenido”: “Algunos encabezados”} se muestre como un HTML H1 – pantalla: bloque, ancho : 100%, alineación de texto: centro, etc.

Tendría que pensar en cómo lidiar con los objetos en línea (como HTML tiene etiquetas en línea), pero creo que básicamente estafando HTML a este respecto estaría bien:

{“content”: “este es un párrafo, y esto es un {” url “:” somesite.com “,” text “:” link “} en un párrafo”}

Porque no son tecnologías competitivas. HTML especifica documentos web, JSON especifica objetos de datos.