Tired of Modern Frontend, I Chose a Simpler Architecture

After nearly 12 years of programming, something has changed a lot in the way I choose technology.

I used to want to try everything.

A new framework, a new library, another way to build components, another stack that someone claimed had finally solved frontend development.

I had more time to explore and, to be fair, it was fun.

But after years of building systems, maintaining software, and solving problems that do not disappear when the tutorial ends, I started valuing something else:

simplicity.

Not simplicity as an excuse to do less.

Simplicity as an engineering decision.

Fewer pieces to understand.

Fewer things to maintain.

Fewer places where something can break.

And, above all, an architecture that can still make sense years from now.

Astro showed up right when I had started thinking this way.

My relationship with frontend development has never been particularly romantic.

Over the years I have worked with jQuery, Bootstrap, CSS, and different ways of building interfaces.

Every phase left a few scars.

jQuery solved a lot of problems, but it could also turn the DOM into a place where five different functions seemed to solve the exact same thing.

Bootstrap was incredibly useful, but some decisions aged worse than you expected when you first built on top of them.

And CSS…

Well.

CSS is always there.

While I was thinking about APIs, databases, business rules, integrations, infrastructure, and production problems, frontend development kept evolving.

New paradigms.

New bundlers.

New ways to manage state.

New concepts.

New frameworks.

And there was always someone saying:

this is the one you should use.

The reality is that I did not have time to master every new way of centering a div.

My main work was somewhere else.

There is something that feels revealing to me now.

Whenever I needed to build a simple website, my first decision was often not how I wanted to build it.

It was finding a template.

I would find something close to what I needed and then try to adapt my sections to its structure.

I have even paid for templates.

Not because I could not build a page.

But because spending hours solving layout, styles, components, and visual behavior was not where I wanted to invest my time.

The problem is that you end up working backwards.

Instead of building the page you need, you try to make your project fit inside something somebody else designed.

And I was almost never completely happy with the result.

Astro felt different.

For the first time in a long time, I stopped looking for a template and started building the site piece by piece.

Like Lego.

One section.

Then another.

A component.

A layout.

A content collection.

A visual detail.

And if I want to change one piece tomorrow, I do not feel like I have to dismantle everything else.

It was not islands.

It was not selective hydration.

It was not a benchmark comparison.

It was speed.

And hot reload.

Saving a file and seeing the change almost immediately.

It sounds trivial.

But when most of your time goes into a system like Metrify, that friction matters.

I do not want to lose an afternoon configuring a toolchain before I can see a section working.

I want to write.

Save.

See.

Fix.

Keep moving.

Astro gave me that feeling immediately.

Later I realized that behind that experience were architectural decisions that fit very well with the way I already thought about software.

Something clicked very quickly:

not every website needs to become a client-side application.

It sounds obvious.

But for years, modern frontend development kept moving more and more problems into the browser.

For this site I needed:

• pages;
• content;
• Spanish and English;
• a technical journal;
• a few effects;
• reusable components;
• strong performance.

I did not need to turn all of that into a SPA.

Astro let me start from HTML and add complexity only when there was a real reason to do it.

---
const lang = "en";
const title = "Engineering";
---

<section>
  <h1>{title}</h1>
</section>

The top section prepares data.

The bottom section describes what I want to render.

For someone who has spent years working with backend systems and server-rendered templates, the mental model feels very natural.

And if a page can be resolved at build time, the user receives finished HTML.

I do not need to ship JavaScript to the browser just to reconstruct something I already know in advance.

To me, that is an architectural decision before it is a frontend feature.

This is probably one of the comparisons that best explains how my way of working has changed.

Years ago I built a website in Spanish and English.

And it was exactly what you would imagine.

One page.

Its English version.

Another page.

Its English version.

Repeated text.

Repeated files.

Changes that had to be made twice.

Today I can centralize much of that information.

Something as simple as:

export const languages = {
  es: "Español",
  en: "English",
};

and then:

export const ui = {
  es: {
    nav: {
      engineering: "Ingeniería",
      now: "Ahora",
    },
  },

  en: {
    nav: {
      engineering: "Engineering",
      now: "Now",
    },
  },
};

One object.

Structured data.

Known rules.

And from there I can build navigation, text, and behavior around languages.

Of course, a real i18n system eventually involves more decisions: routes, canonicals, hreflang, translated slugs, and relationships between content.

But the change in mindset is huge.

Before, I copied pages.

Now, I model information.

And that way of working is much closer to how I think about backend systems.

And this matters too.

Astro does not make architectural decisions for you.

You can build a bad architecture perfectly well with Astro.

This site itself gave me an example.

For a while, English lived at / and Spanish lived under /es/.

The language switcher sent users to the corresponding homepage.

The hreflang tags did something similar.

Visually, everything looked fine.

A Spanish story should point to its actual English translation, not to the homepage.

Fixing that required thinking about:

• content identity;
• equivalent routes;
• canonical URLs;
• hreflang;
• sitemap behavior;
• navigation.

Astro did not solve that problem for me.

But it did not get in the way either.

The architecture was explicit enough that I could see the problem, understand it, and fix it without rebuilding half the project.

That is exactly the kind of property I value more today.

There is another massive difference between when I started and now.

AI.

If I had these tools ten years ago, my relationship with frontend development would probably have been very different.

Today I can be working on a section and ask about:

• CSS;
• accessibility;
• an Astro API;
• responsive behavior;
• a TypeScript detail;
• a micro-animation.

The friction involved in exploring a new technology has dropped dramatically.

But there is something I try not to confuse.

AI accelerates implementation. It does not replace judgment.

It can help me write a function.

It can suggest a structure.

It can explain a feature I do not know.

But it still cannot decide for me whether that feature belongs in my architecture.

The fundamentals still matter.

Understanding data.

Understanding HTTP.

Understanding performance.

Understanding separation of concerns.

Understanding maintenance.

Understanding the problem you are solving.

AI did not replace those years.

It amplified them.

There was a time when JavaScript seemed to produce a new framework every week.

And every one of them came with a new wave of content saying:

use this.

leave that behind.

now everything should be done this other way.

When you have time and you are learning, exploration is valuable.

I did a lot of it.

I still do.

But after enough years, you start asking a different question.

Not:

what can this technology do?

But:

what will this technology make me maintain later?

The learning curve matters.

Dependencies matter.

Ease of upgrading matters.

The cost of adding a feature two years from now matters.

And the cost of having to refactor everything because the ecosystem moved on matters too.

And this is probably the most important part of any technology decision.

Astro is not my answer to everything.

I would not choose it as the primary frontend for a complex ERP just because I enjoy working with it.

An ERP can involve:

• intensive state;
• complex forms;
• application-style navigation;
• long-running workflows;
• frequent updates;
• highly interactive tables;
• operations that live for hours inside a user session.

That problem has different priorities.

And it probably deserves different decisions.

Choosing technology with judgment also means knowing when not to use it.

For a site like javiersalazar.dev, Astro makes a lot of sense.

For another problem, it may not.

That is not a weakness.

That is architecture.

I think this is the biggest difference between how I used to choose technology and how I try to choose it now.

I used to be attracted by possibilities.

Now I am attracted by reducing obligations.

I want a new page to be just a new page.

I want a new story to be just a new file.

I want adding a language to avoid manually duplicating the entire application.

I want a small interaction to stay a small interaction instead of turning the whole site into a client-side app.

I want changing one section to avoid forcing a refactor of five others.

And I want to be able to return to this code years from now and still understand why it was built this way.

That is what I found in Astro.

Not a magical frontend.

Not a universal framework.

An architecture simple enough for the problem I was trying to solve.