DEV Community: Momcilo

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.

9 Next.js Alternatives in 2026 (And When to Actually Switch)

Momcilo — Thu, 30 Jul 2026 14:00:36 +0000

Next.js is a strong default for React teams. It is not the right default for every site. If your bottleneck is JS weight, edge latency, Vue preference, or e-commerce plumbing, a Next.js alternative can be the sane move.
Here is a practical shortlist for 2026 - not a hype ranking, a "pick by problem" map.

What to evaluate before switching

Rendering needs - SSR, SSG, islands, resumability- Performance budget - TTFB, hydration cost, Lighthouse reality- DX - docs quality, boilerplate, how painful data loading feels- Ecosystem fit - CMS APIs, hosting, team skills- Scale story - what breaks at 10k concurrent users or 100k pages## Alternatives worth knowing
Remix - cleaner nested data loading; strong on the edge- SvelteKit - smaller bundles; great when hydration tax hurts- Astro - zero JS by default; islands when needed; excellent for content sites- Qwik - resumability; heavy interactive apps without classic hydration pain- Fresh (Deno) - edge-first, simpler runtime story for some teams- Nuxt - the Vue-native answer to Next-style SSR/SSG- SolidStart - React-like mental model with fine-grained reactivity- Blitz - full-stack conventions for shipping SaaS faster- Shopify Hydrogen - when the store is the product and Shopify is already home## Use-case shortcuts
Blog / portfolio - Astro or SvelteKit usually beat a hydrated Next app- Shopify storefront - Hydrogen beats a Frankenstack of Next + plugins- Dense dashboards - Qwik or SolidStart when hydration becomes the bottleneck- Vue team - Nuxt, not "learn React because the blog said so"## Keep the CMS portable Frameworks change. Content should not. A headless CMS (BCMS included) keeps entries, media, and models behind an API so you can move from Next to Astro or Nuxt without rebuilding the editorial layer. ## Related reading
Next.js advantages that actually matter- Astro Server Islands tutorial- Best CMS for SvelteWant deeper comparisons, install snippets, and the full decision checklist? Read the complete guide: 9 Best Next.js Alternatives for 2026.

Next.js Advantages That Actually Matter for Real Projects

Momcilo — Tue, 28 Jul 2026 14:01:11 +0000

Next.js stays popular because it solves boring production problems: rendering strategy, SEO-friendly HTML, routing, and a path to full-stack features without bolting five tools together on day one.
If you are building content sites, storefronts, or dashboards in React, the useful question is not "is Next.js cool?" It is "which Next.js advantages pay rent on this project?"

Flexible rendering (the real killer feature)

SSR - HTML per request for personalized or frequently changing pages- SSG - prebuilt pages for blogs and marketing, served from the edge/CDN- ISR - static pages that can refresh on a schedule without a full rebuildYou can mix strategies page by page. That is the advantage people underestimate until they try to force one rendering mode on every route. ## SEO and performance defaults Pre-rendered HTML is easier for crawlers than a blank client shell. On top of that, Next.js gives you:
Automatic code splitting per route- next/image for resizing, formats, and lazy loading- Fast Refresh during developmentNone of that replaces good content modeling or caching strategy - but it removes a lot of DIY glue. ## Full-stack without a second repo (sometimes) API routes (and modern route handlers) let you handle forms, webhooks, and light backend work next to the UI. For many products that is enough. For heavy domains you will still split services - and that is fine. ## When Next.js is a strong fit
SEO-heavy marketing and editorial sites- E-commerce catalogs that need both speed and freshness- SaaS dashboards with mixed static and dynamic data- Teams already deep in React## When to look elsewhere
Mostly static content with almost no interactivity - Astro or similar can ship less JS- Ultra-minimal sites where framework weight hurts more than it helps- Teams that want Vue-first DX - Nuxt may feel more natural## Content + Next.js Next.js is the delivery layer. For blogs and product content, keep copy in a headless CMS so editors are not filing PRs for every headline change. BCMS pairs well here: fetch entries in server components, render structured fields, keep the frontend free to evolve. ## Related reading
Why BCMS works well as a Next.js CMS- How to optimize Next.js projects- 9 Next.js alternatives for 2026Want code samples for SSR/SSG/ISR, e-commerce patterns, and a fuller comparison table? Read the complete article: Next.js advantages for your project.

Spec-Driven Development in 2026: Stop Vibe Coding, Ship What You Specced

Momcilo — Thu, 23 Jul 2026 14:01:10 +0000

Spec-driven development (SDD) treats a versioned specification - not the code - as the source of truth. You write what the system should do, plan how, break work into tasks, then implement. When requirements change, you edit the spec first and regenerate or update the code against it.
That sounds old-school until you watch AI agents vibe-code a feature that almost matches intent, invents APIs, and quietly contradicts yesterday's decisions. In 2026, SDD is the bridge between powerful agents and reliable shipping.

Why SDD showed up now

LLM coding agents fail in three predictable ways:

Intent drift - "add login" is too vague; the model invents defaults- Context decay - past the context window, older decisions get ignored- Unverifiable output - without acceptance criteria, review never endsA precise spec fixes all three. The phrase you keep seeing: the spec is the prompt. ## The four phases
Specify - user stories, acceptance criteria, NFRs, out of scope- Plan - architecture, data model, APIs, constraints from a project constitution- Tasks - atomic checklist items a junior (or agent) can execute- Implement - code against the tasks, verify against the criteriaHuman checkpoints at each boundary matter. Skipping them is vibe coding in a costume. ## EARS notation (the part agents actually follow) EARS (Easy Approach to Requirements Syntax) gives five patterns that collapse fuzzy asks into testable claims:
Ubiquitous - The system shall log every authentication attempt.- Event-driven - WHEN a user submits login THE system SHALL validate credentials.- State-driven - WHILE sync is in progress THE system SHALL show a progress indicator.- Unwanted - IF login fails three times in 60s THEN THE system SHALL lock the account.- Optional - WHERE MFA is enabled THE system SHALL require a TOTP code.If it is not EARS-clear, an agent will guess. Guessing is expensive. ## Tooling landscape (quick map)
GitHub Spec Kit - open, model-agnostic reference path- AWS Kiro - agentic IDE with hooks after each action- Claude Code + skills - terminal SDD loop- Cursor Plan Mode + AGENTS.md - IDE-first constitution + plan- OpenSpec / BMAD / Tessl - lighter or compliance-focused variantsPick based on where you already work. Portability usually means Spec Kit. AWS shops often pick Kiro. Cursor teams lean on Plan Mode plus a constitution file. ## SDD vs vibe coding vs TDD Vibe coding is great for spikes. SDD is for anything that ships. TDD says write the test first. SDD says write the whole intent first - behavior, constraints, edge cases - then generate code and tests from that. They complement each other; they are not rivals. ## Pitfalls to avoid
Over-speccing implementation details- Under-speccing behavior ("make it nice")- Skipping a project constitution- Keeping specs in Notion while code lives in git- Letting agents merge without phase reviews## Related reading
BMAD method for website content- Connect BCMS MCP to ChatGPT- Why AI depends on structured contentWant the full tool comparison, Claude/Copilot/Cursor workflows, and a worked example? Read the complete guide: Spec-Driven Development (SDD): The Definitive 2026 Guide.

Astro Server Islands: Keep Pages Fast Without Giving Up Interactivity

Momcilo — Tue, 21 Jul 2026 14:00:48 +0000

Most content sites do not need a full SPA. They need fast HTML first, then a small amount of JavaScript for carousels, comments, or filters. That is exactly what Astro Server Islands are for.
Astro ships static HTML by default. Interactive pieces become islands that hydrate only when you ask for it. The rest of the page stays light, which helps LCP, FCP, and Core Web Vitals.

How Server Islands work

Think of the page as mostly static zones plus a few interactive components:

Static content is rendered on the server and delivered as HTML- Each island is an isolated interactive component- JavaScript loads only for those islands- Hydration timing is controlled with client directivesUseful directives:
client:load - hydrate after the page loads (chat, share, like)- client:idle - hydrate when the browser is idle- client:visible - hydrate when the component enters the viewport (carousels, below-the-fold widgets)- client:only - render only on the clientRule of thumb: use client:load for above-the-fold UI that must work immediately. Use client:visible for everything else. ## Pair Astro with a headless CMS Astro is great at delivery. A headless CMS is great at content ops. With BCMS you get templates (content types), entries (posts), media, and typed content your frontend can fetch without stuffing Markdown into the repo for every edit. That split matters: editors update content in a dashboard. Developers keep framework freedom. The site still ships mostly static HTML. ## Practical setup Start from a BCMS Astro starter: npx @thebcms/cli create astro starter simple-blog After login and project naming: cd your-project && npm install && npm run dev In BCMS:
Templates define the shape of a blog post- Entries are the actual posts- Restart the Astro app after content model changes so types and data refresh## Add an island: image carousel A common pattern:
Install a Vue carousel (Astro starters often already include Vue)- Add a media field on the Blog template in BCMS- Build a Vue component that accepts a media collection prop- Render it in the blog page with client:load or client:visibleConditionally fall back to a cover image when the carousel field is empty. That keeps the page useful even when editors skip optional media. ## Production mindset Use npm run build, then serve the dist output. Visitors get HTML without waiting on a database round trip for every page view. You keep interactivity where it earns its keep. ## Related reading
Best CMS for Astro in 2026- 20 Astro website examples- Jamstack frameworks comparedWant the full walkthrough (screenshots, carousel code, production notes)? Read the complete guide on the BCMS blog: Astro Server Islands tutorial.

I convert videos to printed flipbooks for a living: here's how the pipeline works (FFmpeg print bind)

Momcilo — Fri, 17 Jul 2026 13:59:20 +0000

I spent years shipping software. Now part of my week is printing, binding, and shipping small books.

In 2018 we built a side project that turned short videos into flipbooks. It sat idle for years. In late 2024 we relaunched it as VideoToFlip - a family workshop in Serbia. Upload a clip, preview the frames, we print and bind a pocket-sized book, ship it worldwide.

Stack: Next.js, FFmpeg, ImageMagick, a printer, and our hands. No AI pipeline. It pays bills.

The pipeline

1. Upload + validation

Customers upload MP4 / MOV / AVI, usually under 30 seconds and 100 MB. Before FFmpeg we check:

duration
file size
orientation
that the file is actually a video

Most support tickets come from skipping this step.

2. Frame extraction with FFmpeg

The product is 72 pages, so we extract 72 frames.

Even sampling across the clip is the obvious approach:

# conceptual - evenly spaced frames
ffmpeg -i input.mp4 -vf "fps=..." frame_%03d.jpg

It looks correct and often feels wrong. People care about the peak moment (kiss, jump, laugh), not the lead-in. We bias sampling toward motion so the flip matches what they remember.

ImageMagick handles sizing and crop for print.

3. Preview before checkout

We show the exact frames that will print - not a mockup.

That converted better than any copy change. Gift buyers want to know they aren't ordering the wrong second of the video.

If you sell custom physical goods: preview the artifact, not the promise.

4. Print, bind, finish in-house

We started with local print shops. Quality was inconsistent and turnaround was slow - a problem when wedding favors need to look identical across dozens of books.

So we bought machines and learned printing, binding, and finishing ourselves. The physical object is the product. Outsourcing it was a mistake.

5. Shipping + customs

We ship DHL from Serbia. Tracking matters. Clear customs/VAT messaging matters more. International buyers hate surprise fees on a gift.

Mistakes

Even frame sampling - correct in code, wrong in hand. Optimize for how the flip feels.
Vertical video in a landscape book - validate orientation early.
Outsourcing quality - fine for stickers, bad when the object is the brand.

Not another SaaS story

The web app is real: uploads, preview, checkout. The output leaves the screen. A short clip becomes paper.

People order for gifts, weddings, and family moments. That demand is why this still exists.

DIY version (extract frames, print at home, bind yourself):

→ DIY flipbook guide

Workshop / origin:

→ About VideoToFlip

Questions about FFmpeg sampling, binding, or shipping paper internationally - ask in the comments.

Can AI coding platforms replace traditional page builders?

Momcilo — Thu, 27 Mar 2025 15:50:36 +0000

Will AI make page builders obsolete in the next 12 months? Or are we just swapping one trap for another? This guide breaks down what AI coding platforms can actually do, where they fall short, and how a smarter hybrid approach is already winning.

Tools like Framer AI, Builder.io, and ChatGPT’s Code Interpreter promise to automate code generation and streamline development.

But can they truly replace established page builders like Webflow, Elementor, and Wix?

Picture this: A freelance developer needs to build a landing page overnight. With Framer AI or Builder.io, they can generate an entire layout in seconds. Meanwhile, a small business owner with zero coding knowledge drags and drops elements in Webflow to create a functional website.

Both approaches work, but do they scale? Do they produce clean, maintainable code?

Let’s break down the differences.

AI coding platforms vs. page builders: What’s the difference?

AI website generators function by analyzing user prompts and automatically generating code or design elements.

Platforms like v0.dev allow users to describe a layout, and the AI produces HTML, CSS, and JavaScript.

Some tools even integrate logic, making it possible to generate interactive components without manually coding them.

This approach brings numerous advantages such as:

Speed: AI can generate complete sections of a website in seconds.
Customization: Full control over the output (assuming the user has coding knowledge).
No reliance on plugins: Unlike WordPress or Elementor, AI-generated websites aren’t weighed down by third-party plugins.

But what AI tools can’t do as page builders?

They can not offer consistency. AI-generated designs may lack uniformity across different pages.

Even being “smart” AI code doesn’t always follow design best practices.

On the other hand, page builders like WordPress and Webflow offer structured, template-based systems for creating websites. Even though they are not as fast as AI regarding website building, they allow beginners and developers to build sites quickly.

There is no need for coding knowledge, and built-in templates and themes follow the design through the pages.

Other things that make website building a nightmare are plugin dependency and limited customization.

Let’s break this down by what really matters: speed, flexibility, and maintainability.

AI coding platforms vs page builders: Features comparison

Before going to code analysis and the development process, let’s cover the pros/cons of both, focusing on flexibility, speed, and maintainability.

Feature #1: Speed and performance

AI tools can generate layouts and even functional components in seconds, reducing manual effort. They’re particularly powerful for rapid prototyping and generating boilerplate code.

Traditional page builders offer a no-code or low-code approach, allowing users to build entire sites visually. While they’re quick to set up, the drag-and-drop nature can introduce bloated code and performance issues.

Feature #2: Flexibility and customization

AI-generated code can be fully customized, but it often requires a developer to refine and optimize the output. These tools are best suited for developers who need assistance with repetitive tasks rather than a full website solution.

Page builders offer extensive customization options through UI elements, but advanced customizations often require diving into custom CSS or JavaScript, which can be limiting.

Feature #3: Accessibility

AI Coding Platforms still require users to understand code, making them more suitable for developers than non-technical users.

Page Builders are designed for ease of use, making them ideal for non-developers. However, complex modifications can bring a need for developers.

AI coding platform vs page builders: which one wins?

Here’s how they compare in real-world use.

AI tools win over speed and customization (if you know how to code), while page builders are more scalable and easy to update and manage without breaking layouts.

So, use AI tools if you're a developer looking for full control over code.

Use page builders if you need ease of use and long-term maintainability.

A hybrid approach (AI-generated templates + CMS) could be the best of both worlds. ( more about this later)

But before that, let’s get to the code.

Can AI code be good quality code?

While AI coding tools generate websites quickly, the code quality is often questionable. Let’s break down the key issues:

Code structure

AI-generated code can be messy, redundant, and inconsistent. Unlike a well-structured, manually written codebase, AI tools often create unnecessary divs, inline styles, and inconsistent class naming conventions.

Example:

AI might generate multiple similar CSS classes for buttons across different sections (.btn-1, .btn-2, etc.) rather than following a DRY principle with a reusable .btn class.
Accessibility features like proper heading hierarchy, ARIA labels, and semantic HTML are often overlooked by AI.

Handling reusable components

One of the major limitations of AI-generated sites is the lack of reusable components. While page builders offer systems for managing global components like headers and footers, AI platforms often require users to manually copy and paste code across different pages.

Example:

A manually coded site (or a Webflow project) allows for a single header component that updates across all pages.
An AI-generated site requires you to edit multiple HTML files separately if you need to update the navigation.

Code optimization

AI-generated pages can be unoptimized, with excessive inline styles and redundant scripts.

Debugging and extending AI-generated code

AI is not perfect at debugging. Developers often find that AI-generated code works initially but contains subtle bugs or inefficient logic when extended.

AI-generated JavaScript might work for a simple contact form but lack proper validation handling, requiring manual fixes.

Example: AI-Generated Code Before & After Cleanup

Before (AI-generated code):

html
CopyEdit
<div class="btn-1">Click Me</div>
<div class="btn-2">Click Me</div>

Issues: Creates unnecessary duplicate styles, lacks semantics.

After (Cleaned Up Code):

html
CopyEdit
<button class="btn">Click Me</button>

Fixes: Uses semantic HTML and a reusable class.

Key AI Code Problems:

❌ Messy structure – Unnecessary wrappers, inline styles.
❌ Poor accessibility – Lacks proper heading hierarchy and ARIA labels.
❌ SEO risks – May omit metadata, structured data, or proper alt text.

Resume: AI code can’t build for you

I won’t argue here should or you should not use an AI code tools, instead, I want to conclude that the best option for developers is to approach AI code as a starting point rather than a fully functional solution.

AI is inevitable, so instead of ignoring it, learn ways to outsmart AI and use it as a powerful tool for your development task as an assistant, not as an ultimate solution.

AI + CMS = A hybrid approach that gives a solution

Rather than picking sides in the AI vs. page builders debate, what if you could combine the best AI features with CMS?

What would happen if you choose to top building pages and instead start building reusable and flexible content?

As I mentioned earlier in the text, both approaches are incomplete, so why wouldn’t you try to choose a structured approach?

AI coding tools are great for speed and automation, while CMS-driven sites provide scalability, structured content, and long-term maintainability.

A hybrid approach allows developers to use AI's speed while maintaining full control over the content and structure.

How it works: AI generates, CMS manages

This concept is based on simple logic. Use the benefits of both to make your life easier. Here’s the possible workflow:

Use AI for fast prototyping

AI can generate layouts, components, or even full-page structures in seconds. Instead of manually coding boilerplate sections (e.g., a hero section or a pricing table), developers can use AI tools like Framer AI or Builder.io to create an initial version.

Refine and optimize the code

AI-generated code still needs a developer’s touch. This step involves cleaning up unnecessary elements, improving accessibility, and ensuring semantic HTML for SEO and maintainability.

Integrate with a CMS for content management

AI generates the front-end structure.
A CMS (like BCMS) stores and delivers content dynamically.
Developers connect the CMS to the AI-generated templates, ensuring a scalable, editable system for non-technical users.

Benefits of this hybrid approach

Scalability: A CMS allows easy content updates without breaking the layout.
Customization: AI provides flexibility while developers refine the final product.
Efficiency: AI speeds up development, and the CMS ensures long-term manageability.
Better performance: Unlike bloated page builders, this approach keeps the codebase clean and optimized.

Example: AI + CMS in action

To understand my idea and suggestion, here is a real case:

Imagine you’re building a multilingual website in Next.js.

Host content on BCMS: Store articles in BCMS.
Fetch content: Retrieve articles from BCMS for translation.
User preference: Add a translation button for language selection.
AI translation: Send content to AI for real-time translation and receive the response.
Frontend update: Display translated content without modifying the original BCMS data.

Want to see how this looks?

Luckily, we wrote a step-by-step tutorial for this example. Learn more: Building a multilingual website in Next.js with AI-powered translation

Conclusion: AI as a tool, not a replacement

AI isn’t here to replace developers or even page builders entirely. Instead, it’s a tool that, when used correctly, can improve development workflows.

The best approach isn’t to choose AI over CMS or page builders but to integrate them strategically.

Rather than seeing AI as a website builder, think of it as an assistant, helping developers generate code faster, while a CMS ensures structured content and long-term site management.

By leveraging AI for speed and a CMS for scalability, developers get the best of both worlds: automation without compromise.