Todos somos Hemingway

Rate this content
Bookmark

¿Sabías que la primera novela escrita data del año 1021? Su autora es la noble japonesa Murasaki Shikibu. Desde entonces, innumerables escritores han plasmado sus pensamientos en papel y numerosos lectores han experimentado sus historias. Las personas escriben durante décadas y nosotros, como desarrolladores de software, de alguna manera ignoramos su oficio. Nosotros también escribimos, no novelas, pero software. ¿No es acaso esto también escribir? Creas ficción o código, hay mucho en común. En esta presentación veremos qué tan cerca estamos de gigantes como Hemingway y Stephen King. ¿Podemos obtener algo de su sabiduría y aplicarla a nuestro trabajo diario como ingenieros? Ven a esta charla y obtendrás algunos consejos prácticos. Espero que mi presentación te convierta en un desarrollador React un poco mejor.

22 min
17 Jun, 2021

Video Summary and Transcription

Esta charla cubre consejos importantes para el desarrollo de software, enfocándose en React. Se enfatiza comenzar con lo que sabes y construir sobre ello. Hacer las preguntas correctas y simplificar los componentes demuestra experiencia. Leer código y hacer preguntas son cruciales para encontrar mejores soluciones. Se destacan la función connect en la biblioteca React Red Hook y el patrón de componente función-como-hijo. Se enfatiza escribir código que sea fácil de entender y mantener para otros. Se menciona la importancia de reintentar en el servidor y refactorizar para el ecosistema.

Available in English

1. Introducción

Short description:

Hola a todos, bienvenidos a la Gran Charla de Wear All Hemi. Mi nombre es Krasimir Tzonev y trabajo para una empresa llamada Antidote. Ayudamos a los pacientes a acceder a ensayos clínicos y utilizamos React en todas nuestras aplicaciones de front-end. Hoy he decidido compartir con ustedes los consejos más importantes que he encontrado. Y espero que también les resulten útiles.

♪ Hola a todos, bienvenidos a la Gran Charla de Wear All Hemi. Mi nombre es Krasimir Tzonev y trabajo para una empresa llamada Antidote. Ayudamos a los pacientes a acceder a ensayos clínicos y utilizamos React en todas nuestras aplicaciones de front-end. Cuando no estoy trabajando, paso la mayor parte del tiempo con mi familia. Tenemos dos hijos, así que tengo que llevarlos un poco a la escuela y al jardín de infantes. No sé cocinar en casa, así que mi esposa cocina. Yo lavo los platos. Solía correr antes. Últimamente no corro tanto, pero solía hacerlo. Y durante todas estas tres actividades, en realidad estaba escuchando audiolibros. Así es como mantengo mi cerebro activo. Y empecé escuchando libros de no ficción y luego pasé a los libros de ficción. Y en algún momento, siendo yo mismo autor, pensé por qué no hacer mi cuarto libro una obra de ficción. Hasta ahora solo había escrito libros técnicos, así que pensé por qué no probar algo diferente. Y lo tomé como un proyecto, así que empecé a abordarlo como abordo todos mis otros proyectos, básicamente viendo cómo hacerlo, porque no tengo experiencia escribiendo ficción. Así que decidí ver un tutorial al respecto, como en este caso fue más bien escuchar otros libros, que son libros sobre cómo escribir un libro. Y los encontré realmente útiles y empecé a sacar algunas citas, algunos tips de allí. Y cuando tenía esta lista grande, la revisé y me di cuenta de que en realidad, la mayoría de estos tips también funcionaban para el desarrollo de software. No era solo sobre escribir ficción, por ejemplo. Algunos de estos consejos eran realmente buenos para los programadores. Y si miramos la fecha de la primera novela y la fecha del primer programa, vemos que hay una gran brecha. Así que probablemente todas estas personas que escriben increíbles libros de ficción tienen algo que enseñarnos. Y aproximadamente en este momento, vi una charla de Jane Creighton en React Conf 2019 llamada React es Ficción y pensé, oh mierda, no solo soy yo. Hay otras personas que también se dieron cuenta de lo mismo. Así que hoy he decidido compartir con ustedes los consejos más importantes que he encontrado. Y espero que les resulten útiles.

2. Starting with What You Know

Short description:

Lo primero en escribir, al igual que en programación, es comenzar con lo que sabes. Por ejemplo, en React, si no estás familiarizado con la escritura de aplicaciones, puedes comenzar renderizando un componente de respaldo. Luego, a medida que aprendes más, puedes construir sobre lo que ya sabes. La complejidad surge a medida que adquieres conocimiento, tanto en la escritura como en el desarrollo de software.

Los encontré útiles también. Entonces, lo primero que creo que la mayoría de los escritores de ficción realmente enfrentan es el síndrome de la página en blanco cuando miras la página en blanco y no sabes cómo empezar o no sabes cómo continuar escribiendo. Tenemos lo mismo en la programación también, especialmente cuando te unes a un nuevo equipo o abres una nueva base de código o eres tal vez más junior, realmente no sabes cómo empezar a escribir algo. Y aquí está lo que Hemingway dice, escribe sobre lo que sabes. Y esto puede sonar algo muy simple, pero encontré que funciona muy bien, al menos funciona para mí. Así que pongamos un ejemplo. Digamos que tenemos este componente y tenemos que escribir este componente de obtención de datos, no existe, simplemente recibimos esto como una tarea. Sabemos cómo debería ser la API, el componente debería aceptar una propiedad de URL, debería tener un respaldo, que es un componente que se renderiza cuando los data están cargando. Tal vez el nombre de respaldo no sea el correcto, pero... luego tenemos los data pasados fuera del componente. Entonces, ahora si no tienes experiencia escribiendo aplicaciones de React, tal vez sabemos algo sobre React pero no mucho. Entonces, si sigues este consejo de escribir sobre lo que sabes, puedes simplemente comenzar renderizando el respaldo. Esto es lo más básico con React, simplemente renderizar algo. Así que simplemente renderizamos el respaldo. Este es nuestro primer paso. Luego, probablemente si comenzamos a leer la documentación, veremos esta cosa llamada estados, que es como el bloque de construcción básico sobre la gestión de estados locales, y reservaremos un lugar para los data. Si los data están allí, codificamos los hijos, que esperamos que sea una función. De lo contrario, simplemente renderizamos los componentes de respaldo. Y en este punto, ya tenemos suficiente, así que podríamos comenzar a hacer más preguntas. Y descubrí que esta es una etapa realmente importante donde tienes algo en qué confiar y luego construyes sobre eso, porque si no tienes nada, ni siquiera sabes qué preguntar, en realidad. Entonces, el siguiente paso sería probablemente preguntarle a alguien más experimentado cómo manejar operaciones asíncronas, cómo hacer solicitudes HTTP, o tal vez simplemente continuar leyendo la documentación, probablemente descubrirás este gancho use effect. Y luego colocas dentro la solicitud real, obtienes los data y lo envías usando la función de los hijos. Entonces, esto es lo primero que encontré útil, especialmente cuando comienzo algo nuevo, escribo lo que sé y luego construyo sobre eso. Y esto realmente te pone en una posición de hacer preguntas, que es un buen lugar para comenzar a hacerlo. Luego, cuando comienzas a conocer cosas, viene la complejidad. Cuando estaba escuchando todos estos libros, descubrí que también hay libros complejos, la complejidad no está solo en el software. Escuché algunos libros que tenían muchas líneas argumentales, tenían muchos personajes, muchas conexiones entre los personajes, había algunos flashbacks. Así que tenía que estar realmente atento. Por ejemplo, cuando estaba corriendo, era difícil escuchar libros tan complejos porque tenía que estar realmente consciente de lo que estaba sucediendo en el libro. Y podemos hablar mucho sobre la complejidad en el desarrollo de software, especialmente en nuestro ecosistema de JavaScript. Y aquí está lo que Stephen

3. Writing Components and Asking Questions

Short description:

Cuando escribes software, es importante centrarse en la historia. Pregúntate si cada componente o función es realmente parte de la historia. Por ejemplo, al manejar errores en un componente fetch, renderizar mensajes de error puede que no sea parte de la historia del componente. En su lugar, considera pasar el error como argumento a los hijos del componente. Al hacer las preguntas correctas y simplificar los componentes, puedes demostrar tu experiencia.

King habla sobre escribir. Cuando estás escribiendo una historia, te estás contando una historia a ti mismo. Cuando estás reescribiendo, estás eliminando todas las cosas que no son una historia. Y, para ser honesto, si vas a llevar algo de esta presentación, quiero que sea esta última frase. Lo que entiendo de esta cita es que debemos eliminar todas las cosas que no forman parte de la historia. Y la pregunta que me hago todo el tiempo es, ¿esto forma parte de la historia? Cada vez que escribo un componente o una función o cualquier cosa, siempre me pregunto, ¿esto forma parte de la historia? Y esta es una pregunta tan poderosa para hacer. Especialmente cuando tienes tu primer borrador de algo, entonces deberías realmente preguntarte, ¿esto forma parte de la historia? Y si continuamos con el mismo componente fetch, digamos que tenemos que manejar el error, por ejemplo, no hay manejo de errores. Y recibimos otra tarea sobre, Oye, tenemos que asegurarnos de que si hay un error, la aplicación no se bloquee. Y tenemos que renderizar un mensaje en la pantalla en caso de fallo en la solicitud HTTP. Entonces, escribimos lo que sabemos. Así que simplemente reservamos un espacio para el error usando otro estado local. Y adjuntamos un catch al final de la cadena de promesas. Entonces, si hay algún error, simplemente almacenamos el error en el estado local. Y luego, tenemos que mostrar el mensaje. Tenemos que renderizar el mensaje al usuario. Y podríamos, quiero decir, podríamos verificar si el error no es nulo. Si no es nulo, simplemente renderizamos este mensaje. Y aquí es donde debemos preguntarnos, ¿esto forma parte de la historia? Y para ser honesto, este mensaje no forma parte de la historia de este componente. Porque este componente se trata solo de obtener data. No se trata de copiar. No se trata de estilos. Solo se trata de obtener los data o manejar el error, si lo hay. Definitivamente no forma parte de la historia de este componente. Probablemente forma parte de la historia del componente que consume fetch. Entonces, lo que podemos hacer es verificar si hay algún error. Si hay algún error, podríamos enviar el error como primer argumento de los hijos. Quiero decir, esta es solo mi elección, pero podría ser cualquier otra firma. Al hacer esto todo el tiempo, al preguntarte si esto forma parte de la historia, básicamente estás escribiendo componentes más simples. Al menos esa es mi experiencia. Luego, cuando estés en esta etapa donde comienzas a hacer más preguntas, y para ser honesto, creo que se puede ver claramente la diferencia entre una persona más junior y una persona de nivel medio cuando comienzan a hacer preguntas. Si comienzas a hacer las preguntas correctas y especialmente a responder estas preguntas, entonces puedes hablar de experiencia senior.

4. Importancia de Hacer Preguntas y Leer Código

Short description:

Hacer preguntas es crucial para encontrar mejores soluciones. Sin embargo, la falta de experiencia puede dificultar saber qué preguntas hacer. Para adquirir más experiencia, se recomienda leer código escrito por otros desarrolladores.

Hacer preguntas todo el tiempo es realmente un buen enfoque para encontrar mejores soluciones. El problema es cuando no tienes suficiente experiencia, no sabes qué preguntas hacer. Entonces, ¿cómo puedes obtener más experiencia? Bueno, Hemingway dijo que cuando estaba escribiendo, era necesario que leyera y Stephen King tiene otra cita sobre si no tienes tiempo para leer, no tienes tiempo para escribir. Estoy bastante seguro de que leer mucho código, especialmente el de tus colegas o de tu base de código porque tienes que hacer revisiones de solicitudes de extracción, por ejemplo. Pero de lo que estoy hablando

5. Explorando la Función Connect y Leyendo Código

Short description:

Me fascinó cómo funciona la función connect en la biblioteca React Red Hook. Esto me llevó a escribir un artículo y lanzar una biblioteca basada en este patrón. Sin embargo, más tarde descubrí que este patrón no era nuevo y se había utilizado durante años. Leer código, especialmente en bases de código grandes como React, puede enseñarte mucho.

Una de las cosas que deberías intentar es leer el código de otros desarrolladores. Yo, por ejemplo, y estoy bastante seguro de que tú también, probablemente escribas este fragmento de código muchas veces. Y esta es la forma en que conectamos un componente o una tienda Red Hook. Y en el pasado, me preguntaba cómo funcionaba esta función connect. Y cuando abrí el código de la biblioteca React Red Hook, esta captura de pantalla es similar a lo que tenemos ahora. Supongo que antes era más o menos lo mismo. Pero vemos una función que acepta nuestro componente y luego, en su interior, hay otro componente que renderiza nuestro componente original. Así que empecé a jugar con este patrón y me pareció muy interesante cómo funcionaba todo. Luego empecé a escribir un artículo al respecto. Le di a esta cosa un nombre. Incluso lancé una biblioteca que lo hacía. Y cuando lo compartí en la web, la gente decía que era como un componente de hardware. No era algo nuevo. La gente lo ha estado usando durante años. Así que estaba reinventando la rueda para mí mismo una vez más. Fue realmente interesante descubrir cómo funcionaba todo simplemente leyendo el código. Te puedo decir cuántas cosas he aprendido simplemente leyendo el código de los demás. No solo el código en el trabajo, sino también el código de bibliotecas. Y no tengas miedo de sumergirte en una base de código grande, como la de React, por ejemplo. Incluso solo leyendo paso a paso cómo está organizado todo, aprenderás mucho.

6. El Patrón de Componente Función como Hijo

Short description:

El patrón de componente función como hijo, ejemplificado por Formic, es uno de mis favoritos. Permite que componentes como Formic tengan responsabilidad mientras brindan valor al consumidor. Leer código de bibliotecas populares, que a menudo implican colaboración entre desarrolladores, puede ofrecer ideas valiosas y decisiones inteligentes.

Hay otro patrón que realmente me gusta. Y este es el patrón de componente función como hijo. Este es un ejemplo de Formic. Pero creo que el primer lugar donde vi este patrón fue en la biblioteca de enrutamiento de React. Y aquí, si no sabes cómo funciona esto, podríamos ir directamente a la biblioteca de Formic y ver cómo hay este componente Formic. Oh, leen los hijos de las props. OK, así que esta es la prop nativa de React. Oh, y simplemente llaman a los hijos como una función, lo cual, la primera vez que lo vi, fue un poco extraño. Pero los hijos realmente pueden ser cualquier cosa. Incluso podrían ser una cadena o un número. No importa para React. Entonces, este patrón en particular, para ser honesto, es mi favorito porque le da cierta responsabilidad al componente, como en este caso Formic, pero al mismo tiempo puede proporcionar algo fuera de él, como en el consumidor del componente. Así que lee el código de los demás, especialmente todas estas bibliotecas realmente populares, porque generalmente estos proyectos son una colaboración entre muchos desarrolladores, y estoy bastante seguro de que, colectivamente, han hecho algo realmente inteligente y han tomado decisiones interesantes y buenas. Así que si tienes la oportunidad, solo revisa algunas de estas bibliotecas.

7. Escribiendo Código para Otros

Short description:

El código que escribimos no es solo para nosotros, sino para que otros lo lean, mantengan y amplíen. Stephen King dijo: 'escribe con la puerta cerrada, reescribe con la puerta abierta'. Al escribir código, es importante hacerlo simple para que otros lo entiendan y revisen. Debemos renombrar componentes y props para reflejar su propósito y eliminar los innecesarios. Siguiendo este enfoque, podemos ayudar a otros a comprender mejor nuestro código, incluso sin entrar en los detalles de implementación.

Entonces, la última parte de mi presentación es realmente una pregunta. Nuevamente, vuelvo al punto donde tienes que hacer preguntas todo el tiempo. Entonces, mi pregunta principal suele ser, ¿quién es el lector? Y cuando estamos escribiendo libros de ficción, supongo que esta pregunta es un poco debatible, supongo, para los escritores de ficción, pero para los desarrolladores de software, creo que está muy claro que el código que estamos escribiendo no es solo para nosotros. Es principalmente para que otras personas lo consuman, lo lean, lo mantengan, lo amplíen. Por lo tanto, es importante escribir para otros, para otras personas. Y esto es lo que dijo Stephen King, escribe con la puerta cerrada, reescribe con la puerta abierta. Siempre recuerdo esta cita cuando reviso mis solicitudes de extracción antes de anunciarlas a mis colegas, porque incluso Hemingway dijo que el primer borrador siempre es una mierda, cito textualmente, pero luego de eso, tienes que volver atrás, tienes que preguntarte, ¿esta parte de la historia está siempre presente? Entonces, tienes que escribirlo de una manera que sea simple para que otras personas lo entiendan, sea simple para que otras personas incluso realicen la revisión de código. Si alguien pasa como una hora revisando tus 50 líneas de cambios, significa que no es realmente bueno. Entonces, si tomas este ejemplo, por ahora, no te enfoques en esta área, la prop action del componente form. Digamos que este es un componente sobre, se llama obtener correo electrónico, tenemos un campo de entrada llamado escribimos el correo electrónico. Cuando cambiamos algo, almacenamos el valor en un estado local llamado valor. Y tenemos un botón de enviar, que probablemente, si lo presionamos, vamos a la acción del componente form y registramos al usuario usando el correo electrónico. Entonces, esto lo considero un borrador. Y podría hacer un par de mejoras. La forma en que refactorizo mis componentes es primero mirar los componentes desde el exterior, como la API, lo que significa el nombre del componente y las props. Y en este caso, sé que este componente está registrando al usuario. No se trata solo de obtener el usuario del campo de entrada de correo electrónico. Se trata de realmente registrar a los usuarios, así que es mejor que lo llamemos simplemente registrar. Tenemos una prop llamada callback. Seguro que callback es una función, pero realmente no habla sobre por qué se dispara esta función más tarde. Entonces onSuccess, supongo, es mejor. Error ni siquiera parece una función. Entonces, desde el exterior, no tenemos idea de que tenemos que proporcionar una función, así que es mejor llamarlo onError. Al hacer estos pequeños cambios, aunque solo sea un cambio de nombre, ayudamos a otras personas a comprender mejor nuestro componente, incluso sin entrar en la implementación. Este es mi enfoque. Inicialmente, comienzo desde el exterior, miro la API, y generalmente solo cambio el nombre de las cosas. A veces encuentro props que no deberían estar allí. No forman parte de la historia, por ejemplo. Cuando avanzas hacia adentro, el valor es en realidad un correo electrónico, así que ¿por qué no llamarlo simplemente correo electrónico? Sería más fácil cuando estás leyendo el archivo de arriba a abajo, y cuando llegas al correo electrónico, simplemente ves que esto es un correo electrónico. Y ahora, esta pieza de lógica, que se trata de hacer las solicitudes usando este

8. Reflexiones Finales y Recomendaciones

Short description:

Si se trata de algo en el servidor, lo intentamos de nuevo. La historia aquí trata de hacer una solicitud y manejar el error. La refactorización se trata de probar el código para otros compañeros de equipo y personas en el ecosistema. Gracias por ver y escuchar.

API.users.register, si esto falla, entonces verificamos el tipo de error. Si se trata de algo en el servidor, lo intentamos de nuevo. Y incluso ahora podemos ver que esto tiene un error potencial, porque si esto falla, la aplicación explotará. Y aquí está, una vez más, mi pregunta favorita, ¿cuál es la historia aquí? Y la historia aquí trata de hacer una solicitud y manejar el error. Y podríamos simplemente escribir dos funciones, y es mucho más limpio, creo, e incluso estamos solucionando el error, porque si la segunda solicitud falla, aún estaremos en un error try-catch. Así que toda esta refactorización realmente se trata, supongo que se trata de Measville, porque después de una semana, probablemente no recuerdo qué está sucediendo. Pero en general, es solo para otras personas. Así que debemos probar el código para otros compañeros de equipo, para otras personas, que ni siquiera conocemos en el ecosistema.

Y con esto, quiero terminar mi presentación. Si te gustaron algunos de los tips que mencioné, te recomiendo encarecidamente que consultes estos libros porque los escuché. Y tal vez encuentres algo interesante también. Gracias por ver, por escuchar. Este es mi nombre de usuario de Twitter y este es el enlace para las diapositivas. Sí, gracias.

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

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Top Content
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit Remote Edition 2020React Summit Remote Edition 2020
32 min
AHA Programming
Top Content
Are you the kind of programmer who prefers to never see the same code in two places, or do you make liberal use of copy/paste? Many developers swear the Don't Repeat Yourself (DRY) philosophy while others prefer to Write Everything Twice (WET). But which of these produces more maintainable codebases? I've seen both of these approaches lay waste to codebases and I have a new ideology I would like to propose to you: Avoid Hasty Abstractions (AHA). In this keynote, we'll talk about abstraction and how you can improve a codebase applying and creating abstractions more thoughtfully as well as how to get yourself out of a mess of over or under-abstraction.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)