La discusión de los resultados del año en la interfaz de repente se convirtió en el tema de discusión . Agregaré mi opinión y me alegrará escuchar la opinión de otros.
Me parece que tiene sentido hablar de lo que está sucediendo en la web moderna, se percibe desde afuera y adentro es completamente diferente. Sí, y "dentro" tiene varios niveles. La vista "complican nuevamente el diseño" es absolutamente correcta por un lado, y errónea y depravada por el otro, pero la vista "no nos impiden construir abstracciones" también es ineficaz.
Cuando alguien se queja de que la web moderna se ha vuelto demasiado complicada, cada vez que quiero recordarle a esta persona que esta web moderna confía su dinero en bancos en línea y formularios de compra, correspondencia personal en redes sociales y versiones web de mensajería instantánea, y archivos personales en las nubes. Y lo más probable es que realmente quiera que el proceso de desarrollo de estos sistemas sea complejo, difícil, pero confiable y que no falle.
fuente de imagen
Bajo la interfaz moderna y sus amigos ahora entienden mucho más de lo que parece desde el exterior. Estos son sitios web clásicos y SPA, y aplicaciones en el electrón, y aplicaciones móviles en cordova, NativeScript, React Native e incluso en Flutter. Esta es una infraestructura compleja con CDN, servicios geocentralizados, chatbots en JS e incluso herramientas de aprendizaje automático para optimizar el ensamblaje e incluso la generación de diseño .
Y en la web misma, aparecen soluciones monstruosamente complejas que anteriormente podían funcionar exclusivamente en modo de escritorio. Yo mismo tuve hace un par de años para tocar el desarrollo de un navegador genoma completo en el navegador: estaba comprometido a proporcionar rendimiento y 60FPS, que era un problema lo suficientemente grande pero solucionable. Incluso hace 5 años, nadie podría haber pensado que el navegador del genoma no podría ser algo instalado en una computadora poderosa, y esta solución permitió a los médicos e investigadores trabajar con el genoma incluso desde una tableta o computadora portátil liviana.
Por qué
Por el momento, el paquete HTML + CSS + JS es uno de los más potentes en términos de creación de interfaces, no solo por sus capacidades, sino también por la cantidad de soluciones integradas: marcos CSS, bibliotecas de componentes visuales, interfaces para una gran cantidad de servicios y SAAS . En términos de eficiencia en las horas de desarrollo para el público potencial y la accesibilidad, las tecnologías web están por delante de las soluciones móviles y de escritorio. Y ahora se ha dividido en tres áreas:
- Desarrollo de sitios totalmente estáticos y casi estáticos con contenido parcialmente dinámico (galerías, ventanas emergentes, etc.)
- Desarrollo de aplicaciones web "clásicas" en frameworks de servidor (django, rails)
- Desarrollo de clientes web
Y cada uno de ellos tiene una especificidad completamente diferente.
El desarrollo de JS fue realmente doloroso, por lo que comenzaron a aparecer soluciones que resolvieron este dolor.
Si los mira, puede ver algo muy interesante: primero, comenzaron a aparecer soluciones como jQuery y CoffeeScript, lo que reduce la redundancia y la verbosidad del lenguaje. Pero rápidamente se desvanecieron, y en su lugar aparecieron herramientas que permitieron reutilizar el código de la manera más eficiente posible, detectar errores estáticos y construir abstracciones efectivas, "ocultando" niveles individuales de complejidad detrás de interfaces simples y bien descritas.
Aparece GraphQL, que resuelve problemas con la complejidad de describir, documentar y mantener REST. TypeScript y Flow aparecieron, lo que resolvió los problemas de falta de escritura. Han aparecido nuevas entidades de lenguaje que le permiten trabajar eficazmente con operaciones asíncronas, clases y flujos de datos. WebAssembly ha aparecido, lo que le permite reutilizar el código de otros idiomas y hacerlo rápidamente.
Todas estas soluciones están dirigidas a lo mismo: reutilizar el código y el potencial para construir equipos "planos". Resuelven el problema para tomar el código de otra persona y comenzar a usarlo.
Esta es una clara evidencia de que la web se está desarrollando para trabajar en equipos grandes, se ha convertido en una plataforma para soluciones "para adultos".
Una serie de eventos que sucedieron se convirtieron en evidencia aún más clara: React Native, NativeScript, Dart + Flutter y otras soluciones para reutilizar código en plataformas nativas aparecieron. Este es un punto muy importante: debido a la falta de la capacidad de usar otros idiomas en la web, las empresas comenzaron a ajustar sus procesos en busca de una "bala de plata" que les permitiera reducir de ninguna manera los pequeños costos de desarrollo y el tiempo para ofrecer nuevas funcionalidades a todos los clientes. Es importante que cualquier proyecto sea rápido, y especialistas de alto nivel comenzaron a unirse en busca de la oportunidad de trabajar de manera efectiva en JS.
Por cierto, por la misma razón, los motores de plantillas comenzaron a morir parcialmente: el uso de una semántica más resultó ser menos efectivo que usar HTML familiar con pequeñas extensiones en JS (Angular, Vue) o usar solo un lenguaje para describir el diseño (React, Flutter). La incapacidad de expandirse, la necesidad de introducir a los desarrolladores a un nuevo lenguaje, el riesgo de muerte de la plataforma, la descentralización condujeron al hecho de que comenzaron a preferir los templadores de framework que intentaban estar lo más cerca posible de las plataformas HTML / DOM.
Sin embargo, además de escribir código de manera eficiente, también hay un "coeficiente" para sincronizar un comando. Si el lenguaje le permite trabajar súper rápido, pero al mismo tiempo sincronizar una función individual entre dos desarrolladores crea un dolor terrible, lo más probable es que siga siendo un nicho. Por lo tanto, muchas de las características y soluciones del lenguaje están dirigidas específicamente a reducir los problemas con la sincronización y la ausencia de problemas. Reducen este "coeficiente", que indica cuántos juniors pueden controlar simultáneamente el medio y cuántos middles puede controlar el desarrollador principal. De los últimos ejemplos de tales características, las importaciones de es6 resuelven parcialmente el problema de dependencia cíclica, mientras que más bonito le permite obtener la fusión esperada y adecuada en el código git, independientemente de cómo lo escriba el desarrollador. No debe ser hermoso, debe estar bien sincronizado.
Y como resultado, en pocos años, la web como plataforma ha sido asumida por grandes empresas y equipos serios, por lo que la mayoría ha experimentado la "fatiga de JavaScript" . Por cierto, el principal reclamo al casi monopolio de Google en la web representado por Chromium radica en el hecho de que empujan lo que necesitan a las capacidades de la plataforma web y JS (aunque esto generalmente coincide con lo que la mayoría de las empresas necesitan).
Como resultado, por un lado, obtuvimos una plataforma absolutamente encantadora para el código reutilizado en todas partes, sintaxis que le permite trabajar con grandes comandos planos. Pero ...
Todo se volvió complicado y todos se confundieron
Y nadie entendió qué hacer. ¿Cuál es, de hecho, el problema? En esas tres categorías diferentes.
- Desarrollo de sitios totalmente estáticos y casi estáticos con contenido parcialmente dinámico: este tipo de aplicación se caracteriza por HTML como punto de entrada, velocidad máxima de descarga y JS opcional
- Desarrollo de aplicaciones web "clásicas" en marcos de servidores (django, rails): estas soluciones se caracterizan actualmente por cargar con HTML como punto de entrada, pero en lugar de la velocidad máxima de descarga, se centran en la reutilización de código, DRY y la integración de backend. El código JS se genera parcialmente por el marco (notificaciones, formularios, enlaces turbo, etc.), en parte, debe escribir usted mismo
- Desarrollo de aplicaciones cliente web. Aquí sucede lo inesperado: HTML en lugar de un punto de entrada se convierte en un manifiesto de aplicación y una plataforma de representación, y JS se convierte en un "punto de entrada".
¿Qué quiero decir con un punto de entrada? Esta es una determinada entidad, cuya carga es igual a la entrega mínima al usuario del producto. Si el usuario necesita mostrar la información, entonces necesitamos HTML + CSS, si ejecutamos la aplicación, necesitamos JS que se ejecute desde HTML.
Y para confundir a todos por completo, apareció una cuarta categoría:
Aplicaciones isomorfas
Bajo "isomorfo" en desarrollo web generalmente significa algo que funciona tanto en el servidor como en el cliente. En este modo, las aplicaciones en react, angular, vue.js pueden funcionar, hay marcos prefabricados : Next y Nuxt , por ejemplo.
Ambas tareas son relevantes para ellos: la aplicación web debe entregar su estado inicial al usuario lo más rápido posible y actuar como una aplicación. En otras palabras, deben entregar tanto HTML como JS como dos puntos de entrada, uno para el contenido y otro para la aplicación. Esto crea dos párrafos en conflicto: por un lado, la cantidad de datos entregados debe ser mínima, por otro lado, se necesita reutilizar el código. Para JS, esto se resuelve mediante fragmentos de paquete web, división de código y carga dinámica de código, las plantillas que quedan para JS, pero CSS aún permanece. Y lo más importante: no queremos entregar un solo byte adicional al usuario. Y luego a alguien se le ocurrió la idea: tales aplicaciones realmente tienen dos puntos de entrada. Se pueden procesar como dos entidades autónomas.
A partir de esto, nació el concepto CSS-in-JS, centrándose en dos procesos separados: generar un archivo CSS para contenido estático y guardar estilos junto a los componentes.
Todo le queda a JS.
Ahora en JS puede encontrar estilos, diseño y el código real.
Ahora todo está en js y eso es bueno
Vale la pena hacer otra digresión, ahora al lado del supermercado.
Es importante que cualquier producto en el desarrollo o desarrollo pueda "moverse" en la otra dirección. Actúa en cualquiera de los niveles:
La capacidad de convertir un componente visual en un componente con una lógica mínima agregando una línea de código es genial. La necesidad de reescribirlo desde cero no es genial.
Hacer que sea barato convertirse en una aplicación SPA o del lado del servidor es realmente genial, pero rara vez es posible. Es más sabio, si no impone costos, comenzar desde el principio con dicha plataforma.
Por lo tanto, casi cualquier proyecto web que tenga el riesgo de que deba procesarse en el servidor, el riesgo de que sea necesario refactorizar componentes, pasar de un motor de plantillas a otro, intenta evitar riesgos.
Cuando hay una única plataforma dentro de la cual algunas entidades pueden convertirse en otras de manera bastante económica, el desarrollo es muy rápido.
En el caso de una aplicación en angular / react / vue, esto es exactamente así. Son difíciles de entender. No es tan complicado como Angular 1, por supuesto, pero de todos modos: el camino para comprenderlos es largo, y los cursos en línea de seis meses no son suficientes para comprenderlos. Pero brindan la oportunidad de hacer en pocas horas lo que se hizo varias semanas antes, y en pocos días, lo que solía llevar varios meses.
Sin embargo, lo contrario también es cierto: muchos no los necesitan, pero se usan porque está "de moda".
Cuando el arquitecto de infraestructura del grupo de aplicaciones web y móviles y el diseñador de diseño estén hablando, será muy difícil para ellos. Ahora, estas son direcciones tan diferentes que no tendrán intersecciones en el conocimiento, a excepción de JS.
La próxima vez que quiera decir "la web se ha vuelto muy compleja e hinchada", piense en lo difícil que es diseñar y crear un cliente de correo de bandeja de entrada de Google (con entidades inteligentes que se incluyen según la letra), un IDE web como Cloud9 o banca por Internet .
Pero si un codificador se acerca a usted y comienza a hablar sobre el hecho de que necesita reaccionar, porque necesita una mecanografía estricta y decoradores para el diseño de la página de destino, no sucumbas a la persuasión.