La evolución de la web durante la última década refleja el desarrollo de la economía estadounidense. Todos los indicadores clave se mueven hacia arriba y hacia la derecha en los gráficos, un flujo constante de avances fundamentales proporciona una sensación de "progreso", pero en realidad, la usabilidad y el impacto de la tecnología en las personas se estanca o incluso retrocede.
Esta crisis está afectando a plataformas, creadores y consumidores.
Intentaré analizar y diagnosticar un poco esta situación. Si solo desea leer mi discurso no profesional de mente estrecha sobre la necesidad de reiniciar la web, puede omitir esta parte. La idea es que podamos elegir un nuevo formato de marcado ligero (rebajado) para reemplazar HTML y CSS, dividir la web en documentos y aplicaciones web, recuperando la velocidad, accesibilidad e interés de la web.
Esta publicación utiliza una definición pedante de "web". Varias veces ya he hablado de intentos de reinventar "Internet". Proyectos como dat, IPFS y arweave fueron concebidos para reinventar Internet o sus capas de transporte y transporte de datos. La web es lo que se encuentra en la parte superior de estas capas: HTML, CSS, URL, JavaScript, navegadores.
Choque de plataformas
La semana pasada, hubo un cambio de plataforma importante: Mozilla despidió a 250 empleados y dijo que afectaría el desarrollo de Firefox. Firefox no fue el segundo navegador más popular, Safari lo es, principalmente debido a la audiencia de "esclavitud" de los propietarios de iPhone y iPad. Sin embargo, fue el navegador más popular que eligió la gente .
Gráfico del contador de estadísticas
El verdadero ganador no fue Chrome en sí, sino el motor Chrome. Una base de código KHTML dividida en WebKit (Safari) y Blink (Chrome, Microsoft Edge, Opera, etc.)
En la práctica, así es como se ve la definición de libro de texto de "monocultivo". Por un lado, esta es una victoria en términos de colaboración, porque nadie necesita "perder tiempo" en implementaciones de la competencia, y los desarrolladores web enfrentan las mismas características y errores en todos los navegadores. Pero en un sentido más profundo, amenaza los principios básicos de la evolución web.
Especializaciones e implementaciones
La web ha evolucionado combinando especificaciones e implementaciones . Organizaciones como WHATWG , W3C e IETF han sido espacios para que desarrolladores independientes, corporaciones y académicos colaboren para discutir el potencial de las nuevas capacidades web. Los navegadores han probado sus ideas en muchas implementaciones diferentes.
Era una parte interesante de la estructura: dicho sistema aseguraba que todos pudiéramos desarrollarnos juntos, y que uno de nuestros objetivos era poder contribuir a la web para muchos colaboradores. Nos molesta cuando estamos en caniuseAparecieron celdas vacías, pero la idea general era que incluso si los diferentes navegadores pueden ser mejores en diferentes aspectos, tarde o temprano se igualan entre sí. Chrome no fue el primer navegador en introducir nuevas funciones y optimizaciones.
Trabajar en colaboración es más lento que trabajar solo, pero trae beneficios que hemos perdido hoy. Chrome ha evolucionado extremadamente rápido, agregando nuevas especificaciones e ideas a un ritmo asombroso, convirtiéndose en uno de los productos de software más difíciles de recrear.
Me parece que Mike Healy lo expresó mejor :
¿No cree que la web está prácticamente "monopolizada" en términos de complejidad si los motores de renderización son capaces de crear sólo una o dos organizaciones para ella?
Hoy en día, no solo es casi imposible crear un nuevo navegador desde cero; si lo hace, la carrera constante para implementar nuevos estándares requerirá todo un equipo de especialistas. Puede leer sobre esto en el artículo de Drew DeWalt Los navegadores web deben detenerse ; También recomiendo leer sus otros materiales.
Un desafío para los creadores
Se ha vuelto mucho más difícil de diseñar para la web.
La web solo ha crecido durante 25 años, ha tenido muy pocas oportunidades de encogerse, y hoy está bajo la influencia de una cultura extremadamente miope de crecimiento económico y profesional sin planes a largo plazo. Hay muchas formas de implementar algo, y algunas de las formas más populares de crear aplicaciones en la web son, en mi opinión, por lo general extremadamente, demasiado poderosas.
La mejor manera de ingresar al desarrollo web en 2020 es elegir un nicho como Vue.js o React y esperar tener un experto en CSS en el equipo.
Existe una asombrosa variedad de tecnologías para aquellos que solo quieren crear una página web en lugar de esforzarse por ingresar a la industria, pero las más simples y probablemente las mejores están estigmatizadas. Es más probable que las personas escriban CV de React con GraphQL que HTML en el Bloc de notas.
Un problema para los consumidores
Esperamos que toda la innovación se cree por el bien del usuario , pero a menudo este no es el caso. Parece que los sitios web modernos son los más grandes, lentos y con más errores en la historia de la web. Nuestras computadoras apenas se están volviendo más rápidas y nuestras velocidades de conexión a Internet se están estancando (ni siquiera intentes decir nada sobre 5G). El crecimiento en el tamaño de las páginas web está superando el crecimiento de todos los demás parámetros.
Debido a todo esto, ya no espero que las páginas sean rápidas, incluso con uBlock instalado en Firefox y un buen proveedor de fibra local.
Pero no quiero culpar a estos desarrolladores web por todo.... Puedo compartir una historia bastante divertida de mi antiguo lugar de trabajo. Recopilamos datos sobre la interacción del usuario con los sitios para responder preguntas simples como "¿las personas hacen clic en un botón para cargar archivos en el servidor o usan la función de arrastrar y soltar?" Por lo tanto, usamos Segment , una herramienta que le permite agregar canalizaciones de recolección de datos usando un script simple. Sin embargo, el problema era que Segment tenía una página enorme con cientos de proveedores de datos y empresas de tecnología publicitaria. Y, por supuesto, los tipos que están en el negocio de la empresa comenzaron a presionar todos estos botones .
Verá, el problema con la publicidad y el seguimiento de datos es que todo esto se puede hacer, pero ¿quién lo rechazará? (En nuestro caso, me excluí y agregué un CSP que bloquea el acceso de nuevos anunciantes al nivel de la página).
Un regreso a la sencillez
Es imposible llegar a un sistema simple agregando simplicidad a un sistema complejo. - Richard O'Keeffe
¿A dónde vamos luego? Las personas más inteligentes sugieren que organicemos una revisión de las versiones web.
¿Cómo hacemos que la web sea interesante, colaborativa y buena?
Primero, pensé que había dos sitios web:
Documentos web
Hay "documentos web": blogs, noticias, Wikipedia, Twitter, Facebook. Por lo que tengo entendido, de hecho, esta es la web como se veía originalmente (yo tenía dos años entonces). CSS, que ahora vemos como una herramienta que los diseñadores pueden usar para crear unicidad de marca y agregar detalles con precisión de píxel, originalmente se vio como una forma de hacer que los documentos fueran legibles sin formatear, lo que permitía a los lectores de esos documentos personalizar su apariencia. De hecho, este atributo se almacenó en Chrome como hojas de estilo personalizadas durante un tiempo y todavía funciona en Firefox . Sin embargo, en la web de hoy, esta será una tarea desalentadora, ya que efectivamente ha abandonado la idea del HTML semántico .
Aplicaciones web"
Y luego están las "aplicaciones web". Comenzó como aplicaciones del lado del servidor creadas sobre algo como Django y Ruby on Rails . Antes de ellos, había muchas tecnologías que ahora vivirán para siempre en las corporaciones, como los servlets de Java .
Backbone.js demostró que muchas de estas aplicaciones se podían migrar al navegador, después de lo cual React y muchos de sus competidores de SPA crearon un nuevo orden mundial para las aplicaciones de cliente web con un alto grado de interactividad y complejidad.
Guerra entre partes de la web
Sostengo que es esta naturaleza dual la que crea la magia de la web. Pero también es una fuerza destructiva.
La magia es que un blog simple puede ser un medio creativo, una excelente forma interactiva de expresarse. Mi sitio no es así, pero solo digo que es posible .
El problema es que los "documentos web" a menudo adolecen de características de la aplicación: es JavaScript y la animación, y su complejidad lo que hace que el sitio web de noticias promedio sea un desastre. Cuando los sitios web de documentos adoptan patrones de aplicación, a menudo sacrifican accidentalmente la accesibilidad, la velocidad y la legibilidad de la máquina.
Y las "aplicaciones web" adolecen de las características de los documentos: las aplicaciones interactivas hacen todo lo posible para evitar la mayoría de las características fundamentales de HTML y CSS, y las utilizan solo como materias primas, evitando por completo escribir HTML directamente, evitando escribir CSS , evitando funciones de animación estándar , reemplazando paginar a algo que se vea similar pero que funcione de manera completamente diferente . Las aplicaciones web usan JSX sobre HTML y prefieren manejarlo en el propio navegador, o usan Svelte sobre JavaScript y también lo prefieren.
Cuando leo las publicaciones de blog de "desarrolladores web tradicionales" que están enojados porque HTML y CSS no son suficientes hoy y las cosas se han vuelto tan complejas, creo que esto se debe principalmente a que en muchos lugares el desarrollo de aplicaciones se acumula en la construcción de la web. -sitios reemplazaron la pila de creación de documentos. Dondequiera que hubiéramos usado Jekyll o renderizado del lado del sitio, ahora se aplica React o Vue.js. Hay ventajas en este enfoque, pero para muchos sitios web con una interactividad mínima, esto significa abandonar décadas de conocimiento a cambio de algunos beneficios de velocidad que pueden ni siquiera importar.
El atractivo de las redes sociales
El atractivo de las redes sociales se debe en parte a que nos permite crear documentos sin pensar en la tecnología web y brinda garantías de velocidad, accesibilidad y perfección que nos llevarían mucho tiempo sin las redes sociales. No tenemos que preocuparnos por que las publicaciones de Facebook se carguen rápidamente en los teléfonos de los amigos, o por editar y publicar una foto en Instagram correctamente; nos hemos ocupado de todo eso.
Hasta cierto punto, esto no requiere capacidades de redes sociales: estándares como RSS y servicios como Instapaper demuestran que se puede realizar un hermoso formato y distribución a nivel de plataforma. y construir sobre los sitios web básicos existentes.
Pero no hay una división clara
, - : ! , , -, , , («» JavaScript -), , . , , . : , , , .
Documentos web 2.0
Por supuesto, sería genial implementar una teoría unificada de la nueva web que tenga suficientes características de aplicación y suficientes características de documento para crear todos los documentos interactivos híbridos con los que estamos trabajando hoy. Pero el camino hacia la red dividida está más claro para nosotros, y lo pensé primero, así que hablemos un poco sobre ello.
- Regla n. ° 1: no cree subconjuntos . Si el reemplazo de la web son solo las características que estaban presentes en Firefox 10 hace diez años, entonces a nadie le gustará esta versión.
- №2 — . , , , - , .
- №3 — . , : , , , , , , .
Entonces, digamos que estamos creando un nuevo documento web.
Primero, necesitamos un lenguaje de marcado mínimo y estandarizado para comunicar documentos. Probablemente querremos comenzar con un lenguaje de marcado ligero que se adaptará a la generación de HTML. Un sabor estricto de Markdown llamado Commonmark parece una muy buena elección . Este es el idioma en el que he escrito todas mis publicaciones, el más popular en mi familia. Hay muchos analizadores excelentes para Markdown y un gran ecosistema de herramientas.
A continuación, necesitamos un navegador. Durante mucho tiempo, Mozilla ha estado trabajando en un nuevo navegador: Servo... El equipo de desarrollo fue despedido la semana pasada, lo cual es triste. Este proyecto incluye marcos de trabajo independientes de Rust para renderizar fuentes , así como una implementación de Markdown de alta gama en Rust y un conjunto cada vez mayor de marcos de aplicaciones increíbles . ¿Es posible crear un navegador Markdown puro que utilice esta canalización directamente? ¿Tal vez?
Creo que tal combinación nos permitirá recuperar en gran medida la velocidad perdida. Podríamos llevar una página a la pantalla en una fracción del tiempo en comparación con la web moderna. El consumo de memoria puede ser mínimo. El sistema predeterminado será increíblemente accesible. Puede crear hojas de estilo estándar de gran apariencia y compartir hojas de estilo personalizadas alternativas. Gracias al volumen significativamente reducido, podremos portar el sistema a todo tipo de dispositivos.
¿Cómo serán las herramientas de edición de sitios web (que probablemente sea la más importante)? Pueden ser mucho más simples.
¿Cómo sería la agregación? Si las páginas web fueran más documentos que aplicaciones, entonces no necesitaríamos RSS: los sitios web tendrían un índice que apuntara a los documentos y un "lector" podría agregar las páginas web por defecto.
Podríamos conectar las dos web usando algo como un archivo de protocolo dat conocido , o podríamos usar el encabezado Accept para crear un navegador que entienda HTML pero prefiera páginas ligeras.
Aplicaciones web 2.0
Tengo la sensación de que cualquier problema web que mencione, se me responderá automáticamente que WebAssembly puede solucionarlo. ¿Podría ser así?
Yo no sé. WebAssembly es realmente una gran cosa, pero ¿deberían las aplicaciones web simplemente renderizarse en el lienzo y cada aplicación extraer su propio conjunto de herramientas gráficas? ¿Realmente necesitamos diferencias en la implementación del anti-aliasing en aplicaciones web? Las aplicaciones en contenedores existen, eche un vistazo a Qubes , pero no son realmente lo que los usuarios deberían buscar. Cualquiera que haya usado Blender o Inkscape en una Mac tiene una idea aproximada de cómo se vería.
¿O podría WebAssembly convertirse en el nuevo "núcleo" y aún representar el HTML de la interfaz de usuario? O ... podemos crear una biblioteca vinculada compartida que las aplicaciones WebAssembly puedan usar. Funcionaría de manera similar a SwiftUI y proporcionaría estándares amigables con la aplicación, como restricciones, en lugar de conceptos como la altura de línea y los flotantes que se encuentran en los documentos.
El problema de dar forma al concepto de aplicaciones web es que está creciendo mucho.
Cuanto peor se ponen las Mac App Store, Windows App Store, App Store y Play Store, cuanto más exigen estos monopolios, más costes implica ser un desarrollador de Mac o Windows, más se trasladan estas aplicaciones a la web. Ciertamente, algunas aplicaciones son mejoresEn la red. Pero muchos van allí simplemente porque es el único lugar que queda donde el producto se puede distribuir o vender fácil, barato y libremente.
Érase una vez, podíamos instalar aplicaciones, dar consentimiento explícito para que se ejecutaran en una computadora y usar nuestro hardware. Ese tiempo está llegando a su fin, y las páginas web de hoy tienen formas bastante sofisticadas de obtener cualquier información, desde cámaras web, archivos, controladores de juegos, síntesis de audio hasta criptografía y todo lo que alguna vez fue el reino de las posibilidades
.exey .app. Por supuesto, esto le da nuevo poder, pero la situación es bastante inusual.
¿Quién está trabajando en esto?
- Beaker Browser — dat , .
- Project Gemini — -. ( .)
- taizen — . , .
?
Hay muchas opiniones posibles sobre este problema y formas de resolverlo. Creo que esto es realmente un problema (para todos menos para Google). La idea de un navegador web como algo que podemos entender , las páginas web como algo que más gente puede crear , me parece asombrosa.
El enfoque de rebajas parece muy realista. Creo que el argumento más fuerte en su contra es que "absorbe todas las cosas interesantes de la web", y eso es parcialmente cierto. Sin embargo, la primera web no era interesante en el sentido habitual: allí no podíamos crear arte o usarlo para otra cosa que no fuera el intercambio de documentos. Pero fue increíblemente interesante, porque es interesante compartir información, y allí se podía hacer de manera simple y universal. Por tanto, lo más importante es encontrar los elementos que liberen las posibilidades de tal plan, si, por supuesto, existen. O busque otro plan que "sea lo suficientemente interesante".
Las redes sociales tienden a ser más restrictivas que las páginas web, pero también más atractivas.por muchas razones importantes, la más importante de las cuales es la posibilidad de participación de muchas más personas. ¿Y si el resto de la web tuviera tanta sencillez e inmediatez sin estar tan centralizado? ¿Y si pudiéramos empezar de nuevo?
Publicidad
Los servidores Epic son servidores virtuales para alojar sitios desde un pequeño blog de WordPress hasta proyectos serios y portales con un millón de audiencia. Hay disponible una amplia gama de planes de tarifas, la configuración máxima es de 128 núcleos de CPU, 512 GB de RAM, 4000 GB de NVMe.
