# Front-End No Es "Pintar"...  ## Metadata - Author: [[@enriquedev_ on Twitter]] - Full Title: Front-End No Es "Pintar"... - Category: #tweets - URL: https://twitter.com/enriquedev_/status/1394569130569777152 ## Highlights - Front-end no es "pintar" el resultado del API, ni hacer diseños bonitos. Con la complejidad que tienen las aplicaciones y las necesidades que se necesitan suplir, se trabajan muchos aspectos, y uno de ellos, es el rendimiento. 👇 Aquí dejo una lista de soluciones para este 2021: ([View Tweet](https://twitter.com/enriquedev_/status/1394569130569777152)) - En primer lugar, hay que olvidarse de crear esos archivos js/css monolíticos que contienen todo el JavaScript de la aplicación. No tiene sentido que si el usuario solo puede visitar el 15% de nuestra aplicación, le hagamos descargar el 85% restante. ([View Tweet](https://twitter.com/enriquedev_/status/1394569131857522689)) - Para esto, debemos usar "code splitting", algo que nos permite cargar el código necesario para cada sección, bajo demanda.  ([View Tweet](https://twitter.com/enriquedev_/status/1394569135670104064)) - Esto se puede hacer con Webpack, pero los frameworks más importantes ya tienen configuraciones para crear aplicaciones con esta ventaja sin tener que pelearnos con Webpack, haciendo que cada componente, página y sección que visite el usuario, descargue solo el código necesario. ([View Tweet](https://twitter.com/enriquedev_/status/1394569137230422023)) - Por ejemplo, se puede usar "Creat React App" para React: https://t.co/wKrE27p9c5 O "Vue CLI" para Vue https://t.co/dGQxuaD9us ([View Tweet](https://twitter.com/enriquedev_/status/1394569138551545856)) - Este año se está dando mucho bombo a los "Core Web Vitals", porque Google los tiene en cuenta, pero porque son aspectos que SI afectan al usuario. Un usuario prefiere una página en la que puede interactuar rápido, en la que no tiene que esperar 10 segundos para verla.  ([View Tweet](https://twitter.com/enriquedev_/status/1394569141906989056)) - Estos "Core Web Vitals" se pueden mejorar usando herramientas como Next.js o Nuxt.js, dos "meta-frameworks" de React y Vue respectivamente, que nos permiten desarrollar como siempre hemos desarrollado con estas herramientas, pero aplicando automáticamente optimizaciones. ([View Tweet](https://twitter.com/enriquedev_/status/1394569143551238146)) - Una de estas prácticas es Server-Side Rendering (SSR para los colegas), que "pre-renderiza" en tiempo de petición nuestro código de React/Vue, permitiendo así que descargue el usuario, sea una versión funcional de la página, y no tenga que esperar que se ejecute JavaScript. ([View Tweet](https://twitter.com/enriquedev_/status/1394569144893329410)) - "¿Pero eso no es lo que hacíamos en PHP?" Si y no. El SSR "antiguo" lo que hacia era devolver el HTML por un lado, y el JS por otro lado, tratando el HTML como algo "del servidor". En SSR "moderno", el HTML generado sigue siendo parte del front-end, aunque un servidor lo genere. ([View Tweet](https://twitter.com/enriquedev_/status/1394569146277453827)) - Esto nos permite tener las mismas facilidades de desarrollo y no tener que estar luchando con selectores ni getElementById para intentar hacer interactiva nuestra página: Ya lo hace nuestro código.  ([View Tweet](https://twitter.com/enriquedev_/status/1394569149511307264)) - Si vas a crear algo mas complejo que un blog, web corporativa o tienda online, NO uses WordPress. Ni Wix, ni CMS del estilo. Su arquitectura (si tiene) no está pensada para ser optimizada, está pensada para recibir multiples plugins sin importar como estén hechos, si funcionan. ([View Tweet](https://twitter.com/enriquedev_/status/1394569151256186881)) - Obviamente se puede optimizar un WordPresss, pero si vas a crear una aplicación, es posible que herramientas más modernas te darán mejor DX (experiencia de desarrollo), lo que se traduce en tiempo, lo que se traduce en dinero. ([View Tweet](https://twitter.com/enriquedev_/status/1394569152644452353)) - Si no quieres liarte y quieres seguir usando WordPress como "back-end", se puede usar como headless-cms. https://t.co/kD2MGQLtsi ([View Tweet](https://twitter.com/enriquedev_/status/1394569153973993472)) - Y por último, el hosting. Un servidor de hosting común, no es tan óptimo como uno diseñado para páginas "modernas", ya que solo escupe HTML, dando igual donde estés, que hayas sacado una nueva versión de tu página y necesites purgar la caché de los clientes, etc. ([View Tweet](https://twitter.com/enriquedev_/status/1394569155370790913)) - Para eso existen herramientas como Vercel o Netlify, que aparte de generar pipelines para evitar que subas código que no "compila", cuentan con una red de servidores CDN, proporcionando así el mejor tiempo de respuesta dando igual donde se haga la petición. ([View Tweet](https://twitter.com/enriquedev_/status/1394569156675178496)) - En resumen: - Code-splitting. - Frameworks modernos te solucionan las partes más técnicas sin romperte la cabeza. - Usa CMS genéricos solo para back-end. - Vercel o Netlify. ([View Tweet](https://twitter.com/enriquedev_/status/1394569157962764288)) - Y esto es solo una pequeña superficie de todo lo que se puede tratar en Web Performance, para más, hay titanes de esto como @nucliweb que dan mucha info sobre el tema. ([View Tweet](https://twitter.com/enriquedev_/status/1394569159292375040))