Tailwind can be humbling
Well, I don't want to admit it, but I got irrationally mad at trying to work out how to center a div for the first time in about 4 years. Thanks to the naming convention of justify-content and justifyitems I ended up spending far more time than I would like to have simply aligned the navigation. As with any new tool, there are always growing pains, however, let me tell you about the extensions you need.
Wait, I don't need to rebuild Sanity
You know the most beautiful aspect of a well-built Sanity environment... The fact that we built it once, about 3 years ago (from the time of this post), and we're still using it now, without rebuilding.
For anybody that's not in the agency realm, that's pretty much unheard of. It's nearly always a "full rebuild" - not because developers want to, but often because the CMS or Frontend has gotten out of control and scaled wildly without paying off the all-important development debt.
That's why it's such an achievement to say we've seen Roboto go through 3 refactors, and not once have we started again. That's the power of headless 🎉
That being said, it's always worth brushing up on your GROQ queries, we actually wrote about this here
Previews are as fast as ever
Sanity's most recent announcement offers Perspectives, a game-changing innovation that will revolutionize content previewing. This unique addition streamlines the process of creating audience-specific views, allowing developers to easily customize content variations for distinct experiences. With Perspectives, a single parameter can be introduced to query content, making it extremely versatile for contextual content variations across devices, channels, and contexts. This not only increases the developer's capacity to build previews but also improves the experience for both content teams and their target viewers.
There are three distinct perspectives available: "previewDrafts," which retrieves draught documents, "published," which returns just published versions, and "raw," which retains the existing query functionality. These views provide developers with flexibility and control while assuring a smooth transition. By simplifying complex queries and providing
For the Code Part of live previews
It's quite handy in the field of content management and live preview setups to construct a reusable live preview component for larger applications. This method entails creating a versatile component named "PreviewWrapper," which aids in the management of live queries and effectively provides live-updated content to child components. The true magic here is enabled by @radix-ui/react-slot, a mechanism that allows components to effortlessly transfer props to their direct children, regardless of what those children are.
So, here's how it works: Based on the preview mode and query parameters, PreviewWrapper determines whether to display initial data or live-updated content. Meanwhile, PreviewData handles acquiring and updating live data, ensuring that the child components always have the most up-to-date information. more on this here
Thoughts on Chakra UI
People that know me, know that I love Chakra UI. So what's my opinion after using Tailwind... Well, I still really like it. I would go as far as to say, that I would suspect you will probably be able to build a website faster with it than you would with Tailwind.
However, there's a huge difference we've noticed in performance, that isn't entirely down to tailwind, but because of the lack of "use client". I've written an entire article on it here, but the TL;DR is - more "use clients" worse performance, and Chakra UI uses a lot of "use clients".
So if you're wedded to the original pages router, I wouldn't use Tailwind.css and just use Chakra UI because it'll slip into your app easier than having to setup tailwind configs, and the extra rules around it.
However, if you're building greenfield in the new app router, honestly, just use Tailwind for now. It'll probably set you up for the future until all the issues relating to design tokens and "use clients" are solved. More on this here.
Would I use app router to build a website right now?
Yes.
Long answer: Quick refreshes seems a little slower right now, from our experience, which wasn't really game breaking, as it's literally near imperceivable 100ms... But it's ever so slightly annoying.
However, the trade-off right-now is:
- Easier to achieve top-tier performance
- Simpler flow when fetching data
- Overall cleaner components (if done correctly)
- Anecdotally faster build speeds
But as an honest take - I think RSC React Server Components are here to stay, and they're a painful evolution to the React ecosystem. In the same way, everybody was split with hating/loving React hooks, I suspect the fuss will die down and it'll be the de-facto way to build modern React applications after a year or so of adoption.
What about Vercel? You haven't mentioned Vercel?
Literally, just before pressing publish I realised we've come this far and not even spoke a peep about Vercel. Well, guess what? It was set and forget, and I didn't even have to touch a single setting.
We created one big PR and we worked through all the different aspects of the website, all whilst simultaneously keeping a version of the website in stasis. We just merged it in, and "it just worked"
The most awe-inspiring reason to use Vercel, and the reason we so often hammer on about it is also probably the most mundane - it just works, whatever tool you're using, framework or headless content management system, it'll work flawlessly with image optimisation, CDN, CI/CD, Data Storage etc etc...
Best of all, you're paying like $20 a user. Don't complicate things, just keep it easyyyyy
Quick update:
We're on the Sanity Exchange featured project - couldn't be happier. If anybody needs any help migrating over we would love to help. If you're a dev starting out with Sanity hit us up, and if you're looking for an effortless migration to Sanity
