En la evolución de cómo se hacen aplicaciones web, la mutación principal del ciclo anterior habría sido la separación API/interfaz. En el actual, apostaría que lo fundamental se deriva de que el ecosistema JavaScript (tanto el lenguaje como las librerías a su alrededor) ha interiorizado dos ideas del mundo de la programación funcional: las funciones puras y la inmutabilidad. Esta hipótesis serviría para explicar, por ejemplo, la popularidad de React y Redux que no son más que la aplicación de estos conceptos a la creación de interfaces y la gestión del estado.

Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. Examples of shortcuts are not taking the time to design and architect things well at all levels (low to high — think objects and object hierarchies, database schema changes, etc.), failing to test adequately, and crafting code that is hard to read, maintain and extend.

These kinds of high performers are actually low performers when when TCO is factored in.

— High-performers?

Peticiones de datos modularizables

Recomiendo que echéis un vistazo al video Data fetching for React applications:

Obviando los detalles específicos a ReactJS, Relay y GraphQL la propuesta tiene 2 ideas interesantes:

  • la primera sería que el servidor no tiene muchos endpoints específicos, sino uno al que se le hacen consultas en un formato determinado (GraphQL) y devuelve respuestas en JSON. Hasta aquí nada novedoso porque este estilo de APIs han emergido en los últimos años en muchos productos, sobre todo usando la potencia de SQL (ej: CartoDB).
  • lo novedoso sería cómo se contruye esa petición. Lo típico sería hacerlo en un componente padre que “conoce” lo que necesitan sus hijos. Pongamos un ejemplo usando SQL: el padre lanzaría al API del servidor una consulta tal que «SELECT name, image, etc FROM users » porque sabe que uno de sus hijos necesita la propiedad name y otro la propiedad image. Esta aproximación provoca acoplamiento ya que si uno de los hijos cambia la propiedad que necesita, es necesario hacer cambios en todo el árbol hasta llegar al padre. La propuesta que hacen invierte el control: son los componentes hijos los que declaran qué propiedades necesitan. En este escenario, el padre es agnóstico respecto a los datos que piden los hijos al servidor y centraliza esta lógica en cada componente.

Estoy estos días madurando las lecciones aprendidas de uno de mis últimos desarrollos -una librería de componentes para backbone– y me he encontrado de nuevo con Casey Muratori, un programador de videojuegos independiente. Digo de nuevo porque en este blog ya he publicado sobre un proyecto suyo y una charla sobre diseño de componentes reutilizables. Pero parece que este chico es una fuente inagotable de ideas. O quizás el solape entre las técnicas de desarrollo en videojuegos y el mundo JavaScript es todavía más grande del que yo imaginaba. La última que he documentado en mi glosario: las diferencias entre el Immediate Mode y el Retained Mode.

Compare workflows not frameworks

In general, comparing frameworks in terms of features seems inferior to examining the model it imposes on the programmer.

The latter will inform you about how well the code will fare over time as the product matures and the team grows, but the former won’t. It will also empower you to foresee what the evolutionary path of the technology looks like.

— Guillermo Rauch, en Pure UI, sobre el proceso de rediseño de VideoPress.