Existe la sensación de que el desarrollo de front-end no es un desarrollo real. Es un sentimiento fanfarrón y troll. Aún así, a veces es divertido inflarnos el pecho. Intentemos señalar por qué el desarrollo de front-end es tan difícil y digno del título como cualquier otro subconjunto.
Esta es una continuación de mi publicación de la semana pasada sobre cómo las habilidades esperadas de un desarrollador front-end son difíciles de concretar y cuán diferentes podemos ser todos. Esa publicación tocó la fibra sensible de una buena parte de los lectores, y los comentarios que llegaron estaban llenos de historias y experiencias interesantes sobre lo que significa el desarrollo de front-end tanto en el sentido técnico como personal.
La práctica del desarrollo del front-end es similar a tocar el bajo: es fácil de aprender pero difícil de dominar. Hay mucho más que HTML y CSS (que son bastante difíciles para ellos mismos).
Chris planteó la pregunta en Twitter en un formulario de relleno en blanco:
El desarrollo de front-end es difícil porque _________.
– Chris Coyier (@chriscoyier) 16 de julio de 2015
Y aunque la mayoría de las respuestas fueron ciertamente entretenidas y dignas de LOL, también hubo algunas pepitas de sabiduría. Echemos un vistazo a los temas comunes que hacen que el desarrollo de front-end, ¡uh, el desarrollo!
Tenemos que lidiar con la compatibilidad entre navegadores.
Comportamiento inconsistente del navegador
– Nathaniel Flick (@nathanielflick) 16 de julio de 2015
Esta fue de lejos la queja más citada del grupo. Si bien Internet Explorer sigue siendo la peor parte de la mayoría de los chistes, cada navegador tiene sus propias peculiaridades que a menudo requieren técnicas de desarrollo especiales para superarlas.
Se espera de nosotros que sepamos cómo crear sitios web que puedan funcionar en varios navegadores. Debemos saber qué navegadores admiten qué y cómo depurar y superar problemas específicos del navegador. Deberíamos saber cómo emular o probar en una variedad de navegadores.
Debemos conocer herramientas que nos ayuden con problemas entre navegadores, ya sea de forma automática o que nos permitan escribir código para manejar situaciones de soporte y no soporte de funciones. Deberíamos saber cómo hacer alternativas. Deberíamos saber sobre la mejora progresiva y la degradación elegante.
La compatibilidad entre navegadores es una tarea de desarrollo enormemente compleja.
¡Oh, todos esos dispositivos!
Varios tamaños de pantalla y navegadores.
– Nicholas Bumgarner (@NickBumgarner) 16 de julio de 2015
Además de lidiar con las inconsistencias del navegador, los desarrolladores de front-end también se encargan de desarrollar tantos tamaños de pantalla, orientaciones de pantalla, densidades de píxeles y tipos de entrada como sea posible.
La carga del panorama masivo de diferentes pantallas, navegadores y capacidades recae principalmente en los desarrolladores de aplicaciones para el usuario.
Frameworks, bibliotecas, preprocesamiento, dependencias, complementos …
Tantas cosas nuevas todos los días y no tengo idea de lo que se convertirá en estándar.
– decano (@visualcookie) 16 de julio de 2015
Todos los frameworks aburridos que hay
– Rick Blalock (@rblalock) 20 de julio de 2015
Solía ser que vincular una hoja de estilo y tal vez un archivo JavaScript en el HTML era todo lo que se necesitaba para comenzar a diseñar y construir un sitio. De hecho, esa sigue siendo la línea de base.
El desarrollo de hoy se siente muy diferente. La cadena de herramientas es mucho más gruesa. Estamos tomando decisiones sobre los procesos de compilación, qué bibliotecas usar, en qué lenguajes escribir, cuánto queremos invertir en las sintaxis futuras, cuánto queremos depender de los marcos, qué herramientas de terceros tienen sentido y se sienten seguras usar.
No solo es fatigoso pensar en las opciones, es cada vez más difícil saber cuáles son las mejores opciones y si estas opciones son inteligentes a largo plazo.
Hay tantas opciones, o más, en el nivel de desarrollo inicial que en cualquier otro lugar. Sin mencionar que el paisaje se mueve extremadamente rápido.
Somos el puente entre diseñadores visuales, desarrolladores de back-end y otras disciplinas.
porque ya no se siente del todo “front-end”
– Ara Abcarians (@ItsMeAra) 17 de julio de 2015
Muchos de los frameworks y CMS actuales se encuentran a caballo entre muchas disciplinas diferentes. Los desarrolladores front-end están en el medio de todo. En última instancia, somos responsables del diseño: cómo se ve el sitio. Estamos ayudando a las personas de contenido a asegurarse de que tienen lo que necesitan y nos brindan lo que necesitamos. Estamos trabajando en plantillas para extraer los datos que necesitamos en los formatos que necesitamos. Estamos manejando la entrada del usuario y asegurándonos de que se canalice hacia donde va para más preocupaciones de back-end.
Te confundes entre quién eres: programador o diseñador
– Priyanka N Majumder (@PriyankaNM) 17 de julio de 2015
La cadena de culpa comienza con la parte delantera
– Chris (@chrisdebelen) 16 de julio de 2015
No solo nos sentamos en la intersección de muchas disciplinas, existe la expectativa de que sepamos suficientes lenguajes de back-end para ser útiles. Lo lamentarías mucho, desarrollador de WordPress, si no conocieras PHP. No sería muy útil en un proyecto de Rails si no conociera ninguna de las convenciones de Ruby o Rails. Cuanto más sepa, más ágil y autosuficiente podrá ser para su equipo.
Todo el mundo y su dentista creen que pueden hacerlo.
Es fácil, hazlo así … espera, ahora así … ok, ahora que hemos terminado, ¿podemos cambiar todo a esto? es fácil…
– Liga Andrew (@ aleague888) 16 de julio de 2015
La barrera de entrada para el desarrollo de front-end es bastante baja. Todo el mundo ha oído hablar de HTML. Ellos “saben lo suficiente para ser peligrosos” por así decirlo. Debido a que esa barrera es baja y debido a que es muy fácil incursionar, tiene sentido que la gente asuma que no hay mucho que saber y que el desarrollo de front-end no es particularmente difícil.
Nombrar cosas. Y tenemos que nombrar muchas cosas.
Tienes que nombrar las cosas.
– Stuart Robson (@StuRobson) 16 de julio de 2015
Imagino que has escuchado la máxima de que nombrar cosas es uno de los problemas más difíciles de la informática. Nosotros, los front-end, estamos nombrando cosas todo el tiempo. Nombres e ID de clases, atributos de datos, nombres de archivos, patrones de comunicación con su equipo. Es interminable Parece que hay docenas de opciones de nombres en un día normal.
Sin mencionar que la tarea de redactar textos publicitarios a menudo recae en nosotros, que no es exactamente nombrar, pero tiene una dificultad similar.
“La forma correcta” y “la forma incorrecta” no son tan sencillos como con el desarrollo back-end.
Sin tubería de producción estándar. Sin implementación de navegador de referencia. No hay respuestas correctas, pero hay toneladas de respuestas incorrectas.
– Pelle Bjerkestrand (@pcbjerkestrand) 16 de julio de 2015
En el desarrollo de back-end, si sucede lo que espera que suceda, lo ha logrado. Seguramente son diferentes formas de llegar, unas mejores que otras. Pero en el desarrollo de front-end, los caminos para completar una tarea parecen interminables. Incluso si aparentemente ha tenido éxito, puede parecer solo una cuestión de tiempo hasta que se encuentre un error en la forma en que lo hizo.
CSS es muy difícil de probar.
Los lenguajes de back-end (e incluso JavaScript) pueden usar pruebas unitarias y pruebas de integración para ayudar a asegurarse de que el código funcione como se espera. CSS no tiene tal lujo. Ciertamente, hay personas que lo intentan y hay información y herramientas disponibles. Pero nada de esto es tan bueno y hay muy pocas historias de éxito.
Los errores pueden ser sutiles, confusos e inesperados. Peor aún, un cambio aparentemente pequeño puede tener un efecto adverso en un lugar inesperado donde no se da cuenta hasta que es demasiado tarde.
Hay herramientas para pelar, que ayudan un poco. Existen algunas herramientas de aplicación de guías de estilo, pero en realidad no ayudan a hacer cumplir cosas más importantes como el cumplimiento de los estándares de nomenclatura.
Los desarrolladores de front-end deben tener una comprensión muy sólida de todo el sitio web en su cabeza para ser más efectivos y eficientes.
JavaScript es tan complejo como cualquier otro lenguaje de programación. Es extraño y difícil.
JavaScript es desarrollo de front-end. JavaScript es programación. La programación es parte del desarrollo de software. El desarrollo de software es difícil.
El rendimiento es del 80% sobre nuestros hombros.
La regla general es que el 20% de la espera para que se cargue un sitio web se debe a problemas de back-end. Una vez que llega el documento HTML, el resto del tiempo de carga es asunto de los desarrolladores de aplicaciones para el usuario. Qué recursos se cargan, cuántos recursos se cargan, qué tan optimizados están, de qué manera se cargan y cómo se siente, etc.
Es donde ocurre la accesibilidad.
Construir sitios que sean visualmente impresionantes es una cosa y su accesibilidad es otra. A los diseñadores les importa mucho la forma en que los usuarios interactúan con un sitio y eso no siempre puede ser una interacción visual. Diseñar y desarrollar para discapacidades es una disciplina en sí misma, pero está más estrechamente ligada al desarrollo de front-end. La accesibilidad tiene su propio conjunto de especificaciones que, lamentablemente, no suelen enseñarse junto con la formación de desarrollo de front-end tradicional.
Es difícil contratarlo.
Los desarrolladores de front-end suelen ser los puestos más difíciles de llenar.
Y por supuesto…
Porque lo ponemos difícil.
– (@mikeyb) 16 de julio de 2015
Terminando
¿Entonces, qué piensas? ¿Es el desarrollo de front-end un desarrollo “real”? Me gustaría pensar que sí y creo que la retroalimentación proporcionada aquí, especialmente por otros, es una prueba sólida. ¿Hay más cosas que lo dificultan? SEO? ¿Vale la pena tener esta conversación?