El desarrollo web se está volviendo demasiado complejo y puede ser culpa nuestra

 

 

 

  • Typography Masterclass, with Elliot Jay Stocks
  • Register!

  • Índice
    1. Como era antes
    2. Marcos de JavaScript
    3. Las pilas se hacen más grandes
    4. ¿Necesitamos un marco de JavaScript para todo?
    5. Saber todo y nada al mismo tiempo
    6. Las consecuencias del bloqueo de proveedores
    7. Cada solución introduce un nuevo problema
    8. ¿Cómo podemos simplificar nuestras bases de código?

    Una abrumadora cantidad de marcos y herramientas disponibles en la actualidad da la impresión de que el desarrollo web quizás se haya vuelto demasiado complejo. Como recién llegado, puede resultar aterrador tener tantos para considerar, casi creando el miedo a perderse algo que vemos explotado para vender cursos y tutoriales sobre el nuevo marco de trabajo sin el cual “no se puede trabajar”. ¿Pero tal vez eso sea sólo una exageración? Juan Diego Rodríguez explora esas afirmaciones y descubre si el desarrollo web realmente es tan complejo y, lo más importante, cómo podemos evitar que se vuelva aún más difícil de lo que ya percibimos.

     

    El desarrollo front-end parecía más sencillo a principios de la década de 2000, ¿no? El sitio web estándar constaba principalmente de páginas estáticas hechas de HTML y CSS sazonadas con una pizca de JavaScript y jQuery. Quiero decir, ¿quién no se pierde los días de compatibilidad entre navegadores, verdad?

    Un avance rápido hasta el día de hoy, y parece que se está desarrollando un universo paralelo con una cantidad abrumadora de opciones. ¿Qué marco debería utilizar para un nuevo proyecto? ¿Quizás otros más establecidos como React, Angular, Vue, Svelte o quizás el nuevo que salió el mes pasado? Cada marco viene con su ecosistema único. También debe decidir si utilizar TypeScript en lugar de JavaScript básico y elegir cómo abordar la representación del lado del servidor (o la generación de sitios estáticos) con metamarcos como Next, Nuxt o Gatsby. Y no podemos olvidarnos de las pruebas unitarias y de un extremo a otro si desea una aplicación web sin errores. ¡Y apenas hemos arañado la superficie del ecosistema front-end!

    ¿ Pero realmente se ha vuelto más complejo crear sitios web? Muchos de los marcos y herramientas que utilizamos hoy en día se diseñaron originalmente para proyectos masivos. Como recién llegado, puede resultar aterrador tener tantos para considerar, casi creando el miedo a perderse algo que vemos explotado para vender cursos y tutoriales sobre el nuevo marco de trabajo sin el cual “no se puede trabajar”.

     

    Todo esto da la impresión de que el desarrollo web se ha vuelto quizás demasiado complejo. ¿Pero tal vez eso sea sólo una exageración? En este artículo, quiero explorar esas afirmaciones y descubrir si el desarrollo web es realmente tan complejo y, lo más importante, cómo podemos evitar que se vuelva aún más difícil de lo que ya percibimos.

    Como era antes

    Como alguien que se dedicó al desarrollo web después de 2010, no puedo dar testimonio de mi propia experiencia sobre cómo fue el desarrollo web desde finales de los años 1990 hasta los años 2000. Sin embargo, incluso hace quince años, aprender a desarrollar front-end era infinitamente más sencillo, al menos para mí. Podrías comenzar un sitio web con páginas HTML estáticas, CSS mínimo para diseñar y una pizca de JavaScript (y tal vez un toque de jQuery) para agregar funciones interactivas, desde barras laterales alternadas hasta carruseles de imágenes y otros patrones. No se esperaba mucho más de un desarrollador promedio más allá de eso; todo lo demás se consideraba "hacer un esfuerzo adicional". Por supuesto, las increíbles funciones nativas de CSS y JavaScript que tenemos hoy no existían en aquel entonces, pero también eran innecesarias para lo que se consideraba una mejor práctica en los últimos años.

    Ciertamente, en aquel entonces existían aplicaciones web grandes y dinámicas (YouTube y Facebook, por nombrar algunas), pero fueron desarrolladas por empresas gigantes. No se esperaba que nadie recreara ese tipo de proyecto por su cuenta o incluso con un pequeño equipo. Esa habría sido la excepción y no la norma.

    Recuerdo que en aquel entonces tiendo a preocuparme más por cosas como SEO y optimización de la página que por cómo estaba configurado mi IDE, pero solo hasta el punto de agregar metaetiquetas y palabras clave porque las mejores prácticas no incluían minimizar todos sus activos, tres sacudir su código. , almacenar en caché su sitio en CDN perimetrales o representar su contenido en el servidor (un problema creado por los marcos modernos junto con la hidratación ). Otros factores como la accesibilidad, la experiencia del usuario y los diseños responsivos también se pasaron por alto en comparación con los estándares actuales. Ahora, se analizan en profundidad y se utilizan para mejorar las puntuaciones de Lighthouse e impresionar los algoritmos de los motores de búsqueda.

    La web y todo lo que la rodeaba cambió a medida que se agregaron más capacidades y cada vez más personas dependieron de ella. Hemos creado nuevas soluciones, nuevas herramientas, nuevos flujos de trabajo, nuevas funciones y cualquier otra cosa nueva que sea necesaria para atender una web más grande con necesidades aún mayores.

    La web siempre ha tenido problemas en el pasado que eran dignos de solución: no extraño en absoluto las tablas y los diseños flotantes, junto con la manipulación desordenada del DOM. Esta publicación no pretende arrojar sombra sobre los nuevos avances mientras se muestra nostálgico por los buenos días de la "vieja red salvaje". Al mismo tiempo, sin embargo, los problemas de ayer parecen infinitamente más simples que los que enfrentamos hoy.

     

    Marcos de JavaScript

    Los frameworks JavaScript, como Angular y React, fueron creados por Google y Facebook, respectivamente, para ser utilizados en sus propios proyectos y satisfacer las necesidades que sólo tienen las grandes empresas basadas en la web como ellas. Ahí radica el principal problema de la complejidad web: los marcos de JavaScript se crearon originalmente para sostener proyectos gigantes en lugar de proyectos más pequeños . Muchos desarrolladores subestiman enormemente la cantidad de tiempo que lleva crear una base de código que sea confiable y mantenible con un marco de JavaScript. Sin embargo, la alternativa de usar JavaScript básico era peor y jQuery se quedó corto para la tarea. Vanilla JavaScript tampoco pudo evolucionar lo suficientemente rápido para satisfacer nuestras necesidades de desarrollo, que cambiaron de simples sitios web informativos a aplicaciones dinámicas. Por lo tanto, muchos de nosotros hemos adoptado rápidamente marcos para evitar mezclarnos directamente con JavaScript y su complicada manipulación DOM.

    El desarrollo back-end es un tema completamente diferente, sujeto a sus propias complejidades. Sólo quiero centrarme en el desarrollo de front-end porque es la disciplina que quizás más ha sobrepasado sus límites al fusionarse con las preocupaciones tradicionales de back-end.

    Las pilas se hacen más grandes

    Era lógico que los marcos de JavaScript crecieran en tamaño con el tiempo. La web es un lugar grande y ningún marco puede cubrirlo todo. Pero lo intentan y la complejidad, a su vez, aumenta. El tamaño de un marco parece tener una correlación uno a uno con su complejidad.

    Pero el marco central es sólo una parte de una aplicación web. Varias otras tecnologías conforman lo que se conoce como una “pila” tecnológica, y a medida que la web gana más usuarios y marcos que satisfacen sus necesidades, las pilas tecnológicas son cada vez más grandes. Es posible que haya visto pilas populares como MEAN (MongoDB, Express, Angular y Node) o sus variantes React (MERN) y Vue (MEVN). Estas pilas se comercializan como cimientos maduros y probados, adecuados para cualquier proyecto inicial. Eso significa que el tamaño anunciado de un marco central se subestima enormemente porque dependen de otros micromarcos para garantizar arquitecturas altamente confiables, como se puede ver en stackshare.io . Además, no existe una pila única para todos; la mejor herramienta siempre ha dependido (y seguirá dependiendo) de las necesidades y objetivos de su proyecto particular.

    Esto significa que cada nuevo proyecto probablemente requiera una arquitectura única para cumplir con sus requisitos. Las empresas de tecnología gigantes necesitan arquitecturas colosales en todos sus proyectos, y sus pilas están altamente diseñadas en consecuencia para garantizar la escalabilidad y el mantenimiento. También tienen bases de clientes enormes, por lo que mantener una base de código grande será más fácil con más ingresos, más ingenieros y una imagen más clara del problema. Para minimizar el desperdicio, las pilas de tecnología de las empresas y proyectos más pequeños pueden y deben minimizarse no sólo para que coincidan con la escala de sus necesidades sino también con las capacidades de los desarrolladores del equipo.

     

    La idea de que el desarrollo web se está volviendo demasiado complejo proviene de la creencia de que todos tenemos las mismas necesidades y recursos que las empresas gigantes.

    Intentar imitar sus megastacks no tiene sentido. Algunos podrían argumentar que es un sacrificio que debemos hacer para la escalabilidad y el mantenimiento futuros, pero primero debemos centrarnos en crear sitios excelentes para el usuario sin preocuparnos por las características que los usuarios puedan necesitar en el futuro. Si lo que estamos construyendo vale la pena, llegará al punto en que necesitemos esas arquitecturas gigantes a su debido tiempo. Cruza ese puente cuando lleguemos allí. De lo contrario, no es diferente a usar zapatillas de deporte del tamaño de Shaquille O'Neal con la esperanza de que le crezcan. ¡Es posible que ni siquiera duren hasta entonces, si es que sucede!

    Debemos recordar que la experiencia del usuario final es el foco al final del día, y a los usuarios no les importa ni saben qué pila usamos en nuestras aplicaciones . Lo que les importa es un sitio web atractivo y útil donde puedan lograr lo que vinieron a buscar, no la tecnología que utilizamos para lograrlo. Así es como he llegado a creer que el desarrollo web no se está volviendo más complejo. Son los desarrolladores como nosotros quienes lo perpetuamos al comprar soluciones para problemas que no necesitan resolverse a cierta escala.

    Permítanme ser muy claro: no estoy diciendo que el desarrollo web actual sea del todo malo. De hecho, hemos descubierto muchas funciones excelentes y muchas de ellas se deben a los marcos de JavaScript que han impulsado ciertas funciones. jQuery tuvo la misma influencia en JavaScript durante muchos, muchos años.

    Todavía podemos crear productos mínimos viables hoy con recursos mínimos. No, es posible que no hagan que la gente presione el botón Me gusta en tus publicaciones sociales, pero cumplen con los requisitos, nada más y nada menos. ¡Queremos más grande! ¡Más rápido! ¡Más económico! Pero no podemos tener los tres.

    En todo caso, el desarrollo front-end se ha vuelto mucho más fácil gracias a características modernas que resuelven problemas de desarrollo antiguos, como la forma en que CSS Flexbox y Grid han trivializado diseños que solían requerir trucos complejos que involucraban flotantes y tablas. Es lo mismo que JavaScript obtenga nuevas formas de crear interacciones que solían requerir soluciones inteligentes o código obtuso, como tener la API Intersection Observer para trivializar cosas como la carga diferida (aunque HTML también ha ganado sus propias características en esa área ).

     

    Vivimos en esta tensión entre la facilidad de las nuevas funciones de la plataforma y la complejidad de nuestras pilas.

    ¿Necesitamos un marco de JavaScript para todo?

    Cada proyecto, independientemente de su simplicidad, necesita desesperadamente un marco de JavaScript. Un proyecto sin un marco complejo es como servir caviar en un plato de papel.

    Al menos eso es lo que todo el mundo parece pensar. ¿Pero es eso realmente cierto? Yo diría lo contrario. Los marcos de JavaScript se utilizan mejor en aplicaciones más grandes. Si está trabajando en un proyecto más pequeño, un marco basado en componentes sólo complicará las cosas, haciéndole dividir su sitio web en una jerarquía de componentes que resulta excesivo para proyectos pequeños.

    La idea de necesitar un marco para todo ha sido enormemente sobrevendida. Tal vez no directamente, pero inconscientemente tienes esa sensación cada vez que aparece el nombre de un marco, como expresa elocuentemente el ingeniero de Edge Alex Russell en su artículo, " The Market For Lemons ":

    “Estas tecnologías se lanzaron inicialmente sobre la base de “mejores experiencias de usuario”, pero no han cumplido por completo esa promesa fuera de las organizaciones de alta madurez gerencial en las que nacieron. Trasplantadas a la web en general, estas nuevas pilas han demostrado ser un fracaso costoso”.

    —Alex Russell

    Recuerde, el propósito de un marco es simplificar su vida y ahorrar tiempo . Si el proyecto en el que está trabajando es más pequeño, el tiempo que supuestamente ahorra probablemente se vea eclipsado por el tiempo que dedica a configurar el marco o a hacerlo funcionar con el resto del proyecto. Un marco puede ayudar a que las aplicaciones web más grandes sean más interactivas y dinámicas, pero hay ocasiones en las que un marco es una solución de mano dura que en realidad genera flujos de trabajo ineficientes e introduce deuda técnica.

    Da un paso atrás y piensa en esto: ¿Son suficientes HTML, CSS y un toque de JavaScript para crear tu sitio web o aplicación web? Si es así, quédate con esos. Lo que temo es agregar complejidad por la complejidad y sin querer levantar la barrera de entrada para quienes ingresan al desarrollo web. Todavía podemos lograr mucho solo con HTML y CSS, gracias nuevamente a muchos avances en la última década. Pero damos la impresión de que no son adecuados para el consumo web actual y que es necesario mejorarlos. Nicotine Pouch Guide - Everything About Nicotine Pouches

    Saber todo y nada al mismo tiempo

    El estándar percibido de que los equipos deben adoptar arquitecturas centradas en el marco supone una carga no sólo para el proyecto en sí sino también para el bienestar del desarrollador. Como se mencionó anteriormente, la mayoría de los equipos no pueden permitirse esas arquitecturas y solo tienen unos pocos desarrolladores para mantenerlas. Si socavamos lo que se puede lograr solo con HTML y CSS y establecemos las expectativas de que cualquier proyecto, independientemente de su tamaño, debe tener una pila de vanguardia , entonces el peso para cumplir esas expectativas recae sobre los hombros del desarrollador, con la gran responsabilidad de ser competente en todas las áreas, desde el servidor y la base de datos hasta el front-end, el diseño, la accesibilidad, el rendimiento, las pruebas, y eso no se detiene. Es lo que ha estado impulsando "La Gran División" en el desarrollo front-end , que Chris Coyier explica así:

     

    “La división se produce entre personas que se identifican a sí mismas como (o tienen el puesto de trabajo de) desarrollador front-end pero que tienen conjuntos de habilidades divergentes. Por un lado , un ejército de desarrolladores cuyos intereses, responsabilidades y habilidades giran en gran medida en torno a JavaScript. Por otro lado , un ejército de desarrolladores cuyos intereses, responsabilidades y habilidades se centran en otras áreas del front-end, como HTML, CSS, diseño, interacción, patrones, accesibilidad, etc.

    - Chris Coyier

    Bajo estas expectativas, los desarrolladores que se centran más en HTML, CSS, diseño y accesibilidad que en la última tecnología se sentirán menos valorados en una industria que parece elogiar a quienes se preocupan por la pila. ¿Qué estamos diciendo exactamente cuando empezamos a dividir responsabilidades en términos de “desarrollo completo” o términos absurdos como “desarrollo 10x”? Hace un tiempo, Brad Frost comenzó a distinguir estas divisiones como “front-of-front-end” y “back-of-front-end” .

    Mandy Michael explica el impacto que ha tenido la búsqueda del "full-stack" en los desarrolladores que intentan mantenerse al día:

    “La peor parte de impulsar la mentalidad de “saberlo todo” es que terminamos creando una industria llena de profesionales que sufren agotamiento y enfermedades mentales. Tenemos gente hablando en conferencias sobre bienestar, síndrome del impostor y ansiedad total, pero a pesar de eso, perpetuamos esta idea de que la gente tiene que saberlo todo y ser increíble en ello”.

    — Mandy Michael

    Este no es el único síntoma de la adopción de soluciones estrictas para lo que HTML, CSS y JavaScript “básicos” ya manejan bien. A medida que crecen las expectativas sobre lo que podemos hacer como desarrolladores de aplicaciones para el usuario, también crece la curva de aprendizaje del desarrollo de aplicaciones para el usuario. Una vez más, no podemos aprender y saberlo todo en esta vasta disciplina. Pero nos decimos a nosotros mismos que tenemos que hacerlo, y gracias a esta mentalidad, desafortunadamente es común ver a desarrolladores que pueden ser extremadamente competentes con un marco en particular pero que en realidad saben y entienden poco de la plataforma web en sí, como la semántica y la estructura HTML.

    ( Vista previa grande )

    El hecho de que muchos desarrolladores en ciernes tiendan a saltar directamente a los marcos a expensas de comprender los conceptos básicos de HTML y CSS no es una preocupación nueva, como explicó Rachel Andrew en 2019 :

    “Ese es el verdadero punto de entrada aquí, y sí, en 2019 tendrán que pasar rápidamente a las herramientas y técnicas que los harán empleables, si ese es su objetivo. Sin embargo, esas herramientas al final generan HTML y CSS. Es la base de todo lo que hacemos, lo que hace que la devaluación de quienes tienen habilidades realmente profundas en esas áreas sea mucho más desconcertante”.

     

    —Raquel Andrés

    Y quiero aclarar una vez más que los marcos y bibliotecas de Javascript modernos no son intrínsecamente malos; simplemente no están diseñados para reemplazar la plataforma web y sus estándares . ¡Pero seguimos presionándolos como queremos!

    Las consecuencias del bloqueo de proveedores

    La “dependencia del proveedor” ocurre cuando dependemos demasiado de productos y servicios propietarios hasta el punto de que cambiar a otros productos y servicios se convierte en una tarea casi imposible. Esto suele ocurrir cuando los servicios en la nube de una empresa en particular están profundamente integrados en un proyecto. Es un problema, especialmente en la computación en la nube, ya que mover las bases de datos una vez configuradas es costoso y largo.

    La dependencia del proveedor en el desarrollo web se ha restringido tradicionalmente al back-end, como ocurre con los servicios en la nube como AWS o Firebase; Mientras tanto, el marco frontal era una preocupación completamente separada. Dicho esto, he notado una tendencia reciente en la que la dependencia de los proveedores también está llegando a los metamarcos . Dado que las empresas detrás de ciertos metamarcos ofrecen servicios de hosting para sus propios productos, cambiar de host es cada vez más difícil (ya sea que el bloqueo esté diseñado intencionalmente o no). Por supuesto, será más probable que las empresas y los desarrolladores elijan el servicio de alojamiento de la empresa que creó un marco particular utilizado en sus proyectos: ¡son los expertos! – pero eso sólo aumenta la dependencia del proyecto de esos proveedores y sus servicios.

    Un claro ejemplo es la relación entre Next y Vercel, el servicio en la nube matriz de Next. Con el lanzamiento de Next 13, se ha vuelto cada vez más difícil configurar un proyecto Next fuera de Vercel, lo que ha llevado a proyectos como Open Next , que dice en su sitio web que “si bien Vercel es excelente, no es una buena opción”. si toda su infraestructura está en AWS. Alojarlo en su cuenta de AWS facilita la integración con su backend [sic]. Y es mucho más barato que Vercel”. Afortunadamente, se han escuchado las preocupaciones de los desarrolladores y Next 14 aporta claridad sobre cómo autohospedar Next en un servidor Node.

    Otro ejemplo es Gatsby y Gatsby Cloud . Gatsby siempre ha ofrecido guías útiles y recomendaciones de alojamiento alternativo, pero desde el lanzamiento de Gatsby Cloud en 2019, el marco principal se ha optimizado para que el uso de Gatsby y Gatsby Cloud juntos no requiera configuraciones de alojamiento adicionales. Eso es fantástico si adopta ambos, pero no es tan bueno si todo lo que necesita es uno u otro porque integrar el marco con otros hosts (y viceversa) es simplemente más difícil. Es como si te penalizaran por elegir.

    Y no olvidemos que ningún equipo esperaba que Netlify adquiriera Gatsby Cloud en febrero de 2023 . Este es un caso excelente en el que el problema de la dependencia del proveedor afecta a todos porque la conversión de un sitio a otro tiene un costo. A algunos equipos se les cobró un 120 % más después de realizar la conversión de Gatsby Cloud a Netlify, ¡incluso con el mismo plan que tenían con Gatsby Cloud!

     

    ¿Cual es la solución? La respuesta común que escucho es dejar de usar servicios pagos en la nube en favor de alternativas de código abierto. Si bien esto es excelente y, de hecho, una opción viable para algunos proyectos, no toma en cuenta que un proyecto de código abierto puede no cumplir con los requisitos necesarios para una aplicación determinada .

    E incluso entonces, el software de código abierto depende de la comunidad de desarrolladores que mantienen y actualizan el código base con poca o ninguna remuneración a cambio. Además, el código abierto es igualmente propenso a encerrarlo en ciertas soluciones diseñadas para resolver una deficiencia del software.

    Por supuesto, hay marcos y bibliotecas que no corren peligro de ser abandonados. React es un gran ejemplo porque tiene una comunidad activamente comprometida detrás. Pero no puedes tener la misma seguridad con cada nueva dependencia que agregas a un proyecto. No podemos simplemente seguir instalando más paquetes y componentes cada vez que detectamos un punto débil en la cadena de dependencia, especialmente cuando un proyecto se adapta perfectamente a una arquitectura menos compleja que aprovecha adecuadamente la plataforma web.

    Elegir tecnología para tu pila es un ejercicio de elegir tu propio veneno. Elija un servicio pago y estará sujeto a la dependencia del proveedor en el futuro, o elija uno de código abierto y ore para que la comunidad continúe manteniéndolo.

    Esas son prácticamente las dos únicas opciones. Muchos de los equipos que conozco o en los que he trabajado dependen de servicios de terceros porque no pueden darse el lujo de desarrollarlos por su cuenta; ese es un lujo que sólo las grandes empresas pueden permitirse. Es un problema que tenemos que afrontar al iniciar un nuevo proyecto, pero que podemos minimizar reduciendo el número de dependencias y eligiendo sabiamente cuando sea necesario.

    Cada solución introduce un nuevo problema

    ¿Por qué exactamente las pilas de desarrollo modernas se han vuelto tan grandes y complejas? Podemos señalar con el dedo la “paradoja del desarrollo”. Con cada nuevo marco o biblioteca, surge un nuevo problema y los desarrolladores, faltos de tiempo, pasan meses desarrollando una nueva herramienta para resolver ese problema. Y cuando no haya ningún problema, no se preocupe: eventualmente crearemos uno. Este es un circuito de retroalimentación que crea soluciones y tecnologías asombrosas, pero que puede conducir a sitios web sobrediseñados si no lo controlamos.

    Esto me recuerda la famosa cita:

    “El hecho es que si no tienes un problema, lo creas. Si no tienes un problema, no sientes que estás viviendo”.

     

    —UG Krishnamurti

    Veamos específicamente React . Fue creado originalmente por Facebook para que Facebook desarrollara funciones más dinámicas para los usuarios y al mismo tiempo mejorara la experiencia de los desarrolladores de Facebook.

    Desde que React fue de código abierto en 2013 (y casi volvió a obtener la licencia en 2017, si no fuera por la comunidad de WordPress ), se han creado cientos de nuevas utilidades para abordar varios problemas específicos de React. ¿Cómo se inicia un proyecto React? Están la aplicación Create React y Vite. ¿Necesitas mejorar la gestión de tu estado? Está Redux, entre otras opciones. ¿Necesita ayuda para crear formularios? Hay un formulario de gancho de reacción. Y quizás la pregunta más importante: ¿Necesita renderizado del lado del servidor? Para eso están Next, Remix o Gatsby. Cada solución viene con sus propias advertencias y los desarrolladores crearán sus propias soluciones para ellas.

    Puede ser injusto criticar a React ya que se considera una biblioteca , no un marco . Es inevitablemente propenso a ser extendido por la comunidad. Mientras tanto, Angular y Vue son frameworks con sus propios ecosistemas comunitarios. Y esta es la punta del iceberg, ya que existen muchos marcos de JavaScript disponibles, cada uno con su propia ideología y dependencias distintas.

    Una vez más, no quiero que se haga una idea equivocada. Me encanta que surjan nuevas tecnologías y me resulta liberador tener tantas opciones. Pero al crear algo tan sencillo como una página web o un sitio web pequeño (a lo que algunos han comenzado a denominar “aplicaciones de varias páginas”) tenemos que trazar una línea que defina cuántas tecnologías nuevas utilizamos y qué tan confiables son. Literalmente, estamos mezclando código de terceros escrito por varios desarrolladores externos. ¿Qué puede salir mal? Por favor no respondas eso.

    Recuerde que a nuestros usuarios no les importa lo que haya en nuestras pilas . Ellos solo ven el producto final, por lo que podemos ahorrarnos trabajar en arquitecturas innecesarias que no son apreciadas fuera de los círculos de desarrollo. Puede parecer contradictorio ante el avance de la tecnología, pero saber que al usuario no le importa lo que sucede detrás de escena y solo ve el producto final mejorará significativamente nuestra experiencia de desarrollador y lo liberará de dependencias bloqueadas. ¿Por qué arreglar algo que no está roto?

    ¿Cómo podemos simplificar nuestras bases de código?

    Hemos cubierto varias razones por las que el desarrollo web parece ser más complejo hoy que en años anteriores, pero culpar a los desarrolladores por lanzar nuevas utilidades no es una descripción precisa del problema real. Después de todo, al desarrollar un sitio, no es que nos veamos obligados a utilizar cada nueva tecnología que ingresa al mercado. De hecho, muchos de nosotros a menudo desconocemos una biblioteca en particular y solo la conocemos cuando desarrollamos una nueva característica. Por ejemplo, si queremos agregar notificaciones del sistema a nuestra aplicación web, buscaremos una biblioteca similar react-toastifyen lugar de otra forma de crearlas porque "va con" esa biblioteca específica. Vale la pena preguntarse si la aplicación necesita notificaciones del sistema si introducen nuevas dependencias.

    Imagine que está desarrollando una aplicación que permite a los usuarios descubrir, opinar y calificar restaurantes en su área. La aplicación necesita, como mínimo, información sobre cada restaurante, una herramienta de búsqueda para consultarlos y un flujo de registro de cuenta con autenticación para acceder de forma segura a la cuenta. Es fácil hacer suposiciones sobre lo que un futuro usuario podría necesitar además de estas funciones críticas. En muchos casos, un proyecto termina retrasado porque agregamos funciones innecesarias como SSR, notificaciones, modo fuera de línea y animaciones sofisticadas, ¡a veces incluso antes de que la aplicación haya convertido a su primer usuario registrado!

    Creo que podemos reducir el problema de la complejidad a los deseos personales y las necesidades percibidas en lugar de definir adecuadamente el alcance de un proyecto en función de las necesidades






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    El desarrollo web se está volviendo demasiado complejo y puede ser culpa nuestra

    El desarrollo web se está volviendo demasiado complejo y puede ser culpa nuestra

    Typography Masterclass, with Elliot Jay Stocks Register! Índice Como era antes

    programar

    es

    https://pseint.es/static/images/programar-el-desarrollo-web-se-esta-volviendo-demasiado-complejo-y-puede-ser-culpa-nuestra-1182-0.jpg

    2024-04-04

     

    El desarrollo web se está volviendo demasiado complejo y puede ser culpa nuestra
    El desarrollo web se está volviendo demasiado complejo y puede ser culpa nuestra

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20