Yo soy front-end developer desde hace más de 7 años, entiendo lo que dice Afor, por tal motivo, cuando ya entras a trabajar en un proyecto real, lo mejor es adoptar un sistema de diseño, si eres diseñador web, puedes crear tu propio sistema de diseño, o puedes optar no por muchas librerías, sino por una que brinde la mayor solución a tus requerimientos. yo recomiendo rsuite, para react.js o next.js que cuenta con todo lo que mencionó afor. ya que no es que sea "demasiado complicado", sino que el trabajo es robusto si se realiza la creación de los componentes desde cero y sin seguir un sistema de diseño. pues va a ser peor. Yo considero que para ser un buen front-end developer, se necesita ser un buen diseñador también, que conozca de fundamentos de diseño, simetría, manejo de espacios, contrastes, y todo eso que te da bases para que tu ojo sea agudo a los detalles estéticos.
En mi caso no soy diseñador, pero si me das un diseño se seguir seguimientos para hacerla verse casi igual o igual si no es compleja, por ahi si tengo alguna idea buena para agregar a un diseño, pero fuera de eso, podria ser un buen front-end sin saber de diseño?
Oye, sinceramente, tu explicación está 10/10. A pesar de lo que comentas, creo que lo que realmente falta es tiempo para abarcar todo lo que implica el desarrollo Frontend: animaciones, accesibilidad, i18n, optimistic-updates, caching, gráficos, librerías 3D, etc., y todo esto sin dejar de lado el rendimiento de la aplicación. Espero que este video llegue a aquellas personas que, queriendo o sin querer, desmerecen el trabajo del Frontend sin saber realmente todo lo que implica.
los problemas de asincronismo en el frontend estan infravalorados, hacer que todo renderice en su orden y prevenir pre renders es un dolor de cabeza a veces (cuando piensan que frontend solo es una web bonita)
@@emanuelr9815 cuánto es muchos para ti? 2% 12% ? Veamos las estadísticas de stackoverflow LinkedIn Glassdoor Upwork. Y no nos referimos a vacantes sino a perfiles Dev. Recuerda que son las empresas equivocadas que tratan de meter más funciones en un solo cargo para evitarse pagar 5 personas en una. Es por eso que arfordigital está reclamando.
@@emanuelr9815 hay 3 opciones normalmente, prefiren pagar a derrolladores con grandes limitaciones especificas por ahorrar dinero, realizan tareas intermedias, osea realmente no se dedicana crear todo un sistema sino a integrar las partes o simplemente hacen proyectos para pequeñas empresas o individuos, donde el aspecto es lo que importa, el back mientras cobre y no se caiga es suficiente
No he echo backend pero por parte de frontEnd veo que tienes que mantener estados, evitar fugas de memoria, tienes que validar texto, tienes que ver que tú pantalla se ves bien en todas partes, etc. Pero siento y creo que el backend es como las matemáticas, las personas lo ven complicado pero si conoces las reglas todo se vuelve repetitivo y espero que sea así y lo más difícil sea el primer análisis y luego a construir
si bueno matemáticas, bastante lógica diría yo como todo el mundo metido en esto porque lo algoritmos que quizás necesites no te los comes tu, pillas librerías, ChatGPT o las buscas por ahí y las adaptas xD
No es repetitivo, porque cada trabajo pide cosas diferentes en base a la necesidad del cliente. Para poder entender que tan complejo es tendrias que trabajarlo, asi como un front no puede comprender a un back hasta que lo trabaja, te lo digo como full stack tanto el front como en back tienen sus complejidades
@@petersonperez7875Cierto, pero mi pregunta es con todo el conocimiento que tienes, en back por ejemplo lo usas para casi todo, sin embargo en front tien un mundo ademas que para un front usas un fremw logica casi diferente de otra ahí radica el front, del back
Cada uno es su mundo, el backend tiene reglas y reglas de reglas. Por ejemplo, muchos programadores full stack suelen pensar que hacen un API con express y postgreSQL y ahí acaba el backend pero la verdad es que así como hay frameworks y estructuras de frontend también suele haber en backend. Un ejemplo es cuando haces un backend en Java pero en microservicios y encima en monorepo, tienes que crear un dockerfile para levantar cada uno de esos microservicios y luego usar docker compose para manejar todos esos, aparte de que cuando haces microservicios debes tener una capa de comunicación la cual requiere otro docker como Redis por ejemplo o puedes incluso levantar un microservicio en cada puerto y configuras nginx como reverse proxy para redirigir solicitudes, aparte si quieres usar sockets para eventos a tiempo real como un streaming entonces tienes en algunos casos que hacer uso de librerías o programas tu mismo para conectarte a esos eventos y manejar manualmente el lfujo de bytes recibidos, o incluso en kotlin o rust tienes que saber cuantos y cuales hilos usar para cada proceso, esto por lo general javascript se encarga de manejar los hilos, y si quieres hacer un gateway de graphql es otra historia, programar esquemas además. Todos son su mundo, yo digo que frontend y backend van muy de la mano aunque sean de conceptos distintos, pero creo que la gente los compara mal porque suelen comparar un seniority en frontend contra un junior en backend creyendo que backend es CRUD y ya
@@brahianarias-8872 tienes razon, pero en estos ultimos años, la evolucion de front y todas las cosas que sale de un dia para otro creo que estresa a un programador front, de al menos saber entender como funciona, en back no se la historia sin embargo no veo tanto algo nuevo en back, creo que ahí radica el problema, hoy aprendes algo mañana ya sale otra cosa, las empresas empiecen a considerar usar
@@coldcoder23es que ya el desarrollo web no es tan lucrativo como antes (no es que no se pueda, pero necesitas demasiadas skills y que te necesiten para trabajos muy específicos), no como antes que eras junior y podías ir aprendiendo en la misma empresa.
Trabajo en una empresa en la cual la solución SaaS que ofrece es literalmente la app que has descrito, y la desarrollamos en Angular. Gracias por visibilizar lo que todos los desarrolladores frontend tenemos que sufrir jaja
@@luisaduran9426 Yo hice ingeniería informática y tardé 6 años en acabar, y comenzar a programar se hace muuuy difícil si no tienes una base antes de empezar. Concretamente en desarrollo frontend tengo casi 3 años de experiencia laboral, y me queda mucho por aprender jajaja así que no te preocupes porque te suene a chino, es normal, esto lleva paciencia y dedicación.
No estoy de acuerdo. La idea del video no es declinarse por un bando, es generar conciencia sobre la complejidad que requiere el Front-end. Qué el Front-end sea más complejo que el Back-end (o viceversa) va a depender de los requerimientos del negocio
Yo también puedo decir que hagan componentes reutilizables con patrones de diseño y básicamente el frontend solo tiene que copiar y pegar... Jajaja 😂 en el backend no solo es crear api
muy bien explicado hermosa, gracias me suscribo, me sirvio de mucha ayuda, para crear mi mockup, me gusta que cuando explicas este speudocodigo grafico se entine mejor.
Hcae mucho deje de hacer mis propios componentes a usar librerias UI como nextUI o shadcn ya que estas me permiten trabajar mas rapido el estilizar mis aplicaciones, ademas que los mismos componentes puedo hacerlos reutilizables facilitando el desarrollo
Con angular es muy fácil: angular material, ngx-infinite-scrolling, rxjs, subscribe, unsuscribe, input, output, Viewchild, infiniteScrollDirective, tardaría como 3 o 6 horas, pero es puro talachita, por cierto, lo del buscador, obviamente el back debe paginar las responses para facilitar la implementación en el front, en mi caso uso laravel con eloquent, la facilidad de paginate() es una maravilla.
En angular me gusta más que te da las dependencias necesarias y pocas veces necesitas externas, en cambio React tiene muchas librerías, muchas hacen lo mismo y puede que en un lugar te pidan una y luego otra. Pero tambien lo complicado del front es la subjetividad y dinamismo en los diseños que te pueden dar
Una gran diferencia es que en el backend se maneja la lógica de negocios, seguridade de la aplicación y algoritmos necesarios, en cambio el frontend es full lógica de presentación y algunos algoritmos que son en su mayoría para el manejo y visualización de componentes, cada uno tiene su nivel de complejidad no se puede decir que uno sea mas fácil que otro.
totalmente cierto. y siempre tenes a alguien que dice "eso se hace en 2 minutos". cuanto podes tardar en poner un avatar.. cuanto podrias tardar en hacer una simple tablita y exportarla a excel. y cruza los dedos de que la libreria que vas a usar funcione con el framework que estas usando y que en 24hr va a dejar de tener soporte
Buen video. Para la infinidad de tamaños de pantalla, suele ser buena opción limitar el ancho del container y ya solo tienes que hacer responsive para 3 dispositivos: móvil, tablet y desktop.
Oye Afor, qué lástima que no tuve éste video hace 3 años para mostrárselo a una empresa con la que trabajé, desperdicié horas de mi vida tratando de explicarles esto mismo y no logré que lo entendieran. Por desgracia no lo expliqué tan bien como lo hiciste tu.
Un consejo como SR Frontend (creo que lo soy), piensen su arquitectura para que cada feature sea facil de implementar despues, combinando librerias practicas (que no siempre son las mas populares) yo tuve la suerte de crear mi ultimo proyecto solo (unico front) y fue de las mejores apps que trabaje. Lo que tu comentas se complejiza x4 cada vez que agregas alguien al team. ultimo consejo usen react query hasta que salga algo mejor, no usen redux si no tienen que hacer flujos complejos.
completamente de acuerdo. estoy embarcado en un proyecto complejo yo solo, y en mi caso lo mas importante es pensar de forma abstracta sobre la arquitectura y soluciones generales que evalúen no solo el presente ni un caso especifico, sino que evalúen todos los casos probables y no solo el presente sino también el futuro. Para los features estoy usando una especie de Ducks Pattern pero mas sofisticado adaptado a mi caso especifico donde me enfoco en que partes necesito un control centralizado, reutilizable y basado en configuraciones, seria como un proceso de desarrollar mini librerías. Luego también es util pesar en que partes es mejor descentralizar por ejemplo componentes complejos. También es util pensar en capas de complejidad, identificar "stagings areas" que serian partes del algoritmo que en caso de que se necesiten cambiar en el futuro sean accesibles desde un solo lugar que lo abstrae para evitar encontrarte con situaciones futuras que te hagan perder mucho tiempo por una mala praxis de arquitectura, o sobre ingeniería en entornos complejos y cambiantes.
Totalmente de acuerdo. Desarrollar en frontend es puro caos jaja Lo bueno que tiene frontend es que es más sencillo recibir feedback del resultado. Y a la vez, a veces debugar cuando falla algo es un infierno y hay que volverse loco haciendo prueba y error. También cuesta mucho configurar el IDE, dependencias y el proyecto para que funcione la primera vez (y mas te vale no tocar nada para que no se rompa). Por otro lado, backend es más "lento" de implementar, crear tests y probar. Pero es mucho más estable y sencillo el detectar y arreglar un error. Además, no tienes que volverte loco porque cada 2 meses hay una nueva librería de moda y la que usabas ya ha caído en desgracia 😅🙌🏻
en mi opinion lo mejor es usar una libreria como shadcn o sin estilos radixui, react query y si se quisiera zustand pero ppr lo que se usaria en este esquema se podria usar context tranquilamente. Una buena libreria de componentes te cambia la vida
Yo soy front-end desde hace casi 6 años y lo que dice Afor es cierto, al principio uno piensa que es facil pero a medida que toca expandir el Stack comienzas a pensar a pero q pedo, pero con el tiempo te enganchas y te puede gustar como en mi caso
Anecdota. Me especializé en desarrollo FullStack. Para las practicas profesionalizantes debía salir a buscar un cliente a quien hacerle una pagina y lo hice con una rectificadora importantisima. Utilicé Django y Bootstrap y: -No sabía usar Django. -No sabía con que se comía Bootstrap. Aprendí sobre la marcha y como me manejo bien con javaScript, decidí no utilizar ninguna librería mas para hacer el front. Absolutamente todo el front logico lo hice con js nativo. desde los buscadores hasta los filtros. Terminé con muchisimas carpetas y cuando los profesores lo vieron se les dibujó el horror y el miedo en el rostro jajaja
¿Eres Backend?, todos los Backend dicen lo mismo, como reto personal hice este Dashboard con tan solo una libreria "MDB 5" y me tomo 2 horas, 37 minutos 13 segundos. No me parece tan dificil ser Frontend, es divertido y me permite ser creativa.
Como reto personal yo puedo hacer un back-end mucho más rápido de lo que tardo haciendo el Front-end. Inclusive con servicios como supabase o firebase tengo un back-end con db, storage y auth a un solo clic. No por eso voy a decir que el Back-end es fácil. En el mundo real hay muchos factores que llevan a que uno sea más complejo que otro. Lo que sí creo que deberíamos dejar es la idea de que el Front-end es solo pintar cosas y ponerles colores. Hay mundo entero más allá de eso.
Pixel perfect se hacía antaño y se sigue haciendo a día de hoy. La interfaz se tiene que modularizar con dimensiones, a ser posible múltiplo de 8 por motivos que ahora no vienen a cuento de cuando surgieron las pantallas de PDA, pero bueno. Otra cosa es que CSS ya permite hacer tipografías y contenedores fluidos usando funciones que abarcan un rango entre un mínimo y un máximo como clamp() y te ahorran cientos de lineas de media queries, pero modular se modulariza, ayer hoy y mañana, y hay toneladas de literatura sobre usabilidad que dan reglas para ello, porque luego salen los N,algo pixels de medidas y eso muchas veces da dolorcitos de cabeza
Dios mio, creo que me perdi ese directo, pero se ha vuelto uno de mis videos favoritos de Front, me abriste la mente y me hiciste pensar mucho, que crack...
tambien depende como lo quieras ver, yo siento que es muy facil el frontend (Al menos para mi, porque me gusta diseñar) pero se que lleva su grado de complejidad. asi que depende que tanto te guste hacer tu trabajo.
y sin olvidar que muchas de esas librerías o dependencias a su vez tienen otras dependencias, y a veces tienes varias versiones de las mismas dependencias, o dependencias deprecated, inseguras... y poco control sobre ellas ya que se alojan en el agujero negro que es el node_modules... Y podrías dedicar otro vídeo solo al tema del deployment y las development dependencies que es otro mundo también, que si librerías para que te hagan las migraciones a la base de datos, los tests, los scripts, las github actions, linters, formatters, transpilers y packers jaja es un no parar...
Uso pnpm, es más estricto que yarn, bun o npm, pero no te evita esos problemas que te comento, aunque te los mantiene bajo control, y al menos nos da la opción de especificarle manualmente las versiones o resoluciones (de las subdependencias de nuestras dependencias) o incluso hacer pnpm patch, aspectos que uso a menudo. Me sorprende que la mayoría de devs simplemente ignoran el output de un pnpm install.
si JAJAJAJAJAJJA estaba rayadisimo por que la pagina del cliente no se veia como en mi telefono, tablet, pc, tv, etc. Pues resulta que el maldito "bg-cover" (no se como se escriba en css pero asi es en tailwind xd) NO FUNCIONA EN DISPOSITIVOS CON IOS, y se veia refeo en su ipad pro y su iphone, y pues lptm si no fuera por que me consegui un ipad prestado nunca me hubiera dado cuenta de esa cosa, igual pude hacer que se viera bien ajustando las dimensiones minimas para que se usara el bg-cover solo en resoluciones mayores a QHD
Ver el vaso medio lleno o medio vacio es cosa de cada uno, yo lo veo medio lleno y siento que es más facil de lo que aparenta. Si nos ponemos a desglosar y detallar cada operacion pues obvio no terminamos nunca, pero, si lo vez de manera neutra te daras cuenta que todo es igual. Nuestra vida cotidiana se basa en pasos y pasos y pasos y al final no es mucho o a veces haces 1 paso y es algo muy grande. El problema real son las empresas y personas que creen que somos magicos y además que ellos creen que se expresan bien, le dedico toda mi mente a la toma de requerimientos y eso ha hecho que no me agobie con tonterias, además, de la reutilizacion del codigo propio y la creacion de librerias y paquetes propios ayuda un monton en lo que se habla en el video. Saludos de un fullstack y suerte a todos codificando a toda la comunidad❤🫶🏾💯
me gustan estos videos que muestran la realidad de desarrollar software de calidad y de verdad util. no es como te lo pintan de que después de entender como funcionar tal o x tecnología ya la dominas o podes hacer lo que quieras con ella. sino que la verdadera capacidad de desarrollar software de calidad es proponértelo, un objetivo alto con todas las cosas a tomar en cuenta en cuanto a metodologías, arquitectura, patrones, practicas, etc. y forjar la habilidad a base de errores y experiencia de forma constante por mucho tiempo, hasta stackear una gran cantidad de soluciones en cada una de las etapas y capas de desarrollo. Creo que un dev que no haya llegado a ese punto no puede considerarse un desarrollador de software serio. La mentira de pensar que desarrollar software es para todos o que es fácil les saldrá mas cara a medida que se normalice la demanda anormal que tuvo y todavía esta teniendo el sector (solo que se protege cada vez mas de los pseudo programadores últimamente) por lo que cada vez será menos probable que contraten "desarrollares" que únicamente pican código pero que no saben ni los principios mas básicos de que es lo que significa desarrollar software tan siquiera.
Totalmente cierto! todo todito, todirijillo. Yo me pase se react a svelte para acelerar mi desarrollo hace un tiempo y fue la mejor decisión. De todas maneras, el gran problema del frontend es la cantidad de librerías que se deprecan a diario. React sufre muchísimo ésto por ser tan usado, pero nadie se escapa.
La mayoria de las veces se puede valer solo con un framework (Vue/Angular) y una libreria de componentes como Vuetify o Angular Material. Evidenmente si no se escoge un stack completo antes de empezar el proyecto puedes recaer en un infierno de librerias, pero por ello es bueno hacer un analisis de los que puedas necesitar con anterioridad y hacer un peqeueño researching, con eso puede que te des cuenta si necesitas una libreria completa de componentes o no.
Me iba descojonando cada minuto del vídeo porque es tal cual 😂 En mi caso estoy más en el backend pero me gusta estar al día de lo que pasa en el front en mi trabajo en la medida de lo posible. Añadiendo a lo que comentas, el frontend tiene el contra de que al tener tanta librería y framework es fácil que al iniciar un proyecto se acople tanto a ellas que luego mejorar la arquitectura cuando llegas a esa etapa del proyecto que ya se ha validado la idea de negocio sea un pain brutal. Pero bueno, hay que hacerlo igual 🙃
Ahora estudiando Signals en Angular 😅. Me ha gustado el programa. Al primer momento he temido que llevaras tatuajes por el exceso de maquillaje, que últimamente les he pillado manía. Subscrito.
oigan yo hago experiencia de usuario de manera profesional y pienso que tener acotadas las casuisticas ayuda a tener tangibildad del que queremos crear y ayudar a mi equipo técnico a concentrar esfuerzos donde debe para que cobre impacto todo lo que estamos haciendo.
Ojala exista algo que unifique todo, porque igual dominar varias cosas, react, Javascript, css, html, bootstrap, web pack y todo, la curva de aprendizaje es larga y los días pasan, y pues debe desarrollarse algo que eso sea mas simple, y mas si nos vamos de lado del servidor
Debo decir que llevo con php html css y js bastante tiempo y soy bastante reacio a utilizar librerías "the modern way". He visto desarrolladores usar librerias de npm hasta para hacer circulos... Lo cierto es q siendo un poco pulcro con el código, quizás dividiendo responsabilidades entre ingeniero de datos, maquetador y tal.. las cosas salen bastante bien sin reventarlo todo de librerías y sin necesidad de tener en cuenta 700 pantallas (con 5-6 tipos y un min y un max vas que chutas) que la propiedad "right" no funcione en mac supongo que es un mal ejemplo escogido aprisa y corriendo en directo, pero a menudo pasa que los desarrolladores le tienen alergia a entender qué es cada propiedad de css y como usarla, y esto es precisamente porque: "libreria hacer por mí".
Dios mio, en mis tiempos todo eso se hacía a mano en js, la única posible librería a utilizar era jquery y eso era difícil,tal vez es mi percepción pero ahora las librerías hacen todo muucho más sencillo, recuerdo el infierno que era hacer una tabla de esas dinámicas, pero es mi percepción.
Soy ingeniero de TI pero no he tenido la oportunidad de ejercer así que comenzé a especializarme en front-end. Ahorita estoy estudiando CSS puro, voy en el tema de responsive y flexbox ¿voy por buen camino? Por que en las ofertas de trabajo la mayoría pide frameworks tipo bootstrap o wordpress y ya no se si estoy perdiendo el tiempo o no xD
No hay ningún campo de la informática que me de más pereza que el frontend. Prefiero programar en ensamblador, contando cada bit, antes que tocar frontend.
Dale es verdad, yo trabajo como full stack con react y django, y definitivamente siento que trabajar en el frontend es un poco mas tedioso por todo lo que implica, ya sea el diseño, los estilos, las integraciones con el back, etc. Ahora ya tuve mucho frontend y pedí mas tareas del back jaja ya mucho css.
Con los años vas asumiendo todo de forma gradual y cada vez haces todo de forma más sistemática. Obviamente, todo de cabeza suena muy tedioso, pero cuando llevas un orden, solo se convierte en pasos a seguir.
Qué ya no es como antes para eso esta el boostrap de css ahí muchas que lo hacen más fácil todo y yo no me apaño con boostrap yo aprendí directamente con hacerlo en css directamente al principio complica todo pero luego con el tiempo y la experiencia se hace más fácil las cosas y también con frameworks se hace más fácil las páginas webs, ayudan bastante
el frontend no es complicado cuando agarras costumbre, puedes aplicar todos lo colores o animaciones, lo difícil seria la parte de diseño, diría que si.
A mi me parece que mas que complejo, es la cantidad estupida de trabajo que puede llevar dejar todo bonito, te puede llevar mas tiempo del que te gustaria admitir con un maldito botón que haga alguna animación o que tenga algun requerimiento raro del cliente.
No es complicado. El problema es que la mayoría de programadores no son diseñadores y no saben diseñar interfaces. De hecho, es por eso que el uso de frameworks de terceros se hizo masivo.
Me estaba bajoneando por lo que hago en web y lo estaba viendo de menos, pero ver este videoy recordar como es la lógca, el diseño que implica....qué "fácil" ...pensé xd
El front es mas renegar con config, q de te vean las cosas bonita. El verdadero programador es el backend, el front es mas un diseñador que se la rebusca para q queden las cosas bonitas combinando tools, librerias, etc. El backend es hermoso xq es logica, performance, optimizacion, matematica y toda la complejidad q uno estudia en una universidad por ej la carrera de cs de la computacion. Es la base de todo y es donde todo nacio. Es una verdad q ofende a los frontenders
Lo bonito mi amor es que existe algo que se llama encapsulacion, modulizacion, y todo eso que nos abstrae de tener que pensar que todo es complejo. Ademas esa es la naturaleza del software. Pero cierto es lo que tu dices: en algo tan simple hay detras una gran catidad de faena. Por eso hay que cobrar bien 😂
Es como hacer un Slider... yo no me habia dado cuenta de la complejidad que tenia hacer eso... ojala fuera tan facil como los Sliders que uno hace cuando se esta aprendiendo jajajaja. hay que tener en cuenta que si es touch, que si es con bullets, que si se quiere tener solo 5 bullets para 100 slides... entonces que como se calcula cuando se activa cada bullet, que si presionas un bullet a a que rando de slides te debe de mover.... y asi puedo seguir con un monton de cosas que nunca tuve en cuenta hasta que me toco hacer ese Slider desde cero... Ojala todo fuera tan sencillo como los componentes que uno hace cuando esta aprendiendo xd
aqui uno que se graduó el viernes del ciclo superior de asir haciendo ahora el proyecto final con una api y una web y spoiler estoy atascao con la api. YA ME ESTA DANDO MIEDO LLEGAR A LA WEB!! pero eh te llevas un nuevo sub :)
Me encantó el video y la exlicación... entonces ¿no es bueno llenar de librerías un proyecto? ó ¿como saber cuando si y cuando no usar una librería?, saludos!
Cuando lleguen a un proyecto donde no puedan ingresar mas librerías a lo loco sin dar una buena explicación porque perjudican el performance o porque tocan la dependencia de un montón de otros proyectos, se les va a zafar un tornillo, y no, decir que "se me hace mas fácil con una librería porque ya hace todo" no es dar una buena explicación. Aprendan a hacer cosas con las herramientas que ya tienen o nativas, no todo se puede, pero si mucho.
Cierto, el front y hasta el back estan cada vez mas complejos. Y lo que uno piensa que son ayudas, al final terminan siendo armas de doble filo. Si tienes una aplicacion, y esa aplicacion usa 50 librerias, esto quiere decir que tu aplicacion tiene que tener FE, en que esas 50 librerias esten constantemente activas, actualizadas y mantenidas, osea FE en 50 proyectos adicionales al tuyo. Porque digo esto? porque un codigo desatendido se termina convirtiendo en una puerta trasera para posible hackeo. Estamos en una epoca donde a todos los vulneran, y se esta viendo una corriente silenciona donde se esta convirtiendo en estandar, donde todas aquellas aplicaciones que manejen grandes volumenes de datos o manejen algun tipo de saldo, punto canjeable o criptoactivo, se minimice la cantidad de librerias usadas, lo mas posible. No porque tengan mas librerias la app es mejor. Yo estoy en proyectos, donde las librerias que usamos estan en constante checking, y si algo se puede hacer a mano con vanilla, mejor. En lo que va de a#o, he visto noticias de almenos 5 webs GRANDES vulneradas, solo por librerias con bugs o rotas o desatendidas. saludos buen video.
No me especializo en frontend gracias a dios. Pero cada vez que he tenido que hacer uno busco hacerlo a punta de plantillas, componentes reutilizables y chatgpt, por qué Dios mío el coñazo que es hacer todo eso a mano
Soy Fullstack Springboot Angular, y ya manejo android. No hay nada mas difícil que android, no hubiera pedido hacer nada sin la ayuda de la IA para aprender
Pensé que tenía el video en 1.5x pero estaba en 1x
Yo tb jajajajaja
Es genial.
Jajaja yo estaba verificando
aun asi yo lo escuche en 2x y entendi todo jeje
Yo lo escucho en 1.5
Yo soy front-end developer desde hace más de 7 años, entiendo lo que dice Afor, por tal motivo, cuando ya entras a trabajar en un proyecto real, lo mejor es adoptar un sistema de diseño, si eres diseñador web, puedes crear tu propio sistema de diseño, o puedes optar no por muchas librerías, sino por una que brinde la mayor solución a tus requerimientos. yo recomiendo rsuite, para react.js o next.js que cuenta con todo lo que mencionó afor. ya que no es que sea "demasiado complicado", sino que el trabajo es robusto si se realiza la creación de los componentes desde cero y sin seguir un sistema de diseño. pues va a ser peor.
Yo considero que para ser un buen front-end developer, se necesita ser un buen diseñador también, que conozca de fundamentos de diseño, simetría, manejo de espacios, contrastes, y todo eso que te da bases para que tu ojo sea agudo a los detalles estéticos.
Hola, que canales recomiendas para aprender diseño web.
En mi caso no soy diseñador, pero si me das un diseño se seguir seguimientos para hacerla verse casi igual o igual si no es compleja, por ahi si tengo alguna idea buena para agregar a un diseño, pero fuera de eso, podria ser un buen front-end sin saber de diseño?
El frontend puede ser tan simple o tan complejamente enfermo como se requiera! Éxito a todos los colegas y futuros colegas frontend devs
no, con las IAs ya no, no recomiendes eso, es peligroso
Oye, sinceramente, tu explicación está 10/10. A pesar de lo que comentas, creo que lo que realmente falta es tiempo para abarcar todo lo que implica el desarrollo Frontend: animaciones, accesibilidad, i18n, optimistic-updates, caching, gráficos, librerías 3D, etc., y todo esto sin dejar de lado el rendimiento de la aplicación.
Espero que este video llegue a aquellas personas que, queriendo o sin querer, desmerecen el trabajo del Frontend sin saber realmente todo lo que implica.
los problemas de asincronismo en el frontend estan infravalorados, hacer que todo renderice en su orden y prevenir pre renders es un dolor de cabeza a veces (cuando piensan que frontend solo es una web bonita)
Mi estimado, usted tiene toda la razón.
Por esto ser fullstack esta entre milagros y falacia.
Entonces porque muchos se venden como fullstack?
Por que son gente que les ha tocado hacer de ambos, pero la realidad es que siempre manejan una área mucho más que la otra@@emanuelr9815
@@emanuelr9815 porque las malas empresas (la gran mayoría en latam) quieren ahorrarse dinero contratando un "todo en uno".
@@emanuelr9815 cuánto es muchos para ti? 2% 12% ? Veamos las estadísticas de stackoverflow LinkedIn Glassdoor Upwork. Y no nos referimos a vacantes sino a perfiles Dev. Recuerda que son las empresas equivocadas que tratan de meter más funciones en un solo cargo para evitarse pagar 5 personas en una. Es por eso que arfordigital está reclamando.
@@emanuelr9815 hay 3 opciones normalmente, prefiren pagar a derrolladores con grandes limitaciones especificas por ahorrar dinero, realizan tareas intermedias, osea realmente no se dedicana crear todo un sistema sino a integrar las partes o simplemente hacen proyectos para pequeñas empresas o individuos, donde el aspecto es lo que importa, el back mientras cobre y no se caiga es suficiente
No he echo backend pero por parte de frontEnd veo que tienes que mantener estados, evitar fugas de memoria, tienes que validar texto, tienes que ver que tú pantalla se ves bien en todas partes, etc. Pero siento y creo que el backend es como las matemáticas, las personas lo ven complicado pero si conoces las reglas todo se vuelve repetitivo y espero que sea así y lo más difícil sea el primer análisis y luego a construir
si bueno matemáticas, bastante lógica diría yo como todo el mundo metido en esto porque lo algoritmos que quizás necesites no te los comes tu, pillas librerías, ChatGPT o las buscas por ahí y las adaptas xD
No es repetitivo, porque cada trabajo pide cosas diferentes en base a la necesidad del cliente. Para poder entender que tan complejo es tendrias que trabajarlo, asi como un front no puede comprender a un back hasta que lo trabaja, te lo digo como full stack tanto el front como en back tienen sus complejidades
@@petersonperez7875Cierto, pero mi pregunta es con todo el conocimiento que tienes, en back por ejemplo lo usas para casi todo, sin embargo en front tien un mundo ademas que para un front usas un fremw logica casi diferente de otra ahí radica el front, del back
Cada uno es su mundo, el backend tiene reglas y reglas de reglas. Por ejemplo, muchos programadores full stack suelen pensar que hacen un API con express y postgreSQL y ahí acaba el backend pero la verdad es que así como hay frameworks y estructuras de frontend también suele haber en backend.
Un ejemplo es cuando haces un backend en Java pero en microservicios y encima en monorepo, tienes que crear un dockerfile para levantar cada uno de esos microservicios y luego usar docker compose para manejar todos esos, aparte de que cuando haces microservicios debes tener una capa de comunicación la cual requiere otro docker como Redis por ejemplo o puedes incluso levantar un microservicio en cada puerto y configuras nginx como reverse proxy para redirigir solicitudes, aparte si quieres usar sockets para eventos a tiempo real como un streaming entonces tienes en algunos casos que hacer uso de librerías o programas tu mismo para conectarte a esos eventos y manejar manualmente el lfujo de bytes recibidos, o incluso en kotlin o rust tienes que saber cuantos y cuales hilos usar para cada proceso, esto por lo general javascript se encarga de manejar los hilos, y si quieres hacer un gateway de graphql es otra historia, programar esquemas además.
Todos son su mundo, yo digo que frontend y backend van muy de la mano aunque sean de conceptos distintos, pero creo que la gente los compara mal porque suelen comparar un seniority en frontend contra un junior en backend creyendo que backend es CRUD y ya
@@brahianarias-8872 tienes razon, pero en estos ultimos años, la evolucion de front y todas las cosas que sale de un dia para otro creo que estresa a un programador front, de al menos saber entender como funciona, en back no se la historia sin embargo no veo tanto algo nuevo en back, creo que ahí radica el problema, hoy aprendes algo mañana ya sale otra cosa, las empresas empiecen a considerar usar
Y algún jefe alguna vez me dijo que era "hacer dibujitos en la pantalla"
Los jefes solo saben decir como vas?
Yo con HTML, CSS y JavaScript en el bolsillo 🙃
Vas bien
X2 😂😂
Suerte con ello, esta dificil el mercado para ya los que tienen varios años de experiencia no me imagino para lo que recien empiezan
@@coldcoder23es que ya el desarrollo web no es tan lucrativo como antes (no es que no se pueda, pero necesitas demasiadas skills y que te necesiten para trabajos muy específicos), no como antes que eras junior y podías ir aprendiendo en la misma empresa.
@@coldcoder23 El mercado está bien desde que sepas inglés.
Trabajo en una empresa en la cual la solución SaaS que ofrece es literalmente la app que has descrito, y la desarrollamos en Angular.
Gracias por visibilizar lo que todos los desarrolladores frontend tenemos que sufrir jaja
Estoy enpezando en programación y todo lo que dice es como escuchar chino jajaj
@@luisaduran9426 Yo hice ingeniería informática y tardé 6 años en acabar, y comenzar a programar se hace muuuy difícil si no tienes una base antes de empezar. Concretamente en desarrollo frontend tengo casi 3 años de experiencia laboral, y me queda mucho por aprender jajaja así que no te preocupes porque te suene a chino, es normal, esto lleva paciencia y dedicación.
awww cosita
yo tambien estoy empezando a aprender a programar, espero poder conseguir empleo en 1 anio
Angular, react y vue, si dominos aunque sea uno, tienes trabajo seguro al menos ahorita.
Las miniaturas son cada vez mejores
Miniatura parecida al video de 'El backend es demasiado complicado...'
Es mi vídeo favorito de internet.
Concuerdo... Hamtafor Hamtafor Hamtafor
Pedazo de video! Por favor haz uno explicando el backend !
En efecto, el realizar apps complejas conlleva a qué incluso el front sea más difícil que el back
jajajajajaja
No estoy de acuerdo. La idea del video no es declinarse por un bando, es generar conciencia sobre la complejidad que requiere el Front-end. Qué el Front-end sea más complejo que el Back-end (o viceversa) va a depender de los requerimientos del negocio
jejeje que comentario tan estupid0
Yo también puedo decir que hagan componentes reutilizables con patrones de diseño y básicamente el frontend solo tiene que copiar y pegar... Jajaja 😂 en el backend no solo es crear api
Los frontend solo creen que un backend es crear 4 tipos de endpoints. Jajaj
por experiencia propia casi 3 meses me toco hacer 2 tablitas pero las doña tablas
Joder, como backend-sre e intento de data engineer quisiera tener estos problemas.
muy bien explicado hermosa, gracias me suscribo, me sirvio de mucha ayuda, para crear mi mockup, me gusta que cuando explicas este speudocodigo grafico se entine mejor.
Primera vez que entro en el canal, me gusta como haces los videos y las miniaturas, mucho ánimo
Aparte de que muchas veces hacemos de diseñadores UI/UX tambien.
Hcae mucho deje de hacer mis propios componentes a usar librerias UI como nextUI o shadcn ya que estas me permiten trabajar mas rapido el estilizar mis aplicaciones, ademas que los mismos componentes puedo hacerlos reutilizables facilitando el desarrollo
Con angular es muy fácil: angular material, ngx-infinite-scrolling, rxjs, subscribe, unsuscribe, input, output, Viewchild, infiniteScrollDirective, tardaría como 3 o 6 horas, pero es puro talachita, por cierto, lo del buscador, obviamente el back debe paginar las responses para facilitar la implementación en el front, en mi caso uso laravel con eloquent, la facilidad de paginate() es una maravilla.
En angular me gusta más que te da las dependencias necesarias y pocas veces necesitas externas, en cambio React tiene muchas librerías, muchas hacen lo mismo y puede que en un lugar te pidan una y luego otra. Pero tambien lo complicado del front es la subjetividad y dinamismo en los diseños que te pueden dar
6:13 Terencio Mentioned 🙌
Una gran diferencia es que en el backend se maneja la lógica de negocios, seguridade de la aplicación y algoritmos necesarios, en cambio el frontend es full lógica de presentación y algunos algoritmos que son en su mayoría para el manejo y visualización de componentes, cada uno tiene su nivel de complejidad no se puede decir que uno sea mas fácil que otro.
totalmente cierto. y siempre tenes a alguien que dice "eso se hace en 2 minutos". cuanto podes tardar en poner un avatar.. cuanto podrias tardar en hacer una simple tablita y exportarla a excel. y cruza los dedos de que la libreria que vas a usar funcione con el framework que estas usando y que en 24hr va a dejar de tener soporte
Buen video.
Para la infinidad de tamaños de pantalla, suele ser buena opción limitar el ancho del container y ya solo tienes que hacer responsive para 3 dispositivos: móvil, tablet y desktop.
Oye Afor, qué lástima que no tuve éste video hace 3 años para mostrárselo a una empresa con la que trabajé, desperdicié horas de mi vida tratando de explicarles esto mismo y no logré que lo entendieran. Por desgracia no lo expliqué tan bien como lo hiciste tu.
Yo traté de explicarlo y no surgió efecto, quien no quiere entender, no entiende. ¡Espero que vaya todo mejor ahora!
me agradaste por lo que explicaste en este video un subscritor mas y aumentando
Un consejo como SR Frontend (creo que lo soy), piensen su arquitectura para que cada feature sea facil de implementar despues, combinando librerias practicas (que no siempre son las mas populares) yo tuve la suerte de crear mi ultimo proyecto solo (unico front) y fue de las mejores apps que trabaje. Lo que tu comentas se complejiza x4 cada vez que agregas alguien al team. ultimo consejo usen react query hasta que salga algo mejor, no usen redux si no tienen que hacer flujos complejos.
completamente de acuerdo. estoy embarcado en un proyecto complejo yo solo, y en mi caso lo mas importante es pensar de forma abstracta sobre la arquitectura y soluciones generales que evalúen no solo el presente ni un caso especifico, sino que evalúen todos los casos probables y no solo el presente sino también el futuro. Para los features estoy usando una especie de Ducks Pattern pero mas sofisticado adaptado a mi caso especifico donde me enfoco en que partes necesito un control centralizado, reutilizable y basado en configuraciones, seria como un proceso de desarrollar mini librerías. Luego también es util pesar en que partes es mejor descentralizar por ejemplo componentes complejos. También es util pensar en capas de complejidad, identificar "stagings areas" que serian partes del algoritmo que en caso de que se necesiten cambiar en el futuro sean accesibles desde un solo lugar que lo abstrae para evitar encontrarte con situaciones futuras que te hagan perder mucho tiempo por una mala praxis de arquitectura, o sobre ingeniería en entornos complejos y cambiantes.
Totalmente de acuerdo. Desarrollar en frontend es puro caos jaja
Lo bueno que tiene frontend es que es más sencillo recibir feedback del resultado. Y a la vez, a veces debugar cuando falla algo es un infierno y hay que volverse loco haciendo prueba y error. También cuesta mucho configurar el IDE, dependencias y el proyecto para que funcione la primera vez (y mas te vale no tocar nada para que no se rompa).
Por otro lado, backend es más "lento" de implementar, crear tests y probar. Pero es mucho más estable y sencillo el detectar y arreglar un error. Además, no tienes que volverte loco porque cada 2 meses hay una nueva librería de moda y la que usabas ya ha caído en desgracia 😅🙌🏻
en mi opinion lo mejor es usar una libreria como shadcn o sin estilos radixui, react query y si se quisiera zustand pero ppr lo que se usaria en este esquema se podria usar context tranquilamente.
Una buena libreria de componentes te cambia la vida
Yo soy front-end desde hace casi 6 años y lo que dice Afor es cierto, al principio uno piensa que es facil pero a medida que toca expandir el Stack comienzas a pensar a pero q pedo, pero con el tiempo te enganchas y te puede gustar como en mi caso
Anecdota.
Me especializé en desarrollo FullStack. Para las practicas profesionalizantes debía salir a buscar un cliente a quien hacerle una pagina y lo hice con una rectificadora importantisima. Utilicé Django y Bootstrap y:
-No sabía usar Django.
-No sabía con que se comía Bootstrap.
Aprendí sobre la marcha y como me manejo bien con javaScript, decidí no utilizar ninguna librería mas para hacer el front. Absolutamente todo el front logico lo hice con js nativo. desde los buscadores hasta los filtros. Terminé con muchisimas carpetas y cuando los profesores lo vieron se les dibujó el horror y el miedo en el rostro jajaja
El buscador de filtro puedes hacerlos desde el backend, no se compliquen tratando de adaptar algo que debe de ser por petición
Cuando se tiene conexión lenta el filtro podría tardar más que el javascript del navegador
Solo he visto este video tuyo, y me gusto mucho, muy cierto todo.
es increible, gracias yt por recomendarme esta
¿Eres Backend?, todos los Backend dicen lo mismo, como reto personal hice este Dashboard con tan solo una libreria "MDB 5" y me tomo 2 horas, 37 minutos 13 segundos. No me parece tan dificil ser Frontend, es divertido y me permite ser creativa.
Como reto personal yo puedo hacer un back-end mucho más rápido de lo que tardo haciendo el Front-end. Inclusive con servicios como supabase o firebase tengo un back-end con db, storage y auth a un solo clic. No por eso voy a decir que el Back-end es fácil. En el mundo real hay muchos factores que llevan a que uno sea más complejo que otro.
Lo que sí creo que deberíamos dejar es la idea de que el Front-end es solo pintar cosas y ponerles colores. Hay mundo entero más allá de eso.
Pixel perfect se hacía antaño y se sigue haciendo a día de hoy. La interfaz se tiene que modularizar con dimensiones, a ser posible múltiplo de 8 por motivos que ahora no vienen a cuento de cuando surgieron las pantallas de PDA, pero bueno. Otra cosa es que CSS ya permite hacer tipografías y contenedores fluidos usando funciones que abarcan un rango entre un mínimo y un máximo como clamp() y te ahorran cientos de lineas de media queries, pero modular se modulariza, ayer hoy y mañana, y hay toneladas de literatura sobre usabilidad que dan reglas para ello, porque luego salen los N,algo pixels de medidas y eso muchas veces da dolorcitos de cabeza
Dios mio, creo que me perdi ese directo, pero se ha vuelto uno de mis videos favoritos de Front, me abriste la mente y me hiciste pensar mucho, que crack...
tambien depende como lo quieras ver, yo siento que es muy facil el frontend (Al menos para mi, porque me gusta diseñar) pero se que lleva su grado de complejidad. asi que depende que tanto te guste hacer tu trabajo.
y sin olvidar que muchas de esas librerías o dependencias a su vez tienen otras dependencias, y a veces tienes varias versiones de las mismas dependencias, o dependencias deprecated, inseguras... y poco control sobre ellas ya que se alojan en el agujero negro que es el node_modules...
Y podrías dedicar otro vídeo solo al tema del deployment y las development dependencies que es otro mundo también, que si librerías para que te hagan las migraciones a la base de datos, los tests, los scripts, las github actions, linters, formatters, transpilers y packers jaja es un no parar...
Usa pnpm entonces. Solo descarga una dependencia para todas las librerias. Te ahorraras muchisimos problemas
Uso pnpm, es más estricto que yarn, bun o npm, pero no te evita esos problemas que te comento, aunque te los mantiene bajo control, y al menos nos da la opción de especificarle manualmente las versiones o resoluciones (de las subdependencias de nuestras dependencias) o incluso hacer pnpm patch, aspectos que uso a menudo. Me sorprende que la mayoría de devs simplemente ignoran el output de un pnpm install.
si JAJAJAJAJAJJA estaba rayadisimo por que la pagina del cliente no se veia como en mi telefono, tablet, pc, tv, etc. Pues resulta que el maldito "bg-cover" (no se como se escriba en css pero asi es en tailwind xd) NO FUNCIONA EN DISPOSITIVOS CON IOS, y se veia refeo en su ipad pro y su iphone, y pues lptm si no fuera por que me consegui un ipad prestado nunca me hubiera dado cuenta de esa cosa, igual pude hacer que se viera bien ajustando las dimensiones minimas para que se usara el bg-cover solo en resoluciones mayores a QHD
Esta buenísimo el video, ojalá hagas más abordando temas más específicos como lo de las pantallas, navegadores, etc.
Me encantó el vídeo, de alguna manera me hizo entender que no puedo desarrollar todo desde cero siempre XD
Ver el vaso medio lleno o medio vacio es cosa de cada uno, yo lo veo medio lleno y siento que es más facil de lo que aparenta. Si nos ponemos a desglosar y detallar cada operacion pues obvio no terminamos nunca, pero, si lo vez de manera neutra te daras cuenta que todo es igual. Nuestra vida cotidiana se basa en pasos y pasos y pasos y al final no es mucho o a veces haces 1 paso y es algo muy grande. El problema real son las empresas y personas que creen que somos magicos y además que ellos creen que se expresan bien, le dedico toda mi mente a la toma de requerimientos y eso ha hecho que no me agobie con tonterias, además, de la reutilizacion del codigo propio y la creacion de librerias y paquetes propios ayuda un monton en lo que se habla en el video. Saludos de un fullstack y suerte a todos codificando a toda la comunidad❤🫶🏾💯
me agrada tu rant! jajaja comparto totalmente
me gustan estos videos que muestran la realidad de desarrollar software de calidad y de verdad util. no es como te lo pintan de que después de entender como funcionar tal o x tecnología ya la dominas o podes hacer lo que quieras con ella. sino que la verdadera capacidad de desarrollar software de calidad es proponértelo, un objetivo alto con todas las cosas a tomar en cuenta en cuanto a metodologías, arquitectura, patrones, practicas, etc. y forjar la habilidad a base de errores y experiencia de forma constante por mucho tiempo, hasta stackear una gran cantidad de soluciones en cada una de las etapas y capas de desarrollo. Creo que un dev que no haya llegado a ese punto no puede considerarse un desarrollador de software serio. La mentira de pensar que desarrollar software es para todos o que es fácil les saldrá mas cara a medida que se normalice la demanda anormal que tuvo y todavía esta teniendo el sector (solo que se protege cada vez mas de los pseudo programadores últimamente) por lo que cada vez será menos probable que contraten "desarrollares" que únicamente pican código pero que no saben ni los principios mas básicos de que es lo que significa desarrollar software tan siquiera.
Nextui ayuda mucho jajajja de las mejores librerias de componentes
Totalmente cierto! todo todito, todirijillo. Yo me pase se react a svelte para acelerar mi desarrollo hace un tiempo y fue la mejor decisión. De todas maneras, el gran problema del frontend es la cantidad de librerías que se deprecan a diario. React sufre muchísimo ésto por ser tan usado, pero nadie se escapa.
Los dashboards son el diablo
gran carisma, nuevo suscriptor por aqui, saludos. !
La mayoria de las veces se puede valer solo con un framework (Vue/Angular) y una libreria de componentes como Vuetify o Angular Material.
Evidenmente si no se escoge un stack completo antes de empezar el proyecto puedes recaer en un infierno de librerias, pero por ello es bueno hacer un analisis de los que puedas necesitar con anterioridad y hacer un peqeueño researching, con eso puede que te des cuenta si necesitas una libreria completa de componentes o no.
Me iba descojonando cada minuto del vídeo porque es tal cual 😂
En mi caso estoy más en el backend pero me gusta estar al día de lo que pasa en el front en mi trabajo en la medida de lo posible.
Añadiendo a lo que comentas, el frontend tiene el contra de que al tener tanta librería y framework es fácil que al iniciar un proyecto se acople tanto a ellas que luego mejorar la arquitectura cuando llegas a esa etapa del proyecto que ya se ha validado la idea de negocio sea un pain brutal.
Pero bueno, hay que hacerlo igual 🙃
Ahora estudiando Signals en Angular 😅. Me ha gustado el programa. Al primer momento he temido que llevaras tatuajes por el exceso de maquillaje, que últimamente les he pillado manía. Subscrito.
oigan yo hago experiencia de usuario de manera profesional y pienso que tener acotadas las casuisticas ayuda a tener tangibildad del que queremos crear y ayudar a mi equipo técnico a concentrar esfuerzos donde debe para que cobre impacto todo lo que estamos haciendo.
Ojala exista algo que unifique todo, porque igual dominar varias cosas, react, Javascript, css, html, bootstrap, web pack y todo, la curva de aprendizaje es larga y los días pasan, y pues debe desarrollarse algo que eso sea mas simple, y mas si nos vamos de lado del servidor
Debo decir que llevo con php html css y js bastante tiempo y soy bastante reacio a utilizar librerías "the modern way". He visto desarrolladores usar librerias de npm hasta para hacer circulos... Lo cierto es q siendo un poco pulcro con el código, quizás dividiendo responsabilidades entre ingeniero de datos, maquetador y tal.. las cosas salen bastante bien sin reventarlo todo de librerías y sin necesidad de tener en cuenta 700 pantallas (con 5-6 tipos y un min y un max vas que chutas)
que la propiedad "right" no funcione en mac supongo que es un mal ejemplo escogido aprisa y corriendo en directo, pero a menudo pasa que los desarrolladores le tienen alergia a entender qué es cada propiedad de css y como usarla, y esto es precisamente porque: "libreria hacer por mí".
Dios mio, en mis tiempos todo eso se hacía a mano en js, la única posible librería a utilizar era jquery y eso era difícil,tal vez es mi percepción pero ahora las librerías hacen todo muucho más sencillo, recuerdo el infierno que era hacer una tabla de esas dinámicas, pero es mi percepción.
Soy ingeniero de TI pero no he tenido la oportunidad de ejercer así que comenzé a especializarme en front-end. Ahorita estoy estudiando CSS puro, voy en el tema de responsive y flexbox ¿voy por buen camino? Por que en las ofertas de trabajo la mayoría pide frameworks tipo bootstrap o wordpress y ya no se si estoy perdiendo el tiempo o no xD
No hay ningún campo de la informática que me de más pereza que el frontend.
Prefiero programar en ensamblador, contando cada bit, antes que tocar frontend.
Y aun asi hay gente que solo trabaja con wordpress y se indigna de que les digamos que es un trabajo facil
Dale es verdad, yo trabajo como full stack con react y django, y definitivamente siento que trabajar en el frontend es un poco mas tedioso por todo lo que implica, ya sea el diseño, los estilos, las integraciones con el back, etc. Ahora ya tuve mucho frontend y pedí mas tareas del back jaja ya mucho css.
muy bien dicho, demasiadas librerias en el frontend!
Con los años vas asumiendo todo de forma gradual y cada vez haces todo de forma más sistemática. Obviamente, todo de cabeza suena muy tedioso, pero cuando llevas un orden, solo se convierte en pasos a seguir.
las tablas tambien hay librerias, como material UI
Añade transpilar, compilar, bundleizar,ofuscar... hacerlo compatible con SEO, Babel, linter, prettifier, typescript...
Qué ya no es como antes para eso esta el boostrap de css ahí muchas que lo hacen más fácil todo y yo no me apaño con boostrap yo aprendí directamente con hacerlo en css directamente al principio complica todo pero luego con el tiempo y la experiencia se hace más fácil las cosas y también con frameworks se hace más fácil las páginas webs, ayudan bastante
Mis compañeros después de explicarles todo lo del vídeo:
"Estimación: 3"
el frontend no es complicado cuando agarras costumbre, puedes aplicar todos lo colores o animaciones, lo difícil seria la parte de diseño, diría que si.
Me encanta hacer la logica del front end pero hacerlo full responsive ultimamente es una locura para cada dispositivo jajaja
Saber jugar con flex, grid, media queries y los clamp para el texto
A mi me parece que mas que complejo, es la cantidad estupida de trabajo que puede llevar dejar todo bonito, te puede llevar mas tiempo del que te gustaria admitir con un maldito botón que haga alguna animación o que tenga algun requerimiento raro del cliente.
Mejor centrarse en algo como java que está en el índice tiobe
@@henryleonavicarioq es tiobe
No es complicado. El problema es que la mayoría de programadores no son diseñadores y no saben diseñar interfaces. De hecho, es por eso que el uso de frameworks de terceros se hizo masivo.
Me estaba bajoneando por lo que hago en web y lo estaba viendo de menos, pero ver este videoy recordar como es la lógca, el diseño que implica....qué "fácil" ...pensé xd
Por eso me gusta mantener las cosas minimalistas con Python, HTML y Tailwind CSS. Sin librerías adicionales ni complicaciones.
Igual muy divertido el video, me suscribí.
El desarrollo de software siempre es un reto para cualquier tipo de desarrollador. Hay que tenerle amor a los estudios
7:03 ¿qué no eso lo hace bootstrap y similares?
El front es mas renegar con config, q de te vean las cosas bonita. El verdadero programador es el backend, el front es mas un diseñador que se la rebusca para q queden las cosas bonitas combinando tools, librerias, etc. El backend es hermoso xq es logica, performance, optimizacion, matematica y toda la complejidad q uno estudia en una universidad por ej la carrera de cs de la computacion. Es la base de todo y es donde todo nacio. Es una verdad q ofende a los frontenders
Lo bonito mi amor es que existe algo que se llama encapsulacion, modulizacion, y todo eso que nos abstrae de tener que pensar que todo es complejo. Ademas esa es la naturaleza del software. Pero cierto es lo que tu dices: en algo tan simple hay detras una gran catidad de faena. Por eso hay que cobrar bien 😂
Es como hacer un Slider... yo no me habia dado cuenta de la complejidad que tenia hacer eso... ojala fuera tan facil como los Sliders que uno hace cuando se esta aprendiendo jajajaja. hay que tener en cuenta que si es touch, que si es con bullets, que si se quiere tener solo 5 bullets para 100 slides... entonces que como se calcula cuando se activa cada bullet, que si presionas un bullet a a que rando de slides te debe de mover.... y asi puedo seguir con un monton de cosas que nunca tuve en cuenta hasta que me toco hacer ese Slider desde cero... Ojala todo fuera tan sencillo como los componentes que uno hace cuando esta aprendiendo xd
una vez tuve que hacer un slider con range 100% custom y accesible, y fue de los mayores retos que he tenido, 100% de acuerdo!!
Por fin ALGUIEN QUE HABLA SOBRE ESTO!!!!!!, te felicito, el front end es una verdadera M................... Bravo por tu video
aqui uno que se graduó el viernes del ciclo superior de asir haciendo ahora el proyecto final con una api y una web y spoiler estoy atascao con la api. YA ME ESTA DANDO MIEDO LLEGAR A LA WEB!! pero eh te llevas un nuevo sub :)
Wao que explicacion! me dejaste pegado al ordenador hasta terminar el video y no solo por lo linda 😉!!
Me encantó el video y la exlicación... entonces ¿no es bueno llenar de librerías un proyecto? ó ¿como saber cuando si y cuando no usar una librería?, saludos!
Me gustó tu video, me suscribo
Creo que nunca ha encontrado a un desarrollados backend que teresuelve casi todo lo que ha dicho 😂
Mi profe de brasil favorita
Cuando lleguen a un proyecto donde no puedan ingresar mas librerías a lo loco sin dar una buena explicación porque perjudican el performance o porque tocan la dependencia de un montón de otros proyectos, se les va a zafar un tornillo, y no, decir que "se me hace mas fácil con una librería porque ya hace todo" no es dar una buena explicación. Aprendan a hacer cosas con las herramientas que ya tienen o nativas, no todo se puede, pero si mucho.
Imagínate los que programan el navegador que renderiza todo eso XD.
Este es el autentico "Estoy cansado jefe" de la vida
frontend estan complejo como quieras es opcional
Es verdad... ahora a explicárselo a mi jefe es lo difícil. y cuando esta listo agrega mas cosas Dx
Cierto, el front y hasta el back estan cada vez mas complejos. Y lo que uno piensa que son ayudas, al final terminan siendo armas de doble filo. Si tienes una aplicacion, y esa aplicacion usa 50 librerias, esto quiere decir que tu aplicacion tiene que tener FE, en que esas 50 librerias esten constantemente activas, actualizadas y mantenidas, osea FE en 50 proyectos adicionales al tuyo. Porque digo esto? porque un codigo desatendido se termina convirtiendo en una puerta trasera para posible hackeo. Estamos en una epoca donde a todos los vulneran, y se esta viendo una corriente silenciona donde se esta convirtiendo en estandar, donde todas aquellas aplicaciones que manejen grandes volumenes de datos o manejen algun tipo de saldo, punto canjeable o criptoactivo, se minimice la cantidad de librerias usadas, lo mas posible. No porque tengan mas librerias la app es mejor. Yo estoy en proyectos, donde las librerias que usamos estan en constante checking, y si algo se puede hacer a mano con vanilla, mejor.
En lo que va de a#o, he visto noticias de almenos 5 webs GRANDES vulneradas, solo por librerias con bugs o rotas o desatendidas.
saludos buen video.
Pruebas una app en local y funciona, pasa 1 mes y ya no funciona mas
No me especializo en frontend gracias a dios. Pero cada vez que he tenido que hacer uno busco hacerlo a punta de plantillas, componentes reutilizables y chatgpt, por qué Dios mío el coñazo que es hacer todo eso a mano
Banda, ya me enamoré 😢❤️💻
La mejor definición de desarrollo frontend que he visto 👌🏻
Las tablas no tendrían porque ser complejas al menos que no tengas experiencia.
Soy Fullstack Springboot Angular, y ya manejo android.
No hay nada mas difícil que android, no hubiera pedido hacer nada sin la ayuda de la IA para aprender
en la tabla, lo del buscador es lo mas facil :V , lo mas dificil es la paginación según las condiciones y filtrados
po imagina hacer todo eso por con lit element en una spa a pelo con 0 librerias e infinitamente reutilizable y escalable MI TRABAJO
Es cuestión de gustos. Otros dicen que lo difícil está en backend.
¡Cuanta verdad! Buen video 😆👍
Gracias por el contenido, esto le pasaré a mis clientes para que entiendan lo difícil que es