DEV Community: Momcilo

20 Astro Website Examples That Show What the Framework Can Do

Momcilo — Thu, 10 Sep 2026 14:00:40 +0000

Astro ships HTML first. JavaScript loads only where you ask for it. That philosophy produces fast sites by default, which is why portfolios, docs, blogs, and marketing pages built with Astro tend to score well on Core Web Vitals without heroic optimization work.
But reading about "islands architecture" in the abstract is less useful than seeing what teams actually build. Here are categories of real Astro sites and what makes each pattern work.

Personal portfolios and blogs

Astro is a natural fit for developer portfolios. The content is mostly static (project descriptions, blog posts, about pages), and the visual flair comes from CSS, not heavy client-side frameworks.
What you see in practice:

Markdown or MDX for blog posts with custom components- Minimal or zero client-side JavaScript- Fast load times even on shared hosting- Custom themes built with Tailwind or vanilla CSS- RSS feeds generated at build timeBecause Astro supports content collections natively, blog posts live as local files with frontmatter. No external CMS is required for small sites, though adding one (like BCMS) makes sense when a non-technical co-author needs to contribute. ## Documentation sites Documentation needs fast navigation, searchability, and the ability to update frequently. Astro's Starlight template is designed specifically for docs:
Sidebar navigation auto-generated from file structure- Search built in- Dark mode by default- Versioning through content collections- MDX support for interactive examples inside docs pagesTeams that outgrow a static docs site can connect Astro to a headless CMS for multi-author workflows without losing the speed benefits. ## Marketing and landing pages Marketing sites benefit most from Astro's zero-JS default. A campaign page that loads in under a second and scores 100 on Lighthouse helps conversion and ad quality scores. Common patterns:
Hero sections with animated SVGs (CSS-only)- Testimonial carousels as isolated islands (client:visible)- Pricing tables rendered as static HTML- CTA forms as small React or Preact islands- A/B testing via edge middleware, not client-side scripts## E-commerce storefronts Astro handles product listing pages well when paired with a commerce API. Product detail pages can be statically generated at build time (SSG) or server-rendered on demand. Interactive pieces like cart widgets become islands.
Product grids rendered as static HTML for SEO- Cart icon with client:load for immediate interactivity- Checkout redirects to a hosted payment page (Stripe, Shopify)- Category filters as small interactive components## Agency sites and client work Agencies ship multiple sites per quarter. Astro's low overhead and framework-agnostic island model let them reuse components across projects without locking into a single UI library.
Shared design tokens across client projects- Mix React, Vue, or Svelte components in the same project- Fast builds even for content-heavy sites with hundreds of pages- Easy deployment to Vercel, Netlify, or Cloudflare Pages## Content-heavy editorial sites News sites, recipe blogs, and magazines with thousands of articles benefit from Astro's build performance and content collection features. When paired with a headless CMS like BCMS:
Editors create entries in a visual dashboard- Developers define templates and content models- Build times stay fast because Astro only regenerates changed pages (with incremental builds)- SEO metadata lives in CMS fields, not hardcoded frontmatter## What makes these examples work Across all categories, the pattern is the same:
Static HTML for content that does not change per user- Islands for interactive widgets that justify their JavaScript cost- Content sourced from files, APIs, or a CMS depending on team size- Deployment to edge CDNs for global speedAstro does not try to be everything. It is excellent at content sites and good enough for light interactivity. When your app becomes dashboard-heavy or real-time, a different framework makes more sense. ## Related reading
Astro Server Islands: the full tutorial- Best CMS for Astro in 2026- Jamstack frameworks comparedWant screenshots, live URLs, and a breakdown of each site's Astro configuration? Read the full showcase: 20 Astro Website Examples.

Why a Headless CMS Belongs in Your E-Commerce Stack

Momcilo — Tue, 08 Sep 2026 14:01:29 +0000

An e-commerce site lives or dies on two things: page speed and content freshness. Product descriptions change weekly. Landing pages for sales come and go. SEO copy needs constant tuning. Shoving all of that into a monolithic platform limits how fast your team can iterate.
A headless CMS decouples the content layer from the storefront. You manage product copy, category pages, banners, and editorial stories in a dedicated content tool. Your frontend (Next.js, Nuxt, Astro, or a custom React app) pulls that content through an API and renders it exactly how you want.

The problem with coupled commerce platforms

Traditional e-commerce platforms bundle content editing with checkout, inventory, and payment logic. That coupling creates friction:

Marketing teams wait on developers to push landing page changes- Template overrides make upgrades risky- Performance degrades as plugins pile up- Multi-channel delivery (web, mobile app, in-store kiosk) requires duplicated work- SEO improvements get stuck behind release cyclesDecoupling content does not mean decoupling everything. You keep your commerce engine for cart, checkout, and inventory. The headless CMS handles everything content-related: storytelling, product education, and SEO. ## What a headless CMS handles in an e-commerce context
Product content - extended descriptions, size guides, ingredient lists, comparison tables- Category pages - intro copy, SEO metadata, featured product callouts- Editorial and blog - buying guides, seasonal lookbooks, brand stories- Landing pages - campaign-specific pages that ship fast and die fast- Banners and promotions - homepage heroes, announcement bars, sale badges- FAQ and support content - structured Q&A that also feeds schema markup## Architecture pattern A typical stack looks like this:
Commerce engine (Shopify, Medusa, Saleor, custom) - handles products, prices, cart, checkout- Headless CMS (BCMS) - handles all content types above- Frontend framework (Next.js, Nuxt, Astro) - composes data from both sources into pages- CDN - caches the output for fast global deliveryThe frontend fetches product data from the commerce API and editorial content from the CMS API. At build time or request time (depending on your rendering strategy), both data sources merge into a single page. ## Why BCMS fits this model BCMS is API-first and designed around typed content models. For e-commerce teams that means:
Custom templates for each content type (product page extension, landing page, guide)- Media management with alt text and responsive delivery- Typed SDK responses so your frontend code stays safe- Role-based access so copywriters can publish without touching checkout logic- Works with any frontend framework, so you pick the rendering strategy that fits## Performance wins Separating content from commerce means you can:
Pre-render editorial pages at build time (SSG) while product pages use ISR or SSR- Cache content API responses aggressively since editorial changes are infrequent- Keep your storefront bundle lean by not loading a CMS editor runtime- Serve from the edge without worrying about server-side plugin conflicts## SEO advantages Search engines reward fast, content-rich product pages. A headless CMS lets you:
Add structured data (FAQ schema, product schema) driven by CMS fields- Maintain consistent meta titles and descriptions across thousands of pages- Publish buying guides and category intros that build topical authority- Update content without redeploying the entire storefront## When to adopt this pattern This setup pays off when:
You have more than 50 products and meaningful content for each- Marketing ships content weekly and cannot wait for sprint cycles- You plan to expand to mobile apps or other channels- Page speed directly impacts conversion (it always does, but especially above $10k/month in revenue)## Related reading
API-first CMS: what it means and why it matters- Best CMS for developers in 2026- CMS examples across industriesWant integration examples with Shopify, Medusa, and Next.js, plus a content model template for product pages? Read the complete guide: Headless CMS for E-Commerce.

Headless WordPress with Astro: When It Works (And When to Leave WP)

Momcilo — Thu, 03 Sep 2026 14:13:15 +0000

Headless WordPress + Astro is a popular escape hatch: keep WP as the editorial database, ship a fast Astro frontend. It works - until plugin gravity and WP APIs become the bottleneck you moved the frontend to avoid.

Why teams try this

Editors already know WordPress- Astro ships less JavaScript for content sites- You can keep permalinks and gradually migrate## How the architecture looks
WordPress exposes REST or GraphQL (WPGraphQL)- Astro fetches posts at build time (or on-demand)- Templates map WP fields into Astro components- Media still often lives on the WP uploads host## Pain you should expect
Preview and draft workflows get awkward- Plugin-dependent fields do not always serialize cleanly- You still maintain WordPress security updates- Structured content is weaker than purpose-built headless CMSs## When to switch CMS entirely If you are already rebuilding the frontend, evaluate a true headless CMS (BCMS included). You keep Astro's performance and gain cleaner models, better media UX, and fewer WP-shaped constraints - especially for multi-framework teams. ## Related reading
Headless WordPress examples- Astro website examples- Best CMS for AstroWant setup notes, tradeoffs, and migration guidance? Read the complete guide: Headless WordPress and Astro.

Nuxt vs Vue in 2026: When You Need the Framework

Momcilo — Tue, 01 Sep 2026 14:13:26 +0000

Vue is the library. Nuxt is the framework that makes Vue production-shaped: routing, SSR/SSG, data fetching conventions, and a batteries-included DX.
If you are asking "Nuxt vs Vue", you are usually asking whether you want to assemble the stack yourself or inherit sensible defaults.

Choose Vue alone when

You are embedding widgets into an existing server-rendered app- You already have routing/build tooling you like- The UI is a small island, not a full site## Choose Nuxt when
You need SSR/SSG for SEO and performance- You want file-based routing and layout conventions- You want modules for image, SEO, and content workflows- You are building a full Vue product, not a component demo## Mental model Vue : Nuxt :: React : Next. The library can do everything eventually. The framework removes glue code and standardizes how teams ship. ## Content pairing For marketing sites and blogs on Nuxt, keep content in a headless CMS. BCMS + Nuxt is a common combo: fetch entries in server routes or page data, render structured fields, let editors publish without npm. ## Related reading
Build with Nuxt, Tailwind, and a headless CMS- Nuxt SEO complete guide- Jamstack frameworks comparedWant a deeper feature-by-feature breakdown? Read the full article: Nuxt vs Vue.

Build Room Scheduling Software with Next.js, Clerk, and a CMS

Momcilo — Thu, 27 Aug 2026 14:00:42 +0000

Room scheduling is a classic full-stack exercise: auth, availability, conflicts, and a calendar UI. Pairing Next.js + Clerk + a headless CMS shows how to keep content/config structured while app logic stays in your code.

Core entities

Room - name, capacity, amenities, photo- Booking - room, user, start/end, status- Office / location - optional parent if you have multiple sitesPut relatively stable content (room descriptions, images, amenities) in BCMS. Put high-churn transactional bookings in your app database if concurrency is serious - or start with CMS entries for an MVP and migrate later. ## Auth with Clerk Clerk handles sign-in, sessions, and user identity so you do not invent auth on day one. Gate booking mutations behind authenticated routes. Store Clerk user ids on bookings so you can show "my reservations". ## Conflict rules
Reject overlapping bookings for the same room- Enforce business hours and minimum/maximum duration- Show clear errors in the UI when a slot was just taken## UI sketch
Rooms list from CMS- Room detail with availability grid- Booking form (date, time range)- Confirmation + "my bookings" view## Related reading
Headless task manager tutorial- Structuring relational data- Multi-tenant CMS patternsWant the full build with Clerk wiring and booking flows? Read the complete tutorial: Build room scheduling software.

Customizing Next.js Themes with Content from a Headless CMS

Momcilo — Tue, 25 Aug 2026 14:13:21 +0000

Theme customization in Next.js is easy to over-engineer. The clean approach: keep visual tokens and section content in structured CMS fields, keep layout components in the repo, and let editors change brandable pieces without touching React.

Split responsibilities

Developers - components, routing, design system primitives- CMS - logo, colors (as values), hero copy, nav labels, feature sections- Build/runtime - map CMS fields into CSS variables or Tailwind theme extensions## A practical theme model
Site settings entry: brand name, logo media, primary/secondary color- Navigation entries or a nav group- Page entries composed of widgets/sectionsOn the Next.js side, read site settings once (layout), expose CSS variables on :root, and style components with those variables. Editors change a hex once; the whole theme updates. ## Do not put CSS files in the CMS Letting marketing paste arbitrary CSS sounds flexible until specificity wars and XSS show up. Prefer constrained fields: color, font choice from an allowlist, spacing scale enums, and prebuilt section widgets. ## Workflow
Start from a Next.js + BCMS starter- Add a Settings template- Wire settings into app/layout or _app- Build 3-5 section components editors can assemble- Document which fields are safe for non-devs## Related reading
Optimize Next.js performance- Next.js advantages that matter- Tailwind CSS tutorialWant the full theme field map and code samples? Read the complete guide: Customizing Next.js themes with BCMS.

How to Work with Video in a Headless CMS (BCMS Guide)

Momcilo — Thu, 20 Aug 2026 14:02:35 +0000

Video breaks content workflows when the CMS treats it like a mystery blob. Editors need upload, preview, and reuse. Developers need a stable URL (or streaming strategy) and a frontend that does not tank LCP.

What you want from the CMS

Upload video into a real media library (folders help)- Attach video fields on templates (hero video, lesson, case study)- Preview before publish- Reuse the same asset across entriesBCMS media manager supports video alongside images, audio, and documents - so you are not bolting a second DAM onto day-one projects. ## Frontend patterns that work
Poster + lazy play - show a cover image; load the player on interaction- Below-the-fold deferral - do not autoplay heavy files in the hero unless the brand requires it- Native video element for simple cases; a player library when you need captions/chapters- CDN delivery - serve from the media URL your CMS provides; cache aggressively## Modeling tip Separate "video asset" from "video module". The asset is the file. The module can include title, transcript link, CTA, and whether autoplay is allowed. That keeps editors flexible without hardcoding layout in the media library. ## Performance checklist
Compress before upload when possible- Always provide a poster image- Prefer muted autoplay only when it is truly necessary- Track weight in Lighthouse like you would a giant image carousel## Related reading
Astro Server Islands (hydrate media UI carefully)- CMS examples- What makes a CMS user-friendlyWant the BCMS-specific upload UI walkthrough and field setup? Read the full guide: How to work with video in BCMS.

Build a Headless Task Manager with Next.js and a CMS

Momcilo — Tue, 18 Aug 2026 14:13:19 +0000

A task manager is a great headless CMS tutorial because it forces real modeling decisions: statuses, assignees, due dates, and relationships - not just a blog title field.
You will keep Next.js as the app shell and BCMS as the content/API layer for tasks and related entities. That split teaches the same pattern you will use for dashboards, internal tools, and content-heavy SaaS UIs.

Model the domain first

Task - title, description, status, priority, due date- Status - todo / in progress / done (or a status entry pointer)- Project - groups tasks; optional relation- Media - attachments when a task needs screenshotsResist stuffing everything into one freeform rich-text field. Structured fields make filters, boards, and agent automation possible later. ## App flow
Create templates in BCMS for Task (and Project if needed)- Seed a few entries so the UI is not empty- Fetch tasks in a Next.js server component or route handler- Render a list/board UI with client islands only where interactivity is required- Wire create/update through your API (or CMS write path) with clear validation## UX details that matter
Optimistic UI for status changes feels fast; still confirm against the server- Empty states should teach the model ("create your first task")- Keep auth at the app edge; do not expose privileged CMS keys in the browser## Why CMS instead of only a database UI For many internal tools, a CMS gives you an admin UI for free, media handling, and a clean API. For high-write transactional systems you may still want a dedicated DB - and that is fine. The tutorial's point is the architecture: structured content + framework UI. ## Related reading
Build room scheduling software with Next.js- Structuring relational data in a CMS- Customizing Next.js themes with BCMSWant step-by-step screenshots and the full project walkthrough? Read the complete tutorial: Headless task manager tutorial.

10 CMS Examples That Show What Headless Actually Looks Like

Momcilo — Thu, 13 Aug 2026 14:02:24 +0000

"Headless CMS" is easier to understand from examples than from definitions. The pattern is the same every time: content lives in a CMS API, the frontend is whatever framework you choose, and editors update entries without touching the deploy pipeline for every typo.

What good CMS examples usually share

Clear content models (blog post, product, landing page section)- Media that is not dumped into a single flat folder- A frontend that renders structured fields, not one giant HTML blob- A path for drafts, statuses, and multi-language when needed## Example shapes worth studying
Simple blog - title, slug, cover, rich text, author; SSG frontend- Portfolio - projects with galleries, tags, and case-study widgets- Job board - listings with filters driven by structured fields- E-commerce content layer - product stories, PDP blocks, campaign pages (commerce engine stays separate)- Restaurant / local business - menus, locations, hours as entries- Docs-ish marketing - reusable sections and CTA widgets across pages## Why starters matter The fastest way to learn a CMS is not reading feature pages. It is cloning a starter, changing one template field, and watching the frontend update. BCMS ships starters for Next, Nuxt, Astro, Gatsby, and Svelte so you can see the full loop: model, entry, fetch, render. ## How to judge an example
Can a non-developer edit the content safely?- Can you add a new field without rewriting the whole app?- Is the content reusable across channels (web, app, email)?- Would migrating the frontend still leave the content intact?## Related reading
Simple blog examples- Headless CMS for e-commerce- Best CMS for developersWant the full gallery of CMS examples with stack notes? Read the complete article: CMS examples.

Best UI Frameworks in 2026: Pick by Problem, Not Hype

Momcilo — Tue, 11 Aug 2026 14:00:27 +0000

UI framework choice is not a personality test. It is a bet on rendering model, ecosystem, hiring pool, and how much JavaScript you are willing to ship.
In 2026 the useful shortlist is still familiar - React, Vue, Svelte, Angular, plus meta-frameworks that wrap them - but the decision criteria got sharper: hydration cost, islands, typed content, and whether your CMS can stay portable when the UI layer changes.

What to evaluate first

Rendering story - CSR only, SSR, SSG, islands, or resumability- Bundle tax - what ships to a content-heavy page by default- Ecosystem fit - forms, design systems, CMS SDKs, hosting- Team reality - what you can hire and maintain for 2+ years- Content ops - editors should not need a PR for every headline## Practical map (not a ranking)
React + Next.js - default for large teams, mixed SSR/SSG, huge ecosystem- Vue + Nuxt - excellent DX; strong when the team is already Vue-native- Svelte / SvelteKit - smaller bundles; great when hydration tax hurts- Astro - content-first; zero JS by default with islands when needed- Angular - still wins for large enterprise apps with strong conventions- Solid / Qwik - pick when fine-grained reactivity or resumability is the bottleneck## Content sites vs apps For blogs, marketing, and docs, prefer frameworks that ship HTML first (Astro, Nuxt/Next with SSG, SvelteKit). For dense dashboards, prioritize data loading and component maturity over "least JS on the homepage". Either way, keep content in a headless CMS so the UI framework is replaceable. BCMS fits here: templates define structure, entries hold copy and media, your frontend fetches typed content over the API. ## Related reading
Next.js advantages that actually matter- Nuxt vs Vue: when to use which- Best CMS for SvelteWant the full comparison tables, use-case shortcuts, and stack recommendations? Read the complete guide: Best UI frameworks.

Build a Modern Site with Nuxt, Tailwind, and a Headless CMS

Momcilo — Thu, 06 Aug 2026 14:01:21 +0000

If you like Vue, Nuxt gives you the framework layer: routing, SSR/SSG options, and conventions that keep a marketing site maintainable. Tailwind keeps styling fast without inventing a one-off CSS architecture for every landing page.
Add a headless CMS and you get the missing piece: content that marketers can update without opening a PR for every menu item or dish description.

Why this stack works

Nuxt - Vue DX plus production routing and rendering modes- Tailwind - utility classes that scale for marketing pages- BCMS - structured content, media, and an editor UI separate from your repoThat separation is the point. Design system in code. Words and images in the CMS. ## What you typically build (restaurant starter pattern) A restaurant or local business site is a good teaching project because the content model is obvious:
Home hero and story- Menu items with prices and categories- Gallery media- Location / hours- Contact CTAIn BCMS those become templates and entries. In Nuxt they become pages and components that fetch typed data. ## Workflow that stays sane
Scaffold a BCMS Nuxt starter from the CLI- Confirm templates match the sections you need- Map fields to Vue components (hero, menu card, gallery)- Style with Tailwind utilities and a small set of shared layout classes- Deploy the Nuxt app; keep editing content in BCMS## SEO note for Nuxt sites Model meta titles and descriptions in the CMS. Do not hardcode them only in layout files if editors need to change SEO copy. Pair that with Nuxt's head/SEO utilities so each route gets correct tags. ## Related reading
CMS for Nuxt: why to use it- Nuxt vs Vue key differences- Tailwind CSS tutorial start to finishWant the full restaurant walkthrough with setup commands and component structure? Read the complete tutorial: Nuxt and Tailwind CSS tutorial.

How to Choose a Headless CMS for Blogging in 2026

Momcilo — Tue, 04 Aug 2026 14:00:16 +0000

A blog CMS in 2026 has three jobs: let editors ship content safely, let developers keep their framework, and keep pages fast enough that SEO is not a weekly firefight.
Traditional all-in-one platforms can still work. They often get expensive in plugins, theme fights, and performance debt. Headless CMS tools flip the model: content via API, presentation in Next, Nuxt, Astro, Svelte, or whatever you already like.

What "best for blogging" actually means

Flexible content models - posts, authors, tags, related posts, callouts - not only "Post" and "Page"- Media that editors can handle - uploads, alt text, previews, sensible image delivery- Roles and permissions - writers should not accidentally publish production- Frontend freedom - your blog UI is code you control- SEO fields - titles, descriptions, slugs, structured data hooks## Why teams pick BCMS for blogs BCMS is API-first and browser-configured. You model content visually, keep typed SDKs for frameworks, and give non-devs a dashboard that does not require learning a query language to change a headline. Practical upsides for blogging:
Custom content types without theme overrides- Media support with accessibility-friendly fields- Works with Astro, Next, Nuxt, Svelte starters- Multilingual support when you expand locales- Deploy frontend wherever you want (Vercel, Netlify, your own host)## Content modeling quick rules
Identify reusable parts: hero, author card, CTA, FAQ- Relate entries (author pointers, related posts) instead of copy-paste- Keep structures consistent so templates stay maintainable- Avoid rigid page-builder blobs if you want reuse across channels## How it compares (honest shorthand)
Contentful - polished SaaS, less control, cost scales with usage- Strapi - open and flexible, more ops/security ownership- Sanity - powerful custom studio, steeper for simple editorial teams- BCMS - developer-friendly modeling + editor UX without the heaviest enterprise tax## Fast path to a real blog Use a starter: npx @thebcms/cli create next starter blog (or Nuxt/Astro equivalents). Configure env keys, fetch entries, deploy. Editors work in BCMS; you keep shipping frontend improvements independently. ## Related reading
25 simple blog examples you can clone- Headless CMS SEO practices- What makes a CMS user-friendly in 2026Want fetch examples for Next/Gatsby/Astro, comparison tables, and deploy steps? Read the full article: Why BCMS is a strong CMS blog platform for 2026.