En el futuro previsible: muy probablemente nada .

Todos los lenguajes de programación son intercambiables: probablemente ya haya visto una docena de hilos “¿Debo usar C, C ++, C #, Java, Python, Javascript, Ruby o todo al mismo tiempo?” De hecho, cualquier lenguaje que tenga los conceptos básicos de enunciados condicionales, bucles, funciones puede usarse para reemplazar a otro y servir las mismas características.

Sin embargo, HTML no es un lenguaje de programación: es un lenguaje de marcado. No calcula nada, pero identifica objetos. Cada navegador web está diseñado en su idioma nativo (a menudo C / C ++) para que cuando vea una etiqueta, muestre el objeto apropiado.

Se necesitaría un enfoque completamente nuevo para el formato de contenido para reemplazar HTML. Incluso con eso, el proceso sería dolorosamente largo, ya que todos los editores del navegador web tendrían que volver a codificar todo su motor, sin dejar de ser compatibles con las páginas HTML (como la transición IPV4-IPV6).

Solo comentaré sobre HTML.

Eso no es para minimizar el CSS. Como diseñador, he pasado más de una docena de años en CSS y todavía estoy aprendiendo regularmente nuevas combinaciones y soluciones para ello.

¿Qué es reemplazar HTML?

En 1990, tuve el privilegio de hacer un trabajo independiente para una compañía de Toronto llamada SoftQuad. Desarrollaban software, y codificaban documentos, usando SGML (lenguaje de marcado generalizado estándar).

Gracias a Tim Berners-Lee, HTML suplantó a SGML debido a esta ingeniosa cosa llamada World-Wide Web, pero el concepto era idéntico: un lenguaje de marcado para proporcionar contenido con significado semántico mediante el uso de etiquetas.

El etiquetado proporcionó una capa de abstracción necesaria y legible para el ser humano que permitió que el contenido se reutilizara o adaptara fácilmente a diferentes circunstancias, como el diseño, la visualización interactiva o, como en el caso de SGML, diferentes niveles de clasificación para la subdocumentación nuclear que está proporcionando a tu propia armada frente al mismo modelo que has vendido a un aliado a veces. La reutilización segura supera la reescritura y la edición manual de decenas de miles de páginas.

Después de más de 20 años de WWW, y HTML sigue siendo el rey.

De hecho, HTML5 permite que las etiquetas personalizadas se creen libremente según sea necesario, por lo que lo que conocemos como “HTML” en realidad es solo un conjunto de etiquetas base acordado que puede expandirse según sea necesario.

Por lo tanto, cualquier sucesor directo de HTML probablemente sería una implementación más elaborada, similar a cómo Unicode suplantó a ASCII.

Si algo reemplaza realmente a HTML, imagino que es AI lo suficientemente inteligente como para procesar semánticamente texto y contenido visual de manera confiable y precisa, lo que haría que la codificación, al menos del tipo que los humanos necesitarían ver, sea discutible.

Sin embargo, a juzgar por algunos experimentos recientes fallidos de “bot”, todavía está muy lejos.

Es una buena pregunta Creo que el HTML está aquí para quedarse por bastante tiempo; Necesitamos un marco general para definir diseños, etc. HTML hace esto realmente bien (cuando no le agregas toneladas de cosas del día).

CSS es, por supuesto, un elemento básico, pero de alguna manera, en mi humilde opinión, está fuera de control. ¿Alguna vez has visto algunos de estos nuevos archivos comprimidos / generados CSS? Incomprensible gobbledygook. CSS se ha convertido en un área de programación en sí misma, cuando todo lo que fue diseñado para hacer fue aplicar estilos a elementos HTML.

Realmente tampoco veo nada reemplazando ya que son estándares web profundamente arraigados. Cualquier cosa nueva que surja tendría que ser respaldada por los consorcios del navegador y cualquier otra cosa, y todos sabemos cómo funciona.

De hecho, no lo reemplace con nada. No puedo vivir eso otra vez.

Iré contra la corriente aquí aunque los otros respondedores probablemente estén en lo correcto. Y admito que mi respuesta es más una ilusión que un análisis basado en evidencia. Creo que algo que permita un estilo más imperativo, algo menos propenso a decir: “Sé que querías esto, aunque dijiste que querías eso”, algún día gobernará el mundo web. Ya sea que se trate de un motor de renderizado famoso como “todo debe inclinarse ante mí” o un D3 amplificado o una mezcla de componentes directamente dibujados en la pantalla, solo tiene que suceder alejarse del “flujo de página”. ¡Solo di no a las correcciones y puertas correderas!

Ninguna cantidad de genialidad como stylus y postcss hará que CSS sea cuerdo algún día. En todo caso, estas herramientas están permitiendo que CSS se salga con la suya con más y más ridiculez. Esas herramientas son increíblemente impresionantes, pero no en un sentido independiente de la palabra; solo son “impresionantes” porque hacen que CSS sea apenas soportable. Es el equivalente a decir que la quimioterapia y el tratamiento con radiación son increíbles. O tal vez los medicamentos contra la depresión son una analogía más precisa, dependiendo de quién creas que está matando. (¿Puedes decir que estoy en medio de otra batalla a muerte con mi último proyecto HTML / CSS?)

Por lo tanto, mi conjetura / esperanza, una vez más, completamente desprovisto de evidencia, así que por favor no explique al respecto, es algún tipo de motor de renderizado imperativo basado en componentes y basado en datos que no tiene una extensión .css o .html en visión. Si aprovecha las GPU integradas, mucho mejor. Y terapia gratuita con cada despliegue, definitivamente una necesidad.

[ACTUALIZACIÓN: dado un comentario que hizo una pregunta que debería haber abordado originalmente]

Mi mayor queja es sobre el diseño. Hay probabilidades y finales que son extravagantes, pero el diseño (posicionamiento y tamaño) es increíblemente frustrante. He usado menos, sass y stylus. En ese orden, todas son mejoras para tratar con CSS, pero al final del día / paso de compilación, aún generan CSS. El diseño es realmente un problema de navegador y HTML, pero se controla (mal, en mi humilde opinión) a través de CSS. Estoy empezando a jugar con Lost Grid, que parece muy prometedor. Pero siempre que finalmente se convierta a CSS, no importa qué tan bien lo oculte una herramienta, sigue siendo solo lápiz labial en un cerdo. El diseño imperativo a través de cualquier tecnología que pueda hacerlo y CSS para colores, fuentes, etc. sería perfecto.

Automatización de diseño y estilo

Al usar HTML y CSS, el desarrollador web debe controlar el diseño y el estilo en detalle. Tratemos de automatizar el diseño y el estilo. El navegador, no el desarrollador web, determinará todos los aspectos de diseño y estilo. El desarrollador web escribe código XML que define los elementos de contenido y las relaciones lógicas entre estos elementos. Usando un algoritmo avanzado, el navegador debe ser capaz de presentar un diseño y estilo razonables.

Automatización del diseño web receptivo

Ahora que el navegador automatiza el diseño, también automatiza el diseño web receptivo. Usando el nuevo idioma, el desarrollador escribe el código de la página web sin tener en cuenta el dispositivo del usuario, que puede ser un teléfono inteligente, una tableta, una computadora de escritorio o incluso un televisor. El navegador conoce las dimensiones de su ventana gráfica y presenta un diseño adecuado en el dispositivo del usuario.

Un idioma en lugar de tres

El desarrollo web es más simple utilizando un lenguaje único, unificado y basado en XML en lugar de múltiples idiomas como HTML / CSS / JS. Como el estilo y el diseño ahora son automáticos, no es necesario usar CSS con el nuevo lenguaje. También nos gustaría eliminar la necesidad de usar JavaScript. Un lenguaje de programación de procedimientos como JavaScript es demasiado complejo para los usuarios no técnicos. Las funciones más importantes de JavaScript, incluido AJAX, pueden ser compatibles con elementos XML en el nuevo lenguaje.

Adiós a la barra de desplazamiento

Los navegadores muestran el contenido HTML hacia abajo en la ventana gráfica, lo que permite al usuario desplazarse hacia abajo para ver más contenido. El desplazamiento no es realmente la experiencia óptima del usuario. Con el nuevo idioma, si el contenido de una página no cabe en la ventana gráfica, el navegador divide el contenido en varias pantallas. En lugar de desplazarse, el usuario cambia entre pantallas consecutivas.

Relacionado: agencia de diseño web de Bangalore

Con el debido respeto a Garry Taylor, quien obviamente es un desarrollador experimentado y versado, rogaría que difiriera con un par de puntos.

1. No creo que HTML o CSS necesiten ser reemplazados, modificaciones, ciertamente, pero no reemplazos. Sería equivalente a tirar al bebé con el agua del baño, usar un cliché.
2. Tampoco creo que el reemplazo de la tecnología sea fácil (o incluso deseable).

Las razones de mi punto de vista son que cuanto más analizo las aplicaciones web receptivas, más se hace evidente que la columna vertebral, ya sea embellecida y simplificada por extensiones como JSX, todavía está compuesta por los dos componentes críticos de HTML y CSS.

Lo que parece importante y emocionante es que los desarrolladores están encontrando mejores y mejores formas de integrar y automatizar las fortalezas de HTML, CSS y quizás lo más importante, JavaScript. Con la maduración del estándar ECMAScript 6 que se implementa de manera más amplia y completa todos los días, surge una visión más integral que ve el sitio web de ayer como una aplicación web receptiva que difiere cada vez menos de las aplicaciones de escritorio.

Esto es evolución. Y no denuncia HTML o CSS. Los abraza y los aumenta. La automatización del estilo se puede encontrar en cosas como SASS. React.js lleva esto aún más lejos al ver todo el sitio web (o la aplicación, más apropiadamente) como una interfaz de usuario.

La advertencia, creo, se puede encontrar en la competencia entre los diferentes proveedores para demostrar que su plataforma debería reemplazar este o aquel estándar, como HTML5. El problema con este enfoque, en mi opinión, es que hay muchos estándares competitivos que luego hacen que la integración sea mucho más difícil para el desarrollador / diseñador.

En años pasados, tal competencia por la posición causó pesadillas para los desarrolladores entre las primeras versiones de JavaScript de Netscape y el JScript de Microsoft, esencialmente lo mismo, pero que difiere en varias formas muy molestas que hicieron una experiencia de desarrollo muy dolorosa.

En el ámbito del desarrollo, las innovaciones del hombre están en el horizonte. Yo diría que cuanto más cooperen entre sí y busquen la interoperabilidad, mejores serán las plataformas futuras.

Ciertamente, el factor de dolor del desarrollo se reduciría considerablemente.

Finalmente, y no puedo enfatizar demasiado este punto, cualquiera que tenga la intención seria de desarrollar, diseñar o hacer ambas cosas, debe comenzar con una comprensión firme tanto de HTML como de CSS. Agregue a esa lista una comprensión sólida de JavaScript vainilla (ya que esto informa el uso efectivo de innumerables bibliotecas y marcos excelentes), y emerge un enfoque vibrante y holístico para el desarrollo.

Así que no, no creo que HTML o CSS sean reemplazados pronto. Cada vez son más semánticos y definen claramente la estructura de las aplicaciones. Abandonarlos sería abandonar la nave de un marco probado y adaptable. Cuando Tim Berners-Lee desarrolló la primera versión de HTML, toda la filosofía detrás de ese desarrollo fue la cooperación, la interoperabilidad y la accesibilidad. Reemplazar cualquiera de estos idiomas sería un error, en mi opinión.

¿Lo harán? No

¿Deberían ellos? Por mí si.

Ya no hacen las cosas bien.

HTML define áreas de una página, como sección y al lado, y cosas como imagen de encabezado y párrafo. CSS proporciona una forma de diseñar la página que es un poco no intuitiva y un poco inconsistente en todos los navegadores.

JavaScript me parece un idioma Marmite: podría escribir una publicación sobre cómo no me gusta y ser absolutamente criticado por sus fanáticos de la legión.

Estas cosas muestran la historia del pensamiento detrás de ellos.

La web era texto académico con algunas imágenes de gráficos en 1993. A fines de los años 90, se volvió a aprender que Smalltalk tenía una buena idea y por qué no dividimos lo que mostramos de cómo lo mostramos. eso. CSS intervino, dijo que separaría la presentación del contenido, y espectacularmente no lo hizo de ninguna manera sensata.

Pero donde estamos hoy es que simplemente queremos características y rendimiento de la GUI de escritorio de la vieja escuela en nuestros teléfonos.

Ningún usuario se preocupa por cómo hacemos esto. Ninguna App Store anuncia “¡Ahora está hecho con una bondad HTML 100% pura!”

Me gustaría ver un kit de herramientas GUI decente que ejecute multiplataforma con un cliente HTTP.

Dios sabe cuántas veces se ha intentado esto.

Java tenía AWT, luego Swing (GUI multiplataforma, pero naff) y Applets (exactamente de lo que estoy hablando, pero nunca lo entendí).

Hubo el sistema operativo Symbian con sus herramientas de interfaz de usuario CONE y Eikon. Nunca se dio cuenta.

Windows CE, conocido cariñosamente como ‘wince’. No Ha fallado.

WAP vino y se fue. Windows Mobile Meebo Destello. XAML. XUL.

Absolutamente toneladas de intentos, todos fracasaron.

Y, sin embargo, lo único que hace que nuestras GUI web modernas sean HTML, CSS malhumorados y un montón de marcos JavaScript alternativos que básicamente eliminan todo el HTML de la página y luego lo reemplazan.

Tiene que ser la forma menos eficiente y menos lógica de poner una GUI en un teléfono.

Entonces, ¿cambiarán las cosas? Lo dudo. Pero podrían hacerlo.

Y podría ser simple, ya que las versiones futuras de HTML / CSS / JS simplemente vuelven a identificar las tecnologías GUI existentes, por lo que “HTML 6” podría en esencia simplemente especificar una API estándar para los controles subyacentes del sistema operativo.

Eso estaría bien.

La semántica de HTML y CSS no se reemplazará pronto. Pero hay muchos

herramientas para convertir la sintaxis horrible y detallada de html

en algo bonito hermoso y composable.

Mi favorito es hipo como sintaxis del mundo ClojureScript.

Por ejemplo (de mi proyecto reciente, ahora abierto):

(defn barra de navegación
[q]
[: nav.navbar.navbar-default.navbar-fixed-top
{: style {: height “59px”}}
[: div.container
{: style {: padding-left “75px”}}
[: form.navbar-form
{: style {: border-radius “0px”
: relleno-izquierda “30px”
: relleno-derecho “0px”}
: onSubmit # (do (.preventDefault%) (estado / q-changed! q))}
[: div.input-group
{: estilo {: ancho “80%”
: radio de borde “0px”}}
[: input.form-control
{: marcador de posición “”
: valor q
: on-change # (state / q-changed! (utils / value-of-react%))
: estilo (fusionar {: altura “40px”
: radio de borde “0px”}
(ui-utils / perfect-input-inset))}]
[: span.input-group-addon
{: style {: width “20px”: border-radius “0px”}}
“@”]]]]])

Sal de la caja:

1. Fácil navegación (A través del crédito)
2. Compacidad (mucho más compacta que el html estándar)
3. Homoiconicidad (eso significa que su código html / css también es un programa LISP válido, yay)
4. Puede componer su diseño como si estuviera escribiendo un programa.

1. Puedes dividirlo en espacios de nombres
2. Use map / filter / reduce al componer sus datos con html
3. Puede crear bibliotecas de los css / html más utilizados y componerlas en un nuevo proyecto en cuestión de minutos.

Algunas buenas herramientas para trabajar con hipo:

1. Convertidores HTML a hipo
2. Paredit
3. Bueno, hipo

Todo lo que ves en Internet en formato legible para humanos tiene un formato de archivo que la máquina entiende. Cuando el formato del archivo cambia, los mismos datos pueden tener un significado diferente para la PC a medida que cambia el cifrado.

En Internet, el 90% de los datos que se muestran están en formato HTML. Recuerde que HTML no es solo un lenguaje sino también un formato de archivo. Por lo tanto, incluso si no utiliza HTML como tal, sino otros lenguajes como JAVA o Python, finalmente lo entregará a su cliente como una página HTML. Incluso el archivo .PHP está precompilado en el servidor y entrega doms html al usuario. Puede cambiar doms y datos html utilizando Javascript / Ecmascript u otros marcos JS del lado del cliente, pero recuerde que todo lo que entregará es un formato de archivo HTML.

Puede entregar el archivo .pdf a los usuarios directamente sobre la marcha utilizando PHP o Python o cualquier idioma que desee. Incluso las bibliotecas JS para producir .pdf están disponibles. Entonces, y solo entonces, usará algo que no sea HTML y CSS. Muchos servidores entregan datos directamente a través de sus apis en formato .JSON. Ciertos servidores como AppYet – App Creator crean y entregan directamente archivos .apk a través de su servidor.

Por lo tanto, hasta que alguien lea directamente un archivo FLASH en su lector de libros electrónicos o libro epub a través de su aplicación conectada a su servidor, debe entregar las cosas en la plataforma web internacional, es decir, HTML / CSS.

Cualquier cosa que pueda y reemplace a otra, debería tener más ventaja o disponibilidad que lo existente y no veo nada más que HTML / CSS que sobreviva aquí.

Además, en otras palabras, puede decir que el software del cliente decide qué debe entregar el servidor. Si su ebookreader-> servidor entrega flash / epub; si su servidor de radio por Internet -> entrega audio mp3; si su flujo de red VLC -> el servidor entrega archivos vedio / audio. La mayoría de las personas usan navegadores de Internet como Chrome que entiende

¿La cosa más probable para tener éxito? Una palabra de moda.

Al final, alguien se dará cuenta de que las API de datos son útiles y simples, y que es mejor mantener las IU nativas que los agujeros de seguridad de la web.

Obtendrá un nombre que se convertirá en una palabra de moda, descrita en un libro que sus autores defienden como la razón por la cual alguna metodología popular salva al mundo. XP, Agile, algo así, pero con una filosofía genérica de abstracción de datos de back-end y una documentación de técnicas nativas de API que son comparables, con la conciencia de que nunca se puede escribir una vez y ejecutar en todas partes sin al menos una vez chupando en todas partes.

HTML, JavaScript y CSS persistirán durante mucho tiempo, pero eventualmente serán menospreciados como de calidad inferior.

A lo largo de los años, algunas opciones han intentado responder a esto.

En la historia, una idea de “realidad virtual” intentó crear un marcado para navegar por la web en realidad virtual. Esto se cayó debido a que es engorroso y de bajo interés.

Sin embargo, la tecnología de pantalla táctil también se probó varias veces en el pasado y falló por varias razones, incluido el bajo interés del mercado.

Con el reciente surgimiento de la próxima generación de realidad virtual, y que parece ser significativamente más popular que la versión anterior, hay muchas posibilidades de que alguien decida que es hora de abordar la experiencia web virtual una vez más.

Dicho esto, no creo que VWE reemplace html o páginas web típicas, al menos no en los próximos años. Como bueno o malo, html, css y javascript están aquí para quedarse al menos por un tiempo.

Lo más probable es que nada. No solo porque HTML y CSS están profundamente arraigados en toda la web, sino también por DOM ( Modelo de Objeto de Documento ). El lenguaje basado en etiquetas, como HTML, es la mejor manera de representar DOM, y CSS es la mejor forma de representar la estilización de las estructuras DOM.

Los preprocesadores ya están haciendo un trabajo increíble al abstraer no solo HTML y CSS, sino también JavaScript, así que no, no creo que algo reemplace HTML y CSS en el futuro.

Todas las respuestas son buenas. Nada y nada, puedes soñar lo que quieras.
Se necesitan al menos 20 años para cambiar la tecnología y es bastante difícil.

Me desarrollo durante el tiempo de IE6 y no puedo decir que IE6 todavía existe, XP todavía existe.

Dígame cómo le ha dicho a todas las empresas del mundo que utilicen un nuevo navegador, que vuelvan a desarrollar todo su marco personalizado, cómo cambiar las tecnologías cuando pasaron años y años desarrollando esta tecnología.

Google intenta cambiar javascript a Dart, pero al final. No es lo suficientemente popular como para cambiar a dardo y al otro actor como Microsoft, Mozilla, Firefox.

Y para cambiar la tecnología, necesita el consorcio de los tres gigantes y especialmente Google. ¿Puedes demostrarles que HTML no es lo suficientemente bueno y pedirles que cambien su sistema de indexación … Buena suerte.

Olvidó tener en cuenta el SEO, las herramientas en torno a HTML. ¿Por qué tenemos lenguaje de procesador y no otro idioma que no sea HTML / CSS / Javascript? Lo que pueden hacer es mejorar el motor.

Pero nunca tengo algo mejor que HTML, CSS. Quizás Xcode y su plantilla IOS engin. Pero para la lectura humana en HTML, no hay nada más simple que eso.

Lo que es más probable que suceda es que HTML y CSS no desaparecerán, pero los navegadores web serán más indulgentes y cambiarán naturalmente.

Si mira HTML, puede salirse con la suya en un navegador moderno que al principio no podía. Un documento HTML hoy puede ignorar grandes cantidades de estructura HTML tradicional.

Como ejemplo, los navegadores aceptarán esto como un documento HTML:

Encabezado

Párrafo uno

Párrafo dos

Puede ignorar , , ; ni siquiera necesita una etiqueta en la parte superior. Érase una vez, esto no hubiera funcionado. Entonces, en cierto sentido, HTML se está convirtiendo lentamente en un lenguaje diferente.

En cuanto a CSS, Google quiere implementar variables en CSS, que es algo para lo que anteriormente se usaría un preprocesador de CSS como SASS o LESS, pero Google quiere que sea una función vainilla.

La otra forma de verlo es que los sistemas como plantillas o preprocesadores son ‘reemplazos de HTML y CSS’. Claro, primero tienes que compilarlos .

¿Pero no es así como funcionan la mayoría de los lenguajes de programación? 😉

El W3C intentó reemplazar HTML con varios tipos de XML. Ese esfuerzo fracasó. Pero su fracaso nos dio HTML5.

No tiene sentido, en el futuro previsible, reemplazar HTML. Está bien establecido Y CSS está casi tan bien establecido.

Esto no quiere decir que no puedan ser reemplazados, pero es extremadamente improbable.

Sigue esa discusión también:
En el futuro, ¿el lenguaje HTML, CSS reemplazará a otro lenguaje (me refiero a una nueva plataforma como HTML, CSS)? Ya sea que HTML o CSS sean permanentes o no? ¿Solo se cambiará la versión?

Esta es una pregunta bastante interesante. En mi opinión, reemplazar HTML y CSS casi no es posible todavía porque son bloques de construcción fundamentales para casi cualquier aplicación basada en web.

Entonces, cuando preguntas qué reemplazará a esos dos cuando incluso otros marcos como Ruby, Php y muchos más dependen de ellos, todavía no es factible.

Si se reemplazaran por completo, creo que tendrá que ser algo nuevo o una plataforma con la que estemos familiarizados que pueda ofrecer las mismas necesidades que HTML y CSS. Ni siquiera puedo imaginar aplicaciones web sin un poco de esos dos.

De todos modos, esta es solo mi opinión. Alguien más podría tener una respuesta más informativa.

Gracias por el A2A!

Para responder a su pregunta en una palabra, nada .

Como otros ya han dicho aquí, reemplazar HTML y CSS como el medio dominante para crear o representar sitios web es una tarea bastante difícil. Todo y lo que quiero decir es que todo finalmente se presenta como HTML para mostrarse como una página web. Todo, desde el último y mejor sistema operativo de naufragio de trenes de Microsoft hasta el portal de Pokemon GO, se representa como HTML.

Como respondí una pregunta similar aquí: ¿los navegadores web dejarán de admitir HTML y CSS?

Todo usa HTML de Windows desde 3.1 y Apple, de alguna manera u otra, a las versiones más recientes de cada uno usa HTML para representar la interfaz gráfica de usuario (es decir, GUI). Todos los programas y software representan sus GUI en HTML. Todas tus aplicaciones favoritas para Android y iPhone (y) usan HTML. Incluso los sitios web codificados con PHP, ASP, JScript, AJAX, Python y Unity se representan como HTML antes de mostrarse.

Soy un gran admirador de SVG.

SVG es parte de HTML5 (antes era un ciudadano de segunda clase). Pero, el momento de la creación de la página web es MUCHO MENOS.

La gente habla sobre problemas de diseño con CSS. Son grandes problemas. He utilizado muchas herramientas de desarrollo para front-end que superan tanto a HTML que es ridículo. Pero veo que las personas se convierten en expertos en CSS y pasan sus vidas dentro de él. Pero, con muchas de las herramientas que he usado, todo lo que tienes que hacer es dibujar. ¿Por qué no simplemente dibujar en lugar de disputar archivos CSS?

SVG es algo que se puede obtener del programa de dibujo. InkScape es gratuito, Illustrator también puede producirlo. Y, si lo necesita, puede usar CSS. Pero no tienes que usar mucho CSS. No creo que nadie haya pensado inicialmente que CSS se usaría para crear archivos de programas largos de definiciones CSS. Quizás lo hicieron. Pero, nunca lo habría aceptado si alguien me hubiera preguntado alguna vez.

Entonces, SVG no reemplaza HTML porque es parte de HTML. Pero, puede preferir usar etiquetas SVG sobre las etiquetas HTML más antiguas. Ya hay una guerra de preferencias entre tablas y listas y hacer ubicaciones DIV. SVG podría tener su propio campamento.

Pero, SVG ciertamente tiene su propio campamento. Sin embargo, no es muy grande. ¿Por qué? Solo puedo adivinar que es así porque hasta HTML4 había que poner SVG en un iframe o usar algún otro truco para usarlo.

¿Carga SVG lenta? Puede ser si haces muchas formas curvas. Sin embargo, puede crear secciones de texto y rectángulos que no ocupen más espacio de archivo que los divs y otro contenido. Por lo tanto, hay pocas razones para evitar SVG. Y, dado que también puede usarse para imágenes, pero se cargará más rápido que png u otros medios, SVG puede cargar más rápido y dar un buen control sobre su representación. Cambiar el tamaño de SVG es solo una simple especificación de cuadro. Por lo tanto, no hay necesidad de crear uñas para el pulgar u otras imágenes de soporte para diferentes tamaños. Y eso significa que hay menos trabajo en la creación de sitios más allá del trabajo ahorrado luchando por CSS.

SVG es simple, más económico y más fácil de controlar.

SVG es parte de HTML5. No reemplazará HTML como resultado. Pero, podría convertirse en la parte más utilizada de HTML.