mejor-empresa-joven-listado

mejor-empresa-joven-body

Innusual mejor empresa joven

No cabe duda de que en los últimos cinco años el panorama del desarrollo web ha experimentado una transformación significativa y, como ecosistema vivo, continúa evolucionando constantemente. Quizás en la era actual de los LLMs, este cambio parece más pronunciado (aunque en realidad no es tan drástico como podría percibirse). Lo que sí es innegable es que hemos presenciado un salto cualitativo en nuestra forma de trabajar como ingenieros de software. Han surgido numerosas herramientas que nos han permitido reducir considerablemente las horas de trabajo, algo que sin duda agradecemos; otras, sin embargo, simplemente viven de las rentas y seguimos manteniéndolas hasta que los productos para los cuales se utilizan completen su ciclo de vida.

El ecosistema Javascript continúa demostrando un gran dinamismo entre 2020 y 2025. Lejos de estancarse, ha experimentado una expansión notable con la aparición de nuevas herramientas. Hemos presenciado el surgimiento de empaquetadores más eficientes, herramientas de testing más robustas, y frameworks tanto para frontend como backend que han revolucionado las prácticas de desarrollo dentro de este ecosistema.

## El panorama actual: dominación y erosión de React

React continúa dominando el panorama de frameworks frontend con aproximadamente un 82% de adopción entre los desarrolladores web. Esta librería ha revolucionado el desarrollo de UI durante los últimos 10 años, esto no lo hace cualquiera, pero mientras que su uso sigue siendo masivo, las métricas en satisfacción y positividad han descendido, la tasa de retención ha bajado del 92% al 75% en los últimos dos años y las búsquedas de "alternativas a React" aumentaron en un 47% en el último año.

Existen algunos factores que han contribuido a esta situación: 

* Complejidad y claridad: Concurrent Mode y Server Components, dos enfoques novedosos e interesantes, pero que añaden complejidad. Especialmente los Server Components que actualmente solo podemos utilizarlos dentro de Next.js u otro framework SSR. 
* Ecosistema: React tiene probablemente el mayor ecosistema de herramientas de su categoría, algo muy positivo, pero para nuevos desarrolladores supone acceder a un entorno confuso y con una mayor curva de aprendizaje. 
* Bundle y rendimiento: otras herramientas han conseguido superar a React, dejando atrás algo que en su momento fue innovador, el DOM virtual. Y finalmente el tamaño de nuestras aplicaciones crece y crece cuando empezamos a instalar dependencias. 

Estas razones han abierto espacios para otros frameworks, que lejos de distanciarse de React, se han inspirado de esta librería, como Vue con sus composables y Svelte con sus runas (aunque internamente funcionan de manera distinta, la forma de escribir nos resulta familiar), Solid (mejorando el rendimiento) o Astro (con su enfoque "cero JS por defecto")

## La guerra de convergencias - React, Vue y Angular

Es innegable la influencia en cómo los principales frameworks abordan la composición y reutilización del código: 

* **React introdujo los Hooks** (2018), revolucionando su propio ecosistema al permitir lógica stateful en componentes funcionales. 
* **Vue respondió con la Composition API** (2020), un enfoque notablemente similar que abandona el modelo Options API tradicional 
* **Angular adoptó signals** y un enfoque más funcional, alejándose de su tradicional arquitectura basada en clases 

La similitud no es coincidencia: representa una evolución colectiva hacia paradigmas más funcionales y composables.

Veámoslo con un sencillo ejemplo:

React (Hooks)

```jsx
function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `Contador: ${count}`;
  }, [count]);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicks: {count}
    </button>
  );
}
```

Vue (Composition API):

```vue
<script setup>
import { ref, watchEffect } from 'vue';

const count = ref(0);

watchEffect(() => {
  document.title = `Contador: ${count.value}`;
});
</script>

<template>
  <button @click="count++">
    Clicks: {{ count }}
  </button>
</template>
```

La convergencia de paradigmas ha creado una inesperada ventaja: 

* Los **conceptos fundamentales** (estado, efectos, ciclo de vida, props) son transferibles entre frameworks. 
* Los **patrones de arquitectura** como la composición y la separación son universales. 
* Las **herramientas del ecosistema** como TypeScript, testing y build tools son compartidas. 
* La **curva de aprendizaje** para cambiar entre frameworks se ha reducido significativamente. 

Esta transferibilidad de conocimientos representa un cambio fundamental en el desarrollo frontend: los desarrolladores podemos ahora elegir la herramienta adecuada para cada proyecto sin necesidad de casarnos con un único framework, aprovechando sus fortalezas específicas mientras mantenemos la misma experiencia relevante en todo el ecosistema.

## Vite y la guerra de los bundlers

Durante años, webpack ha dominado el ecosistema de desarrollo frontend como el empaquetador por defecto. Esto parece estar cambiando en el último par de años.

En 2020 aparece Vite, creado por Evan You, cambiando el enfoque, para dividir procesos entre desarrollo y producción, carga bajo demanda y pre-empaquetación de dependencias utilizando esbuild (Go). Este cambio supone una reducción drástica de tiempos de arranque de minutos a segundos. A partir de aquí hemos ido viendo como la adopción de Vite ha ido en aumento, primero Vue, React, Svelte, Angular (con compatibilidad experimental), Solid, Qwik, Astro, Remix, etc…

Esta convergencia es inédita en el ecosistema frontend, donde en el pasado cada framework tendía a desarrollar su propio stack.

Pero es probable que veamos una nueva guerra de herramientas, porque a Vite sigue teniendo competidores como Webpack y Parcel, SWC y otros más nuevos como Turbopack, RSPack, o Rolldown (creado por Evan You también). Curiosamente estos tres últimos están programados en Rust, que empieza a ser un lenguaje muy utilizado para construir herramientas para trabajar con Javascript.

Todo esto ha supuesto enormes beneficios a la hora de mejorar la experiencia de desarrollo, teniendo características como fast refresh, estados, mejores mensajes de error, y un cambio en el flujo de trabajo, acortando los ciclos de desarrollo, menores distracciones, configuración simplificada, e incluso brindándonos espacio para la experimentación y democratizando herramientas avanzadas para que puedan ser accesibles a desarrolladores menos experimentados.

## La nueva generación. Signals, hidratación y rendimiento

Vaya, no hemos mencionado a Angular hasta ahora, pero este framework que mucha gente considera estancado ha renacido, introduciendo signals (puedes leer más acerca de esto [aquí](https://innusual.tech/insights/gesti%C3%B3n-estado-signals-angular/)), reduciendo de forma drástica el tamaño del runtime, contemplando la hidratación parcial y mejorando su compilador.

Podemos observar cómo las soluciones técnicas están convergiendo entre frameworks aparentemente dispares:

| Característica             | React                  | Vue            | Svelte    | Angular           | Qwik         | Solid   |
| -------------------------- | ---------------------- | -------------- | --------- | ----------------- | ------------ | ------- |
| Sistema reactivo primitivo | Signals (experimental) | Reactivity API | Compilado | Signals           | Signals      | Signals |
| Hidratación parcial        | RSC                    | Islands        | Islands   | Partial Hydration | Resumability | Islands |
| Compilador optimizado      | ✓                      | ✓              | ✓         | ✓                 | ✓            | ✓       |
| Server-first               | ✓                      | ✓              | ✓         | ✓                 | ✓            | ✓       |

Esto no es coincidencia sino resultado de limitaciones del DOM y Javascript, priorización de métricas de rendimiento y necesidades de mejoras en aplicaciones modernas (mobile o con bajo ancho de banda).

Arquitecturas modernas como "Islands", "Resumability" de Qwik o los Server Components de React comparten un objetivo común:

* **Renderizar en servidor** la mayor parte del contenido posible 
* **Hidratar selectivamente** solo los componentes interactivos 
* **Cargar código bajo demanda** cuando sea necesario para la interacción 
* **Preservar HTML estático** sin procesamiento Javascript innecesario 

Y esto ha supuesto un resultado en mejoras de métricas en Tiempo de Interacción (TTI), reduciéndola a un 70%, First Input Delay (FID) casi eliminado, o Interaction to Next Paint (INP) mejorado.

## Conclusiones. ¿Hacia dónde se dirige el desarrollo frontend?

Las tendencias apuntan a frameworks basados en compilación, poniendo hincapié en tiempos de construcción, menor código runtime (esto se trasladaría a compilación) u optimizaciones especificas por componente.

El renderizado predictivo parece también un objetivo interesante, ya que permite precargar recursos basados en patrones de navegación (mejorando enormemente la experiencia de usuario), y las transiciones (dando soporte a View Transition API) entre estados de la aplicación.

Además, estamos viendo como aparecen arquitecturas híbridas adaptativas que cambian entre cliente/servidor según el contexto (atendiendo a capacidad del dispositivo, red disponible, etc…), por ejemplo, en conexiones lentas, habría más contenido renderizado en el servidor.

También atenderemos a métricas mucho más centradas en el usuario y en su experiencia real por encima de tecnicismos, priorizando la UX continua sobre una carga inicial rápida.

Todas aquellos frameworks que liderarán la próxima generación, serán aquellos que logren equilibrar experiencia de desarrollo intuitiva, rendimiento óptimo por defecto, flexibilidad para casos de uso y adherencia a la plataforma (estándares de la web).

Fuentes relacionadas:

* Frontend Frameworks – [State of JS 2024](https://2024.stateofjs.com/en-US)
* Developer Survey – [Stack Overflow](https://survey.stackoverflow.co/2024/)


Evolución de los frameworks frontend

Accesibilidad EAA (European Accessibility ACT)

En esta ocasión, me gustaría profundizar en la elección entre SPA, SSR y SSG, tres enfoques fundamentales en el desarrollo web moderno. Estos métodos no solo impactan el rendimiento de nuestras aplicaciones web, sino que también influyen en la experiencia del usuario y en cómo los motores de búsqueda perciben nuestro sitio.

Al hablar de estos enfoques, me gusta considerar no solo las necesidades técnicas del proyecto, sino también la experiencia de nuestros usuarios. Antes de arrancar un proyecto debemos plantearnos algunas incógnitas… ¿Cómo garantizamos que nuestros usuarios disfruten de una experiencia rápida y fluida, mientras atendemos las exigencias de SEO? ¿Cómo evitamos la frustración que puede surgir de tiempos de carga lentos o de una navegación poco intuitiva? Para responder a estas preguntas, es esencial conocer los puntos fuertes y las limitaciones de cada técnica de renderizado.

## SPA (Single Page Application)
Las SPA ofrecen una experiencia similar a la de una aplicación de escritorio. Todo el contenido de la aplicación se carga en una única página y las subsecuentes interacciones se manejan en el navegador sin recargar la página. Esto hace que la navegación sea rápida y fluida, lo que es excelente para aplicaciones muy interactivas como paneles de administración o plataformas donde el usuario interactúa constantemente con la interfaz, como herramientas de gestión de proyectos o aplicaciones de edición.

La principal ventaja de las SPA es su rapidez al manejar cambios en el DOM de manera dinámica. Esto es posible gracias a frameworks como React, Angular o Vue, que ofrecen un modelo de renderizado basado en componentes. Sin embargo, las SPA dependen mucho de JavaScript, y eso presenta desafíos de SEO. Tradicionalmente, los motores de búsqueda han tenido dificultades para indexar contenido que depende exclusivamente de JavaScript, aunque esto ha mejorado con el tiempo. Sin embargo, si nuestro proyecto tiene una gran dependencia del SEO, las SPA no siempre serán la mejor opción.

En mi experiencia, las SPA funcionan mejor cuando la prioridad es la interacción continua del usuario y la carga inicial es rápida. Si el contenido estático no es una prioridad y el SEO puede pasar a un segundo plano, una SPA puede ser ideal.

## SSR (Server-Side Rendering)
Si buscamos optimizar el SEO y la velocidad de carga inicial, el SSR se convierte en una opción muy atractiva. Con SSR, el servidor procesa y entrega una página ya renderizada al navegador, lo que ayuda a que el contenido sea visible casi instantáneamente y facilita la indexación por motores de búsqueda. Este enfoque es excelente para sitios que necesitan contenido actualizado y relevante en tiempo real, como sitios de noticias, e-commerce o aplicaciones con contenido en constante cambio.

SSR soluciona algunos de los problemas de las SPA al equilibrar la rapidez en la carga inicial con una buena indexación SEO. En ocasiones me ha tocado elegir entre frameworks como Next.js, Nuxt.js, Remix y Astro permiten implementar SSR con relativa facilidad. Estos frameworks gestionan el renderizado en el servidor y ofrecen funcionalidades que facilitan la actualización y el mantenimiento del contenido. Eso sí, SSR implica una carga mayor en el servidor, ya que cada vez que un usuario solicita una página, el servidor tiene que procesar esa petición y enviar el contenido renderizado. Esto puede incrementar el costo y la complejidad del despliegue.

## SSG (Static Site Generation)
En el otro extremo, tenemos el enfoque de SSG, donde las páginas se generan una sola vez en el momento de la compilación y se sirven de forma estática. Las páginas resultantes se pueden distribuir a través de una CDN, lo que garantiza tiempos de carga extremadamente rápidos, ya que no se requiere procesamiento adicional en el servidor para servir el contenido. Esto hace que SSG sea una opción excelente para sitios con contenido que cambia poco, como blogs, portfolios y otros sitios con contenido mayormente estático.

Frameworks como Next.js, Astro y Gatsby facilitan la implementación de SSG, permitiendo que el sitio sea rápido, seguro y eficiente en el consumo de recursos. Una de las ventajas clave de este enfoque es su capacidad de escalar fácilmente. En lugar de depender de servidores robustos para procesar cada solicitud, los sitios SSG distribuyen el contenido ya generado, reduciendo la carga en el servidor y los costos de infraestructura.

Sin embargo, SSG no es la mejor elección para proyectos que requieren actualizaciones de contenido constantes, ya que cada cambio en el contenido implica una regeneración del sitio. Esto puede ser un proceso lento en sitios grandes y no es ideal para aplicaciones que necesitan datos en tiempo real o contenido que se actualiza frecuentemente, como un sitio de noticias.

## Ventajas y Desventajas
Es importante tener en cuenta las ventajas y desventajas de cada enfoque en función de los requisitos del proyecto:

- **SPA**: Ofrece una navegación rápida y una experiencia de usuario muy interactiva. Sin embargo, la carga inicial puede ser más pesada y el SEO puede verse comprometido si no se implementan soluciones adicionales, como el uso de prerendering o SSR en determinadas páginas.

- **SSR**: Optimiza la carga inicial y el SEO, proporcionando contenido pre-renderizado. No obstante, puede requerir más recursos del servidor, y la implementación y el despliegue pueden ser más complejos.

- **SSG**: Garantiza tiempos de carga rápidos y una menor carga en el servidor, lo que lo hace perfecto para contenido estable y mayormente estático. Sin embargo, es menos flexible para sitios con contenido que cambia constantemente y necesita regeneración para reflejar nuevos cambios.

## ¿Cuándo usar SPA, SSR o SSG?
Al seleccionar entre SPA, SSR o SSG, es importante valorar las características y necesidades específicas de tu proyecto:

- **SPA**: Ideal para aplicaciones que requieren mucha interactividad y donde el SEO no es una prioridad. Ejemplos: aplicaciones de tipo panel de usuario o herramientas de gestión.

- **SSR**: Excelente para proyectos que necesitan un equilibrio entre SEO, rendimiento inicial y contenido en tiempo real. Ejemplos: e-commerce, sitios de noticias y redes sociales.

- **SSG**: Perfecto para sitios donde la velocidad y el SEO son prioritarios y el contenido cambia poco. Ejemplos: blogs, portfolios y sitios de documentación.

## Conclusión
Elegir la técnica de renderizado adecuada entre SPA, SSR y SSG es una decisión estratégica que impactará en el rendimiento, la usabilidad y el posicionamiento en buscadores de nuestra aplicación. No existe una única opción correcta; cada proyecto tiene sus propias necesidades y prioridades. En mi experiencia, conocer bien los beneficios y limitaciones de cada enfoque me permite tomar una decisión fundamentada, logrando aplicaciones que no solo funcionen bien técnicamente, sino que también ofrezcan una experiencia excepcional al usuario.

Innusual mejor empresa joven

>>> Podría interesarte

Evolución de los frameworks frontend

Accesibilidad EAA (European Accessibility ACT)

Optimiza el rendimiento y SEO de tu web

.css-adcnbg{font-family:var(--chakra-fonts-body);font-weight:300;color:inherit;}>>> Podría interesarte

Evolución de los frameworks frontend

Accesibilidad EAA (European Accessibility ACT)

Optimiza el rendimiento y SEO de tu web

>>> Podría interesarte