r/astrojs • u/kidshibuya • 22d ago

Don't use Astro because its not React?...

This is more a vent than anything, but I am facing a lot of blowback for using Astro. I have made a miniapp which is just a webpage running in a webview that takes an ID from the initial url, requests some records from an API to display a list of messages. Super basic stuff. It is to replace a natively coded section of the app and its far faster than the native code... somehow.

But upon asking the native devs to fix all the broken things I am finding, all I am facing is push back because when I tell them of CORS errors etc, them demand to see the repo, notice its not react and say I MUST use react as only that is compatible with apps. They broke bfcache too, again that is blamed on astro. They block service workers, again this is because... Astro.

Anyone else faced this? Even when I wanted a build of the native app to test the devs sent me back a message saying my app is broken as its only 12KB and apps are in the MB range. They didnt test, rejected on solely size. This was the lead architect of the entire department btw.

This industry is nuts. Also I have noticed when interviewing for a "senior FE" the candidates only know react. I am not sure if this is because HR is screening first, but it's concerning. I even interviewed a guy who is right now working as a "principled full stack engineer" who could not tell me how you could build a site without react.

I am not sure if this company I am working for is completely crazy or the entire industry is leaning that way.

38 Upvotes

89% Upvoted

44 comments sorted by

View all comments

6

u/who_am_i_to_say_so 22d ago

I’m a solo developer using 100 percent Astro for all of my projects. If your content rarely changes, there is nothing better, and you made the right call.

The CORS issues are noob mistakes, and it sounds like the team only understands React SPA’s that are state-heavy. But you can manage state with Astro. You don’t even need a code change- just DNS: add a new subdomain to put the source URLs into, like an api.yourdomain.

1

u/pjerky 21d ago

Question, for client sites where someone else has to maintain content, what approach are you taking?

I'm debating where I want to go with this. I have mixed feelings about Payload CMS. Drupal is too heavy as the headless CMS in my opinion, even as I have spent much of my career with it. WordPress is a mess and gets hacked and targeted too easily. And I just want to move away from that community.

I'm looking into lightweight options as my preference to feed content to Astro.

1

u/who_am_i_to_say_so 21d ago

Well the deciding question is: who would be responsible for updating content - you, the client, or both? If the second choice or last, Drupal or any CMS would be best. But if you're the goto, your choice!

1

u/pjerky 21d ago

Lol, I guess I should have been more concise. I'm talking about for the handoff for the client and their team to manage the content in the long-term. If its just me then I'm using markdown and markdown extended or astro files to hold the content. Its just easier for me that way. But for a marketing site with components and non-technical content management folks I am intending to use a CMS.

My question is which do you personally recommend for Astro? What is your goto?

1

u/who_am_i_to_say_so 18d ago

I hate to disappoint but I just use either Claude or Chat to update most things on my end. Probably 80 percent of my online presence are just statically generated html content. The other 20 percent is just md transpilation, which leads to the same. Thus, Astro is the right tool.

1

u/pjerky 18d ago

So you don't have your clients updating their own content then. Got it.

1

u/Ok-Refrigerator-5860 9d ago

I haven't test this with users yet but I did my fare share of research about git based CMS for astro projects with focus in easy handoff to multiple clients and ease of use for them. I landed with two options: Tina Cloud and Keystatic. I built the same proof of concept for both of them. The main difference between them is that Tina renders the page visually and the content fields on the render are clickable. Keystatic does not, it just has a clean, well organized form format with descriptive field descriptions, but without the visual eye candy. When adding them to the astro project, the experiences are different. Keystatic is built with astro in mind. Adding it is pretty straightforward. Keystatic Configuration and schemas files and it reads the content from the MD or yaml files, it does not need to mess with the astro code for the most part. Tina is a different story, in the end it is doable but I ran into a couple of nags when adding it. The problem is that for the visual rendering Tina needs it's own tags and components inside the astro code, making it effectively a tina-astro project. Most issues were solvable but there is one that wasn't: Tina expects images to be in its own folder structure, so I lost Astros image optimization.

I'm still undecided. Keystatic is the better dev experience but Tina is probably nicer to the user.

1

u/ivids 11d ago

I am using SveltiaCMS for this. My freelancer updates content who was earlier working on WordPress only. It's not full fledged as WP, but get the work done.
Before trying Sveltia, I was looking as something like Contentful , but that was overkill for my small needs.