Ruby on Rails es una gran tecnología y muy buena, se han creados muchos productos con ella. DHH y Theo han tenido sus roses desde hace rato por el tema de Javascript, creo que esta vez Theo se paso y quedo muy mal, porqué a pesar de que DHH a veces se comporte arrogante es un gran programador y muy innovador que ha aportado mucha simplicidad a la web y por eso es su descontento con los lenguajes typados como typescript. Al final, cada quien programa y es feliz con lo quiere, yo programo en Ruby y me va muy bien con esta tecnología.
Ps yo no me quejo de Ruby on rails, llevo un año trabajandolo y me ha parecido un lenguaje excelente, facil de entender y la interacción con las bases de datos es muy sencilla. Sinceramente es el lenguaje que más me ha gustado.
Puedes usar Rails 7 sin Hotwire y meterle React, Vue o lo que quieras. Hotwire es opcional. Su ventaja es que reduce el número de horas en un proyecto. Para MVPs rápidos, RoR con Hotwire es perfecto. Luego, si el producto madura, lo mueves a un front framework. La potencia de Rails está en su back y la cantidad de gems que tienes a tu alcance.
@@JuanFernandoGallegoGomez Airbnb y Github estan hecho en RoR.
Před 3 měsíci+18
eso que ahora lo ven como "super moderno" era cómo empezo ajax, hacias solicitudes al servidor con un click y en un div cargabas la respuesta que era HTML y no json. El mundo del desarrollo se está volviendo un caos, antes era que había que darle más trabajo a los clientes perezosos (browser) y salieron los frameworks javascript y ahora que mejor siempre no 😑 Yo ya deje por un lado el famoso server side rendering no me aporta NADA nuevo que no pueda hacer con c#, PHP o java y los frameworks de toda la vida.
El otro dia me recomendaron filament para hacer un back, que usa algo llamado livewire presentado como algo "moderno" y cuando vi que devolvia HTML por peticiones AJAX me quede como wtf??? ya existe algo mejor y es con JS, quizas el problema aca es que hace falta un framework que tenga una curva de aprendizaje más rapida, o directamente separar back y front como se viene haciendo y poner un profesional para cada area del desarrollo... o no se. Yo soy back y de front lo que toqué es Vue.js y me parece el framework con la curva de aprendizaje más corto que hay y ademas es rapidisimo, estan trayendo cosas que no necesitamos.
Jajajaja total, los nerds haciendo micro benchmarking pelandose por 0.0000005 segundos que no se aplican en la vida real, ni desde aqui en Venezuela tengo conexion tan mala!
En mi opinión cargar el propio renderizado en la parte del servidor no tiene ningún sentido. Al final el servidor tiene mucha mas carga, cuando cada vez hay mas capacidad de computo en la mano de los usuarios, pero yo que se. Yo solo pasaba por aquí.
HTTP está diseñado para devolver texto; JSON es texto, XML es texto, HTML es texto. El servidor no está renderizando nada, construye texto, devuelve texto; el navegador (más específico el rendering engine) es quien hace el rendering.
@@rtalexk Pues eso la generación de texto y eventos que se haga en el cliente para hacer un uso redistribuido de los recursos. Los datos se pueden transferir en formato JSON. No tiene sentido gastarse el dinero en servidores cuando la parte visual se puede hacer toda en el cliente. El cliente lo único que tiene que hacer es presentar los datos que el servidor le entrega y el servidor gestionar los datos que el cliente le entrega. Hacer todo en el servidor es un desperdicio. Por otro lado no caigamos en fundamentalismos. No hay herramientas fundamentalmente buenas ni malas solo son fundamentalmente herramientas.
Jajaja eso suele pasar mucho cuando el usuario tiene conexión regular o mala, si no se pone un loader o un optimistic render o similar, el usuario le va a dar enter o clic muchas veces Jajaja
Existe una persona más detestable actualmente en el desarrollo web que Theo? El tipo está literalmente hablando mierda de cualquier cosa que no sea JavaScript/React para intentar convencer al resto que JavaScript/React es lo mejor que le pasó a la humanidad. Me pareció excelente la respuesta de DHH haciendo dos cosas, - primero: solucionó algo que era muy sencillo y no ameritaba armar tanto escándalo; - segundo: la reflexión sobre esta tendencia de que tienen personas como Theo de que para hablar bien de lo que a ellos les gusta lo tienen que hacer hablando mierda de tecnologías que a otros les funciona. Y para eso cita el inicio de Ruby on Rails donde no se criticó ni tiró mierda a otra tecnología simplemente lo presentaron diciendo "hey, hicimos esto, puedes hacer esto así, te sirve para hacer tal cosa. A nosotros nos soluciona estos problemas, ojalá también les sirva a ustedes". Theo está empecinado en hablar mierda de todo el trabajo de los demás, no hay que darle más vueltas a eso.
JS es una verguenza de lenguaje. Si no te hace humilde, es porque no entendiste nada. Es mi sincera conviccion que cualquier persona que piensa que JS es bueno, es porque no conoce ningun otro lenguaje, o trata de usar C en la web, sino no se entiende. Y mira que Ruby tampoco es santo de mi devocion, pero no le rompen los huevos a nadie. Los JS fanboys, sin embargo ...
vengo del mundo backend puro, pero hace un año empecé a ver frontend, y realmente es muyyyy intreresante, creo que en estos tiempos es necsario aprender frontend.
Y no es solo experiencia de usuario, si quieres ser lo más eficiente en tu página, necesitas usar la tecnología adecuada para cada caso. Imagina que eres una empresa grande que recibe muchos formularios, si tuvieras que enviar y recibir feedback por cada error de cada usuario, vas a cargar tu servidor innecesariamente. En cambio, si haces una validación inicial en cliente y luego en servidor, más del 90% la información que envíes al servidor solo lo tienes que validar una vez y procesar. Al final cada lenguaje y cada Framework soluciona un ámbito de problemas, el caso es hacer una buena exploración para elegir aquellos que consideres más importante y que te solucionen el 80% de los problemas lo antes posible.
Hotwire es la versión de Htmx en Rails consiste de turbo/stimulus turbo entregaría el html desde el server y stimulus daría la interacción con javascript.puede ser híbrido según el caso de uso no tiene que ser todo el html desde el server
Soy desarrollador de Ruby on Rails, y es bien sabido desde hace años que es lento en cuestion de performance en comparacion con otros frameworks, perooooo la velocidad de desarrollo es mucho mayor, es por eso que es un excelente framework cuando eres un startup y lo que que quiere es tener un producto para probar tu modelo de negocio, a medida que la app escala, es recomendable ir cambiando de framework o arquitectura sin lugar a dudas, pero para cada trabajo es mejor escoger la herramienta adecuada.
Ya, pero dile esto al ceo de la startup que no entiende de tecnología. Simplemente te dirá que está bien lo que hay y que construyas sobre ello. Al final se va volviendo una bomba de tiempo que recién te pediran cambiar cuando está avanzado. Haciendo de tu vida laboral un infierno.
Es que pareciera que es una dirección del marcado. Al menos con Laravel, ya tienes varias opciones así, no tocas el front para nada. El mercado determinará si lo adopta o no.
Es que si es server side rendering es un poco dificil que lo adopte el mercado, las grandes empresas tienen que mejorar sus procesos y pasar del client side rendering al server... necesitas mas servidores, ergo es más caro todo... yo no le veo futuro a esto, es una simple tendencia temporal.
@@jeko3700 Si, hay algo de eso, pero como debes saber hay truco, incluso tambien con JS y no está nada mal. Para mi no es para todo y hay casos de casos.
gracias a esto , descubrí que puede hacer lento las peticiones, me hizo de gran ayuda porque el frontend hacia una recarga rapida despues de un request y no me dejaba ver la url de la request , el payload, etc , jajaj ty midu
Porque les gusta la idea de disfrutar de su trabajo? Yo tengo que usar TS y me quiero cortar los huevos con una cuchara a diario, no imagino encima no tener tipado.
Me parece una tontería como una casa xd A mi me pasaba eso, ya que me salia mas a cuenta parsear una parte de la UI en el lado del servidor, lo que hice fue un fallback porque no podía hacer una optimistic UI porque no tenia sentido. Todo depende de la necesidad que tengas
genial midu, no solo es salseo, es información genial de javascript, de csr y ssr, experiencia usuario, ux optimista, etc, y mucho sentido común en todo, gracias midu!
Coincido que todo se puede hacer bien en ambos enfoques. Pero como Rails dev agregaría que su filosofía siempre ha sido CoS para sacar aplicaciones y prototipos como pan caliente. El rendimiento y la experiencia del usuario es algo con lo que hay que jugar acorde a las necesidades complementandose con Js
No entiendo la necesidad de querer hacer ver mal a X o Y tecnología solo por el simple hecho de que no usa o no es lo que tu quieres (no lo digo por ti Midu), yo amo Rails, pero uso JS, TS, Java, Python, PHP, Kotlin, y todos tienen sus pros y contras. Pero por ejemplo, si yo no uso el servicio de HEY, para qué voy a estar "probándolo" o probando que está "mal" según mis "estándares", no lo uso, pues ni lo volteo a ver. A la gente le gusta hacer polémica para tener visibilidad o porque tienen suficiente tiempo de sobra para estar haciendo tantas cosas de estas... baah...
@@r-tn5zr estimado, tengo bastante tiempo utilizando RoR, y conozco el entorno tanto de Ruby como de Rails como para conocer el contexto, no entiendo tu comentario si a lo que voy es que no hay que criticar herramientas, si DHH es como es, no lo puedo controlar pero no apoyo eso, me encanta la herramienta que creó junto a su equipo en Rails, y nada más.
@@r-tn5zr y por eso mi respuesta, si DHH es así, allá él, pero no lo estoy justificando ni nada, ¿O eso te pareció a ti? Porque yo decía que no entiendo por qué la gente critica solo porque no es afin a X tecnología, y en ese sentido no estoy exonerando a nadie. Te puede gustar menos X o Y, y listo, y si no te gusta, no la uses, y si no la usas para qué criticar...
Exacto en Ruby On Rails también se pueden aplicar todas estas tecnologías (Vanilla JavaScript, React, Enfoque Optimista, etc.). Simplemente fue una decisión de los desarrolladores usar una u otra.
20:31 Pero digamos que andas rápido y mueves 10 elementos drag a su lugar designado, los mueves rápido y ves que se movieron. Cierras el navegador, pero no se llegó a mandar nada y tu no lo sabes...
Theo debe estar enojado porque su video de por que "javascript no necesita un laravel o rails" tuvo un backlash enorme. Hay un excelente video de respuesta hecho por un youtuber llamado Daniel Berg, y DHH retuiteó el video. La realidad es que el ecosistema node se esta volviendo demasiado impredecible.
Esquematización no tiene sentido enviar hasta h1 y tags HTML cuando se puede pasar en un JSON comprimido y evitar cargas de red in necesarias re utilizando cosas que se pudieron obtener solo con una petición de n archivo JS o algo (mi opinion)
No creo que sea un tema de no "usar nada de javascript" es que hay todo tipos de caso de uso y gente que no domina (ni quiere dominar) estos frameworks de frontend tan increiblemente enredados. HTMX es la mejor idea que he visto de esto, y es una libreria de JS! el problema es que muchos no quieren entender que a veces una app se puede hacer sin react/vue/angular o cualquiera de estos frameworks. Hay todo tipo de casos de usp por supuesto y ni HTMX ni React (ni nada) son perfectos para todo
soy noob, pero me atrevo a opiniar 😁. me gusta muchisimo js por su forma sencilla de escribir code, pero si que sueño el día en que le pongan los benditos tipos 😅, se que existe tsc, pero a es un dolor tener que estar creando carpetas para types, odio eso con el alma. intenté pasarme a golang, pero es duro encontrar información tan fácil como encuentras algo sobre js, siento que tiene mas comunidad.
@@josebecerra7719 en unos años pienso cambiar de lenguaje, primero quiero entrar lo mas que pueda con js. al inicio me encantaba el tipo dinamico, pero luego ya como que cambié de opinión y me da rabia que no sea estricto, he estado 2h o mas buscando un error que era una maricada de tipos insignificante. además, cuando probé tsc con vsc fue lo mas lindo del mundo dar control espacio y que te saliera todo lo que podía ser algo. pero igual me gusta js, es jodido explicarlo 😅 tengo fe que algún día tendremos tipos con todas las de la ley.
Me sorprende la atención en minucias de las interfaces gráficas, que son sencillas incluso de modificar y arreglar, cuando eso es lo de menos. Lo importante es la tecnología, lo que es el conjunto de tecnologías, lenguajes.¿ Pero en serio que por un "botoncito" que no responda que es simplemente un par de líneas de modificar, es suficiente para lapidar el gran esfuerzo que hay detrás de todo el conjunto de estas? Sinceramente esto es lamerse las pel...... porque te cuelgan. De verdad deberíamos estar dando botes de alegría de la gran cantidad de tecnologías,, lenguajes, que tenemos hoy en día, y no centrándonos en aspectos que no son ni propios de estas herramientas. Un saludo.
Es por eso que me gusta phoenix liveviews cada canal y conexiones es como un ~websocket si quiero puedo eliminar liveview conectar mis controles a un framework como react y seguir con mi backend. Claro si es que algún día nos alcanza para tener un team de frontend.
En liveview no es ningún problema puede tener millones de canales sin problema puedes tener millones de peticiones son de unos bytes se manejan con una maquina virtual llamada BEAM que es Erlang
Toda tecnología es buena si se usa para solucionar el problema adecuado. Hotwire es una solución estupenda para aplicaciones que requieren de poca interacción de usuario, pero según aumenta esta interacción, la experiencia de usuario puede ser terrible, sin hablar de la capacidad que necesita un backend al que le estamos enviando requests cada vez que un usuario pulsa una tecla. Javascript es terrible (en mi opinión) pero está más vivo que nunca y es claramente por algo.
Bueno a mí me gusta yo pasé de Silverlight a razor Y si recuerdo que en Silverlight había que controlar el doble enter con token para evitar el doble registro en las laptops de la planta
Yo lo veo simple, depende del número de miembros del equipo de trabajo, costos, gustos, etc. Querer meter JavaScript siempre me parece un error y no es ser infantil. Si soy un solo desarrollador que no quiere tener que mantener dos tecnologías donde en JavaScript hay breaking changes cada 6 meses me parece muy loco y poco escalable. Yo pienso que uno debe usar lo que más funcione, aunque no de la mayor experiencia de usuario, pero que funcione bien, tanto para al pequeña, mediana o grande empresa como para los usuarios. La cantidad de requests? Que importa! Mientras funcione bien. Que se queda pegado un poquito? Que importa! Esperar uno-dos segundos no es nada de vida ó muerte en el desarrollo web.
@@stevenperez5260 no del todo, está demostrado que una carga inciial rápida retiene más a los usuarios contrario a la carga lenta, pierdes usuarios, pierdes clientes pierdes dinero..
Yo siempre veo a estos CTOs y sus polémicas como un intento de popularizar sus herramientas. En este caso Ruby... que feo porque a la final solo asustan a sus potenciales clientes.
Yo estoy mas bien en contra de un internet no libre. Cada vez que buscas una web se envía el código ofuscado, cookies por todos lados; en general el usuario no tiene la libertad de saber que se esta ejecutando en su máquina, lo que a fin de cuentas resulta en espionaje y acciones negativas para el susodicho usuario. No se si soy el único con esa vision libre dentro de esta comunidad de youtube pero creo que es algo que se debe hablar a fondo en alguno de los vídeos de midu
Uso Hotwire en mi curro, concretamente Stimulusjs. Lo empezamos a usar porque el lider técnico y el resto del equipo es full php y no quieren saber nada de js ni frameworks de js. Sinceramente es muy incómodo trabajar con él y terminas tardando un montón en desarrollar una tontería, no se lo recomendaría ni a mi peor enemigo
muy mal asumir que todos los usuarios tienen conexiones optimas de internet, para esa gracia volvemos a las aplicaciones cliente->servidor en una LAN y esa no es la idea. Además esa cantidad de conexiones por cada tecla presionada... no se me suena a desperdicio de recursos del lado del servidor también. En una app en producción abierta el publico debe tener buenas practicas y madurarla mas de lo que mostraron en el video, siempre hay que optimizar recursos y ser eficiente.
yo por ej estoy creando una libreria de cache que incluye un dashboard que se renderiza en el servidor ahi lo veo bien y tiene su logica pero no lo usuario para todo la verdad todo tiene sus pros y contras
Cada vez los haters estan locos. La idea idea de que todo se haga en el servidor es pesima porque para una buena experiencia de usuario es necesaria sacar un espacio/tiempo y eso lo da el cliente talvez se podria lograr que todo se haga en el servidor y generar esos espacios pero tendria un coste enorme y una mala experiencia de usuario como resultado.
A menos que no sea necesario, puedes hacerlo cuando pierde el foco del input de esta forma no le estas pegando cada rato al servidor consumiendo recursos innecesarios, porque en 1 a 10 usuarios no afecta pero si son 100 o 1000 haciendo esas solicitudes por cada caracter es una locura
Hay una tecnica que es esperar 300 milisegundos cuando alguien escribe cada letra, para asi esperar un poco a la siguiente. Eso reduce el numero de peticiones.
Usa una función de throttling o debounce (en tu caso debounce sería mejor) , hay varias en Internet, incluso librerías, son muy sencillas de usar y de hacer. La idea es limitar la cantidad de veces que se puede llamar a una función por unidad de tiempo.
No me imagino lo que incrementa el pago en la cuenta del proveedor cloud si cada que presionas una tecla manda un request :S Las lambdas/ec2 corriendo a tope
Todo el que se queja de que quién tiene una conexión así (simulando 3G en el navegador) es porque desconoce el mejor (y único) ISP de Cuba. En fin, viva JavaScript.
Por algo José valin se fue de Ruby on rails y creo elixir (basado en erlang), hoy el lenguaje tiene frameworks tan poderosos como Phoenix que incluye algo parecido (llamado liveview) que es ultra performante ❤. El problema de Ruby es que es realmente muy complejo agregarle al lenguaje concurrencia real y por eso no escala
Me parece que lo de RoR no sera tan bien aceptado, al final esta bueno para quienes sean amantes del lenguaje pero dudo haya ofertas laborales reales sobre ello
La mayoría de frameworks back está haciendo algo similar, por ejemplo Phoenix con liveview,Htmx en el mundillo de Python o alpine ajax, livewire en Laravel, hotwire en rails, está interesante
@@josebecerra7719 claramente Laravel, phoenix, Django y algunos otros frameworks están en gran parte inspirados por Rails.copias tal cual no porque claro que cada uno tiene sus propias cosas, pero la influencia de Rails es fuerte
Que asco damos los humanos de verdad jajajajaja En el deporte es igual, en la politica es igual y por lo que veo tambien en el mundo del desarrollo.... Siempre tendemos a irnos a un extremo y a menospreciar y atacar a muerte el otro extremo.
eso es una ridicules, si tiene tan mal internet, seguramente nosea objetivamente un publico util para la gran mayoria de paginas web, asi como hoy nadie hace juegos para los pentium
@@ed115tahlas empresas privada que tienen fibra y que son carisimas y nada si vives en ccs, pero el internet sigue siendo lento y mas caro q afuera. Y no hablemos de cantv, s la muerte
Ruby on Rails es una gran tecnología y muy buena, se han creados muchos productos con ella. DHH y Theo han tenido sus roses desde hace rato por el tema de Javascript, creo que esta vez Theo se paso y quedo muy mal, porqué a pesar de que DHH a veces se comporte arrogante es un gran programador y muy innovador que ha aportado mucha simplicidad a la web y por eso es su descontento con los lenguajes typados como typescript. Al final, cada quien programa y es feliz con lo quiere, yo programo en Ruby y me va muy bien con esta tecnología.
Ps yo no me quejo de Ruby on rails, llevo un año trabajandolo y me ha parecido un lenguaje excelente, facil de entender y la interacción con las bases de datos es muy sencilla. Sinceramente es el lenguaje que más me ha gustado.
lo de que manden solicitud por cada letra que escriben es de Junior
Yo soy partidario de poner a trabajar el pc del usuario con el frontend. 🗿
Es que es ridículo a veces no creo que ni el 1% de las web del mundo necesite una pc medianamente moderna para ir bien
Cierto. No todos tienen para un servidor que aguante peticiones por cada acción de cada usuario
x2, hay que ahorrar dineros
😂😂😂😂
Aumenta el coste de producir un MVP. Todo depende de la madurez del proyecto. Si ya tienes ingreso ok, si aún no, quieres algo rápido.
Puedes usar Rails 7 sin Hotwire y meterle React, Vue o lo que quieras. Hotwire es opcional. Su ventaja es que reduce el número de horas en un proyecto. Para MVPs rápidos, RoR con Hotwire es perfecto. Luego, si el producto madura, lo mueves a un front framework. La potencia de Rails está en su back y la cantidad de gems que tienes a tu alcance.
Esto debe ser la buena practica, no lo que mostraron en el video en una app en producción.
@@JuanFernandoGallegoGomez Airbnb y Github estan hecho en RoR.
eso que ahora lo ven como "super moderno" era cómo empezo ajax, hacias solicitudes al servidor con un click y en un div cargabas la respuesta que era HTML y no json.
El mundo del desarrollo se está volviendo un caos, antes era que había que darle más trabajo a los clientes perezosos (browser) y salieron los frameworks javascript y ahora que mejor siempre no 😑
Yo ya deje por un lado el famoso server side rendering no me aporta NADA nuevo que no pueda hacer con c#, PHP o java y los frameworks de toda la vida.
El otro dia me recomendaron filament para hacer un back, que usa algo llamado livewire presentado como algo "moderno" y cuando vi que devolvia HTML por peticiones AJAX me quede como wtf??? ya existe algo mejor y es con JS, quizas el problema aca es que hace falta un framework que tenga una curva de aprendizaje más rapida, o directamente separar back y front como se viene haciendo y poner un profesional para cada area del desarrollo... o no se. Yo soy back y de front lo que toqué es Vue.js y me parece el framework con la curva de aprendizaje más corto que hay y ademas es rapidisimo, estan trayendo cosas que no necesitamos.
"Los extremos nunca son buenos".
Buena frase 🤙🏼
Cada vez que veo a alguien quejandose del rendimiento ya pienso en XZ-Utils jajajja
Back doors de los finos 🥵
Jajajaja total, los nerds haciendo micro benchmarking pelandose por 0.0000005 segundos que no se aplican en la vida real, ni desde aqui en Venezuela tengo conexion tan mala!
Yo digo que hotwired tiene un backdoor
En mi opinión cargar el propio renderizado en la parte del servidor no tiene ningún sentido. Al final el servidor tiene mucha mas carga, cuando cada vez hay mas capacidad de computo en la mano de los usuarios, pero yo que se. Yo solo pasaba por aquí.
HTTP está diseñado para devolver texto; JSON es texto, XML es texto, HTML es texto. El servidor no está renderizando nada, construye texto, devuelve texto; el navegador (más específico el rendering engine) es quien hace el rendering.
@@rtalexk Pues eso la generación de texto y eventos que se haga en el cliente para hacer un uso redistribuido de los recursos. Los datos se pueden transferir en formato JSON. No tiene sentido gastarse el dinero en servidores cuando la parte visual se puede hacer toda en el cliente. El cliente lo único que tiene que hacer es presentar los datos que el servidor le entrega y el servidor gestionar los datos que el cliente le entrega. Hacer todo en el servidor es un desperdicio.
Por otro lado no caigamos en fundamentalismos. No hay herramientas fundamentalmente buenas ni malas solo son fundamentalmente herramientas.
Vida a RoR y ruby 😎
y arriba JS
los "edge cases", como presionar enter dos veces
Jajaja eso suele pasar mucho cuando el usuario tiene conexión regular o mala, si no se pone un loader o un optimistic render o similar, el usuario le va a dar enter o clic muchas veces Jajaja
el tema de los frameworks y que se pelean cual es el mejor. Es parte de la inmadurez de los desarrolladores
Existe una persona más detestable actualmente en el desarrollo web que Theo? El tipo está literalmente hablando mierda de cualquier cosa que no sea JavaScript/React para intentar convencer al resto que JavaScript/React es lo mejor que le pasó a la humanidad.
Me pareció excelente la respuesta de DHH haciendo dos cosas,
- primero: solucionó algo que era muy sencillo y no ameritaba armar tanto escándalo;
- segundo: la reflexión sobre esta tendencia de que tienen personas como Theo de que para hablar bien de lo que a ellos les gusta lo tienen que hacer hablando mierda de tecnologías que a otros les funciona. Y para eso cita el inicio de Ruby on Rails donde no se criticó ni tiró mierda a otra tecnología simplemente lo presentaron diciendo "hey, hicimos esto, puedes hacer esto así, te sirve para hacer tal cosa. A nosotros nos soluciona estos problemas, ojalá también les sirva a ustedes".
Theo está empecinado en hablar mierda de todo el trabajo de los demás, no hay que darle más vueltas a eso.
Este comment merece ser enmarcado en algún lado. 💯
JS es una verguenza de lenguaje. Si no te hace humilde, es porque no entendiste nada.
Es mi sincera conviccion que cualquier persona que piensa que JS es bueno, es porque no conoce ningun otro lenguaje, o trata de usar C en la web, sino no se entiende.
Y mira que Ruby tampoco es santo de mi devocion, pero no le rompen los huevos a nadie.
Los JS fanboys, sin embargo ...
Ya pero dilo repetir mucho la palabra "mierda"... Que lo encuentro cada 5 palabras en tu comentario
@@carlosjose-om3qr Y si lo que hace es hablar mierda que querés que diga?
A mi Ruby on Rails me molaba mucho, trabaje un par de años con el y muchos frameworks modernos que he tocado depues han copiado cosas de el.
vengo del mundo backend puro, pero hace un año empecé a ver frontend, y realmente es muyyyy intreresante, creo que en estos tiempos es necsario aprender frontend.
Y no es solo experiencia de usuario, si quieres ser lo más eficiente en tu página, necesitas usar la tecnología adecuada para cada caso. Imagina que eres una empresa grande que recibe muchos formularios, si tuvieras que enviar y recibir feedback por cada error de cada usuario, vas a cargar tu servidor innecesariamente. En cambio, si haces una validación inicial en cliente y luego en servidor, más del 90% la información que envíes al servidor solo lo tienes que validar una vez y procesar.
Al final cada lenguaje y cada Framework soluciona un ámbito de problemas, el caso es hacer una buena exploración para elegir aquellos que consideres más importante y que te solucionen el 80% de los problemas lo antes posible.
La queja no es tanto JavaScript, sino las SPAs.
Cualquier bobada se hace con una SPA con la complejidad que conlleva.
Hotwire es la versión de Htmx en Rails consiste de turbo/stimulus turbo entregaría el html desde el server y stimulus daría la interacción con javascript.puede ser híbrido según el caso de uso no tiene que ser todo el html desde el server
esto faltó por decir
Soy desarrollador de Ruby on Rails, y es bien sabido desde hace años que es lento en cuestion de performance en comparacion con otros frameworks, perooooo la velocidad de desarrollo es mucho mayor, es por eso que es un excelente framework cuando eres un startup y lo que que quiere es tener un producto para probar tu modelo de negocio, a medida que la app escala, es recomendable ir cambiando de framework o arquitectura sin lugar a dudas, pero para cada trabajo es mejor escoger la herramienta adecuada.
Ya, pero dile esto al ceo de la startup que no entiende de tecnología. Simplemente te dirá que está bien lo que hay y que construyas sobre ello.
Al final se va volviendo una bomba de tiempo que recién te pediran cambiar cuando está avanzado. Haciendo de tu vida laboral un infierno.
Es que pareciera que es una dirección del marcado. Al menos con Laravel, ya tienes varias opciones así, no tocas el front para nada. El mercado determinará si lo adopta o no.
Pero si a venido siendo bien adoptado, incluso quieren verlo muerto, pero no se puede.
Es que si es server side rendering es un poco dificil que lo adopte el mercado, las grandes empresas tienen que mejorar sus procesos y pasar del client side rendering al server... necesitas mas servidores, ergo es más caro todo... yo no le veo futuro a esto, es una simple tendencia temporal.
@@jeko3700 Si, hay algo de eso, pero como debes saber hay truco, incluso tambien con JS y no está nada mal. Para mi no es para todo y hay casos de casos.
una alternativa a js es blazor y funciona bastante bien
gracias a esto , descubrí que puede hacer lento las peticiones, me hizo de gran ayuda porque el frontend hacia una recarga rapida despues de un request y no me dejaba ver la url de la request , el payload, etc , jajaj ty midu
Por que no quieren usar JavaScript? Si JavaScript nos va a enterrar a todos 😂
Porque les gusta la idea de disfrutar de su trabajo?
Yo tengo que usar TS y me quiero cortar los huevos con una cuchara a diario, no imagino encima no tener tipado.
Tu respuesta es todo lo que esta bien.
Al final todo termina en php.
PSDT: Te quiero mucho midu :D
Theo es el Jorge Rial de USA
Con todo esto, ¿qué opinan de HTMX? También esta ideado para desaparecer o minimizar Js en el Front
Me parece una tontería como una casa xd
A mi me pasaba eso, ya que me salia mas a cuenta parsear una parte de la UI en el lado del servidor, lo que hice fue un fallback porque no podía hacer una optimistic UI porque no tenia sentido.
Todo depende de la necesidad que tengas
genial midu, no solo es salseo, es información genial de javascript, de csr y ssr, experiencia usuario, ux optimista, etc, y mucho sentido común en todo, gracias midu!
Hola midu por que no te organizas un curso de Ruby on rails sería excelente
En mi canal doy buen contenido de Ruby ❤
Eso de UI optimista es lo que nosotros implementamos como "anticipación" y es algo común para que el usuario tenga reactividad.
El problema es que la aplicación no cumple la heurística de Nielsen de control de estado, al igual que las contrademostraciones con React
No sabia que existia el renderizado en el servidor, alguien conoce un buen video en español que lo explique no se si midu tiene
Por lo que veo son más problemas de implementación que de solo usar el servidor o del lenguaje.
Coincido que todo se puede hacer bien en ambos enfoques. Pero como Rails dev agregaría que su filosofía siempre ha sido CoS para sacar aplicaciones y prototipos como pan caliente. El rendimiento y la experiencia del usuario es algo con lo que hay que jugar acorde a las necesidades complementandose con Js
No entiendo la necesidad de querer hacer ver mal a X o Y tecnología solo por el simple hecho de que no usa o no es lo que tu quieres (no lo digo por ti Midu), yo amo Rails, pero uso JS, TS, Java, Python, PHP, Kotlin, y todos tienen sus pros y contras. Pero por ejemplo, si yo no uso el servicio de HEY, para qué voy a estar "probándolo" o probando que está "mal" según mis "estándares", no lo uso, pues ni lo volteo a ver. A la gente le gusta hacer polémica para tener visibilidad o porque tienen suficiente tiempo de sobra para estar haciendo tantas cosas de estas... baah...
Bueno, deberias saber quien es DHH y como ha promocionado ROR para tener un poquito mas de contexto
@@r-tn5zr estimado, tengo bastante tiempo utilizando RoR, y conozco el entorno tanto de Ruby como de Rails como para conocer el contexto, no entiendo tu comentario si a lo que voy es que no hay que criticar herramientas, si DHH es como es, no lo puedo controlar pero no apoyo eso, me encanta la herramienta que creó junto a su equipo en Rails, y nada más.
@@edwineinsen me refiero a que es la misma tecnica que ha utilizado DHH para promocionar ROR.
@@r-tn5zr y por eso mi respuesta, si DHH es así, allá él, pero no lo estoy justificando ni nada, ¿O eso te pareció a ti? Porque yo decía que no entiendo por qué la gente critica solo porque no es afin a X tecnología, y en ese sentido no estoy exonerando a nadie. Te puede gustar menos X o Y, y listo, y si no te gusta, no la uses, y si no la usas para qué criticar...
@@edwineinsen no le veo nada de malo criticar a algo que uno piensa que esta lleno de hype. Baja a la realidad a muchos proyectos.
Hotwire no es sin Javascript. Dice sin custom JS. Hotwire tiene su producto estrella que es Stimulus, y es JS puro y duro que se ejecuta en navegador.
Exacto en Ruby On Rails también se pueden aplicar todas estas tecnologías (Vanilla JavaScript, React, Enfoque Optimista, etc.). Simplemente fue una decisión de los desarrolladores usar una u otra.
20:31 Pero digamos que andas rápido y mueves 10 elementos drag a su lugar designado, los mueves rápido y ves que se movieron. Cierras el navegador, pero no se llegó a mandar nada y tu no lo sabes...
Necesita liveview
Theo debe estar enojado porque su video de por que "javascript no necesita un laravel o rails" tuvo un backlash enorme. Hay un excelente video de respuesta hecho por un youtuber llamado Daniel Berg, y DHH retuiteó el video. La realidad es que el ecosistema node se esta volviendo demasiado impredecible.
Esquematización no tiene sentido enviar hasta h1 y tags HTML cuando se puede pasar en un JSON comprimido y evitar cargas de red in necesarias re utilizando cosas que se pudieron obtener solo con una petición de n archivo JS o algo (mi opinion)
No creo que sea un tema de no "usar nada de javascript" es que hay todo tipos de caso de uso y gente que no domina (ni quiere dominar) estos frameworks de frontend tan increiblemente enredados. HTMX es la mejor idea que he visto de esto, y es una libreria de JS! el problema es que muchos no quieren entender que a veces una app se puede hacer sin react/vue/angular o cualquiera de estos frameworks. Hay todo tipo de casos de usp por supuesto y ni HTMX ni React (ni nada) son perfectos para todo
soy noob, pero me atrevo a opiniar 😁. me gusta muchisimo js por su forma sencilla de escribir code, pero si que sueño el día en que le pongan los benditos tipos 😅, se que existe tsc, pero a es un dolor tener que estar creando carpetas para types, odio eso con el alma. intenté pasarme a golang, pero es duro encontrar información tan fácil como encuentras algo sobre js, siento que tiene mas comunidad.
Pasate por Ruby On Rails. Puede q sea el framework q buscas y Ruby el lenguaje q te puede hacer feliz
@@josebecerra7719 en unos años pienso cambiar de lenguaje, primero quiero entrar lo mas que pueda con js. al inicio me encantaba el tipo dinamico, pero luego ya como que cambié de opinión y me da rabia que no sea estricto, he estado 2h o mas buscando un error que era una maricada de tipos insignificante. además, cuando probé tsc con vsc fue lo mas lindo del mundo dar control espacio y que te saliera todo lo que podía ser algo. pero igual me gusta js, es jodido explicarlo 😅 tengo fe que algún día tendremos tipos con todas las de la ley.
C# es el padre de todo
Que pesado es Theo, se nota la mala intención en su reacción.
Siempre lo veo llorando en sus videos en su canal
Por éso lo deje de seguir
No soporto a Theo, y cada vez me lo recomienda mas youtube y twitter
Aunque muchas veces no estoy de acuerdo, yo lo sigo por sus hot-takes, siento que es necesario romper el status quo xd
Me aparece de vez en cuando en la home de yt, veo la miniatura y paso de largo SIEMPRE
Me sorprende la atención en minucias de las interfaces gráficas, que son sencillas incluso de modificar y arreglar, cuando eso es lo de menos. Lo importante es la tecnología, lo que es el conjunto de tecnologías, lenguajes.¿ Pero en serio que por un "botoncito" que no responda que es simplemente un par de líneas de modificar, es suficiente para lapidar el gran esfuerzo que hay detrás de todo el conjunto de estas? Sinceramente esto es lamerse las pel...... porque te cuelgan. De verdad deberíamos estar dando botes de alegría de la gran cantidad de tecnologías,, lenguajes, que tenemos hoy en día, y no centrándonos en aspectos que no son ni propios de estas herramientas. Un saludo.
Es por eso que me gusta phoenix liveviews cada canal y conexiones es como un ~websocket si quiero puedo eliminar liveview conectar mis controles a un framework como react y seguir con mi backend. Claro si es que algún día nos alcanza para tener un team de frontend.
En liveview no es ningún problema puede tener millones de canales sin problema puedes tener millones de peticiones son de unos bytes se manejan con una maquina virtual llamada BEAM que es Erlang
Toda tecnología es buena si se usa para solucionar el problema adecuado. Hotwire es una solución estupenda para aplicaciones que requieren de poca interacción de usuario, pero según aumenta esta interacción, la experiencia de usuario puede ser terrible, sin hablar de la capacidad que necesita un backend al que le estamos enviando requests cada vez que un usuario pulsa una tecla. Javascript es terrible (en mi opinión) pero está más vivo que nunca y es claramente por algo.
Next App router, loading.js en el componente podría ser un caso de uso para este ejemplo
Bueno a mí me gusta yo pasé de Silverlight a razor
Y si recuerdo que en Silverlight había que controlar el doble enter con token para evitar el doble registro en las laptops de la planta
Yo lo veo simple, depende del número de miembros del equipo de trabajo, costos, gustos, etc.
Querer meter JavaScript siempre me parece un error y no es ser infantil. Si soy un solo desarrollador que no quiere tener que mantener dos tecnologías donde en JavaScript hay breaking changes cada 6 meses me parece muy loco y poco escalable.
Yo pienso que uno debe usar lo que más funcione, aunque no de la mayor experiencia de usuario, pero que funcione bien, tanto para al pequeña, mediana o grande empresa como para los usuarios.
La cantidad de requests? Que importa! Mientras funcione bien. Que se queda pegado un poquito? Que importa! Esperar uno-dos segundos no es nada de vida ó muerte en el desarrollo web.
@@stevenperez5260 no del todo, está demostrado que una carga inciial rápida retiene más a los usuarios contrario a la carga lenta, pierdes usuarios, pierdes clientes pierdes dinero..
No es una locura hacer una petición por cada tecla que presiona un usuario?
Sería bueno que hagas uno de Livewire de Laravel
El problema no lo tiene Ruby on Rails, el problema está en cómo escribieron el código ❤ al final lo puedes solventar con JS de una forma eficiente
Yo siempre veo a estos CTOs y sus polémicas como un intento de popularizar sus herramientas. En este caso Ruby... que feo porque a la final solo asustan a sus potenciales clientes.
Javascript es como el Real Madrid, lo podés amar u odiar con toda tu alma pero al final es inevitable
Yo estoy mas bien en contra de un internet no libre. Cada vez que buscas una web se envía el código ofuscado, cookies por todos lados; en general el usuario no tiene la libertad de saber que se esta ejecutando en su máquina, lo que a fin de cuentas resulta en espionaje y acciones negativas para el susodicho usuario.
No se si soy el único con esa vision libre dentro de esta comunidad de youtube pero creo que es algo que se debe hablar a fondo en alguno de los vídeos de midu
Ruby on Rails es el framework y lo seguira siendo!
Que pedazo de vibes a keylogger da eso de hotwire jaskjas al final que tremendo mal necesario termina siendo js
Eso no es hotwire. Solo es q programaron un poco mal esa parte. Estoy seguro q próximamente lo corrigen.
Uso Hotwire en mi curro, concretamente Stimulusjs. Lo empezamos a usar porque el lider técnico y el resto del equipo es full php y no quieren saber nada de js ni frameworks de js.
Sinceramente es muy incómodo trabajar con él y terminas tardando un montón en desarrollar una tontería, no se lo recomendaría ni a mi peor enemigo
Y que crees de Rails ? Como te ha ido? Tengo entendido que te da una experiencia de desarrollo muy buena, quizás caiga un poco en performance
muy mal asumir que todos los usuarios tienen conexiones optimas de internet, para esa gracia volvemos a las aplicaciones cliente->servidor en una LAN y esa no es la idea. Además esa cantidad de conexiones por cada tecla presionada... no se me suena a desperdicio de recursos del lado del servidor también. En una app en producción abierta el publico debe tener buenas practicas y madurarla mas de lo que mostraron en el video, siempre hay que optimizar recursos y ser eficiente.
yo por ej estoy creando una libreria de cache que incluye un dashboard que se renderiza en el servidor ahi lo veo bien y tiene su logica pero no lo usuario para todo la verdad todo tiene sus pros y contras
Cada vez los haters estan locos. La idea idea de que todo se haga en el servidor es pesima porque para una buena experiencia de usuario es necesaria sacar un espacio/tiempo y eso lo da el cliente talvez se podria lograr que todo se haga en el servidor y generar esos espacios pero tendria un coste enorme y una mala experiencia de usuario como resultado.
JavaScript es un lenguaje que ha mejorado muchísimo pero hay mucha gente que cree que sigue igual
Y yo, que tengo como lenguaje de programación favorito Javascript
El problema esta entre el teclado y la silla....
Django + htmx + Alpine y vive feliz
yo hago eso de una petición con cada keypress con un autocomplete, quisiera que no lo hiciera. alguna idea?
A menos que no sea necesario, puedes hacerlo cuando pierde el foco del input de esta forma no le estas pegando cada rato al servidor consumiendo recursos innecesarios, porque en 1 a 10 usuarios no afecta pero si son 100 o 1000 haciendo esas solicitudes por cada caracter es una locura
Hay una tecnica que es esperar 300 milisegundos cuando alguien escribe cada letra, para asi esperar un poco a la siguiente. Eso reduce el numero de peticiones.
Usa una función de throttling o debounce (en tu caso debounce sería mejor) , hay varias en Internet, incluso librerías, son muy sencillas de usar y de hacer. La idea es limitar la cantidad de veces que se puede llamar a una función por unidad de tiempo.
Genial, me pondré manos a la obra, gracias por las sugerencias.
Yo tranquilo viendo las peleas entre frameworks porque hago webs con JS plano 🍿
no conocía a Theo, haré como que nunca lo conocí, que horrible que la comunidad haga videos tratando de destruir a sus colegas, en fin...
Si, le falta amor al UI pero esos milisegundos de carga si es molesto.
No aprendimos nada de web forms ¡Nada!
cuanto cuesta el servicio de email hecho en ruby on rails para saber cuanto me estoy ahorrando? 😍🥰
Ya cuando dicen Trolls, son unos viejos meados
Ironico que WebForms tenian ese principio 😅
Blazor es una buena opción
se nota que no han usado el buen asp
EL problema, que no hay debate sano y desgraciadamente Theo és el peor en este caso está siempre a criticar
pero eso hacemos con Django 5 y listo jaja.
No me imagino lo que incrementa el pago en la cuenta del proveedor cloud si cada que presionas una tecla manda un request :S
Las lambdas/ec2 corriendo a tope
Básicamente, hace lo mismo que Livewire en Laravel 🤦♂
que bien me cae theo jajaja
ami me paso con flask y django jaajaj amaba jinja2 a hora uso vue en el fron-end jaajaj y odio, amo jinja2.
Holaa midu, cuando vendras Malaga?
Todo el que se queja de que quién tiene una conexión así (simulando 3G en el navegador) es porque desconoce el mejor (y único) ISP de Cuba. En fin, viva JavaScript.
IA: Da igual que tecnología usen, su trabajo esta condenaaaado.
lidiar parda jajaja
Esto que es PHP 2 ? Volvemos a PHP y Ajax ? Esto es gastar ancho de banda como antes.
Todo esto para no tocar JS no le veo sentido
Jajajaja si PHP va por el 8 ya 🤣
Como dijo midu, es algo ux, esta mal programado y falta más cariño
Por algo José valin se fue de Ruby on rails y creo elixir (basado en erlang), hoy el lenguaje tiene frameworks tan poderosos como Phoenix que incluye algo parecido (llamado liveview) que es ultra performante ❤. El problema de Ruby es que es realmente muy complejo agregarle al lenguaje concurrencia real y por eso no escala
Me parece que lo de RoR no sera tan bien aceptado, al final esta bueno para quienes sean amantes del lenguaje pero dudo haya ofertas laborales reales sobre ello
Y al revés javascript metiéndose en el servidor 😂
HotWire, el nombre hasta se parece a Livewire de laravel
La mayoría de frameworks back está haciendo algo similar, por ejemplo Phoenix con liveview,Htmx en el mundillo de Python o alpine ajax, livewire en Laravel, hotwire en rails, está interesante
Laravel es básicamente una copia de Ruby On Rails para php 🤷🏻🤷🏻🤷🏻
@@josebecerra7719 claramente Laravel, phoenix, Django y algunos otros frameworks están en gran parte inspirados por Rails.copias tal cual no porque claro que cada uno tiene sus propias cosas, pero la influencia de Rails es fuerte
Laravel con livewire
Que asco damos los humanos de verdad jajajajaja En el deporte es igual, en la politica es igual y por lo que veo tambien en el mundo del desarrollo.... Siempre tendemos a irnos a un extremo y a menospreciar y atacar a muerte el otro extremo.
Mi teléfono con 3g no le gusta eso
Livewire
Soy el único al que le parece que lo que piden es PHP? 🤭
en resumen, programen sus app pensando que sus usuarios viven en Venezuela o Cuba por la velocidad de su internet
Lo creas o no venezuela ya no tiene problemas de internet desde que las empresas privadas empezaron a instalar fibra óptica.
eso es una ridicules, si tiene tan mal internet, seguramente nosea objetivamente un publico util para la gran mayoria de paginas web, asi como hoy nadie hace juegos para los pentium
@@ed115tahlas empresas privada que tienen fibra y que son carisimas y nada si vives en ccs, pero el internet sigue siendo lento y mas caro q afuera. Y no hablemos de cantv, s la muerte
@@juanpablogarcia6293dejas un nicho afuera, xq no quieres desarrollar paginas ligeras?