Premisa

Lo que sigue es una respuesta al hermoso artículo de Josh Collinsworth que puedes encontrar aquí.

Decidí estructurar este contenido tomando cada cita resumida que hace en su artículo y respondiendo a cada una de ellas con mi opinión.

Este artículo debe considerarse, por tanto, como una serie de ideas que identifican una opinión personal. De las 12 citas reportadas, me encontré de acuerdo con ✅ 8 de ellas, en desacuerdo con ❌ 3 y no tengo opinión sobre . 1.

[TL;DR] En general estoy de acuerdo con la opinión del autor y su punto de vista, aunque en algunos casos la visión distorsionada creada por el artículo me ha llevado a estar en desacuerdo con algunas afirmaciones. El análisis sobre los prejuicios ha provocado, en mi opinión, el mismo prejuicio hacia el mundo del desarrollo por parte del autor.

Siento que estoy viendo una disminución generalizada de la práctica del frontend. Casi dondequiera que mire, noto que se minimiza su importancia y se trivializan sus desafíos.

✅ Estoy totalmente de acuerdo con esta afirmación.

Durante demasiado tiempo, el frontend ha sido considerado el “hermano pequeño” del backend, y esto es un error. El frontend es la parte de una aplicación que el usuario final ve e interactúa y, por lo tanto, es fundamental para el éxito de un producto. Su importancia no se puede subestimar, pero esto sucede con demasiada frecuencia, y Yo mismo a veces he considerado mi trabajo como desarrollador frontend “inferior” a lo que hacía en backend.

¿Por qué sucede esto? Desde mi punto de vista, creo que se debe a que en la última década el mundo del desarrollo frontend ha sido invadido por frameworks y librerías que han hecho el trabajo más sencillo y accesible para todos. Esto ha llevado a dar respuesta a muchos de los problemas que surgieron en el pasado, haciendo que el desarrollo frontend sea “más simple”. Esto ha llevado a una devaluación del papel del desarrollador frontend, a quien a menudo se le considera un “mono de código”. Sin embargo, simple no significa fácil, y al desarrollador frontend a menudo se le pide que resuelva problemas complejos y tome decisiones importantes, precisamente porque ya no se espera que él o ella resuelva problemas “simples”, ya resueltos por el marco, sino más bien para enriquecer las experiencias del usuario de formas nuevas e innovadoras.

Es como si CSS existiera en algún extraño estado cuántico; De alguna manera, ambos son demasiado complejos para usar, pero demasiado simples para tomarlos en serio, todos a la vez.

✅ Aquí también estoy de acuerdo.

CSS es uno de los lenguajes más subestimados y devaluados en el mundo del desarrollo web. CSS es un lenguaje potente y complejo que le permite crear interfaces de usuario complejas y detalladas. Sin embargo, el alejamiento de la forma normal de escribir código, su particular sintaxis y su lógica de funcionamiento dificultan a menudo su dominio y uso. CSS es un lenguaje que requiere tiempo y dedicación para dominarlo, y lo que pasó con el movimiento CSS-in-JS es un claro ejemplo de cómo la comunidad intentó resolver un problema que no existía creando un uno nuevo, al mismo tiempo que agrega abstracción a un lenguaje que ya es muy complejo.

En muchos sentidos, CSS tiene un mayor impacto que cualquier otro lenguaje en la experiencia del usuario, lo que a menudo influye directamente en el éxito. ¿Por qué, entonces, se menosprecia tanto su papel?

✅ Estoy de acuerdo.

Como mencioné en respuesta a la cita anterior, creo que el problema con CSS se debe a su lógica de funcionamiento y su particular sintaxis. El problema es que muchas veces se lo ve como un lenguaje “secundario” respecto a JavaScript, cuando en realidad es un lenguaje en sí mismo, con sus reglas y peculiaridades, y requiere un tiempo de aprendizaje comparable al de una programación. CSS es un lenguaje poderoso y complejo, y su papel no puede subestimarse.

En general, nadie dice que el frontend sea menos importante, o menos real, o que no sea necesario ser tan inteligente para hacerlo. Pero a menudo parece estar implícito.

✅ Estoy parcialmente de acuerdo.

A decir verdad, veo este tema mucho más explícito de lo que dice el autor. De hecho, a menudo tengo que debatir con personas que consideran que el frontend es un trabajo “menor” en comparación con el backend, y que creen que el desarrollador frontend no debería ser un programador, sino un apoyo a quienes hacen el trabajo real, el backend. Cuando me preguntan cuál es mi rol, siempre respondo Full-Stack, porque en mi formación y crecimiento hay varios y diferentes elementos, y ambas caras de la moneda han sido importantes y significativas para mí.

Creo que la comunidad necesita hacer más para erradicar esta mentalidad. El desarrollador frontend es un profesional en todos los aspectos, y su trabajo es fundamental para el éxito de un producto.

El desarrollador frontend está llamado a resolver problemas complejos, apoyado en herramientas en constante evolución, lo que aumenta enormemente la carga cognitiva, y a tomar decisiones importantes que influyen directamente en la experiencia del usuario, el baluarte de un producto exitoso.

Nuestra producción es artística, hasta cierto punto, y las cosas artísticas tienen una larga historia de devaluación trágica simplemente porque parecen simples y agradables.

✅ Estoy de acuerdo.

La falta de comprensión de los roles y responsabilidades juega un papel fundamental en nuestra industria. El desarrollador frontend es a menudo visto como un “artista”, un “creativo”, y su trabajo se devalúa porque no es “técnico” como el del desarrollador backend. Esto es un error en dos sentidos.

En primer lugar, a menudo no es el desarrollador frontend quien decide el diseño de una aplicación, sino el diseñador (UX, UI, llámalo como quieras). El desarrollador frontend debe traducir el diseño en código y hacerlo de forma eficiente y de alto rendimiento. Esto requiere habilidades técnicas y conocimientos específicos, que van mucho más allá de simplemente escribir código.

En segundo lugar, como ya se mencionó anteriormente, las responsabilidades de un desarrollador frontend a menudo van mucho más allá de simplemente escribir código. Si modifico el código en mi aplicación backend, lo más probable es que las pruebas automáticas noten cualquier regresión antes que yo. Si modifico el código en mi aplicación frontend, es muy probable que la única forma de notar cualquier regresión sea probar manualmente la aplicación o esperar un informe de los clientes finales*. Esto hace que el trabajo del desarrollador frontend sea mucho más complejo y exigente de lo que podría pensarse. Sin mencionar la cantidad de lógica empresarial y gestión estatal, ambas vertidas rápidamente en el frontend, que hacen que el rol esté cada vez más integrado con el negocio.

*Nota: Conozco muy bien la existencia de pruebas de extremo a extremo, pero su implementación es mucho más compleja y costosa que las pruebas automáticas tradicionales, además su confiabilidad es muchas veces cuestionada debido a sus condiciones aleatorias y externas.

El lenguaje implica que las interfaces están desacopladas del software y no son una parte real del mismo.

? No hay opinión sobre esto.

Se hace referencia aquí a la paradoja de que en nuestro sector parece haber una diferencia entre Desarrollador e Ingeniero y que necesariamente debe mostrarse como algo más. No tengo opinión al respecto, pero estoy de acuerdo en que hoy en día la proliferación de títulos y pancartas no hace más que enturbiar las aguas respecto de lo que realmente hacemos cada uno de nosotros.

Escribir CSS parece considerarse muy parecido a tomar notas en una reunión, con todo el sexismo implícito y la devaluación de la importancia de quien toma notas en la sala.

✅ Estoy de acuerdo.

Como ya se mencionó anteriormente en este artículo, estoy de acuerdo con la devaluación incorrecta de CSS y el mundo frontend en general. Además, en esta parte del artículo se hace referencia al chovinismo presente en nuestro sector, y aunque nunca he tenido una percepción directa del mismo, entiendo su realidad y gravedad. Nuestra industria sigue siendo con demasiada frecuencia un entorno hostil para las mujeres y creo que la comunidad debe hacer más para combatir esta mentalidad.

Como si el trabajo casi imposible de soportar todos los dispositivos, sistemas operativos, tamaños de pantalla, navegadores, preferencias de usuario e interfaces posibles en el pasado, presente y futuro fuera tan simple que inventamos toda la complejidad nosotros mismos, sólo porque estábamos aburridos.

✅ Estoy de acuerdo con el significado intrínseco de esta declaración.

La complejidad del mundo actual hace que el papel del desarrollador frontend sea aún más complejo que nunca, y cuando los chistes y remates se vuelven sesgos, es fácil caer en la trampa de devaluar el trabajo de los trabajadores frontend.

Sí, como grupo nos entusiasman las cosas nuevas. Pero ¿por qué eso no nos hace curiosos, adaptables o inquisitivos? ¿Por qué no se nos reconoce el mérito por nuestra alegría de aprender, en lugar de denigrarnos por negarnos a permanecer en el lugar?

❌ Estoy menos de acuerdo con este.

Si bien es cierto que la evolución del mundo frontend —como ya se mencionó anteriormente— ha llevado a una proliferación de ideas, herramientas y metodologías, el Síndrome del Objeto Brillante es un problema real y extendido, especialmente en la comunidad front-end. Esto no significa que no debas ser curioso o adaptable, sino que muchas veces caes en la trampa de adoptar nuevas tecnologías sin comprender completamente los pros y los contras, y sin evaluar si realmente son necesarias o no.

Si nuestras habilidades son valiosas como cinta adhesiva para tapar las grietas de las deficiencias organizacionales, ¿por qué no lo son durante la planificación y la toma de decisiones que llevaron a esos defectos, cuando potencialmente podríamos prevenirlos?

✅ Totalmente de acuerdo.

Exactamente como un Arquitecto de Software (O Tech Lead, o quien esté a cargo de la arquitectura) debe involucrar a cada miembro del equipo en las elecciones arquitectónicas - a pesar de tener la última palabra y en última instancia la responsabilidad sobre ellas -, también la decisión El proceso de creación que conduce a la creación de una aplicación o parte de ella debe involucrar a todos los miembros del equipo, incluidos los desarrolladores frontend. Aquellos que han estado haciendo esto durante suficiente tiempo pueden encontrar brechas en la experiencia del usuario o en el diseño que otros no verían, e involucrarlos en el proceso de toma de decisiones puede conducir a una mejor experiencia de usuario y a un producto exitoso.

Las herramientas de frontend se promocionan a sí mismas como si el frontend fuera algo que nadie quisiera hacer y que a nadie debería importarle más de lo necesario.

❌ Puedes ver claramente que la frustración aumenta a medida que se desarrolla la publicación, pero en este caso solo puedo estar en desacuerdo.

El marketing, como lo define Josh, de las herramientas frontend nunca ha trivializado ni tratado de simplificar los desafíos de los desarrolladores, excepto por algunas raras excepciones. Estas herramientas apuntan cada vez más a hacer el trabajo del desarrollador frontend más simple y más eficiente, pero nunca banal, y es correcto que la dirección siga siendo la misma. La promesa nunca es convertir al desarrollador frontend en un mono de código, sino permitirle centrarse en lo que es realmente importante: la creación de una experiencia de usuario exitosa y el impacto en el negocio y el mundo que lo rodea. Lo mismo ocurre con el mundo backend, donde las herramientas han evolucionado para permitir a los desarrolladores centrarse en el producto, en lugar de en opciones técnicas o problemas de configuración.

Finalmente, recordemos que el mundo de las Relaciones con los Desarrolladores se ha desarrollado de manera estructurada en los últimos años, y cualquier paso en falso por parte de algunas empresas no debe considerarse la norma.

Parece que ya nadie piensa en el frontend como una parte crítica del producto; Solo lo consideran la bonita caja en la que llega el producto.

❌ Aquí también, lamentablemente, no estoy de acuerdo con Josh.

El frontend es una parte fundamental de un producto, y su importancia no puede subestimarse, pero eso no significa que necesariamente tengas que permitirte la complejidad y la abstracción. El desarrollo frontend ya es lo suficientemente complejo como para no requerir un diseño súper sofisticado o arquitecturas abstrusas, y exactamente como en el mundo backend, la estandarización, si se hace con pleno conocimiento de los hechos, nos permite no agregar carga cognitiva innecesaria y centrarnos en otros aspectos. del producto.