Tienes Tiempo para Construirlo Dos Veces

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Si no tienes tiempo para construirlo bien, ¿cuándo tendrás tiempo para construirlo dos veces? En las startups de crecimiento hiperactivo, el viejo adagio se desmorona. Obtienes un horizonte de tiempo en expansión, SI puedes hacer que se envíe. Una característica imperfecta la próxima semana supera a la característica perfecta dentro de 2 meses. Tu código no importará si estás muerto. No creí esto hasta que lo vi yo mismo. Una startup al borde del hockeystick me contrató para reescribir su aplicación jQuery en React. Su tecnología probó la idea y luego se convirtió en una carga. Durante el próximo año reescribimos toda la aplicación desde cero, formamos un equipo de expertos en React, creamos un código base que es un placer trabajar con él, y llevamos a la empresa a una Serie B de $100,000,000. Todo porque los primeros ingenieros sabían que si la versión de mala calidad funciona, habrá tiempo y recursos para arreglarlo más tarde. Esta charla es sobre lo que he aprendido mientras reescribía una aplicación con usuarios golpeando la puerta.

This talk has been presented at React Summit 2022, check out the latest edition of this React Conference.

FAQ

Una reescritura de software implica rediseñar y reprogramar una aplicación existente, como cambiar de jQuery a React. Este proceso puede incluir rediseñar la arquitectura de la aplicación, actualizar tecnologías y mejorar la funcionalidad general para cumplir con los requisitos actuales y futuros.

React ofrece una gestión más eficiente y moderna del estado y la interfaz de usuario, permitiendo componentes reutilizables y un mejor manejo del DOM virtual, lo que facilita la escalabilidad y el mantenimiento del código comparado con jQuery.

El patrón Strangler es una técnica de desarrollo de software que implica la refactorización incremental de una aplicación, reemplazando gradualmente partes del código antiguo con nuevas implementaciones hasta que todo el código antiguo es reemplazado, mejorando así la estructura sin detener el funcionamiento de la aplicación.

La reescritura de jQuery a React en la empresa resultó en una mejora significativa en la interfaz de usuario, la experiencia del usuario y la eficiencia del código. Además, durante el proceso de reescritura, la empresa creció cuatro o cinco veces y consiguió una importante financiación de Serie B.

Considerar una reescritura de software es crucial cuando la tecnología subyacente ya no es eficiente o no cumple con las nuevas demandas del mercado, los problemas de mantenimiento incrementan y para aprovechar las mejoras en las tecnologías modernas que pueden ofrecer una mejor escalabilidad, rendimiento y experiencia de usuario.

Los principales desafíos incluyen asegurar la continuidad del negocio durante la reescritura, manejar la complejidad del código legacy, evitar la expansión excesiva del alcance del proyecto y mantener la funcionalidad durante el proceso para no afectar a los usuarios finales negativamente.

Swizec Teller
Swizec Teller
21 min
17 Jun, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La Charla de hoy se centra en las reescrituras de software, específicamente la transición de jQuery a React. El orador comparte su experiencia de reescribir una aplicación jQuery a React, destacando los beneficios de la reescritura en términos de mejor experiencia de usuario y aumento de las conversiones. Se discuten los enfoques para las reescrituras de software, incluyendo el enfoque página por página que permite la innovación del producto. El orador enfatiza la importancia de priorizar las reescrituras o refactorizaciones para las startups. La Charla concluye con ideas sobre pruebas, funcionalidad del lado del servidor y el valor general de la reescritura.

1. Introducción a las reescrituras de software

Short description:

Hoy, quiero hablar sobre las reescrituras de software. Más tarde es el momento mágico cuando todo puede suceder, con más dinero, un equipo más grande, más experiencia y una mejor comprensión del problema. Reescribimos una aplicación jQuery a React, lo que no ralentizó la velocidad del equipo sino que en realidad hizo crecer la empresa. jQuery sigue siendo popular, con un 84% de JavaScript de producción utilizándolo. React ha ganado las Guerras de Framework con un 8% de JavaScript de producción. Se discute la objeción a reescribir desde cero, utilizando el ejemplo de Netscape perdiendo ante IE.

Hola a todos. Soy Suez. Soy ingeniero de software, autor, y puedes decir que soy legítimo porque hay una gran pantalla detrás de mí. Así que hoy quiero hablarles sobre las reescrituras de software.

¿Quién ha visto esta cita antes? Si no tienes tiempo para construirlo bien, ¿cuándo tendrás tiempo para construirlo dos veces? No pude encontrar una atribución para esta cita porque muchas personas la han dicho. Lo que quiero decirles hoy es que tendrán tiempo para construirlo dos veces más tarde. Porque más tarde es el momento mágico cuando todo puede suceder. Porque, al menos en una empresa en crecimiento que está yendo realmente bien, más tarde también viene con más dinero, un equipo más grande, más experiencia, una mejor comprensión de tu problema, y simplemente, más tarde es este momento mágico, mágico.

La historia que quiero contarles es cómo reescribimos una aplicación jQuery, sí, una aplicación jQuery en 2020, de jQuery a React, reescritura completa, empezamos desde cero, y mientras lo hacíamos no solo no ralentizamos la velocidad del equipo, en realidad hicimos crecer la empresa cuatro o cinco veces y conseguimos una ronda de Serie B de $100 millones que se anunció en la famosa pantalla de NASDAQ, que por cierto, no sucede solo para las IPOs. Si conoces a las personas correctas, puedes simplemente pagarles cien dólares y apareces allí.

Así que sé, sé, sé, dije jQuery y quién aquí ha usado jQuery en el último, quién recuerda haber usado jQuery. Vale, vale. ¿Quién ha usado jQuery en 2020 justo antes de la pandemia? Vale, tenemos tres manos. Genial. Así que sé que jQuery es malo, pero en realidad sigue siendo súper popular. Esto es lo que tuiteé justo después de que SWIX, Shawn Wang diera una charla en React.com en San Francisco hace un par de meses. Resulta que el 84% de la producción de JavaScript sigue siendo jQuery. Y tiene este bonito gráfico que, vale genial, puedes verlo. Si miras el gráfico, hay como jQuery, 84%, luego tienes jQuery, Migrate, y yo no sé ni qué es eso. Y luego React está en como el 8% de la producción de JavaScript. Sin embargo, eso todavía significa que estás en la conferencia correcta porque React 1, porque ninguno de los otros frameworks están en el gráfico. Así que, al poseer el 8% de la web, React ha ganado las Guerras de Framework, sí, increíble.

La otra objeción que podrías tener a reescribir y empezar desde cero es si alguna vez has leído esta entrada de blog que salió en 2020, no, lo siento, no en 2020, en el año 2000 cuando los blogs todavía eran populares, este tipo de software Jolon que luego pasó a hacer stack overflow y un montón de otras cosas escribió un artículo realmente genial llamado Cosas que nunca deberías hacer y esencialmente explica por qué no todos estamos usando Netscape ahora mismo. ¿Quién recuerda Netscape? Vale. ¿Quién ha usado realmente Netscape? Genial. Vale. Así que hay un par de ustedes. Hace el argumento de que Netscape estaba ganando las guerras de los navegadores hasta que decidieron, sabes qué, Netscape 4 es un poco malo. Vamos a escribir Netscape 5 desde cero. Y luego IE entró y se comió su almuerzo.

2. Reescritura de jQuery a React

Short description:

Cuando me uní a la empresa, tenían una aplicación jQuery con 100,000-200,000 líneas de código. Era difícil de trabajar con ella, utilizando variables globales y mezclas mágicas. Decidimos reescribirla utilizando React, sin renderizado del lado del servidor. La nueva aplicación no solo se ve mejor, sino que también tiene más conversiones y usuarios más felices. La reescritura nos permitió mejorar el producto y aprovechar lo que aprendimos. Escribir software es como patear una lata, explorando y resolviendo problemas de manera incremental. Nuestra reescritura implicó cambiar y actualizar cosas basándonos en los comentarios de los usuarios.

Entonces, la historia sobre la reescritura de jQuery a React. Cuando me uní a la empresa en junio de 2020, tenían esta pequeña aplicación. ¿Se reproducirá? Se está reproduciendo. Vale. Entonces, esta es una aplicación jQuery. Se grabó en modo móvil porque eso era todo lo que había. Si abres esto en pantalla completa, todavía se vería tan ancho como se ve ahora. Y esto era aproximadamente 100,000, 200,000 líneas de código jQuery. Nadie sabía exactamente dónde estaban todas las funciones. Si intentabas mover algo, básicamente explotaría en tu cara. Estaba haciendo todas las mejores cosas de jQuery, variables globales, mezclas mágicas que simplemente crean nuevo code. Y gran parte de ello estaba trabajando en el frontend. Y aquí está la parte súper divertida. Cuando entré en la empresa, dije, vale, tenemos que reescribir. Vamos a hacer una SPA basada en React, sin renderizado del lado del servidor, etc. Ahora el renderizado del lado del servidor es popular y todo esto se renderizaba en el servidor porque así es como se usa jQuery. Tomas express, escupes un montón de HTML, luego añades variables globales de jQuery y funciones y funciona, más o menos.

Esto es lo que tenemos ahora. Está un poco mejor diseñado. Creo que se ve mejor. Hay algunos spinners de carga. Estamos usando en realidad React Query, que resolvió muchos de nuestros problemas. Esa fue una de las partes agradables. Y además de verse mejor, también tiene más conversiones, los usuarios están más contentos, nuestros puntajes NPS, eso es el puntaje de promotor neto sobre cuánto disfrutan los usuarios de tu empresa, tu producto en realidad subió. Y el punto que estoy tratando de hacer aquí es que no solo reescribimos la aplicación desde cero, también utilizamos todo lo que aprendimos para mejorar el producto en sí y la reescritura fue lo que nos dio la capacidad de reescribir.

Entonces, y eso es porque escribir software es como patear una lata, sabes, cuando estás caminando, es un bonito domingo, el sol está brillando, y estás caminando por la calle y hay una lata, y obviamente, te acercas y pateas la lata. Y luego sigues caminando y la lata rebota y va al otro lado y tú la pateas desde este lado, y estás como yendo a donde va la lata, ¿verdad? Y eso es más o menos cómo funciona el software también. El software se trata de exploración y descubrimiento lúdico de tu espacio de problemas, algo como patear una lata, sabes, vale, tengo este pequeño problema y voy a resolverlo, pateas la lata un poco más lejos por el camino, luego vas a donde te lleva el software y dices, vale, ahora sé mejor, tengo que intentar patearlo más en esa dirección. Entonces, eso es más o menos de lo que se trataba nuestra reescritura. Estábamos cambiando cosas, actualizando, obteniendo feedback de los usuarios, y esa es la parte importante, porque cuando tienes mal code, el nivel de esfuerzo que se necesita para hacer un cambio aumenta exponencialmente.

3. Abordando una Reescritura

Short description:

Construir una buena versión de una aplicación requiere tiempo y esfuerzo, pero es más fácil hacer mejoras una vez que tienes una base sólida. React ofrece flexibilidad y facilidad de mantenimiento de código en comparación con jQuery. El espacio de oportunidad radica en el equilibrio entre el desarrollo rápido y el código de calidad. Las startups deben priorizar la finalización de reescrituras o refactorizaciones antes de que sea demasiado tarde. Enfoques como el patrón Strangler o la reescritura del Ship of Tethius permiten el reemplazo gradual del código. Dos enfoques comunes son de arriba hacia abajo, reemplazando páginas enteras, y de abajo hacia arriba, creando una isla React dentro de la aplicación existente.

Generalmente, construir la primera versión de una aplicación mediocre es súper fácil. Puedes hacerlo de la noche a la mañana, puedes hacer como un primer prototipo muy básico, puedes hacerlo de la noche a la mañana eres como, todos ustedes son personas increíbles. Yo no puedo, soy viejo. Entonces haces la primera versión, y es súper rápida, y la lanzas al mercado. Pero si te tomaras el tiempo para construir una buena versión y trataras de seguir todas las best practices, todos los advice de los libros de texto, te llevaría mucho tiempo construirlo. Sería más difícil empezar.

Entonces esa es la curva del buen code, es muy difícil empezar, pero una vez que lo tienes, es más fácil seguir adelante y hacer mejoras, porque como, especialmente con React, uno de mis cosas favoritas sobre React, comparando el código jQuery con el código React, fue que con jQuery, no quiero tocar nada. Si mueves una función a un archivo diferente, no tienes idea de lo que va a romperse. Con React, puedes simplemente saltar, agarrar una función, y porque todo está autocontenido y solo depende de las props y todo eso, puedes simplemente moverlo a otro lugar y VSCode arregla tus importaciones y todo funciona genial. Así que obtienes mucha de esa flexibilidad que luego, una vez que tienes mucho code y más ingenieros, facilita el trabajo en equipo.

Pero ese espacio en los gráficos, donde el mal code es rápido para empezar y luego se vuelve realmente difícil, y el buen code es lento para empezar y luego se vuelve realmente fácil, eso es lo que yo llamaría tu espacio de oportunidad. Si tú, mierda, ¿cómo iba a explicar esto? Entonces, ese es tu espacio de oportunidad. Ahí es donde puedes obtener mucha retroalimentación muy rápidamente y empezar a usarla en una reescritura que te permite mejorar y obtener un mejor code. Y lo que esperas lograr es que antes de que las dos líneas se crucen, si tu reescritura o si tu refactorización o mejoras no están listas, mueres. Y esa es la parte divertida de trabajar en startups. Es como, o lo hacemos o en realidad no importa porque a nadie le importa una startup cuyo code ya no se usa. Podría usar un ejemplo realmente contundente allí. Pero de todos modos, ¿cómo abordas una reescritura, verdad? Estoy seguro, en realidad, ¿quién aquí ha abogado por dejar de trabajar en características e ir a reescribir el code? Sí. ¿Quién tiene una lista de pendientes de ingeniería a la que nunca llegas? Exactamente. Y la razón por la que eso sucede es porque las personas de negocios no son tan estúpidas como podrías pensar. No tienes tiempo para detener la empresa y simplemente ir a trabajar en la deuda técnica, porque eso es cómo murió Netscape. No fue porque estaban reescribiendo, es porque dijeron, simplemente no vamos a tener una nueva versión del software durante tres años mientras hacemos esto. Y eso no funciona. Lo que sí funciona es algo llamado el patrón Strangler, o puedes, también he oído que se llama la reescritura del Ship of Tethius donde reemplazas lentamente tu code pieza por pieza hasta que no queda nada de tu viejo code. En realidad no recuerdo por qué se llama el patrón Strangler. No es como agarrar el viejo code y estrangularlo hasta que desaparezca. Tiene un origen mucho más agradable. Creo que es algo sobre las enredaderas en la selva. Entonces, hay dos formas en que puedes abordar esto. Siempre que estés construyendo una nueva característica o añadiendo funcionalidad a tu aplicación, puedes decidir si vas a ir de arriba hacia abajo, donde reemplazas páginas enteras con nueva funcionalidad, o puedes ir de abajo hacia arriba, donde creas algo como, en mi empresa, lo llamamos una isla React, donde esencialmente construyes un plug-in tipo GQuery que renderiza React en un div.

4. Enfoque Página por Página

Short description:

El enfoque página por página para reescribir una aplicación completa es más fácil y proporciona una experiencia de usuario más suave. Los usuarios pueden pasar de la versión antigua a la nueva de la aplicación, pero siempre que se mantenga la continuidad del diseño, a los usuarios no les importan los cambios.

Eso realmente funciona muy bien. Si estás reescribiendo una aplicación completa, si tienes tiempo para reescribir toda la aplicación, el enfoque página por página es, creo, mucho más fácil. Lo que hicimos fue que durante aproximadamente un año o seis meses, algo así, tuvimos una experiencia un poco desordenada. Los usuarios utilizarían la aplicación GQuery, harían clic en un botón aleatorio y terminarían en la hermosa aplicación rediseñada React, y luego harían clic en otro botón y volverían a la tierra de GQuery, que parece terrible. Como usuario, es como, ¿qué demonios está pasando aquí? Creo que el mayor ejemplo de esto en la práctica que he visto fue mi banco, donde la página de inicio de sesión era increíble y hermosa, y luego haces clic en iniciar sesión, y estás en esta vieja aplicación desordenada que parece que fue diseñada hace 10 años. Pero siento que, como personas, como usuarios, estamos acostumbrados a estos rediseños, por lo que siempre que los diseñadores hagan un buen trabajo, y mantengan esa continuidad de diseño, o lo que sea que quieras llamarlo, a los usuarios en realidad no les importa. Entienden, sí, sabes, un nuevo BMW sale cada año y tiene parrillas cada vez más grandes, pero sigue siendo un BMW, reconoces que es un BMW, sabes que es un coche, sabes cómo conducirlo, y las cosas principales son las mismas, pero las cosas pequeñas siguen cambiando.

5. Beneficios del Enfoque Página por Página

Short description:

El enfoque página por página permite la innovación del producto, no solo las correcciones de código. Comenzar con un monopatín y gradualmente construir un producto increíble es un proceso gratificante. A los gerentes de producto les encantan las reescrituras porque pueden centrarse en nuevas características sin lidiar con problemas heredados. Innova en el producto, no en el esquema de precios. A pesar de los desafíos, reescribir la aplicación de jQuery a React valió la pena, resultando en una mayor valoración. Estoy escribiendo un libro sobre refactors y reescrituras. Si estás interesado, escanea el código QR para actualizaciones.

Y el enfoque página por página también te da una excusa o una oportunidad para hacer producto innovación. No solo estás arreglando el code, también estás arreglando cómo funciona el producto. Comienzas con un monopatín, luego construyes un scooter, lo conviertes en una bicicleta, luego tienes una motocicleta, y al final tienes un increíble BMW o Porsche, o simplemente Este coche genial que a todos les va a encantar.

Y la reescritura en realidad, en mi experiencia, a los gerentes de producto les encanta si lo haces de esta manera, porque también odian lidiar con cosas heredadas. Les encantaría simplemente tener nuevas características y vienen a ti con esta gran idea y tú dices, sí, ¿sabes qué? Eso va a ser realmente fácil, podemos construirlo porque estamos desechando todo el viejo code y lo estamos haciendo en el nuevo estilo que es más rápido para trabajar, así que no tenemos que lidiar con todo lo demás, porque déjame decirte, en una compañía más antigua que tuvimos, como, estábamos arrastrando alrededor de cinco años de producto, de iteración de modelo de precios y el PM vino a mí y me dijo, oye, ¿podemos agregar este nuevo tipo de cobro a los usuarios? Y yo dije, sí, podemos cobrarles de otra manera. Va a tomar tres meses agregar eso. Y desafortunadamente decidimos agregar eso y una lección que aprendí es que nunca innoves en la preparación, en tu esquema de precios. La gente solo quiere pagar por mes y no les importa nada más. Simplemente, no vale la pena. Pero sí innova en el producto, sí innova en lo que los usuarios están usando realmente.

Ahora, al final del día, pasamos un año entero reescribiendo la aplicación desde cero. Ahora mismo si vas a nuestra cosa, si haces clic en ciertos botones, todavía vuelves al viejo mundo de jQuery, porque no pudimos actualizar el backend. Y la pregunta podría ser, ¿valió la pena? ¿Valió la pena todo este esfuerzo? ¿Valió la pena poner el esfuerzo para reescribir la aplicación de jQuery a React? Y honestamente, lo fue. Cuando recaudamos la ronda, como la ronda de cien millones de dólares, fue, nuestro esfuerzo fue esencialmente vale medio millón de dólares por empleado, pero la valoración subió a alrededor de tres millones. Puede valer la pena, si tu empresa está en la trayectoria correcta.

Y por favor escucha la última línea de mi tweet allí. Vales mucho dinero para tus empleadores, ve a negociar eso y cobra. Y, de hecho, ahora mismo estoy escribiendo un libro basado en esta experiencia. Va a profundizar mucho más en cómo funcionan los refactors y las reescrituras. Y si quieres ser notificado cuando esté listo, ese es el código QR para ti. Y eso es realmente todo lo que tenía que decir. Buen trabajo, hombre. Gracias. Sí. Oh, hay líneas en el suelo. Entonces, Swissec, charla refrescante. Estaba pensando en una experiencia que tuve cuando estaba entrevistando en una empresa que ahora en el momento en que estaban decidiendo construir su primer prototipo. ¿Vamos a JQuery, lo iniciamos, o vamos a construirlo correctamente? Y para mí, esa fue una decisión difícil, porque no quería ir a ellos si decidían ir al mundo de JQuery bootstrap. Soy un poco snob, quizás. ¿Pero qué te hizo decidir que realmente querías hacerlo? Entonces, esa es realmente una historia divertida, porque cuando el jefe de ingeniería me convenció para venir a reescribir su aplicación JQuery a React, dijo, necesitamos hacer esto porque es imposible contratar ingenieros para que trabajen en JQuery.

QnA

Experiencia con React y Aplicación Mobile-first

Short description:

Nadie quiere hacer esto. Tengo la oportunidad de diseñar toda la experiencia con React, establecer el futuro de la empresa. Me uní cuando la parte de jQuery React ya estaba hecha en producción. Buena experiencia. Pregunta de anónimo: ¿La aplicación sigue siendo mobile first? Sí, es mobile first, funciona en todas partes y se adapta automáticamente. Las estadísticas muestran un cambio de móviles a portátiles. Protegerse contra el alcance excesivo: unirse a una empresa en rápido crecimiento con usuarios que demandan innovación.

Nadie quiere hacer esto. Y sí, por eso fui. Porque era como, sí, tengo la oportunidad de design toda la experiencia con React, el framework, establecer el futuro de la empresa, y creo que hasta ahora ha funcionado bien.

Entonces, ¿te uniste cuando la parte de React jQuery ya estaba hecha en producción? Vale. Sí. Así que me uní cuando eso ya estaba listo. Era lo mejor que sabían en ese momento. Era lo mejor, era la forma más rápida para ellos de construirlo. Sí. Y luego dijeron, necesitamos un experto en React para que venga y lo arregle para nosotros. Y tú eres el chico para hacerlo. Genial. Bueno, buena experiencia.

Así que vamos a pasar a las preguntas de la audiencia. Pregunta de anónimo. ¿La aplicación sigue siendo mobile first? Creo que lo mostraste, ¿verdad? Sí. ¿Verdad? Así que estamos usando un framework de CSS en componentes. Como dije, un framework de CSS y JS llamado Team UI. Eso es súper adaptable. Así que la aplicación es mobile first, pero funciona en todas partes y se adapta automáticamente. Y esa fue una de las razones por las que reescribimos, porque podríamos hacerlo más fácil con las herramientas modernas. Pero, ¿todavía ves en tus estadísticas que tal vez nueve de cada diez personas todavía acceden a través del móvil porque están acostumbrados a acceder al producto desde el móvil? Y en realidad eso fue disminuyendo lentamente. A medida que la aplicación empezó a funcionar mejor en los navegadores, la gente empezó a acceder más desde los portátiles. Y probablemente también nuevos usuarios que no sabían que no había experiencia de escritorio. Sí. Genial. ¿Cómo te proteges del alcance excesivo cuando se trata de la innovation del producto durante la reescritura? Correcto. El alcance excesivo es principalmente... Honestamente, la mejor solución que encontré para el alcance excesivo es unirme a una empresa que está creciendo realmente rápido y tiene usuarios golpeando la puerta.

Pruebas, Funcionalidad del lado del servidor y Conclusión

Short description:

No tuvimos tiempo de hacer la reescritura perfecta, ya que estábamos perdiendo usuarios al no poder enviar rápidamente. Algunas pruebas en la antigua aplicación ya no se aplicaban debido a la reinvención y mejora de la aplicación. La funcionalidad del lado del servidor fue manejada por una aplicación Express, utilizando llamadas API en lugar de renderizar HTML con jQuery. El equipo de backend hizo un gran trabajo. Gracias por su tiempo.

Sí. Porque entonces todos están de acuerdo con, está bien, vamos a sacar esto rápidamente. No tenemos tiempo para hacerlo perfecto porque literalmente estamos perdiendo usuarios al no poder enviar. Eso hace que sea realmente fácil decirle a tus PMs, oye, no tenemos tiempo para esto. Sí, tenemos que seguir adelante.

¿Y en la aplicación Legacy, había alguna prueba escrita o simplemente tenías que esperar que lo que reescribiste fuera lo mismo? Había algunas pruebas en la antigua aplicación. El beneficio de nuestra reescritura fue que los PMs también querían mejorar el producto. Así que todas las pruebas antiguas simplemente ya no se aplicaban porque las características eran diferentes. No era solo una reescritura desde una perspectiva técnica, también era una reinvención y mejora de la aplicación.

Sí, está bien, no fue una reescritura uno a uno. Sí, no fue una reescritura uno a uno. Entonces es como, ya sabes, estás convirtiendo un submarino en un barco, no muchas pruebas todavía se aplican. Sí, tal vez una o dos pruebas, se hace esta llamada backend, pero eso es todo. Sí, exactamente.

Está bien. ¿Y luego, había alguna funcionalidad del lado del servidor? ¿Y si sí, qué framework o biblioteca utilizaste? Había mucha funcionalidad del lado del servidor, porque esta era una aplicación Express que estaba renderizando HTML y luego jQuery se hacía cargo. Así que tenían como, básicamente tenían hidratación antes de que supiéramos sobre la hidratación. Así que todo el backend se quedó. Lo convertimos en llamadas API y ahora estamos reescribiendo lentamente el backend también. Está escrito en Express, Node.js con JavaScript puro.

Bueno, parece una sólida ingeniería de software. Sí, el backend, hicieron un gran trabajo. Bien, entonces, eso es todo el tiempo que tenemos para SwissEx, así que voy a agradecerte. Bueno tenerte. ¡Así que, un gran aplauso por supuesto!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

No resuelvas problemas, elimínalos
React Advanced 2021React Advanced 2021
39 min
No resuelvas problemas, elimínalos
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
Impacto: Creciendo como Ingeniero
React Summit 2022React Summit 2022
26 min
Impacto: Creciendo como Ingeniero
Top ContentPremium
This Talk explores the concepts of impact and growth in software engineering. It emphasizes the importance of finding ways to make the impossible possible and the role of mastery in expanding one's sphere of impact. The Talk also highlights the significance of understanding business problems and fostering a culture of collaboration and innovation. Effective communication, accountability, and decision-making are essential skills for engineers, and setting goals and finding sponsors can help drive career growth. Feedback, goal setting, and stepping outside of comfort zones are crucial for personal development and growth. Taking responsibility for one's own growth and finding opportunities for impact are key themes discussed in the Talk.
Sobre convertirse en un Tech Lead
TechLead Conference 2023TechLead Conference 2023
24 min
Sobre convertirse en un Tech Lead
Top ContentPremium
The role of a Tech Lead involves shaping the roadmap, helping the team be more effective, and working on important projects. Lessons learned include encouraging idea sharing, avoiding taking on all the work, and focusing on delegation. Tech Leads focus on the outcome, involve the team in decision-making, and make plans based on how different pieces will interact. The role of a Tech Lead is to focus on engineering and guide the team in figuring out how the whole system should fit together. Architecting can become problematic when it loses touch with the coding part, resulting in implementation issues.
Los Átomos de Jotai Son Simplemente Funciones
React Day Berlin 2022React Day Berlin 2022
22 min
Los Átomos de Jotai Son Simplemente Funciones
Top Content
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.

Workshops on related topic

React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
Masterclass Web3 - Construyendo Tu Primer Dapp
React Advanced 2021React Advanced 2021
145 min
Masterclass Web3 - Construyendo Tu Primer Dapp
Top Content
Featured Workshop
Nader Dabit
Nader Dabit
En esta masterclass, aprenderás cómo construir tu primer dapp de pila completa en la blockchain de Ethereum, leyendo y escribiendo datos en la red, y conectando una aplicación de front end al contrato que has desplegado. Al final de la masterclass, entenderás cómo configurar un entorno de desarrollo de pila completa, ejecutar un nodo local e interactuar con cualquier contrato inteligente usando React, HardHat y Ethers.js.
Fundamentos de Remix
React Summit 2022React Summit 2022
136 min
Fundamentos de Remix
Top Content
Workshop
Kent C. Dodds
Kent C. Dodds
Construir aplicaciones web modernas está lleno de complejidad. Y eso solo si te molestas en lidiar con los problemas
¿Cansado de conectar onSubmit a las API del backend y asegurarte de que tu caché del lado del cliente se mantenga actualizada? ¿No sería genial poder utilizar la naturaleza global de CSS en tu beneficio, en lugar de buscar herramientas o convenciones para evitarla o trabajar alrededor de ella? ¿Y qué te parecería tener diseños anidados con una gestión de datos inteligente y optimizada para el rendimiento que simplemente funciona™?
Remix resuelve algunos de estos problemas y elimina completamente el resto. Ni siquiera tienes que pensar en la gestión de la caché del servidor o en los conflictos del espacio de nombres global de CSS. No es que Remix tenga APIs para evitar estos problemas, simplemente no existen cuando estás usando Remix. Ah, y no necesitas ese enorme y complejo cliente graphql cuando estás usando Remix. Ellos te tienen cubierto. ¿Listo para construir aplicaciones más rápidas de manera más rápida?
Al final de esta masterclass, sabrás cómo:- Crear Rutas de Remix- Estilizar aplicaciones de Remix- Cargar datos en los cargadores de Remix- Mutar datos con formularios y acciones
Vue3: Desarrollo Moderno de Aplicaciones Frontend
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Desarrollo Moderno de Aplicaciones Frontend
Top Content
Workshop
Mikhail Kuznetsov
Mikhail Kuznetsov
Vue3 fue lanzado a mediados de 2020. Además de muchas mejoras y optimizaciones, la principal característica que trae Vue3 es la API de Composición, una nueva forma de escribir y reutilizar código reactivo. Aprendamos más sobre cómo usar la API de Composición de manera eficiente.

Además de las características principales de Vue3, explicaremos ejemplos de cómo usar bibliotecas populares con Vue3.

Tabla de contenidos:
- Introducción a Vue3
- API de Composición
- Bibliotecas principales
- Ecosistema Vue3

Requisitos previos:
IDE de elección (Inellij o VSC) instalado
Nodejs + NPM
Construyendo una Aplicación de Shopify con React & Node
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Construyendo una Aplicación de Shopify con React & Node
Top Content
Workshop
Jennifer Gray
Hanna Chen
2 authors
Los comerciantes de Shopify tienen un conjunto diverso de necesidades, y los desarrolladores tienen una oportunidad única para satisfacer esas necesidades construyendo aplicaciones. Construir una aplicación puede ser un trabajo duro, pero Shopify ha creado un conjunto de herramientas y recursos para ayudarte a construir una experiencia de aplicación sin problemas lo más rápido posible. Obtén experiencia práctica construyendo una aplicación integrada de Shopify utilizando el CLI de la aplicación Shopify, Polaris y Shopify App Bridge.Te mostraremos cómo crear una aplicación que acceda a la información de una tienda de desarrollo y pueda ejecutarse en tu entorno local.
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
JSNation 2023JSNation 2023
174 min
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
Top Content
WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
Esta masterclass de SvelteKit explora la integración de servicios de terceros, como Storyblok, en un proyecto SvelteKit. Los participantes aprenderán cómo crear un proyecto SvelteKit, aprovechar los componentes de Svelte y conectarse a APIs externas. La masterclass cubre conceptos importantes incluyendo SSR, CSR, generación de sitios estáticos y despliegue de la aplicación usando adaptadores. Al final de la masterclass, los asistentes tendrán una sólida comprensión de la construcción de aplicaciones SvelteKit con integraciones de API y estarán preparados para el despliegue.