¿El desarrollo web de back-end está tan roto como el desarrollo de front-end?

No, para nada, ni siquiera cerca.

Front-End es realmente un desastre, debes ser un tipo especial de soldado para que esa mierda funcione correctamente. HTML es bastante malo, CSS es peor y JS es aún peor que eso. Hay problemas de representación entre los navegadores web, incluso en el mismo navegador web …

Los buenos desarrolladores front-end tienen mi mayor respeto, son las botas en el suelo, los muchachos en las trincheras, el … bueno, ya entiendes la idea.

El desarrollo de back-end es campos verdes y cervezas frías en comparación con eso.

Lo mejor de Back-end es que puedes escribirlo en casi cualquier idioma que desees, y las API son generalmente geniales. Si desea utilizar Java y MySQL, consulte JDBC, es estable, bien documentado y bien diseñado.

Swift / Kitura se ve muy bien, Swift es un lenguaje encantador y Kitura es agradable y simple.

Con microservicios, puede mezclar y combinar si lo desea, escribir este bit en Go, ese bit en Python, no es gran cosa.

El back-end tiene muchas opciones, muchas buenas opciones, y es sensato .

No hay comparación , en el back-end, tiene su opción de grandes tecnologías, en el front-end, la elección está hecha para usted, y eligieron mal.

Hay una diferencia fundamental entre el software escrito para el front-end y el software escrito para el back-end. Se encuentra donde se ejecuta el software .

En el backend , el desarrollador también controla el entorno de implementación: en qué sistema operativo se ejecutará, qué tipo de recursos tendrá y en qué plataforma / idioma estará escrito. Eso significa que tiene total autonomía.

¿Quiere escribir python y ejecutarlo en máquinas Linux de alta memoria? No hay problema. Quiere escribir código C # y ejecutarlo en Windows, ¡adelante!

Usted controla dónde se ejecuta el código y necesita que se ejecute solo en ese entorno (incluso cuando obtiene código local y multi-nube, aún puede usar Docker para replicar esa ventaja).

En la parte frontal , escribe código que se ejecuta en máquinas de clientes, un entorno sobre el que no tiene control. Cada cliente tiene un conjunto de circunstancias muy diferente, que incluye:

  • Sistema operativo (iOS, Android, Mac OS, Linux, Windows) y versión del sistema operativo

  • Navegador (Chrome, IE, Edge, Opera, Firefox) y versión (cada uno tiene cientos de versiones)

  • Recursos disponibles (ancho de banda de internet, CPU, GPU, memoria)
  • Tamaño de pantalla (desde teléfonos inteligentes de 3.5 ″ hasta monitores de computadora 4K)
  • Configuración de seguridad (¿Flash habilitado? ¿Cookies? ¿Almacenamiento local?)
  • Y así sucesivamente y así sucesivamente…

Hay tantos millones de combinaciones de esas configuraciones, que puede estar bastante seguro de que su combinación es bastante exclusiva para usted (esa es la base para las huellas digitales del dispositivo. Haga clic aquí para ver cuán único es).

Al escribir aplicaciones web front-end, debe escribirlas de manera que funcionen de manera uniforme en todos esos entornos. Para mí esto es magia muy oscura.

El desarrollo web de extremo bancario no está tan roto como el desarrollo front-end.

Si últimamente ha trabajado en desarrollo web front-end, probablemente se haya dado cuenta de lo complicado que es todo. Desde lenguajes que se compilan sobre otros lenguajes hasta la cantidad ridícula de marcos que se publican todos los días. De hecho, probablemente ya estés luchando por mantenerte al día; Pero confía en mí. no estas solo. Echemos un vistazo a lo que está sucediendo y cómo llegamos aquí en primer lugar.

navegadores compatibles estándar

Firefox trató de arreglar las cosas, y lo hizo. El navegador de Mozilla era el navegador compatible más estándar que podía obtener en ese momento. Admitía tecnologías modernas como SVG y lienzo. Fue tan bueno que comenzó a ganar cuota de mercado, dejando atrás a IE. Chrome fue lanzado por Google y allí comenzó la era de la web moderna. Pero no tan rápido …

Lo que acabo de esbozar antes en unos pocos párrafos, sucedió entre 1995 y 2005. 10 años de Internet, obstaculizado por IE y su motor de renderizado. Pero bueno, en 2005 Internet ya estaba en todas partes. Entonces, ¿qué podrían hacer empresas como Google y Mozilla al respecto? Bueno, usa las tecnologías que ya estaban disponibles y mejoralas.

HTML

El lenguaje de marcado de hipertexto nació con Internet. No puedes decir “Internet” sin pensar en HTML, y si lo haces, no eres un desarrollador (¿ves lo que hice allí?). Este lenguaje es muy básico y le permite agregar y agrupar gráficamente las cosas que ve en un sitio web. Hay 5 versiones de HTML, siendo la más nueva compatible con IE9 (aunque no todas las características). La característica más importante de HTML5 es el “lienzo”, que permite a los desarrolladores dibujar cosas interesantes en un “lienzo” mediante el uso de JavaScript.

Durante la historia de Internet, HTML ha perdido algunas etiquetas (introducidas originalmente por IE), ha agregado otras nuevas, pero su núcleo no ha cambiado mucho. Se podría decir que fue una tecnología bien pensada desde el principio y se mantiene fiel a sus raíces.

CSS

Las hojas de estilo en cascada se inventaron en 1996, y déjenme decirles algo, desde entonces, no ha cambiado ni un poco. La idea detrás de CSS es permitir a los desarrolladores “diseñar” ese HTML y hacer que se vea mejor, más elegante y más bonito. No permite ninguna anidación, lógica, variables, no, nada de eso. En cambio, permite escribir reglas aburridas que apliques a cada etiqueta para que se vean diferentes. Cuando haya terminado, terminará con archivos grandes, difíciles de leer y dolorosos de mantener.

Exageré cuando dije que no ha cambiado un poco. Ha cambiado, por supuesto. El W3C ha incluido nuevas reglas, nuevas propiedades, soporte de animación, transformaciones 3D y muchos otros beneficios. Pero su núcleo, su estructura de reglas de un nivel es el mismo lenguaje lisiado que obtuvimos hace 18 años.

Debido a estas limitaciones, viene la gran variedad de herramientas de las que probablemente ya haya oído hablar: Brújula, SASS, MENOS, fuentes CSS, marcos CSS, etc. Todos tratan de arreglar lo que está roto con CSS y tratar de superar sus limitaciones para Permitir a los desarrolladores escribir código más inteligente y legible.

JavaScript

Lo ha tenido fácil si no se ha desarrollado en JavaScript moderno. JavaScript (JS) fue escrito por Brendan Eich en unas pocas semanas cuando trabajaba para Netscape. Dado que Netscape era el competidor directo de IE cuando Internet estaba en su infancia, Netscape empujó a JS hacia adelante al promover lo fácil que era aprenderlo. Luego Microsoft lo adoptó para IE y en 1996 se estandarizó como ECMASCript. Desde entonces, JS ha evolucionado lentamente, principalmente porque sus nuevas características no son ampliamente compatibles con todos los navegadores. Por ejemplo, ECMAScript 6, que se lanzará a mediados de 2015, ni siquiera es compatible en un 50% con Chrome o Firefox (en el momento de la redacción). Entonces, si desea escribir cosas complejas con JS, necesitará marcos y otros lenguajes que se compilen en JS.

jQuery fue uno de los primeros en ingresar al mercado JS Framework (junto con Mootools, Prototype y otros). Le permite escribir reglas simples que luego son procesadas por el motor jQuery y traducidas a vanilla JS (JavaScript puro). jQuery es tan popular que todavía se usa hoy en día. Sin embargo, los marcos más complejos se han unido a la fiesta, como Angular, Embed, Knockout, React, Backbone y podría seguir adelante. Se denominan marcos MV *, que intentan emular una práctica de codificación de desarrollo de back-end conocida como MVC (Model-View-Controller). Hay tantos de estos marcos, que hay un sitio web dedicado que intenta hacer un seguimiento de todos ellos.

Estos MV * no solo cambian constantemente, sino que no son fáciles de aprender. Su curva de aprendizaje te obligará a olvidar todo lo que sabes sobre otros frameworks y trabajar en un entorno obstinado de lo que los desarrolladores piensan que es correcto. Entonces, buena suerte tratando de aprenderlos a todos. Angular, el más famoso de todos, que fue adquirido por Google (no, Angular no fue inventado por Google) cambia tanto en cada versión principal que ha generado algunas preocupaciones en la comunidad.

Además de eso, debe saber lo que también le gusta (php, diferentes tipos de framework como bootstrap framework, Foundation framework), etc.

Después de haber pasado 6 años en el back-end y 5 en el front-end, no creo que puedas hacer un juicio definitivo de una forma u otra. Cuando trabaja con código o compañeros de trabajo que no pueden escribir código limpio, use convenciones de nombres crípticos, no organice activos o no siga los principios de mentalidad de equipo, entonces no importa si es front-end o back-end. Esos problemas son posibles y realmente probables en ambos casos. Si vives en un mundo donde todos hacen bien lo anterior (¡ja!), Entonces hay algunas distinciones relacionadas en gran medida con las diferencias en el apoyo ambiental.

  1. Front End tiene que evolucionar rápidamente con compatibilidades diversas y cambiantes de navegador y dispositivo, mientras que el desarrollo de backend es bastante inmune a esos cambios. Solo actualiza su código BE cuando USTED decide cambiar los entornos del servidor o cambiar el idioma / marco de su elección. Es posible que el backend deba evolucionar con problemas de seguridad, pero estos problemas rara vez tienen un efecto dramático en el código común.
  2. Los idiomas BE son ciertamente más estables y poderosos. Pero eso tiene sentido cuando los idiomas BE solo tienen que preocuparse por un entorno y tener acceso directo a bases de datos y un número infinito de herramientas de software. Los idiomas FE deben ser considerados con los cambios en un par de docenas de entornos diferentes.
  3. Los desarrolladores de FE deben admirar nuevos y emocionantes avances de código y esperar años hasta que realmente sean compatibles en el extranjero.
  4. Herramientas de solución de problemas: Sí, Javascript tiene herramientas de solución de problemas terribles en comparación con prácticamente cualquier otro idioma. Pero, de nuevo, las herramientas de solución de problemas son específicas de cada navegador o dispositivo. Por lo tanto, no tener una herramienta universal no es una sorpresa.
  5. Supongo que si usted o su empresa están interesados ​​en usar las funciones FE más recientes y excelentes y tienen que escribir líneas de código excesivas para hacer que el nuevo código sea compatible con versiones anteriores, entonces sí, el desarrollo FE es, con mucho, el mayor desastre. Pero tiendo a adoptar un enfoque más conservador y no trato de ofrecer características del sitio web que no son compatibles con la gran mayoría de los navegadores.

Si puede ser conservador en sus ambiciones de Front End, entonces no creo que el desarrollo de FE sea en absoluto un desastre mayor. De ninguna manera lo considero roto.

Ahora, si quieres hablar sobre el desarrollo del correo electrónico, ¡sí! ¡es un desastre! ¡esta roto! Es el salvaje oeste salvaje y todos deberían huir asustados.

El backend está fragmentado en 2 sistemas operativos, al menos 20 idiomas, cada uno tiene de 2 a 10 marcos principales, innumerables bibliotecas, que las opciones de base de datos y nosql, proveedores de nube, proveedores de virtualización y contenedores y muchos más tecnología de la semana.

BE no es más fácil, solo más maduro. Stuf como mysql, java y php existen desde 1995. Javascript es un lenguaje en construcción.

El back-end tiene un trabajo: crear una base de datos normalizada. Se trata de una herramienta, un idioma y un editor de texto básico.

La tecnología de back-end tiene una vida útil mucho más larga que los lenguajes y marcos de front-end. Hubo algunos primeros ganadores claros que fueron ampliamente adoptados y no han sido derrocados.

Estoy descontando la supervisión del rendimiento, la seguridad, el DR y los matices del trabajo de back-end. Pero solo hacer una base de datos que pueda soportar una aplicación es aproximadamente el 3% (o menos) del trabajo involucrado en la creación de una aplicación.

No, no por mucho!

Nunca dejo de sorprenderme por la mezcolanza oportunista, de crecimiento orgánico, hinchada de lo que comúnmente se llama “tecnología” front-end.