Categorías
Desarrollo web General

Trabajando en miniproyectos

Uno de los obstáculos con los que me estoy enfrentando a la hora de seguir mi aprendizaje en el mundo del desarrollo web es que los proyectos que inicio suelen eternizarse.

Esto, al final, tiene un efecto importante y es que afecta a la motivación y el interés por el proyecto y, por ende, en el aprendizaje, decae.

Excesiva complejidad = expansión en el tiempo

Cuando te lanzas a entender y comprender un nuevo lenguaje de programación y asimilas algunas de sus estructuras básicas y su potencia puedes tener la tentación de querer abarcar más de lo que eres capaz en realidad.

Como un Sísifo del código, te impones una roca demasiado grande y una montaña demasiado elevada.

A los numerosos parones a los que tienes que enfrentar tu motivación por tratarse de un constante proceso de aprendizaje, has de añadirle que el proyecto, por su propia complejidad, crece en el tiempo y se termina por eternizar.

Aquí es cuando el impulso inicial se diluye y, lo más normal, es el abandono prematuro del proyecto.

Agilidad, especificidad y retorno rápido

Con la idea de los mini proyectos, lo que busco es alcanzar los mismos objetivos de aprendizaje, pero segmentándolos en tareas cerradas más sencillas.

De esta forma, el proyecto tiene un principio y un final mucho más definido, se extiende mucho menos el tiempo y el retorno en forma de satisfacción al haber completado los objetivos es más inmediato.

Lista de mini proyectos

To Do App

Lista de tareas implementada con React & Typescript con un backend basado en SQLite.

Fue mi primer contacto con NES.css, un pequeño framework de CSS con un rollo pixelart muy divertido.

QuizApp

Sistema de preguntas y respuestas. Aquí también empleé React y TypeScript, aunque no desarrollé backend. En su lugar, gestioné las preguntas con un archivo JSON bastante sencillo.

La parte más interesante del proyecto fue su despliegue en Heroku y ver cómo respondía ante un acceso de un usuario externo.

Aplicación de recetas

En proceso.

Categorías
Desarrollo web

Client-side rendering vs Server-side rendering

En el momento en el que aterrizas en el mundo del desarrollo web, una tormenta de terminología te sacude dándote la bienvenida.

Uno de esos términos que aparentan ser complejos, pero que en realidad son una forma ‘cool’ de decir algo simple, es lo que se conoce como Client-side rendering (CSR) y Server-side rendering (SSR).

La comunicación web

Client-side rendering

El Client-side rendering (CSR) es el funcionamiento más común: nuestro navegador (cliente) realiza una petición de una serie de recursos y el servidor los devuelve. Entre ellos, los archivos Javascript (.js), que se ejecutan en el navegador del cliente, realizando así los procesos programados en el lado del cliente.

Server-side rendering

El Server-side rendering (SSR), en cambio, nos facilita una primera versión pre-renderizada del contenido de forma que mejoramos la velocidad de respuesta. El contenido servido se puede mostrar directamente en el navegador. No obstante, y esto es importante, la parte dinámica de nuestra aplicación no se procesa. Esto se hace con posterioridad, descargándose los archivos Javascript necesarios.

La diferencia es obvia, la primera versión estática pre-cargada en nuestro navegador se realiza de forma mucho más rápida y eficiente, mientras que la descarga de la parte más pesada y dinámica se realiza mientras el usuario ya tiene la posibilidad de ver contenido.

En una solución CSR, el usuario debe esperar hasta que se descarguen todos los recursos para poder interactuar con la página.