¿Podrían HTML y CSS quedar obsoletos a fines de la década de 2030?

Mirando hacia atrás donde estaban HTML / CSS hace 20 años, la respuesta es “probablemente no”.

Probablemente habrá algo llamado HTML / CSS, pero esto será una evolución de lo que tenemos ahora, ya que HTML5 es una evolución de HTML 1.0.

Además, el futuro HTML / CSS seguramente tendrá lenguajes agregados para varios propósitos, como vimos el avance de JS / SVG / etc.

Un reemplazo para HTML / CSS requeriría:

  • Una tecnología capaz de hacer lo que HTML / CSS puede hacer
  • un proveedor de navegadores capaz de implementarlo y empujarlo
  • algo que empujaría a los desarrolladores a usarlo en lugar de HTML / CSS, es decir, una ventaja competitiva

Flash tenía el último (capacidad para reproducir video), pero los proveedores de navegadores prefirieron adaptar HTML / CSS para eliminar Flash en lugar de presionarlo.

El único jugador que podría ir por ese camino puede ser Google.
Impulsa Chrome y los principales servicios para que pueda proporcionar un navegador “compatible con reemplazo” y también muestre una versión “mejorada” de sus servicios para mostrar la ventaja (“¡Mira! Es más rápido”).

Pero HTML / CSS también evolucionará para reducir esta ventaja, como vimos recientemente para admitir video.
Entonces, mientras haya personas para hacer que HTML / CSS evolucione hacia la necesidad de la industria, estarán aquí.

La respuesta corta es “no”, HTML y CSS estarán disponibles de alguna forma hasta que se retire. Recuerde que Fortran (declarado “muerto” cuando salió C ++) todavía está presente y hay muchos programas todavía en uso, con “Fortran 2015” en discusión. Lo mismo con Cobol.

A lo largo de mi carrera, hubo algunos lenguajes y sistemas que iban y venían (estaba triste con la muerte de Lisp). Sin embargo, los idiomas principales terminan siendo demasiado críticos para ser reemplazados. En cambio, las aplicaciones se mantienen según sea necesario.

Para dar un ejemplo concreto, el sistema SAP ERP está escrito en un lenguaje llamado ABAP. Tiene más de 300 millones de líneas de código, por lo que la transferencia no es práctica. Uno de los mayores clientes de SAP instaló la versión desde 1995 y todavía está en producción con esa versión y nunca se ha actualizado, y probablemente no lo haga mientras SAP esté en el negocio. Se rumorea que el tiempo de inactividad para el sistema SAP costaría alrededor de $ 1.5 millones por hora en pérdida de productividad y una actualización requeriría al menos 6 horas de tiempo de inactividad.

No creo que nadie tenga una respuesta difícil para esta pregunta, pero he visto algunas advertencias interesantes:

El argumento principal para html / javascript / css es la portabilidad: la vieja moto “escribe una vez, despliega en cualquier lugar”. HTML (visto aquí como la trinidad, junto con js / css) trató de llenar ese vacío, al menos en cuanto a la interfaz. Al igual que Java, una sola página HTML dará las instrucciones que una aplicación escrita nativamente (el navegador) traducirá al lenguaje específico de la máquina / SO real.

Eso está muy bien hasta que comience a ver algunos navegadores muy diferentes, escritos para sistemas con capacidades muy diferentes, como los teléfonos móviles. Es posible que pueda instalar complementos en su escritorio Chrome, pero apenas en el “mismo” navegador (Chrome), pero en su Android.

Teniendo esto en cuenta, los desarrolladores web (y las grandes empresas) se dividen en dos “equipos”: permiten una página portátil, de tamaño único para todos los entornos, o usan complementos.

El equipo de complementos puede requerir que el usuario instale (y habilite el uso de) un paquete, que puede ser engorroso / no disponible, y aún así tener que escribir código que sea compatible con la plataforma y que pueda o no usar completamente la potencia del hardware (aceleración 3D , acceso a la cámara, etc.).

Por otro lado, el equipo de HTML limpio no solo no tiene acceso a muchas funciones de SO / hardware (a favor de la portabilidad), sino que también está escribiendo más de una aplicación: una para el escritorio y otra para móviles (a veces más de una vez , ya que el uso de tabletas puede ser diferente del uso de teléfonos inteligentes).

Pero eso no es todo: los navegadores admiten diferentes especificaciones HTML (es decir, te estoy mirando), el usuario puede tener js habilitado o no, y los usuarios de iOS tienen diferentes requisitos de interfaz como sus contrapartes de Android (comenzando sin un botón “atrás”) en dispositivos iOS), y ambos son diferentes a un escritorio.

Los complementos nos pueden dar capacidades nativas similares a las aplicaciones porque, en muchos sentidos, eso es lo que son. ¿Es eso algo malo? Cuando intento abrir alguna página web o seguir un enlace en mi navegador móvil, a veces lo que se abre es una aplicación que descargué, no la página HTML, y mi experiencia se enriquece por eso.

En mi opinión, ningún complemento equivale a una interacción y capacidades limitadas. Claro que podemos agregar cámara, 3D (como en webgl), táctil o lo que sea a HTML, pero ¿por qué no usar (o, al menos, permitir el uso) de las herramientas nativas que el sistema ya nos brinda?

En mi humilde opinión, los complementos no han ido lo suficientemente lejos. Muchos simplemente se implementan porque el desarrollador quiere proteger su código fuente (y con razón, dado que js solo se puede codificar, pero no se puede proteger fácilmente), o porque tienen más confianza al escribir en otro idioma. Deberíamos poder jugar nuestro juego o aplicación favorita lo más cerca posible de la versión nativa, DIRECTAMENTE desde el navegador. Si eso significa que tenemos que ajustar o reescribir grandes partes de nuestro código para adaptarnos a diferentes plataformas, creo que deberíamos poder tener al menos esa opción, como ya está sucediendo en el mundo móvil.

Creo que en la próxima década o dos vamos a experimentar nuevas interfaces que pueden ser completamente originales en comparación con un navegador tradicional. Estamos tan cómodos con nuestras páginas HTML que olvidamos que NO se debe exigir a un usuario que sepa siquiera qué es una URL, y solo nos centramos en la experiencia de obtener la información que desea.

¿Eso desencadenará la “caída” de HTML? No lo sé. Pero tengo esperanzas.

Sí, todo se vuelve obsoleto en algún momento. Eventualmente será reemplazado por algo más eficiente y eso puede hacer más. Pero este es un camino por el camino. Actualmente, HTML o CSS no irán a ninguna parte en el futuro cercano.

Bueno, hay Jade para reemplazar HTML y STYL para CSS, pero solo hacen que codifique de manera diferente, los broswers aún entienden css y html. Supongo que estas cosas pueden reemplazar html y css, pero solo en desarrollo. ¿Los navegadores entenderán algo más que html y css? Bueno, esa es otra historia. Personalmente, sin embargo, creo que serán obsoletos, pero no porque no sean suficientes, sino porque cada tecnología debe renovarse en algún momento, porque serán insuficientes ya que sus técnicos hermanos mejoran bastante rápido.

Lo más probable es que conserven el nombre, pero estarán muy lejos de lo que hoy conocemos como HTML y CSS.
Por ejemplo, el motor Diesel todavía se llama así, pero los motores Diesel actuales están muy lejos del primero.

tal vez será reemplazado en 20 años, pero actualmente no veo ninguna razón por la cual. siempre necesitará un lenguaje evaluado por un navegador y el sistema de html no es malo. quizás algún día el navegador admitirá directamente a haml, pero no estoy seguro de si haml tendrá la fuerza para reemplazar html. con respecto a css es lo mismo. Aquí no veo ninguna alternativa en este momento.