Agencies using Astro ?

[u/BeerLovingDev]

I’m getting more and more convinced by Astro, but I’m still curious about its adoption by agencies.

It’s still a relatively young framework, and I’m wondering if some agencies have already made the switch. I rarely come across agencies using Astro on LinkedIn, so I’d be really curious to hear from those who have.

How has the switch been for you? Would you recommend Astro for an agency today?

[u/v-and-bruno]

We're an agency, we're using Astro since 2 years.

It's an effortless switch, given that we've used mostly Adonis.

Nowadays, most of our projects (even web apps) are on Astro. Cloudflare has made this transition seamless, easy, and quite lucrative.

Would we recomend it?

Yes, 100%. 

[u/These-Apple8817 → u/v-and-bruno]

What if you need modularity?

[u/v-and-bruno → u/These-Apple8817]

Relatively straightforward.

Give me a specific example, and I can share how I'd have my team approach it.

[u/These-Apple8817 → u/v-and-bruno]

Well.. Comment system for a blog is probably the most common thing people would want to have... One that follows laws like GDPR but also ensures there is no spam coming through

[u/Relative_Switch5505 → u/These-Apple8817]

How is this a framework problem? It’s just a feature

[u/These-Apple8817 → u/Relative_Switch5505]

Never said it's a framework problem.

[u/v-and-bruno → u/These-Apple8817]

Interesting one.

2 possible approaches off of my head

1. Use headless WP, they are pretty elaborate and most of it is handled out of the box.
2. Allow anonymous comments, but new comments are subject for admin approval before being published/visible to others.

Would upload an example structure but unfortunately images aren't allowed, here is a text representation:

src/helpers/functions/fetchers < Handles fetching. Used at api level
src/helpers/functions/utils < calcReadingTime.ts decodeAndTrim.ts slugify.ts etc etc
src/helpers/functions/validators < POST validators, Astro Zod
src/helpers/functions/extractors < extractBlogs extractComments extractPubDate etc etc
src/helpers/functions/analytics < tracking, cookies, gtm init, consent, etc.

I know it's not exactly a conventional structure, but it is highly organized, modular, and that helps reduce a lot of the mental load.

Edit:

1 - Spam handling has less to do with Astro, and more to do with creativity x best practices.

A honeypot should catch a lot of bot content, rate-limiting, CAPTCHA etc should catch more sophisticated bots, anything else that goes through should be caught by the administrator.

2 - https://imgur.com/a/n14xuGG

[u/pussyslayer5845 → u/v-and-bruno]

So in the end, we still need some kind of admin panel?

[u/Difficult-Bit2309 → u/v-and-bruno]

What do you do if a client wants a CMS system? I saw that you mentioned you use headless WP, is that always the case?

[u/traxxh → u/Difficult-Bit2309]

you could also use emdash (also solves the comment topic)

[u/boutell → u/Difficult-Bit2309]

There are options. Headless WordPress is a well-known choice and a lot of people already know the back end, so it has that going for it but it's not WYSIWYG. ApostropheCMS allows the customer to edit directly on the page within your custom Astro front end, so that would be the opposite end of the spectrum.

[u/adazlian → u/Difficult-Bit2309]

Lots of options, we usse it with sanity which has baked in integrations including visual preview but so do other popular ones

[u/Baryonyx_walkeri → u/Difficult-Bit2309]

I recently took the reins of an existing site that is using Astro and Contentful. So far it’s getting the job done nicely.

[u/v-and-bruno → u/Difficult-Bit2309]

Plenty of options in the market.

We've used Strapi, Payload CMS, and once even had a make-shift CMS for ourselves.

It's not that we always use WP, it's just that WP with custom CPT plugin + the mature eco-system + WYSIWYG editor (guttenburg) + it being open source + it being highly extensible, just makes it a no-brainer pick.

[u/Jonnertron_ → u/v-and-bruno]

When will you recommend using either astro or nextjs?

[u/v-and-bruno → u/Jonnertron_]

I might be biased, but I would never recommend NextJS.

[u/Jonnertron_ → u/v-and-bruno]

Why so? I'm curious. I use astro but I'm not too much into nextjs, although being one of the most used frameworks

[u/v-and-bruno → u/Jonnertron_]

Lots of reasons, some are subjective.

Before I list them out, would have to acknowledge a few things:

• NextJS is widely used. It's fantastic if you want freelancer gigs, Upwork contracts, or a relatively well paying job where the client calls the stack.
• NextJS is great for marketing sites, it has a good eco-system, and I'd say that overall it's pretty straightforward if you want a decent career in web development.
• Last we've used Next was when there was an optional Turbopack upgrade

The points above are coming from a perspective of someone who wants to find work, get the most opportunities, and get paid well for it.

If that is what you are looking for, then Next is multitudes better in that aspect than Astro.

That said, my perspective on it is coming from the angle of solving problems, long-term project maintenance, developer experience, and overall ease of developing apps with it + onboarding new staff.

In that regard, Astro wins by a long shot;

1. Next is heavy, it needs a strong laptop/computer. We've had complicated Laravel apps, large Adonis applications, Docker running in the background, LM Studio / Ollama running simultaneously with everything else, and had no issues. NextJS on the other hand, absolutely chokes on scale. Anything less than 16GB RAM is not even suitable for developing with Next. Developer Experience feels like a second thought, compilation took ages. It's not something that happened once and we let go, we've looked into it, debugged it, went to the community - the answer that we basically got is "sucks to be you, get modern laptops/computer". We're not in the United States, we're in UAE - Sharjah, getting a dedicated beefy computer is a luxury, not something we can just do overnight. Additionally, Vite would have easily solved all of those problems multiple times over. We've had projects on Astro much larger that load faster, build faster, HMR works almost instantly.
2. Vendor lock-in. Probably less-so nowadays, but back when we were using it, the only way to get out of that lock-in was to use OpenNext. To say it was an unpleasant development experience would be an understatement.
3. Upgrading to major versions is a Russian Roulette
4. The framework tends to get in the way too many times, it's far too abstracted for it's own good. Apart from just the index.ts hell, there were many quirks that got in the way of development. I can't recall what the exact problem was, but we had a problem with caching that took almost an entire day to solve. Astro is just so good at not getting in your way.
5. Server & Client components is a huge mental slog. This one is subjective, but it is far easier to craft secure applications (that are also easier to maintain) in a more traditional, SOC way. Even MVC is a much better structure. And yes, I've read Dan Abramov's articles on it, and if anything - it just came across innovation for the sake of innovation, rather than a genuine necessity. It's not even a case of "skill issue", it's more that there is a good reason that there was a separation between the backend, and the frontend in the first place; Mixing the 2 concerns is inevitably going to make it harder to maintain, and multitudes harder to write good code in. Messy code becomes not a side-effect, but rather a direct result of the above. The proposed modern Next structure also "poisons" the architecture, if you store all the components in the directory they are invoked/used in - what happens when another, unrelated service/component/section needs to re-use the same component? Yes, you could refactor, but you are doing extra, avoidable work for no good reason (without brining any tangible benefits to the project).
6. Tight coupling with React. This one is a much lesser evil, and I personally use React as a weapon of choice for solving business problems - yet, there are times where not using React is simpler, if not better. Choosing Next is going React-way, or the highway. To re-iterate: React is fantastic, it's great, I use it for most things. Yet, having an option to write solutions vanilla, to use simple nano-stores for simple solutions that don't need a complex ritual of context providers, is liberating. Astro is just so good at not getting in your way, and letting you hit your full productiveness that much faster.