Technology Selection Criteria
For development teams, adapting to the demands of a constantly evolving technological context is a major challenge. This requires professionals dedicated to researching, selecting, and adopting new technologies for the team’s stack. No less challenging than adopting new technologies is identifying and phasing out legacy tools, which may continue to exist in ongoing projects but will no longer be adopted for future ones.
Here are some of the criteria we at Workoholics consider when making these types of decisions:
- Project characteristics and requirements: The first factor when considering the technical solution for a project is whether the project’s requirements are limiting, conditional, or incompatible with the existing options.
- Inherited technology: Some projects may inherit previous technologies that completely shape the decision. Integrations with third-party tools may also require the use of a specific technology.
- Technological context: It is essential to consider the technological environment at a given time. Many options should be evaluated based on factors such as maturity, adoption, and developer community.
- Team know-how: Adopting a technology has a direct impact on the team. Adoption time depends on the team’s knowledge and the learning curve of the tool, making this a decisive factor when selecting or discarding a technology.
- Client characteristics and technical capabilities: Clients also impact technology selection. Sometimes, a specific technology may even be a mandatory requirement for a project. Client involvement may range from direct collaboration in development and source code, to content management via a CMS. Considering these scenarios is key to an optimal technology choice.
- Scalability and versatility: Tools that support scalability are critical. A digital project must be a living entity, capable of evolving and scaling flexibly over time.
Throughout our journey, we have selected and discarded many technologies, betting on a stack that adapts to the times. One of the frameworks that has best suited our team and proven successful across projects of various types is Astro, which we will discuss below.
Evolution of Astro
The relationship between Astro and Workoholics began in 2022, the year its first version was released. Despite its short track record, we decided to adopt the technology over Gatsby, the framework we were then using for static site development. Astro’s initial goal was static, content-driven sites. While we started using it for that purpose, its evolution has been different, focusing on versatility and scalability and adapting well to different contexts, scenarios, and complexities.
Today, the stable version is Astro 5, reflecting its maturity as a framework. It has become more robust and expanded its functionality, offering solutions to a wide range of challenges in web environments.
Versatility at Multiple Levels
Astro is a flexible framework adaptable to different contexts: from static sites without a single line of JavaScript to complex projects with content managers, multiple data source integrations, heavy functionality, and high interaction levels.
In terms of adoption, it adapts to different knowledge levels and has a gradual learning curve, allowing projects of varying complexity.
Content-Oriented
Astro is content-oriented and capable of integrating multiple data sources within the same project. You can combine Markdown for static pages, fetch data from a REST API, read structured JSON, or connect a CMS like Strapi or WordPress. This flexibility enables building dynamic experiences without sacrificing performance and simplicity.
Moreover, Astro handles all data sources uniformly, regardless of format, simplifying both integration and development.
Rendering Strategies
Astro supports different rendering strategies: SSR (Server-Side Rendering), SSG (Static Site Generation), and hybrid rendering. From a development standpoint, differences are minimal, but infrastructure requirements may vary depending on the hosting environment. Key considerations include differentiating between server-side, runtime, and client-side code.
- SSG (Static Site Generation): Content and code are processed at build time using the Vite compiler, which generates all static assets (HTML, CSS, JS) and optimizes images. Hosting can be as simple as Nginx.
- SSR (Server-Side Rendering): Core adapters exist for NodeJS, Vercel, Netlify, and Cloudflare. We typically use the NodeJS adapter, installed as a dependency and included in the config file. Output can be standalone (compiled for direct serving) or middleware (requiring a server like Express or Koa). This strategy is ideal for dynamic sites, where the server fetches data sources and hydrates components on demand.
- Hybrid Rendering: A particularly interesting approach, combining SSR with static sections. Developers can strategically mark static parts of the site to be built and served statically with just a line of code.
Frontend-Framework Agnostic
Astro’s agnosticism toward frontend frameworks provides development teams with great flexibility. Instead of being locked into one framework, developers can use React, Vue, Svelte, or Web Components by adding just a few lines to the config file. It’s even possible to mix multiple frameworks within the same project, which is useful in cases requiring integration of prebuilt modules.
Astro Islands
Astro uses a component-based architecture. These components are compiled and hydrated either at build time or on the server. Interactive components, called Astro Islands, are isolated interactive units with independent state and event handling. Their main advantage is performance: most of the site remains static HTML/JS, with only specific components running on the client.
Astro provides hydration directives to control behavior:
- client:load → Loads immediately, useful for UI elements needing instant interaction.
- client:idle → Loads after the initial page load (via
requestIdleCallback), ideal for low-priority UI. - client:visible → Loads when the component enters the viewport, useful for off-screen or resource-heavy elements.
- client:only → Loads only on the client side.
Other Features
- Integrated Vite 6 with improved environment APIs.
- Image optimization system for multiple resolutions and formats.
- Dynamic “live” content collections with runtime loaders (experimental).
- Middleware layer to intercept requests and execute custom logic.
- Native i18n support, enabling multilingual projects easily.
Lasai: First Project with Astro
Our first Astro project was Lasai’s corporate website, a company designing, manufacturing, and marketing solar-electric boats. Their main goal was to position the brand internationally around values of sustainability, design, innovation, and quality.
Astro was chosen due to the site’s static nature, low update frequency, and need for i18n. We used React for the presentation layer and Markdown files for static content, organized by directories for localization. Rendering was handled via SSG.
Later, a boat configurator was added, requiring a Strapi CMS for content management. Updates were still infrequent, so we maintained SSG, with content compiled and deployed on-demand by the CMS.
Getxo Kultura: Ultra-Fast Headless WordPress
In 2022, we developed Getxo Kultura’s website, a cultural portal for the city council, centralizing event information and ticket sales. Since the content team was familiar with WordPress, it was chosen as the headless backend. The frontend combined Astro + React, offering optimized performance and interactivity.
Due to frequent updates, SSR was used. However, WordPress API slowness led us to implement middleware that generated static files at each update, balancing SSR’s dynamism with static efficiency.
Athletic Club: Astro Frontend in a Collaborative Project
For Athletic Club’s corporate website, we developed the frontend, collaborating with their team, which built a custom backend.
The site included massive amounts of live and historical data (news, matches, standings, stats), updated daily (5+ news posts plus seasonal data).
Given the high update frequency, Astro + React with SSR was chosen to ensure instant content reflection.
CAF: A Clear Example of Hybrid Rendering
The CAF corporate website overhaul included backend, frontend, and CI/CD setup. Content varied: dynamic sections (investor area, solutions) and static ones (about us, contact).
The backend used Strapi with collections and components. The frontend, built with Astro + React, employed a hybrid rendering strategy: SSG for static sections and SSR for frequently updated areas.