Podemos burlarnos de Ballmer por este ataque de nervios medio loco, pero su mensaje dio en el blanco. Si no les da a los desarrolladores las herramientas y el conocimiento que necesitan para trabajar con su sistema, no solo experimentarán dificultades, ¡sino que tampoco podrán desarrollar lo que está trabajando!



Lamentablemente, en la práctica, vemos que a este respecto, los propios desarrolladores pueden ser sus peores enemigos. Eligen "marcos" terribles que los hacen trabajar más duro en lugar de más inteligentes, o hacen alarde deliberadamente de su ignorancia de los fundamentos y copian el código de otra persona con la esperanza de que haga la tarea requerida.



En ninguna otra área esto es más obvio que en una actitud arrogante, indiferente, si no francamente despectiva hacia HTML. No hay límite para un sinfín de tonterías y declaraciones erróneas de quienes no pueden escribir una sola línea en este idioma.



En pocas palabras, los desarrolladores no se toman el HTML lo suficientemente en serio, pero ¿qué sucede si les señalas sus debilidades? En respuesta, ¡solo esperaremos un flujo interminable de excusas sin sentido de por qué no deben distraerse con su implementación correcta!

Lista de excusas débiles

"HTML no es un lenguaje de programación real"

Es una secuencia de comandos que siguen las computadoras para completar una tarea. Si hay otra definición de lenguaje de programación, entonces en cuatro décadas de escribir software, no la he escuchado. ¿Está completo de Turing? No ... pero, sin embargo, le dice a la computadora cómo transmitir el significado gramatical y estructural del contenido de una manera independiente de la máquina. Existen reglas para usar sus etiquetas, orden y sintaxis.

"A nadie le importa el código si le parece correcto al usuario".

Exactamente hasta el momento en que te encuentres con usuarios ciegos. HTML no es solo el aspecto de la página ... ¡No! Lo arreglaré : HTML no se trata de cómo se ve algo en absoluto. Se necesita HTML para comunicar cuáles deberían ser los elementos en términos de gramática y estructura para que el usuario-agente pueda transmitir este valor al usuario. Entonces tenemos CSS para describir cómo deberían verse los elementos. Si alguna de sus etiquetas, identificadores o clases comunican cómo deberían verse los elementos, entonces ha elegido el código incorrecto basado en las suposiciones incorrectas.



Lectores de pantalla (software para leer una página en voz alta), libros electrónicos en Braille, TTY ... todos estos son objetivos no visuales; y no olvide que los motores de búsqueda tampoco tienen ojos. Ni siquiera les importa cómo "se ve" su página.



Además, es importante para las personas que su página sea más lenta o más costosa de alojar, o que viole las pautas de accesibilidad para personas con discapacidades o que obstruya todo el canal disponible. Marcado no semántico , DIV interminables y sin sentido que no hacen nada, clases de presentación : ¡todos se suman y afectan el resultado!



Escucharás las mismas excusas para muchos otros aspectos del desarrollo web, y casi siempre es una mentira. Ya sea semántica mala / rota, problemas de accesibilidad para personas con discapacidades, JS opcional inflado, uso de tecnologías de "aplicación web" para cosas que no deberían ser una aplicación, etc., etc.



Muy a menudo, al usar todo esto, el usuario se da cuenta de que algo anda mal, pero no puede explicarlo. Los usuarios no son programadores, no saben cuál es el error y quién tiene la culpa, pero sienten que algo anda mal, todo es aleatorio.



¿Qué pasa con el próximo perdedor desafortunado que tiene que respaldar el resultado de su trabajo, que contiene todos los errores de la lista, cómo NO usar HTML? La gente siempre está charlando sobre cómo se supone que su terrible "marco" roto "nos ayuda a trabajar juntos". ¿Cómo puede "mejorar la colaboración" dos o diez veces la cantidad de código que no se ajusta a las reglas básicas de HTML y viola el propósito mismo del lenguaje?

"Pero los ejemplos en marcos funcionan exactamente así, y fueron escritos por expertos"

No son especialistas en desarrollo web. Más bien, son especialistas en marketing, propaganda y engaño. El marcado en ejemplos de sistemas como Bootstrap y Tailwind son prácticas HTML de pesadilla. Apestan a una mezcla horrible de "No quiero aprender HTML y CSS" y "Extraño el marcado de la década de 1990", renunciando a más de veinte años de progreso. El hecho de que sean utilizados por millones de sitios ("la mayoría no puede estar equivocada"), y los expertos autoproclamados les alaban (apelar a la autoridad), no los convierte en buenos ni a ellos ni a prácticas similares.

"Es más difícil trabajar con el código vainilla".

Lo haces difícil. Aquí está el problema: al ignorar las reglas semánticas de estructuración y todo el propósito del HTML, hace que sea más difícil trabajar con él. A esto contribuye el hecho de que los cebos para novatos como W3Schools (también conocidos como W3fools) están llenos de información inexacta, simplificaciones vulgares y la ausencia total de la mayoría de los conceptos básicos de HTML.



El contenido debe definir el marcado, el contenido + el marcado + el entorno de destino / las capacidades del agente de usuario deben definir la estructura. Siguiendo la semántica básica, y mejorando gradualmente y usando la separación correcta de funcionalidades, terminará con un conjunto de instrucciones que facilitan la creación de páginas fáciles de mantener. Si tiene problemas con esto y cree que estos "marcos HTML / CSS" le están facilitando la vida, entonces no sabe lo suficiente sobre HTML o CSS para realizar ninguna de las tareas.



En general, Tailwind es más simple que el HTML / CSS básico, solo necesita aprender más de 500 clases, el 90% de las cuales ya existen como propiedades CSS, ¡y luego ignorar casi todas las reglas de cómo se debe usar HTML!



En caso de que no lo entendiste, fue sarcasmo.

"Le das demasiada importancia al HTML"

Escucho estas tonterías todo el tiempo, ¡y me molesta su miopía!



Es como decir que presto demasiada atención al suelo debajo del sitio de construcción o los materiales utilizados para crear los cimientos. Si descuida esos detalles, ¡no se sorprenda de que todo se derrumbará de una "manera incomprensible" o será absorbido por un sumidero kárstico!



HTML es la base y la piedra angular. Si lo descuida, no se sorprenda de que los resultados sean un completo desastre.



De hecho, muchos de los conceptos erróneos que utilizan los desarrolladores web para convencerse a sí mismos de que no deben preocuparse por el futuro no son diferentes de los que conducen a todos los desastres de ingeniería. Ahorrar en calidad, ignorar las especificaciones o el usuario final, alimentar su propio ego; además, muchos cometen un error fatal: confunden arte con diseño.



Este último error lleva a edificios que deslumbran a las personas con la luz del sol reflejada en sus ventanas: alguien que se imagina a sí mismo como un artista convence a la gente con disfraces de gastar miles de millones en un proyecto en el que la forma es más importante que la función.

"Pero HTML no nos da las herramientas que necesitamos para ofrecer la UX".

Hay muchas versiones diferentes de esta excusa, pero en general implican lo anterior. Aquellos que dicen esto casi siempre se refieren a los fanáticos de las "aplicaciones web" o "aplicaciones de una sola página", intentan usar JavaScript en todas partes, no les importa la accesibilidad para las personas con discapacidades e insisten en que los "usuarios" de alguna manera "necesitan" todo sus cosas elegantes para mejorar la "experiencia del usuario".



Pero para ser perfectamente honesto, estos payasos saben tanto sobre UX como los artistas que han caído en la ilusión de ser "diseñadores web" saben sobre diseño.



Y puede ver los resultados de su trabajo AHORA en toda nuestra industria.: las soluciones frágiles, hinchadas y lentas que "pueden mejorar el scripting" ralentizan tanto los sistemas de carritos de compras de las tiendas en línea que muchas de ellas ni siquiera pueden mantener el tiempo de actividad (hola Zotac) ; al mismo tiempo, los usuarios presionan ferozmente F5, esperando poder comprar una tarjeta de video. Debido a que se recarga toda la página y se vuelve a ejecutar el script, todas las funciones de la "aplicación" solo conducen a una REDUCCIÓN de la velocidad de carga de la página. Y esto es aún más pronunciado si escupe sobre el marcado usando las clases de presentación.



Y dado que las secuencias de comandos se pueden desactivar y el contenido generado por secuencias de comandos es más difícil para los lectores de pantalla, los libros electrónicos en Braille, etc., las aplicaciones de una sola página (SPA) violan las pautas de accesibilidad para las personas con discapacidades.



No estoy diciendo que SPA y similares no tengan usos razonables, pero si no puede crear un carrito de compras simple o un portal bancario de carga rápida que pierda poco al deshabilitar los scripts, entonces probablemente no debería estar haciendo ningún trabajo. es un negocio. ¡Las aplicaciones web NO deben usarse para algo ridículamente simple como un carrito de compras en un sitio web!



Y si cree que usar secuencias de comandos para hacer esto realmente mejora la experiencia del usuario, ¡entonces obviamente no ha probado el sistema con usuarios reales y tráfico real! Como mínimo, no realizaron una comparación real de la división de tareas utilizando la caché en cargas de página normales y en páginas con scripts novedosos.

Entonces, ¿el desarrollador web tiene la culpa de todo?

De ninguna manera . Volvamos al principio del artículo ya los gritos de Ballmer de "desarrolladores, desarrolladores, desarrolladores".



Cuando desarrolló su pequeño boceto, fue diseñado para resolver el problema de que a finales de los 90 Windows no era de ninguna manera en primer lugar, porque los desarrolladores a menudo no usaban las herramientas proporcionadas por Microsoft. Borland ha publicado la mejor documentación para la API de Windows. La gente usaba herramientas que no eran de Microsoft porque los lenguajes "visuales" se consideraban juguetes. Estaban tan por detrás de las tecnologías de desarrollo web que podemos decir que todavía están tratando de ponerse al día con ellas.



El W3C y WhatWG tienen problemas similares con el llamadoLas "especificaciones" simplemente no están escritas para las personas que escriben sitios web. Permítanme repetir: la especificación del lenguaje utilizado para escribir sitios web no es para las personas que realmente escriben sitios web . ¡Está escrito para personas que escriben agentes de usuario! El navegador es el usuario-agente, pero la UA no siempre es el navegador.



De hecho, es tan absurdo que la versión idiota del "documento dinámico" de WhatWG se refiera a MDN para que lo entiendan "simples mortales".



: , « » (living document), HTML- . HTML 5, , HTML 5, HTML 5 ? !



Hecho simple: para obtener descripciones de los significados de las etiquetas en un lenguaje sencillo, debe recurrir a fuentes de terceros, muchas de las cuales ni siquiera coinciden entre sí. Es más, el W3C se ha vuelto completamente ineficaz, de acuerdo ciegamente con todo lo que dice WhatWG, a pesar de que WhatWG ha demostrado una y otra vez que no está calificado para crear un descendiente de HTML 4 Strict. La aceptación de EMBED como una etiqueta válida, creando y / o manteniendo etiquetas que son redundantes en relación con OBJECT, ya no admitía (afortunadamente) la etiqueta HGROUP, lo que demostró que ni siquiera entendían para qué eran los encabezados numerados y cómo usarlos. .. Quién trabajó en él, el desafío para HTML 5 nunca ha sido crear una especificación o estándar que nos diga cómo construir sitios web útiles.Se trataba de documentar si las personas lo están haciendo bien o mal hoy y que los navegadores pueden apoyar, ¡pero no lo que deberían soportar! Dado que durante el desarrollo de HTML 5, la mayoría de los desarrolladores seguían trabajando en HTML 3.2 y garabateando el tipo de documento HTML 4 pervertido, ¿por qué sorprenderse de que todo resultara ser una colección de prácticas tan malas, obsoletas y anticuadas?



Si los desarrolladores no se toman el HTML lo suficientemente en serio, los que lo desarrollaron como una "especificación" tienen la culpa; incluso llamarlo HTML 5 era un crimen tan grave contra el desarrollo web ... Al igual que un crimen contra la música era darle un Grammy a Billie Eilish por sus mediocres creaciones.



El W3C y WhatWG ni siquiera son tomados en serio por otras organizaciones de estándares, y por una buena razón.

¿Cuál debería ser la solución?

Sería una buena idea comenzar haciendo que los desarrolladores no perciban HTML como un niño subdesarrollado del mundo de los lenguajes de programación. En particular, lograr que practiquen el marcado semántico, separando la presentación del contenido, lo que aumentará en gran medida la usabilidad, la accesibilidad y la eficiencia.



Además, nosotros mismos, como desarrolladores, tenemos nuestra voz y desconcertamos al W3C por el desastroso fracaso de su trabajo como organismo de certificación . Necesitamos exigir documentación en lenguaje más simple y limpia de la fuente oficial. No se puede justificar que un documento que describe algo tan simple como HTML sea de cinco a diez veces más largo que las constituciones de la mayoría de los países desarrollados.El mero hecho de que la especificación del lenguaje utilizado para construir sitios web no esté escrita para las personas que usan el lenguaje para crear sitios web es un voto de censura.



Pero necesitamos algo más que documentación oficial mejorada, necesitamos reducir el lenguaje, hacerlo más orientado a las tareas. Revive muchas de las ideas que estaban contenidas en HTML 5 antes de que el W3C las tirara a la basura y adoptara la versión WhatWG. El hecho de que Microsoft haya pasado décadas haciendo que IE nos impida usar OBJECT no es una razón no solo para mantener la etiqueta IMG, sino para agregar muchas etiquetas nuevas innecesariamente (VIDEO, AUDIO). El hecho de que a los "artistas" y a los delincuentes de marketing les guste abrir nuevas ventanas para el usuario, le guste o no, todavía no es una razón para que la especificación incluya TARGET="_BLANK"



...



Además, el uso EXPLÍCITO y los significados de las etiquetas deben colocarse en el centro de la especificación , y tal vez incluso en una guía de uso separada para quienes aún viven en 1997.



Hacer una versión más simple, limpia y útil de HTML que nos guíe a todos no es un gran problema.



Además, nos será de utilidad si los desarrolladores del navegador tienen menos peso a la hora de crearlo. Microsoft, Mozilla, Apple y Google tienen un gran impacto en el W3C y WhatWG, y esto es completamente poco ético. Su peso en la toma de decisiones va en contra del concepto mismo de una web libre y abierta.

---

Publicidad

Los servidores Epic son VDS para alojar sitios desde una pequeña tienda en línea en Opencart hasta proyectos serios con una gran audiencia. ¡Cree sus propias configuraciones de servidor en un par de clics!



Únete a nuestro chat de Telegram .