La controversia de las bibliotecas CSS de animación

[@enriqueruiz320]

Tiene sentido usar solo CSS si eres exclusivamente diseñador, pero como la mayoría somos todologos pues tenemos que destinar el tiempo a otras cosas relacionadas con el desarrollo y tenemos que depender de herramientas.

[@juanpablogarcia6293]

esa discusión es una bobada, si fuera por eso nadie usaria wordpress, incluso no usariamos python, el propio javascript, ni java, que solo seria c y c++ si fueramos por eficiencia, cada uno lo hace a lo que le parece comodo y que afronte las consecuencias de hacerlo a su modo

[@gatitosmiaomaio]

en ese caso, no creo que sea posible reemplazar javascript solo con c++, por el tema de navegador,

[@juanpablogarcia6293]

@@gatitosmiaomaio mijo, obvio hablo de como se desarrolla la industria y los programadores y como algunos vienen con la mamada de que css es más eficiente, y obvio lo es pero si muchas personas no lo hacen o usan librerías será por algo, así como en los navegadores no se les hizo adaptaciones para usar c nativo desde un inicio, en vez de usar el Javascript

[@Natusch_]

Totalmente, el desarrollador de CSS del tweet peca del cliché del ingeniero: Pensar que las tecnologías son el fin y no el medio. Si la forma en la que saca el código Framer no supone algo perjudicial en términos de rendimiento o experiencia para el usuario, qué más da.

[@emmanuelbarba2567]

​@@gatitosmiaomaio en realidad sí puede con webassembly.

[@gatitosmiaomaio]

@@emmanuelbarba2567 pero no compilas en c, webassembly se compila en rust o c++, que es muy diferente a c puro y duro. Lo se porque me gano mis atunes con webasembly,

[@DraquioOficial]

He trabajado con Framer y no se si es cosa mia o que, a ratos las animaciones las siento fluidas y a ratos no jaja

[@joseecheverri3867]

Me pasa exactamente igual, a veces pienso que omito alguna configuración para mejorar el desempeño…

[@josueeleazartejedamorales3473]

cuando esos cambios en los valores son constantes, es decir cambian mucho y tienen cierto costos, como logs en la consola, o el hecho de que estos cambios se reflejen en el dev tool, etc, generan lentitud, tambien depende de otras cosas xd pero si es comun

[@vosyasabesquien]

de todos modos la idea no es meter framer motion solamente para hacer una transición simple... AnimatePresence, Gestures, hooks últiles etc.

[@mto88a]

Para react server components me hace bastante sentido tirar solo de CSS, sacrificar el renderizado del servidor por 2 slider con autoplay que igual al usuario le interesan poco o nada; no lo creo

[@stormgamesyt]

KZbin me lo recomendo re temprano, de locos.

[@ai.charly]

No sé, yo soy un purista del CSS, al inicio usaba Gsap para las animaciones, pero CSS ha evolucionado tanto que ya no necesito más librerías que CSS y en casos extremos un poco de js, ¿cuál es su biblioteca favorita?

[@devjesusc]

Pues mira, cada quien pone lo que necesite en el sitio y es verdad que no se necesitan cosas tan elaboradas. ANTES cuando teníamos FLASH abundaba la creatividad (había de todo, muy buenas y mediocres) pero fue padrísimo por que muchos hacían animaciones y las poníamos en los sitios y el cliente super contento. Luego tuvimos el periodo minimalista donde a todo lo animado y único se le miró feo o no necesario hasta el día de hoy. Si el cliente le gusta algo así, cuando ellos mismos te dicen, quiero un slider asi y asi, y es cómo lo que hace este chavo pues vale!. Lo peor es que hoy todavía muchos presumen sus páginas y ponen en su "splash screen" una imagen de más de 6000px con peso mayor a 10 ,15 Mb y no se dan cuenta que están dando calaca a su sitio, ah pero presumen estan hecho con quien sabe qué. Pienso que todo debe estar balanceado, y que se debe estudiar todos los días, darse un tiempo diario a investigar, probar, etc. Gracias por tus videos.

[@gatitosmiaomaio]

exacto, hasta ahora no he visto ninguna web javascript que se pueda comparar a las paginas webs con flash con 3d, incluso tenian reflejos, y eran muy buenas muy interactivas. todo eso se perdio.

[@vosyasabesquien]

ese 'periodo minimalista' se dio por varias razones: 1) porque tomamos consciencia de la naturaleza de html como un documento / dom vs un sitio 'como un artboard' todo metido en un object embed. 2) que esa información debía poder ser indexada por buscadores, agregadores rss, etc. 3) los sitios multidispositivo / responsive vs el 800 x 600 fijo de flash 4) html nativo vs plugin (para la compatibilidad multidispositivo). 5) el advenimiento de la 'web 2.0' y los sitios dinámicos conectados a un cms vs sites estáticos. si vamos a la experiencia visual, actualmente con la maduración del frontend JS y libs tipo threejs, es perfectamente posible lograr sitios que ofrezcan experiencias visuales inmersivas como las de flash, pero que funcionan y se adaptan perfectamente a 2024. en awwwards sobran ejemplos de lo que digo. aun asi, la realidad indica que hoy por hoy hay muy pocos developers que se especialicen en web-gl y creative coding. lo cual hace que se manejen costos elevados en esa clase de sitios. y que tampoco abundan clientes premium que estén dispuestos a pagar por ello.

[@k4r4m310.]

comparto su opinion, un cordial saludo

[@Max29xD]

Tiene un impacto en el rendimiento si no tienes un buen móvil, ya que hablamos que la mayoría de usuarios navega por el móvil, esto creo que funciona perfectamente para un equipo de escritorio, así que sería bueno crear un flag para cuando sea en móvil se desactive y en escritorio normal, y así no reste el rendimiento en móvil.

[@MsSoldadoRaso]

Para eso están las apps nativas, como por ejemplo si la web detecta que estás en móvil te puede redirigir a la play store a descargar la app, así como hace Reddit

[@mijailvillegas1034]

Tiene mucho sentido, yo me hice un carrusel con simple y plano CSS y no era necesario usar JS más que para cargar la lista de imágenes, pero no era nada necesario usar un framer ni alguna librería para eso realmente.

[@enricperpinya3375]

Tienes razón, pero también hay problema a futuro si este código de framer luego se pasa a un equipo de desarrollo...

[@Camilofuentesito]

con los computadores de los 90 pudo haber importado, la realidad es que el internet y el rendimiento de los computadores va cada vez más rápido, asi que no es tan terrible usar librerias que facilitan el trabajo como desarrollador, mi humilde opinion

[@AllanQuiroz-q3u]

Framer es todo un ecosistema y Framer Motion forma parte de, por lo que no tiene sentido alguna la comparación. Uno usa CSS para su componente y el otro te ofrece un catalogo de componentes parametrizable, para gente que sabe y no sabe programar.

[@evartvalls2432]

Correcto... Justo hoy tengo que formatear mi PC 😥... He descargado tantas herramientas y dependencias que son mas bien innecesarias y que ya no son tan vanguardistas como para el benchmark o mejorar alguna otra cosa. Ademas soy Junior y tengo tantas herramientas en mi pc como si yo fuera ls empresa completa

[@alejandro_dom]

5:40 "a quien le importa" jajaja 5:41 "lo importante es que funcione" se resumió todo

[@airixxxx]

Framer Motion hace cosas que no se pueden hacer con CSS, como animar elementos que se remueven del DOM con state. Este muchacho antes de trabajar en Vercel hacia muchos videos de Framer, ahora paso a Vercel y las librerias de este estilo no funcionan en server side... Sabe mucho, su canal de KZbin tiene cosas buenísimas, pero el tipo creador de Framer con el que esta discutiendo esta en otro nivel.

[@michaelandresdiazcastillo9326]

Yo opino que depende, ambas opciones son una solucion para diferentes problemas, si auieres una web bonita, barata y rapida de hacer pues usa las librerias, si quieres algo mas escalable, optimo y caro esta el css puro, incluso un proyecto podria hacer uso de ambas cosas, vamos que como devs es nuestro deber el momentk en el que usar una herramienta u otra, eso de casarse con una herramienta o metodologia me parece un gran error

[@luisfelipereyesdelosreyes4920]

Cuando haces un curso de Open-props?

[@bobobo1673]

Open props?

[@OcultoTube]

Hay mucha diferencia entre los roles de QA Automation y Backend o cobran lo mismo ??

[@MsSoldadoRaso]

XD

[@eduardoguevara4849]

El problema es centralizarlo todo en javascript, porque estan usando para TODO javascript ignorando los roles de cada lenguaje Para que carajo existe css si usaran librerias de JS en su lugar? Para que tienen lenguajes de backend si al final usaran JS con memory leaks? Es exagerada la prioridad que hemos dado a javascript, hace no mucho ser front tambien era saber a profundidad css, en que momento cambio eso?

[@HamzaEngineering]

Las dos opiniones y maneras de explicar como desarollar la animacíon CSS tienen puntos positivos. Pero la forma en que como ha llegado la discusíon no parece la mejor. Deploy and then optimize and refactor.

[@alejandrocb139]

Muchas de estas librerías de animaciones son geniales y muy amplias, pero para métricas de tipo google lighthouse o similares son extremadamente pesadas y casi siempre penalizan de forma horrible la calificación incluso si tú no lo notes como usuario te calificara mal, quizá es encontrar un punto medio entre css y js, si no requieres animaciones demasiado complejas, css siempre será mejor que js, ya que si necesitas animaciones complejas con trigers y eventos particulares y no te importa perder rendimiento, pues js es una opción

[@juanpablogil59]

El lio es que ves todas esas paginas hechas con ese tipo de herramientas y funcionan hermoso en en desktop, pero el mobile es desastroso a muchos niveles.

[@MsSoldadoRaso]

Para eso están las apps nativas

[@issa.garcia]

porqe ese clickbait de miniatura midu jaja, buen video como siempre

[@snithfferx]

jejejeje, como no se usar css y a penas se javascript, esto me paso como esos chistes tai o filip que hay en la red. (no siendo nativo del lugar, no te enteras de nada y no le hayas la gracia)

[@galaxiapixel]

La falta de amor propio y reconocimiento que tiene ésta gente por favor! una falta de amor.

[@roguegoblin2407]

La discusion es muy boluda, obviamente para animaciones o interacciones simples css es rey, pero para cosas mas complejas te volves loco, framer motion te lo simplifica bastante. En los unicos casos que sufri impactos de rendimiento fue usandolo en conjunto con three.fiber, pero eso solamente porque soy un choto laburando con 3d todavia. Cada uno usa lo que quiere, estas discusiones de "esto es mejor, no esto es mejor eso es una mierda" son una pelotudez atroz, quiza hay cosas mejores dependiendo del caso y listo. Si el back es simple usas supabase, si es una app enorme usas nestjs, si es una pagina estatica usas astro y si es muy dinamica usas nextjs, que se yo

[@AioriaPoderoso]

1338 tan cerca pero tan lejos del 1337

[@Trox-the-gamer]

🥵🥵🥵

[@yohcg]

Al final es una herramienta automatizada. Si quieres algo limpio o que sea “entendible” debes hacerlo desde 0. Pero para que reinventar la rueda, a menos que pidan cambios y que la herramienta no sea capaz de dártelos. Ahí ya sería de discutir y ver qué tanto el cliente está dispuesto a ceder

[@angelogalaz1632]

this is a bad and bored salseo xd