Los tres son los frameworks de JavaScript más usados para construir interfaces web, pero cada uno tiene una filosofía distinta que conviene entender antes de elegir.

1. React

Mantenido por Meta, es hoy el más usado en el mercado laboral, con la mayor cantidad de ofertas de trabajo y recursos de aprendizaje disponibles. Técnicamente es una librería, no un framework completo, lo que le da mucha flexibilidad pero también significa que vas a tener que elegir e integrar otras herramientas vos mismo (routing, manejo de estado global) según el proyecto.

2. Vue

Diseñado pensando en una curva de aprendizaje más suave, con documentación considerada por gran parte de la comunidad como la mejor explicada de los tres. Viene con más decisiones ya tomadas de fábrica (routing, manejo de estado oficial), lo que significa menos decisiones que tomar vos al empezar un proyecto nuevo.

3. Angular

Mantenido por Google, es el más completo y «opinado» de los tres: viene con absolutamente todo integrado (routing, formularios, testing, inyección de dependencias), pero eso también lo hace el más complejo de aprender al principio. Es muy usado en empresas grandes y sistemas corporativos complejos, donde esa estructura rígida termina siendo una ventaja para equipos grandes.

4. La comparación rápida

Más oportunidades laborales hoy: React, por lejos.

Más fácil de aprender desde cero: Vue.

Mejor para proyectos empresariales grandes con equipos numerosos: Angular.

5. ¿Cuál aprender primero?

Si tu prioridad es conseguir trabajo rápido, React tiene la mayor demanda y comunidad, lo que facilita encontrar soluciones a cualquier problema que se te presente. Si priorizas una curva de aprendizaje más amigable para tu primera experiencia con frameworks, Vue suele generar menos frustración inicial. Una vez que dominás bien uno de los tres, aprender los otros dos lleva semanas, no meses: los conceptos fundamentales (componentes, estado, props) se repiten en los tres con distinta sintaxis.

Cada vez que un video carga sin demora o un asistente de voz responde al instante, hay buenas chances de que el edge computing esté trabajando detrás de escena.

1. El problema que resuelve

Tradicionalmente, cuando tu celular le pide algo a una app, ese pedido viaja hasta un servidor central (que puede estar a miles de kilómetros), se procesa ahí, y la respuesta vuelve. Ese viaje de ida y vuelta lleva tiempo, y para aplicaciones que necesitan respuesta casi instantánea (autos autónomos, cirugía remota, realidad aumentada), esos milisegundos de más pueden importar muchísimo.

2. Qué es el edge computing, en criollo

En vez de procesar todo en un centro de datos central y lejano, el procesamiento se hace en servidores mucho más cercanos físicamente al usuario («en el borde» de la red, de ahí el nombre), o incluso directamente en el dispositivo. Menos distancia significa menos tiempo de viaje de los datos, y por lo tanto respuestas más rápidas.

3. Ejemplos donde ya lo estás usando

Los CDN que aceleran la carga de sitios web guardando copias de contenido en servidores cercanos a cada región son una forma temprana de edge computing. Las cámaras de seguridad inteligentes que procesan video localmente en vez de mandar todo a la nube, y los asistentes de voz que reconocen comandos básicos sin conexión, también aplican este principio.

4. Por qué crece ahora con más fuerza

La llegada del 5G (que ya explicamos en otra nota) potencia mucho al edge computing, porque una red más rápida entre el dispositivo y los servidores cercanos multiplica los casos donde vale la pena procesar cerca en vez de en la nube central.

5. ¿Le importa a una empresa chica?

Directamente, es poco probable que necesites implementarlo vos mismo salvo que trabajes con IoT o aplicaciones de tiempo real. Pero indirectamente ya te beneficia: cuando usás un CDN para tu sitio web (algo que cualquier hosting moderno ofrece), estás aprovechando esta misma lógica de acercar el contenido al usuario para que cargue más rápido.

Si ya entendiste qué es una API REST, la siguiente pregunta natural es: ¿qué es GraphQL y por qué tantos proyectos nuevos lo eligen?

1. El problema concreto que resuelve GraphQL

Con REST, cada endpoint devuelve una estructura fija de datos. Si necesitás el nombre de un usuario pero el endpoint también te devuelve su dirección, teléfono y 15 campos más que no usás, igual los recibís todos: es información de más que viaja innecesariamente. Y si necesitás datos de dos recursos distintos (usuario y sus pedidos), a veces hay que hacer dos pedidos separados.

2. Cómo lo resuelve GraphQL

Con GraphQL, vos pedís exactamente los campos que necesitás, ni uno más: «dame el nombre del usuario y el total de sus últimos 3 pedidos», en un solo pedido, y recibís exactamente esa estructura, sin campos de sobra. Es como pedir en un restaurante a la carta en vez de un menú fijo con platos que no elegíste.

3. Cuándo REST sigue siendo mejor opción

REST es más simple de entender, documentar y cachear (guardar temporalmente respuestas para no repetir el mismo pedido), lo que lo hace ideal para APIs públicas donde muchos desarrolladores externos van a integrarse, o para proyectos chicos donde la simplicidad pesa más que la flexibilidad de las consultas.

4. Cuándo GraphQL tiene ventaja real

Cuando tenés pantallas complejas que necesitan combinar datos de múltiples fuentes distintas (típico en apps móviles con conexión limitada, donde minimizar el tamaño de cada pedido importa mucho), o cuando distintas partes de tu equipo necesitan formas muy distintas de consultar los mismos datos sin tener que crear un endpoint nuevo para cada caso.

5. ¿Hace falta elegir uno solo?

No necesariamente. Muchas empresas grandes usan ambos según el caso: REST para integraciones públicas simples y estábles, GraphQL para las pantallas internas complejas de su propia aplicación. Para tu próximo proyecto, si es chico y directo, REST sigue siendo la opción de menor fricción; si anticipás pantallas con datos complejos y variables, vale la pena invertir el tiempo extra de aprender GraphQL.

«Framework» y «librería» se usan a veces como sinónimos, pero la diferencia entre ambos cambia cómo estructurás tu proyecto entero.

1. Qué es una librería

Es un conjunto de funciones que vos llamás cuando las necesitás, dentro de tu propio código. Vos tenés el control: decidís cuándo usarla, cómo, y en qué orden. Ejemplo: una librería para manejar fechas, que llamás solo cuando necesitás formatear una fecha específica.

2. Qué es un framework

Es una estructura completa que define cómo tiene que organizarse tu proyecto entero, y es él quien llama a TU código, no al revés. Ejemplo: un framework web como Django o Laravel te obliga a organizar tu código en carpetas específicas, con archivos que cumplen roles predefinidos, y es el framework el que decide cuándo ejecuta tu código (por ejemplo, cuando llega una solicitud web).

3. La diferencia clave, en una frase

Con una librería, VOS llamás al código. Con un framework, EL FRAMEWORK llama a tu código. Es lo que en la jerga técnica se llama «inversión de control»: el framework toma las decisiones estructurales grandes, y vos completás las piezas específicas dentro de esa estructura.

4. Ventajas y desventajas de cada uno

Las librerías te dan más flexibilidad, pero te obligan a tomar más decisiones de arquitectura vos mismo. Los frameworks te dan velocidad de desarrollo (ya vienen con patrones probados y mucho trabajo resuelto), pero te atan a su forma específica de hacer las cosas, lo que hace más costoso cambiar de framework después.

5. Ejemplos concretos para que quede claro

Librerías: Lodash (utilidades de JavaScript), Requests (peticiones HTTP en Python), Chart.js (gráficos). Frameworks: React y Angular (frontend), Django y Rails (backend), Flutter (apps móviles).

Dato curioso: React técnicamente se autodenomina «librería», aunque en la práctica muchos equipos lo usan con tantas convenciones estructurales que funciona casi como un framework. La línea entre ambos conceptos no siempre es tan nítida como parece en la teoría.

Es una confusión clásica de quienes recién empiezan: usar los tres nombres como si fueran sinónimos. No lo son, y entender la diferencia te ahorra confusiones más adelante.

1. Git: la herramienta

Git es un sistema de control de versiones: un programa que corre en tu computadora y lleva registro de todos los cambios que haces en tu código, permitiéndote volver a versiones anteriores o trabajar en paralelo sin pisar el trabajo de otros. Existe desde 2005, no depende de internet, y funciona igual sin importar dónde subas después tu código.

2. GitHub: una plataforma que usa Git

GitHub es un sitio web (propiedad de Microsoft) donde podés alojar tus repositorios Git en la nube, colaborar con otros, y acceder a funciones extra como issues, pull requests y automatizaciones. Es, hoy, la plataforma más popular para proyectos open source.

3. GitLab: una alternativa a GitHub

Cumple un rol similar a GitHub (alojar repositorios, colaboración), pero con un enfoque más orientado a empresas que quieren todo el ciclo de desarrollo integrado en una sola plataforma (desde el código hasta el despliegue en producción). También permite instalarlo en tu propio servidor, algo que GitHub no ofrece de la misma forma.

4. La analogía que lo aclara todo

Git es como el sistema de correo postal: las reglas y la infraestructura básica para que las cartas (tus cambios de código) lleguen a destino. GitHub y GitLab son como dos empresas de correo distintas (piense en FedEx vs DHL) que usan ese sistema, pero cada una con su propia interfaz, oficinas y servicios adicionales.

5. ¿Cuál aprender primero?

Aprendé Git primero, siempre: es la base que necesitas sin importar en qué plataforma termines subiendo tu código. Recién después elegí GitHub o GitLab según lo que te pida el trabajo o proyecto en el que estés (GitHub sigue siendo el más pedido en ofertas laborales por su popularidad).

Si ya entendiste Docker, la pregunta natural es: ¿qué pasa cuando tengo cientos de contenedores corriendo a la vez? Ahí entra Kubernetes.

1. El problema que resuelve

Un contenedor Docker suelto es fácil de manejar. Pero una aplicación real puede necesitar cientos de contenedores corriendo a la vez, distribuidos en varios servidores, que hay que iniciar, reiniciar si fallan, y escalar según la demanda. Hacer esto a mano es inviable a partir de cierto tamaño.

2. Qué hace Kubernetes, en criollo

Es un «director de orquesta» para contenedores: vos le decís «quiero que esta aplicación tenga siempre 5 copias corriendo», y Kubernetes se encarga de mantenerlo así automáticamente. Si un contenedor se cae, Kubernetes levanta uno nuevo sin que nadie tenga que intervenir manualmente. Si hay mucho tráfico, puede levantar más copias solo.

3. Docker y Kubernetes no compiten, se complementan

Docker empaqueta la aplicación en contenedores; Kubernetes coordina muchos de esos contenedores a gran escala. Es como la diferencia entre saber armar una caja de envío (Docker) y coordinar toda una flota de camiones que las transportan (Kubernetes).

4. ¿Necesitás aprenderlo?

Si trabajás en una startup chica o un proyecto personal, probablemente no lo necesites todavía: es una herramienta pensada para escala. Se vuelve relevante cuando una aplicación crece lo suficiente como para necesitar múltiples servidores coordinados, o cuando buscás trabajo en empresas medianas/grandes con infraestructura compleja, donde aparece seguido en los requisitos.

5. La curva de aprendizaje, sin endulzarla

Es bastante más compleja que Docker. Tiene su propio vocabulario (pods, deployments, services) y conceptos que llevan semanas asimilar bien. No es algo para aprender en un fin de semana, pero tampoco hace falta dominarlo a fondo para empezar a ser útil con él en un equipo.

«API REST» es uno de esos términos que se usan todo el tiempo en tecnología sin explicarse nunca. Acá va, con ejemplos de la vida real.

1. Qué es una API, en criollo

Una API (Interfaz de Programación de Aplicaciones) es un «mesero» digital: vos (una app) le pedís algo a la cocina (otro sistema), el mesero lleva el pedido, la cocina lo prepara, y el mesero te trae la respuesta. No necesitás saber cómo funciona la cocina por dentro, solo cómo hacer el pedido correctamente.

2. Un ejemplo cotidiano

Cuando usás una app del clima, esa app no «sabe» el clima por sí sola: le hace un pedido a la API de un servicio meteorológico («dame el clima de Montevideo»), esa API le responde con los datos, y la app te los muestra en pantalla. Lo mismo pasa cuando pagás con tarjeta en una tienda online: esa tienda usa la API de la pasarela de pagos para procesar tu transacción sin manejar ella misma tus datos bancarios.

3. ¿Y qué es lo «REST» específicamente?

Es un conjunto de reglas comúnmente aceptadas para diseñar APIs de forma predecible. En la práctica, esto significa que las acciones básicas se organizan en verbos claros: GET (pedir información), POST (crear algo nuevo), PUT (actualizar algo existente), DELETE (borrar algo). Cualquier programador que conozca REST puede entender rápido cómo usar una API nueva, porque sigue este mismo patrón.

4. Por qué son tan importantes hoy

Casi toda la tecnología moderna se conecta vía APIs: tu app de banco habla con los servidores del banco por API, un sitio de e-commerce se conecta con el correo para calcular envíos por API, y hasta los asistentes de IA usan APIs para conectarse con calendarios, emails y otras herramientas (como el estándar MCP que explicamos en otra nota).

5. Un dato clave si trabajás con datos sensibles

Una API bien diseñada solo entrega la información necesaria para cada pedido, y requiere autenticación (una «clave» o token) para acceder a datos privados. Si alguna vez usás una API con datos de clientes, verificá que esté protegida correctamente antes de conectarla a tu negocio.