DEV Community: Momcilo

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.

How to outsmart AI as a developer: Tricks & tips to win

Momcilo — Wed, 19 Mar 2025 14:58:27 +0000

"Will AI take my job?"

If you ask me that is a wrong question. The right one should be “ Can I outsmart AI?”

Tools like ChatGPT, GitHub Copilot, and other AI-powered assistants handling tasks from debugging to writing boilerplate code, may bring the feeling that there will be fewer jobs for developers.
But here's the truth: developers who learn to work with AI, rather than against it, will thrive in this new era.

In the long run, AI will not replace you, it will enhance your abilities.
Let’s break down why your job as a developer is not only safe but about to become more dynamic, impactful, and valuable than ever before.

Historical perspective: Tech changes that shaped development forever

Throughout software development, certain technological advancements have radically changed the industry. These industry shits weren’t just incremental, they completely transformed how developers think, work, and create.

Here’s a look at some of the pivotal shifts that paved the way for today’s AI revolution:

Version Control Systems

The introduction of version control tools like Git and SVN was revolutionary. Developers moved from difficult manual file-sharing methods to collaborative workflows where teams could simultaneously write, review, and merge code.

Impact:

Boosted collaboration in open-source and enterprise projects.
Made practices like Continuous Integration (CI) and Continuous Deployment (CD) feasible.

Cloud computing

Services like AWS, Azure, and Google Cloud eliminated the need for developers to manage physical servers.

Impact:

Allowed for scalable application hosting.
Introduced infrastructure as code (IaC), creating a bridge between development and operations (DevOps).

JavaScript frameworks

The rise of frameworks like React, Angular, and Vue.js revolutionized front-end development.

Impact:

Standardized front-end architectures.
Help developers to create dynamic, interactive user interfaces.

Headless CMS

Headless content management systems, decoupled content creation from its presentation.

Migrating from traditional CMS to headless CMS had a huge impact not only on content teams but also on devs:

Allowed developers to deliver omnichannel digital experiences.
Streamlined workflows by using APIs for dynamic content delivery.

Programming Languages

Each era of development brought new languages that redefined how software was built:

C enabled low-level system programming with portability.
Java introduced cross-platform development with its "write once, run anywhere" philosophy.
Python and Ruby simplified scripting and web development, inspiring frameworks like Django and Ruby on Rails.
Modern web development relies on JavaScript, which started out as a browser scripting language.

What about AI-powered tools?

As you can see from the examples mentioned above, new technologies don’t eliminate the need for expertise, they enhance it. AI tools are not designed to “think” like developers but to assist them in repetitive tasks, freeing up time for complex problem-solving.

Want to know how to make artificial intelligence your ally? Here are some strategies.

Strategies to Outsmart AI in development

Rather than fearing AI, use it as a collaborator. Here’s how:

Outsmart AI by using it as a coding assistant

Use tools like GitHub Copilot to:

Automate routine coding tasks (writing boilerplate code).
Converting Figma designs to code.
Catch common bugs in real-time.
Generate suggestions for optimizing algorithms.
Build prototypes faster with AI-generated code snippets.

💡Treat these assistants as a starting point, not the final solution.

Shift focus to find solutions for high-level problem-solving tasks

AI excels at repetitive tasks but struggles with complex, abstract challenges. Developers should:

Prioritize learning system architecture and design patterns.
Deepen expertise in niche areas like cybersecurity or machine learning.

Build AI-powered side projects

Experimenting with AI APIs, like OpenAI or TensorFlow, can:

Help you automate tedious parts of your workflow.
Expand your portfolio by working on AI projects.

Use headless CMS to bring structured data into AI

Leverage structured content in headless CMS to orchestrate artificial intelligence. As an analysis tool, AI systems use structured data to maintain consistency, clarity, and organization when identifying patterns and making predictions.

Structured data in AI ensures that the data is structured properly and is accessible for AI-related operations such as:

Auto-filling fields
Generating product descriptions
Improved search functions

Use cases: AI augmenting development

To understand AI’s potential, consider these real-world applications:

Automating code reviews

AI tools like DeepCode analyze pull requests to:

Identify potential vulnerabilities.
Suggest best practices for cleaner, more efficient code.

Prototyping faster with AI

Imagine integrating Figma with an AI tool that instantly converts designs into React components. AI makes rapid iteration cycles seamless.

Revolutionizing content delivery with Headless CMS

AI enables content personalization by analyzing user behavior and dynamically adapting what users see.

For instance, by pairing CMS with AI you can:

Deliver region-specific content in real-time.
Use AI for multilingual support
Deliver personalized user experiences using AI-driven analytics

Conclusion: Work smarter not harder

We cannot stop the development of AI programming, even if we want to. I think the industry will enter an environment where human and AI programmers co-exist.

So to make the best of it you should focus on:

Understanding the basics of AI
Knowing the limits of AI
Learning how to recognize AI deception

So, stop worrying about AI taking your job, start leading the AI revolution, and use it to push the boundaries of what you can achieve. After all, isn’t that why you became a developer in the first place?

Speaking of taking action, try out BCMS as a headless CMS for AI-driven content management.

Structured Data in AI: Is Headless CMS the Key to Smarter Automation?

Momcilo — Mon, 24 Feb 2025 14:18:01 +0000

Artificial intelligence has completely changed the way we used to approach content management.

You can see a major change in how data is structured today and how it is made available for modern technologies such as artificial intelligence.

The main challenge is how to make the best-structured data in AI.

Most of you would not know but at the core of this major transformation is the headless content management system. This is an advanced architecture that handles content creation and is responsible for helping businesses deliver content across different channels and platforms.

When combined with structured data, this headless approach can help a business uncover the true power of AI and also facilitate automation.

In this guide, we are going to discuss in detail the combination of structured data, ai, and headless content management systems, and explore why combining them is so important for achieving smarter and efficient automation.

Structured data in AI an Overview

A headless content management system is a back-end CMS that stores content but doesn’t manage the way how it is presented or delivered. A headless CMS is different from traditional platforms.

In a traditional CMS, like WordPress, the backend where content is managed, and the frontend where the content is displayed are combined. However, in a headless CMS, the frontend and backend are separated, meaning that content can be accessed via an API and displayed on any platform or device, whether it’s a website, mobile app, or even an IoT device.

Headless CMS would rely on the backend instead of the front end, enabling content to be accessed via APIs. This means content can be added to websites, applications, IoT devices, and other digital platforms.

Coming to structured data refers to the data organized in a predefined style or format. Structured data is more searchable and readable by machines.

AI tools that rely on data analysis would require structured data to work effectively. This is because well-arranged data allows AI algorithms to understand and process information with greater accuracy.

When AI works with structured data in a headless CMS, it can bring tons of benefits.

APIs can serve as the connection between the two systems which helps in better integration that is very important while handling tasks such as content creation, automation, and recommendations.

When put together, these technologies can create an intelligent content management system where data would not only be stored but would also be used for improving business operations.

Why structured data is so much important for AI?

There is no doubt about the fact that structured data has become essential for accuracy and efficiency.

But before we get down to the reasons behind its importance, we would urge you to read about the differences between both structured and unstructured data.

How is structured data different from unstructured data?

Let’s start with structured data. This is a highly organized form of data and is well-formatted in a way that it is easily understood by both humans and bots.

Structured data is typically used for advanced databases or spreadsheets and can easily be analyzed with the help of digital tools.

You can take an example of product descriptions, prices, and dates as these are stored in specific fields and have a consistent format.

Unstructured data on the other hand refers to the data that has no formal structure. It includes heavy textual content having some kind of underlying message.

Popular examples of unstructured data include blogs and emails. Here you should know that unstructured data no doubt holds its importance but it requires machines to have complex processing techniques to make sense of it.

Natural language processing is one of the most common techniques used by AI tools for analyzing unstructured text/data.

Now that we have gone through the key differences of both data types, let’s get down to the next section.

Structured data in AI: Why AI model need structured data?

AI systems rely on structured data because this is what helps them maintain consistency, clarity, and organization when identifying patterns and making predictions based on analysis.

You can take the example of machine learning models that require large amounts of clean and structured data to train on.

Without it, AI would face a lot of issues in making accurate predictions or decisions.

A headless CMS plays a very important role in ensuring that the data is structured properly and is accessible for AI-related operations.

By simplifying how content is stored, tagged, and categorized, a headless CMS makes sure that AI tools can get access to relevant data in minimal time and can use it for tasks such as content generation, paraphrasing, personalization, etc.

The role of APIs in artificial intelligence and CMS integration

APIs short for Application Programming Interface are the backbone of any headless content management system that allows content to be accessed and delivered to a wide range of devices/platforms.

In the context of API, these allow AI tools to interact directly with the data stored in the CMS. APIs make it possible to automate procedures related to the content, and provide data quality making sure that AI generates the right information.

Put it simply: Lost in Data? Call an API for directions.

How do APIs connect AI tools with Headless CMS data?

APIs assist in two-way communication between headless CMS and AI systems.

When an AI tool needs to analyze user behavior or make content suggestions, it can use an API to fetch structured content from CMS.

When AI generates new content like product descriptions or blogs, it can send that content back to the CMS through the API for various purposes including storage and delivery.

For deeper insights check out: How to get Structured Content in headless CMS

Examples of an API Request/Response for AI assistive content
Consider an AI model designed to help generate blog posts. The request would look like this:

API Request:

GET /API/content?category=technology&tags=AI

This would retrieve all content in the “Technology” category with an “AI” tag.

API Response:

{
  "articles": [
    {
      "title": "AI in Healthcare: The Future of Medicine",
      "body": "AI is changing the healthcare industry by enabling..."
    },
    {
      "title": "The Rise of AI in Business Operations",
      "body": "AI is increasingly becoming important in business decision-making..."
    }
  ]
}

The AI tool can now analyze this content, learn from it, and even generate a new article based on patterns it identifies.

It could then send a new blog post back to the CMS!

API Response (AI-generated content):

{
  "title": "How AI is Revolutionizing the Future of Work",
  "body": "The business world is transforming as AI tools become integrated into everyday tasks...(continued)"
}

AI content management system: Use cases

Combining structured data, a headless content management system, and artificial intelligence can lead to plenty of opportunities for smarter automation.

If you are not familiar with this, read on this section as below we are going to list some of the most compelling use cases for your knowledge:

Auto-filling fields

AI as you would already know, can easily predict and suggest content based on structured data that it collects from the CMS.

For example, when writing a new blog post, AI can suggest metadata, headless, and even categories based on existing content. This helps one save a lot of time and ensure consistency among all blog articles.

Generating product descriptions

The majority of ecommerce platforms including Amazon rely on generative AI to automate the process of generating product descriptions.

Writing product descriptions manually can be a time-consuming task but AI tools can automate this by grabbing labeled data from a headless CMS API.

Based on data, they can create a detailed, unique, and seo-optimized description.

Example: An AI tool can generate a product description for a new smartwatch:

{
  "product_name": "Dashing Smartwatch",
  "features": ["Heart Rate Monitor", "GPS Tracking", "Water-Resistant"],
  "price": "$99"
}

AI-Generated description:

The Dashing Smartwatch is the perfect companion for your active lifestyle. With a built-in heart rate monitor, GPS tracking, and water resistance, this smartwatch ensures you stay connected and fit no matter where you are. Priced at just $99, it's a must-have for tech geeks.

Improved search functions

Artificial intelligence can also provide help in enhancing search functionality by analyzing and understanding user search intent.

By analyzing the content in a content management system, AI can easily deliver more personalized and relevant search results based on past user behavior and preferences.

Platforms like Netflix, Disney, and even YouTube rely on AI for enhancing semantic search.

For example, if a user searches for motivational songs on YouTube, the AI search engine would pull up the most relevant songs based on the past searches, preferences, and intent of the user.

This is why AI has become important for ensuring a personalized experience.

Learn more: 10 ways to use ChatGPT with headless CMS

Why is BCMS a strong fit for AI-driven content?

BCMS is a very powerful headless content management system that is specifically designed for developers and digital experts building modern websites and stores. It doesn’t matter whether you are working with Reach, Vue, or any other platform, BCMS can help you manage content the way it suits you.

There are many reasons why BCMS is a strong fit for AI-driven content generation out of many other overrated platforms. Below we have listed some of the most popular reasons:

BCMS works efficiently with all front-end frameworks. You can build your UI without worrying about any restrictions.
This platform empowers you to optimize content according to the guidelines of the search engine. It doesn’t matter whether you’re building a static blog or a dynamic site, you can rely on BCMS for content-related tasks.
BCMS is probably one of the only platforms that has been designed to scale. It can handle small as well as enterprise-level projects without any hassle.
BCMS comes with a top-rated global CDN system that ensures that your content is delivered quickly no matter where your users are.
BCMS allows you to control SEO elements like meta tags, sitemaps, and URLs. The platform has been designed to make your content easily crawlable and SEO-friendly.

So if you want to effectively automate your content generation tasks, it is best that you check out BCMS.

Conclusion: Use BCMS as the best CMS for AI data management

The combination of structured data with the best headless content management system can be quite beneficial for a business that wants to achieve smarter automation in terms of content generation and refinement.

Structured data ensures that AI can process information quickly and accurately, and the headless CMS architecture offers flexibility and scalability.

By using APIs to connect AI tools with CMS data, a business can easily streamline content-related tasks, enhance personalization, and deliver personalized experiences.

Artificial intelligence is growing and evolving every turning day so choosing a reliable content management platform like BCMS can provide you with the tools and services for smarter automation.

Try BCMS and check out how this powerful combination can transform your content management strategies.

BCMS Wrapped 2024: Top tracks & top achievements

Momcilo — Tue, 31 Dec 2024 08:49:30 +0000

For this year's review, let’s look back at BCMS’s chart-topping achievements, much like the hit songs that defined the year.

BCMS hit the right notes across the board, from global events to major product launches that changed the game for developers.

Let’s break it down, track by track, as we look back at our standout moments of 2024.

BCMS 2024:Chart-topping achievements

Just like any music award competition, there are categories to win. If there are categories in the headless CMS industry, BCMS would win in the following:

Best New Artist: BCMS Cloud

The all-new BCMS Cloud ensures that you remain unstoppable when working on development tasks while making content management intuitive and scalable.

Here's a summary of what we were shipping:

Input Flexibility: More options for tailoring content to your needs.
Faster Media Management: The system has been revamped to make finding and using files easier.
Seamless Editing: Keep your productivity high with a smoother writing and editing experience.
Effortless Collaboration: BCMS has new tools that make working together super fun.

The Biggest Surprise in 2024: BCMS’s launch of Astro starters

Just like Benson Boone’s "Beautiful Things" celebrates the unexpected success of beauty found in growth, 2024 saw BCMS unveil something truly unexpected—the launch of Astro starters.

It was a surprise to many, yet the reception was positive, with developers quickly embracing the simplicity and power of Astro CMS.

Just like the song’s theme of finding beauty in the most unexpected places, the Astro starters became one of our most beloved features in a short amount of time.

npx @thebcms/cli create astro

Best Collaboration 2024: BCMS Affiliate Program

Launched in 2024, the affiliate program represents the best collaboration between BCMS and the developers who are passionate about working with our platform.

This partnership allowed developers to integrate BCMS into their projects while being rewarded for their efforts.

If we speak in the music industry slang, with this program “fans” can even earn by supporting their fav artist.

By joining the BCMS affiliate program fans can:

Earn 50% commissions on every subscription by helping their community discover a developer-first CMS.

Wanna join?

Start in 3 easy steps:

Join the program.

Share BCMS with your audience.

Earn big rewards!

Become a BCMS affiliate in 2025.

The Best Tour 2024: Web Summit Lisbon

For the second year in a row, we had an opportunity to go through the Web Summit experience, and here’s what we gained:

Four high-quality investor meetings were booked.

User growth: Our user base increased by 1,400%, from 100 to nearly 1,500.
Product expansion: We launched 30+ free code starters for major frontend frameworks, like Nuxt, Next.js, and Gatsby, to show our product’s flexibility.
Time for fun

BCMS 2024 highlights in numbers

XX new affiliates joined the program, expanding our reach and community.

1,400% growth in user base, jumping from 100 to 1,500 active users.

40+ code starters launched to make development even easier across multiple frameworks.

Looking Ahead: 2025 – New Hits, New Collaborations

2024 was just the beginning. With BCMS Cloud and Astro integrations, new features, and even more opportunities for collaboration, 2025 is shaping up to be another year full of excitement.

If we keep using music industry jargon, Here’s what new nominations are coming for BCMS in 2025:

Most Anticipated Release: The Svelte Integration

Developers are choosing Svelte more often because it skips the virtual DOM entirely. No virtual DOM. No framework overhead in the browser. Just fast, efficient websites and apps.

So the next challenge for BCMS is to explain to developers, why is BCMS the best CMS for Svelte. We will prepare guides, tutorials, and examples for 2025, but for now, here is a little sneak peek:

BCMS loves TypeScript maybe even more than Svelte
BCMS supports both static site generation and server-side rendering
Responsive image handling

Last but not least, there will be code starters for Svelte too! 😍

Best Performance: New BCMS pro features

Here’s a breakdown of the new features arriving next year for BCMS:

- Trash: Never worry about deleting something by accident again.

With the new Trash feature, BCMS will keep everything you delete for a set period. On the Free plan, deleted items are stored for 7 days, giving you a chance to access them. For Pro plan users, this extends to 90 days, offering more time to recover important content.

History: Track all your changes with ease.

The History feature will automatically store every update made within BCMS. On the Free plan, it retains changes for 7 days, while the Pro plan extends this to 90 days. This allows for effortless rollbacks to previous versions, ensuring you never lose important edits.

Advanced Input Validations: Customize your content inputs with precision.

BCMS will support advanced input validations, so you can set specific criteria for your fields. Whether it's a minimum or maximum value, or even more complex validations like minimum/maximum dates or date ranges, you can ensure that only the correct data is submitted.

Advanced Media Previews: See your media files like never before.

The new Advanced Media Previews feature allows BCMS to render previews of a variety of new media file types, including 3D objects, PDFs, and more.

Commenting on Entries: Collaboration just got easier.

With the ability to comment directly on entries, team members will be able to discuss content without leaving the BCMS interface. Whether it's feedback, suggestions, or notes for future changes, this feature simplifies communication and helps keep everyone on the same page.

Best Special Event: HeadlessCMS Month & BCMS Hackathon

Looking ahead to 2025, we’re preparing for two major events that will define our year: HeadlessCMS Month and the BCMS Hackathon, to bring the community together and push the boundaries of what’s possible with BCMS.

HeadlessCMS Month: We will dedicate an entire month to celebrating headless CMS with a series of guides, tutorials, giveaways, and community engagement activities. Just like a major album release, this month will be packed with informative sessions where developers can learn, connect, and explore new possibilities with BCMS.
BCMS Hackathon: For the first time in 2025, we’ll be hosting our very own BCMS Hackathon. It’s going to be the ultimate stage for developers to show off their creativity and innovation. Participants will compete to build amazing solutions using BCMS, and we can’t wait to see what the community comes up with.

The world tour: BCMS will Rock in Rio!

Besides preparation for Web Summit 2025 in Lisbon, BCMS will perform at the Web Summit Rio 2025

This will be the first time that BCMS will perform overseas. So, keeping up with BCMS preparation for this conference that will be held April 27-30, 2025. - Save the date to see BCMS on a world tour.

As you can see, the stage is set, the lights are on, and BCMS is ready to release even more chart-topping hits in 2025! Meanwhile, while waiting for 2025 to come, I invite you to join the Discord BCMS community for new updates and start listening to the BCMS FM playlist that will help you build awesome things with BCMS in 2025.

Astro vs Gatsby: Is Astro becoming a replacement for Gatsby?

Momcilo — Mon, 30 Dec 2024 14:31:11 +0000

Gatsby trends show that this once-fav framework is losing its bliss, as developers seek faster, simpler, and lighter options. One competitor that stood out is certainly Astro.

But you know what they say about statistics: “There are three kinds of lies: lies, damned lies, and statistics.”

So, we will leave statistics aside and compare Astro vs. Gatsby in depth to understand what these trends are trying to tell us.

Why is Gatsby losing its bliss?

There are a lot of reasons why developers love to hate Gatsby, but here are the top 4 reasons:

Plugins maintenance
React-based
Can be too slow
Gatsby Cloud didn’t improve build times

From this, you can conclude that developers looking for solutions with fewer plugins ( or plugins that are easy to update) have the freedom to choose tech-stack and top of it to be fast and efficient.

Why is Astro becoming popular?

On the other hand, Astro is becoming more and more popular (besides being a newer tool on the market) for:

File-based routing
Frontend-agnosticism
Component islands architecture
Ships zero JavaScript by default

Even though both are static site generators, how do these differences affect the development process? It’s time to compare Astro and Gatsby based on the features crucial for building websites, apps, or other projects.

Astro vs Gatsby: Features comparison

Here are the features and differences that can make dev life easier or harder, depending on your framework.

Astro vs Gatsby: Performance and speed

Regarding performance and speed, Astro and Gatsby offer unique advantages but differ in their approaches to site generation and rendering, which can significantly impact how fast your site feels to users. Here’s a closer look at how they compare:

Rendering strategy: Astro Islands vs Gatsby Functions

Astro uses an Islands architecture approach, meaning it only sends JavaScript to the client for interactive components ("islands"), while the rest is static HTML. Minimizing JavaScript on the front end speeds up loading times, making Astro extremely lightweight.

Gatsby, on the other hand, relies on React and primarily uses static generation, but it tends to send more JavaScript to the client. While Gatsby does support deferred loading through "Gatsby Functions" and server-side rendering (SSR), its core approach still depends heavily on a JavaScript layer.

Astro vs Gatsby: Build times

Astro is known for its fast build times, as it only processes the necessary parts of the site. Because Astro generates static sites with no JavaScript by default, it is ideal for rapid development and deployment.

Gatsby is known for longer build times, especially on large sites with thousands of pages, mainly because it needs to compile a significant amount of JavaScript and run GraphQL queries for data. However, Gatsby Cloud and incremental builds have helped reduce these times, but they still don’t reach Astro’s level of efficiency for static builds.

JavaScript and client-side rendering

As Gatsby loads all React components on the client, even those that don't need immediate interaction, Astro's selective hydration feature lets only specific components hydrate when needed. This results in minimal JavaScript and reduced page weight, leading to faster time-to-interactive.

Data handling

Unlike Gatsby, Astro doesn’t have a built-in GraphQL layer, making it more straightforward for simple, content-based sites. It relies on direct data imports or fetches, which can sometimes be faster and less complex.

How are these differences in approach reflected in practice? Let's say, you want to build a content-heavy blog site with hundreds of articles and a few interactive components, the development process would look like this:

Astro site structure example:

index.astro: The homepage lists blog posts using static generation.

[slug].astro: Dynamic blog post pages for each article, generated server-side.

Astro would statically generate the HTML for the article pages and only hydrates JavaScript on the interactive SearchBar and Comments components.

This minimal JavaScript approach results in a fast and quick initial load, as only necessary interactive components are hydrated.

Gatsby site structure example:

For the same blog example, Gatsby uses GraphQL to query the content. All components (including SearchBar and Comments) are loaded with React.

As a result, users may notice a slightly longer initial load, especially on mobile devices, because the entire React application and its JavaScript payload are loaded for every page, regardless of the actual interactivity needed.

Astro vs Gatsby: Syntax

Astro’s syntax is very similar to HTML, so if you know basic HTML, you’re ready to use it. You need to admit that this is very convenient, even for beginners. Besides being HTML-based, it is framework-agnostic, so you can use its syntax and mix it with different frontend frameworks (React, Vue, Svelte), without any complex configuration. This file-based routing makes Astro easy to use and learn.

Gatsby’s syntax is fully React-based, so you’ll be writing in JSX, however, it relies on GraphQL for data fetching makes it powerful but a bit more complex.

Overall, if you are looking for simpler and more flexible syntax that doesn’t lock you into a single framework Astro would be a better choice.

JavaScript vs TypeScript support

JavaScript vs TypeScript support in Astro and Gatsby is a key area where they differ.

Even though Astro is designed to work with JavaScript out of the box it has built-in support for TypeScript, which allows you to add static typing without any extra configuration.

Gatsby also has solid TypeScript support, and many of its plugins and templates are TypeScript-friendly. However, because Gatsby is React-based, its TypeScript usage aligns specifically with React’s component-based structure.

The main difference here is that Gatsby doesn’t support components from other frontend frameworks out of the box, so TypeScript’s benefits are focused on React’s APIs and patterns while Astro makes it easy to use TypeScript with any framework you prefer.

Support for Tailwind, SCSS, and CSS modules

Both Astro and Gatsby offer support for these popular technologies for building modern sites. The difference is how: out of the box or through plugins. Since Gatsby is known for its plugin system ( almost like WordPress) you can conclude the outcome:

As you can see from the table, Astro takes the lead in flexibility and simplicity, offering out-of-the-box support for these styling and configuration tools without extra plugins, which keeps projects lightweight and reduces dependency issues.

Astro vs Gatsby: SEO comparison

As a person whose daily job is to worry about SEO, I can’t not compare these two in terms of SEO. I will start this comparison with something that both frameworks slay: SSG.

Static site generation (SSG)

The two frameworks both produce static sites that are lightweight and easy for crawlers to crawl. It means that the site is generated from static HTML, CSS, and JS files and is not hosted on a backend server. By this approach, both frameworks offer SEO-friendly features such as:

Pre-rendered content: Both frameworks generate static HTML pages during the build process, which ensures that all content is available to search engines. This eliminates the need for SSR or CSR, making it easier for crawlers to index your site.
Fast loading times are directly tied to better SEO performance, as search engines prioritize speed and user experience.
SEO-friendly URLs: Both Astro and Gatsby support clean, readable URLs that are optimized for SEO, with clear hierarchies and no unnecessary query strings or dynamic parameters.
Sitemap generation: Both Astro and Gatsby allow you to automatically add and update a sitemap. It is done using @astrojs/sitemap in Astro, and gatsby-plugin-sitemap in Gatsby.

Although both frameworks are SEO friendly, each one of them has unique features that improve SEO and that make them different.

Astro SEO features that are better:

No/Minimal JavaScript by default

Astro’s default behavior is to minimize JavaScript usage. The framework is designed to render static HTML and CSS with zero JavaScript unless needed. By reducing JavaScript, Astro improves page speed and core web vitals, which are crucial for SEO performance. Pages with less JavaScript tend to load faster.

Crawler friendliness

Since Astro generates minimal JavaScript, search engines can crawl your site more quickly. Crawlers spend less time executing JavaScript, so they can index your content faster, making better use of your crawl budget. This is particularly beneficial for large sites where the crawl budget is limited.

Gatsby SEO features that are better:

SEO Plugins

Gatsby has a rich ecosystem of SEO plugins, such as gatsby-plugin-seo, that allow you to manage meta tags, open graph tags, and structured data for better indexing by search engines. With this plugin, it’s easy to configure your site's title, description, and other important metadata, ensuring your site is optimized for search engines automatically.

Image optimization

While Astro does support modern image formats and lazy loading through built-in functionality (@astrojs/image) its features are more limited compared to Gatsby’s (gatsby-plugin-image), which automatically serves responsive images with lazy loading, WebP support, and image compression.

Out of the two, Gatsby does it a lot better. Astro lacks the specific loading styles that Gatsby features, such as images that fade from zero to full opacity when they load.

In terms of SEO capabilities, I would say that Gatsby and Astro are quite similar. Each one supports SSG and includes features that contribute to strong SEO performance.

That said, Astro stands out for sites that don’t rely on heavy interactivity, as it uses minimal JavaScript. On the other hand, if your site requires a high level of interactivity Gatsby may be a better choice.

Interested in how Gatsby compares with other frameworks? Read the comparison of: Gatsby vs Next vs Nuxt: Key Features and Differences

Final thoughts: Is Astro ready to take over Gatsby?

Without a doubt, Astro aims to be the best Gatsby alternative because it solves some of Gatsby’s biggest drawbacks (and devos nightmares): heavy JavaScript, longer build times, and complex GraphQL setups.

In conclusion, Astro is a strong contender and may indeed replace Gatsby for many developers prioritizing speed, simplicity, and modern site architecture. But for high-interactivity sites that rely on advanced plugins, Gatsby still has the upper hand. Astro is close, but it may need a broader plugin ecosystem and more interactivity support before it can fully take over Gatsby's role in the SSG landscape.

Good news?

BCMS offers support in whichever framework you choose to build your sites.

Try Astro CMS to see why this framework is becoming more and more popular.

And if you need a platform to give back bliss to Gatsby projects, you could try using BCMS as your headless CMS for Gatsy.

The best CMS for Astro: How to choose CMS for Astro projects

Momcilo — Fri, 27 Dec 2024 14:56:47 +0000

Would you agree with this statement: Finding the best CMS for Astro is the easiest task ever?

I know this may sound like “lame marketing copy", which could only be believed by people with no coding skills or inexperienced developers. But all of you guys who have been coding every single day for years now know that this statement is nothing more than true.

Before I get into details I need to explain this statement. Astro is a framework-agnostic framework (🤪) that brings a high level of flexibility within any Astro project, but also makes the CMS choosing process way easier. Why does this matter? Keep reading.

What Astro is a framework-agnostic means

The Astro framework is framework-agnostic in the sense that it allows developers to use components and libraries from multiple front-end frameworks (like React, Vue, Svelte, and others). In contrast to other JavaScript frameworks, Astro allows you to mix and match components without committing to a single one.

Three key elements allowed Astro to bring these innovations into web development:

Component islands architecture

Astro Islands architecture allows you to create isolated components, only loading JavaScript for the parts of the page that need interactivity.

In other words, the static content will load quickly without any extra JavaScript, and only the interactive parts =( islands) will load JavaScript when they need it.

Let me use the BCMS home page as an example:

Say the BCMS homepage has a mix of static content, like an introduction section with text, images, etc., and some interactive parts, like a header or CTA buttons.

With Astro islands, only the interactive parts—the "islands"—would load JavaScript. So, the text content loads almost instantly, while JavaScript is used only for the parts that need user interaction, such as clicking the CTA button to launch a form.

This approach keeps the initial page load lightweight and quick, while still allowing the interactive sections to function smoothly when they're needed.

Framework-agnostic rendering

By default, Astro compiles the project to static HTML, sending JavaScript only when necessary. Since Astro doesn't dictate a particular front-end framework, you can use anything you like, even pure HTML/CSS/JavaScript. As a result, it is easy to integrate any framework without excessive bundling or overhead.

Astro component syntax

If you know HTML, you already know enough to write your Astro component. The upgrade starts with .astro files being designed to support components from various frameworks in a single format, which Astro's compiler understands.

You can import components from different frameworks without compatibility issues, and Astro will render them correctly.

For full insights and understanding you can check out the Astro Syntax template.

Besides these elements, some features make Astro more and more popular.

Astro features that make website development easier

Static site generation (SSG) and Server-side rendering (SSR

Even though being a static site generator by default, Astro also supports server-side rendering if necessary. Thanks to this support, SSR generates pages on the server in response to user requests. Users can access dynamic content directly, such as personalized data or frequently changing information.

How does Astro handle SSR?

As I said, Astro handles SSR by configuring it to generate HTML for each page on the server in response to individual requests.

To enable SSR in Astro, you’ll need to use an SSR-compatible adapter. Astro offers several official on-demand rendering adapters, such as:

Vercel: @astrojs/vercel
Netlify: @astrojs/netlify
Node: @astrojs/node
Cloudflare: @astrojs/cloudflare

These adapters allow you to deploy your Astro site to a server environment that supports SSR. For detailed information visit Astro docs guide.

In summary:

SSG (default): Astro generates static HTML by default for high-performance sites.
SSR (optional): Astro can also handle SSR, allowing for dynamic content.

This flexibility makes Astro versatile, letting you choose the best rendering strategy based on your needs.

Flexible data fetching

Astro has a flexible fetch of data from multiple sources during the build process, including:

REST APIs
GraphQL endpoints
Markdown files
Custom data sources

This flexibility supports structured content by fetching it in one central location.

A major benefit of this feature is that Astro provides the freedom to integrate various data sources without restrictions, making it easy to pull data from a headless CMS or other external sources.

Image optimization

Astro has built-in support for image optimization through its @astrojs/image package, which improves image loading and performance.

By using an <Image /> component when you add an image, Astro resizes, formats, and serves the image automatically, applies lazy loading, and generates responsive sizes.

This ensures that the appropriate image resolution is loaded for each user's device, resulting in faster loading times and better performance.

These features make Astro versatile and suitable for both static and dynamic sites, but what about content management systems? How to find the best choice? As I said at the beginning, this can be easier than you think.

What is the best CMS for Astro?

Before I go any further with the explanation I must tell you one big truth: you can use Astro without a CMS thanks to built-in support for Markdown, which lets you build entire sites.

For smaller sites or blogs, managing content directly through Markdown files keeps things simple and lightweight, perfect if you prefer keeping everything within the codebase. You can also use JSON, YAML, or fetch content from APIs, giving you control without adding a CMS.

But why is it better to use CMS for Astro

For simpler sites or smaller projects, managing content directly within Astro might be sufficient, but as the project grows (and to be honest all online grow these days), a CMS becomes inevitable.

Here’s when a CMS is most beneficial:

Scalability

As websites grow, handling content can become difficult if managed directly in Markdown or JSON files. A CMS makes it effortless since it provides a structured environment for managing, editing, and organizing content without requiring direct code changes.

Easier for non-tech teams

Don’t forget about marketers and others in the content creation process. Most of them never used Markdown or JSON files to create blogs, articles, etc. Another reason, marketing teams need more content types that Markdown doesn’t support such as images, videos, tables, and on and on.

Different content statuses:

CMS platforms offer versioning, staging, and publishing workflows. These workflows help content teams review and approve content changes before publishing, track past edits, and roll back changes. They're essential for larger teams or organizations that want to check and balance the published content, especially when updating content frequently.

API integrations and dynamic content:

CMS can serve content via API, making it easy to dynamically load content into Astro pages at build time or on-demand. Also, you can serve content to multiple channels (like web, mobile, and apps) and fetch dynamic data by Astro principles.

What about SEO?

The markdown can be SEO-friendly, particularly when used correctly in the context of static site generators like Astro ( clean HTML output, easy formatting, inclusion of metadata). As for dynamic content, a CMS improves SEO by providing built-in tools to manage structured data, optimize content for search engines, and update content easily.

Headless vs Traditional: Which one is the best CMS for Astro

For Astro sites, a headless CMS takes a win over traditional ones. Here’s why:

Performance and static site optimization

Traditional CMS platforms often require dynamic page rendering, where each request pulls data in real-time, which can slow things down.

On the other side, by pairing Astro with headless, you’ll get a compatible platform that allows Astro to pre-render pages into static HTML, allowing for ultra-fast load times while headless delivers content through APIs, which Astro can fetch at build time, ensuring a faster performance.

Flexible front-end choices

This is more than obvious, traditional CMSs prevent Astro from being framework agnostic since requires working within CMS templates and themes.

Headless on the other hand, improves Astro’s agnosticism by decoupling the content entirely from the front end, giving Astro the freedom to render data in whatever way fits best and for you to choose front-end development tools for your stack.

Content delivery

Traditional platforms are typically web-centric, making it challenging to share content beyond the website. Since headless platforms deliver content via API, you can push content to any device, from websites to mobile apps, and even IoT devices.

Smooth development workflow

Traditional CMS systems often come with extra overhead like plugins, themes, and customization, which can complicate the codebase, (limited to PHP or a monolithic setup), and bring complexities when integrating with Astro’s build process.

Thanks to webhooks, an API-driven structure that can trigger rebuilds in Astro whenever the content is updated, headless support automatic content deployment.

For more differences and deep understanding check out: Traditional CMS vs. Headless CMS - Full Comparison

Why is BCMS the best CMS for Astro

Besides being headless (obviously) BCMS is the best choice for Astro due to its compatibility with Astro's unique architecture and the following BCMS features:

API-first design: BCMS’s API-first approach aligns with Astro's islands architecture, loading data only for interactive components and reducing JavaScript load.
Flexible rendering options: Works seamlessly with Astro’s static site generation (SSG) and server-side rendering (SSR), providing optimized load times and improved SEO.
Content modeling: Allows the creation of reusable content types that integrate easily with Astro’s component-driven structure.
Responsive image handling: BCMS optimizes images and uses lazy loading to ensure responsiveness and fast performance.
User-friendly interface: Simple for marketers and non-developers, allowing them to edit and publish content independently.

All in all, BCMS is a perfect match for Astro. Developers can focus on building great features, while BCMS takes care of the content and performance.

Speaking about developers' building, you can give a try with BCMS Astro code starters, choose a blog code starter, and follow all the instructions from this tutorial: Building Astro Blog with BCMS.

How to make a resume website in Next.js using headless BCMS

Momcilo — Tue, 24 Dec 2024 13:53:38 +0000

Creating a resume with React or other frontend technologies is often viewed as a simple task for one to try out his frontend skills. But while this project is simple, it is also very easy to mess up and over-engineer.

In this step-by-step guide, you will learn how to make a resume website with Next.js with the resume data hosted on BCMS, a headless CMS.

How to make a resume website with the headless approach?

Why this approach you may ask? Well, there are a couple of reasons why to use headless CMS as a resume website builder, to name a few:

Easier Content Updates: With your resume content hosted separately from your app, you can modify your resume without touching your codebase.
Real-Time Updates: You can make changes on your CMS and they’re instantly reflected on the Next.js website.
Customization and Integration: Headless CMSs often have APIs allowing deep customization. If you need to integrate with other services (like job application APIs, and social media like LinkedIn, or GitHub), a CMS can facilitate these integrations more seamlessly than hard-coded data.

These features do not come standard with any CMS, so using a headless CMS with these and other features is essential. That is why BCMS is the best choice for building a professional resume, along with Next.js.

By the end of this tutorial, you will be able to harness the power of Next.js and the super features that BCMS provides to create a fully functional resume website.

Table of contents: How to make a resume website with BCMS

Setting up Next.js app
Setting up BCMS and creating Resume Content
Fetching resume content from BCMS and rendering on the Next app.
Deployment
Next Steps

Setting Up Next.js App

Now let’s set up the Next.js frontend, add styling, and populate resume fields with dummy data.

To begin, head to Next CMS, copy the terminal command and paste it on your terminal to create a simple BCMS Next project using one of the Next starters available.

For this tutorial, I will be using the simple blog website template:

npx @thebcms/cli create next starter simple-blog

This Command will create a next.js project, clone the simple-blog starter inside of it, and then connect to a BCMS instance (more on this later).

This is where it requires you to log in, so simply log in when it prompts you to log in using your browser or create a new account if you don’t have a BCMS account yet.

After logging in, the command will prompt you for the name of the project and then successfully create it, as shown in the image below.

Navigate to the project folder, run the install command and the npm run dev command, after that, your page will be live at localhost:3000.

Now your Next.js project is ready to go and is linked to a BCMS backend, which is where these blog posts are coming from. You don't need these blog posts, though, because your needs are different. So, let's clean up the page.

Page Cleanup

Navigate to the src folder, followed by app, in your newly created Next.js project. There's page.tsx, which is the index page, and that's the only page we'll use for this tutorial because it's a one-page resume with no links to other pages.

First, I'll remove the BlogCard and Tag templates that I won't be using, as well as the BlogEntry types that were automatically generated for me when I used the bcms CLI command.

//Delete

import { BlogEntry, BlogEntryMetaItem } from '../../bcms/types/ts';
import BlogCard from '@/components/blog/Card';
import Tag from '@/components/Tag';

After that, you can change the page title to any title of your choice.

Moving on to the HomePage function, remove all functions and clean up the return statement leaving just a div there with a simple “My Resume”.

The code for the page.tsx should look something like this at this point:

import React from 'react';
import { bcms } from './bcms-client';
import { Metadata } from 'next';

const pageTitle = 'Resume - My Simple Resume';
export const metadata: Metadata = {
    title: pageTitle,
    openGraph: {
        title: pageTitle,
    },
    twitter: {
        title: pageTitle,
    },
};

const HomePage: React.FC = async () => {
    return <div>My Resume</div>;
};

export default HomePage;

And on the browser, this is what will be displayed:

Great, you’ve successfully cleaned up the page.

But there are still other files in the project that we don’t need, so I’m just gonna safely delete them. They’re :

src/app/blog
src/components

Delete every other file in this folder except the layout folder which holds the footer.

After deleting these folders or the files in them, your application structure should look like this:

Great, with the project cleaned up, it is time to set up the UI for the resume.

Designing Page UI

Now, I will set up the page for the resume, and for now, it will hold dummy hardcoded data.

This requires creating the page's HTML structure and then styling it with Tailwind CSS. I will not go into detail about the CSS or Tailwind CSS used to style the page because this is not a CSS tutorial; instead, simply copy the page and replace your existing page.tsx code with it.

import React from 'react';
import { bcms } from './bcms-client';
import { Metadata } from 'next';
import Image from 'next/image';

const pageTitle = 'Resume - My Simple Resume';
export const metadata: Metadata = {
    title: pageTitle,
    openGraph: {
        title: pageTitle,
    },
    twitter: {
        title: pageTitle,
    },
};

const HomePage: React.FC = async () => {
    return (
        <div className="w-8/12 mx-auto mt-6 bg-white px-20 py-12">
            <header className="flex flex-row justify-between mb-4">
                <section className="name">
                    <h1 className="font-bold text-3xl">Your Name</h1>
                    <h3 className="text-2xl">Senior Product Designer</h3>
                </section>
                <section className="profile-photo mr-24">
                    <Image
                        src="/images/avatar.svg"
                        height={90}
                        width={90}
                        alt="resume profile picture"
                    />
                </section>
            </header>
            <main className="details flex justify-between gap-10">
                <section className="basis-[60%]">
                    <h4 className="uppercase text-[#73808D] text-sm tracking-widest mb-1">
                        Experience
                    </h4>
                    <div className="mb-6">
                        <h1 className="font-bold mb-1">
                            Senior UI/UX Product Designer
                        </h1>
                        <h3 className="mb-1">Enterprise Name</h3>
                        <h4 className="text-[#73808D] text-sm">
                            Aug 2018 - Present - 1 year, Paris
                        </h4>
                        <p>
                            Directly collaborated with CEO and Product team to
                            prototype, design and deliver the UI and UX
                            experience with a lean design process: research,
                            design, test, and iterate.
                        </p>
                    </div>
                    <div className="mb-6">
                        <h1 className="font-bold mb-1">
                            UI/UX Product Designer
                        </h1>
                        <h3>Enterprise Name</h3>
                        <h4 className="text-[#73808D] text-sm">
                            Aug 2013 - Aug 2018 - 5 years, Paris
                        </h4>
                        <p>
                            Lead the UI design with the accountability of the
                            design system, collaborated with product and
                            development teams on core projects to improve
                            product interfaces and experiences.
                        </p>
                    </div>
                    <div className="mb-6">
                        <h1 className="font-bold mb-1">UI Designer</h1>
                        <h3>Enterprise Name</h3>
                        <h4 className="text-[#73808D] text-sm">
                            Aug 2012 - July 2013, Paris
                        </h4>
                        <p>
                            Designed mobile UI applications for Orange R&D
                            departement, BNP Paribas, La Poste, Le Cned...
                        </p>
                    </div>
                    <div className="mb-6">
                        <h1 className="font-bold mb-1">Graphic Designer</h1>
                        <h3>Enterprise Name</h3>
                        <h4 className="text-[#73808D] text-sm">
                            Sept 2010 - jul 2012 - 2 years, Paris
                        </h4>
                        <p>
                            Designed print and web applications for Pau Brasil,
                            Renault, Le théatre du Mantois, La mairie de Mantes
                            la Ville...
                        </p>
                    </div>
                    <h4 className="uppercase text-[#73808D] text-sm tracking-widest mb-1">
                        Education
                    </h4>
                    <div className="mb-6">
                        <h1 className="font-bold mb-1">
                            Bachelor European in Graphic Design
                        </h1>
                        <h3>School Name</h3>
                        <h4 className="text-[#73808D] text-sm">
                            2009 - 2010, Bagnolet
                        </h4>
                    </div>
                    <div className="mb-6">
                        <h1 className="font-bold mb-1">
                            BTS Communication Visuelle option Multimédia
                        </h1>
                        <h3>School Name</h3>
                        <h4 className="text-[#73808D] text-sm">
                            2007 - 2009, Bagnolet
                        </h4>
                    </div>
                </section>
                <section className="text-[#73808D] basis-[30%]">
                    <div className="contact mb-4">
                        <p>yourmail@gmail.com</p>
                        <p>+33 6 33 33 33 33</p>
                        <p>Vernouillet</p>
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Industry Knowledge</h3>
                        <p>Industry Knowledge</p>
                        <p>Product Design</p>
                        <p>User Interface</p>
                        <p>User Experience</p>
                        <p>Interaction Design</p>
                        <p></p>
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Tools & Technologies</h3>
                        <p>
                            Figma, Sketch, Protopie, Framer, Invision, Abstract,
                            Zeplin, Google Analytics, Amplitude, Fullstory...
                        </p>
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Other Skills</h3>
                        <p>HTML, CSS, jQuery</p>
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Languages</h3>
                        <p>French (native)</p>
                        <p>English (professionnal)</p>
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Social</h3>
                        <p>yoursite.com</p>
                        <p>linkedin.com/in/yourname</p>
                        <p>dribbble.com/yourname</p>
                    </div>
                </section>
            </main>
        </div>
    );
};

export default HomePage;

From the code above, you can see that you need a photo, for now, it will be hosted on Next.js Project but it will be changed later, so simply go to the public folder, create a new folder named images and save a portrait of your choice to use as a sample profile photo.

Moving on, go to the layout.tsx file under the app folder and change the background color so we get a more beautiful feel and focus on the resume section.

<body className={`${inter.className} overflow-x-hidden bg-[#E5E5E5]`}>

After that, your page should have come to life:

Great, now it's time to set up BCMS and create the resume data.

Setting up BCMS and creating Resume Content

Navigate to BCMS Cloud to login to your BCMS account. On the left side of your dashboard, you see a dropdown containing a list of your BCMS instances (also called projects).

BCMS instance is just like a box or repository containing your application data, so this is the backend for that particular application. You can create different instances for different applications.

If this is your first time using BCMS, you should see only one instance there.

So how do you create data for your application?

The principle behind BCMS data creation is no different from the ones you’ve been using, be it your custom-made backend with either PHP or Nodejs or another CMS if any: You create a data model, this is where you specify the inputs you need, and the property types for that input and then you create data based on those data models.

On the left side of your BCMS dashboard is an administration panel containing Templates, Widgets, and Groups…., and then further down, you will find entries.

What does this all mean, and how do they come together?

Templates - This is your content structure, your building block. Here is where you spell out what fields you need for the section you’re creating a template for.

Entries - An Entry is a simple record of a template, a dynamic piece of content that follows the content structure you defined in your template.

Groups - Groups in BCMS are reusable building blocks made of multiple properties. Groups can be included in any template, widget, or other group.

****Let’s see this in action.

Modelling Data in BCMS

On your templates tab, you’ll find a blog template that was automatically generated upon the creation of this project using the CLI command up above. Since you’ve gotten rid of all blog-related files on your frontend app, it means the blog template is no longer useful to you.

So, click on this template, and then click on edit template on the top right of the page, and then safely delete it.

Now let’s model the data I need for the resume.

First, create a new template named resume. Select a single entry as you will only have just one resume, unlike a blog where you can have multiple blogs.

So what is the data needed for this resume?

Name - String - Required
Title - Automatically created by BCMS
Profile Picture - Media - Required

Work Experience

This will be a group. Groups in BCMS group reusable pieces of fields together. To create a group, navigate to the group tab in your dashboard and click on "Create a new group".

I will name this group "Work Experience" as it will hold information concerning work experience. The information it will hold is:

Job Title - String - Required
Enterprise Name - String - Required
Work Duration - String - Required
Work Description - Rich Text - Required

Now back to the Resume template, you can successfully link to this group, and it should be an array since it will be holding multiple work experiences.

Education: Like the work experiences, this will also be a group holding similar data.

Create the group and link it to the resume template.

Contact form information - This will be a group holding the contact information

Create the group and link it to the resume template.

Industry Knowledge - String, Array
Tools and Technologies - Rich Text
Other Skills - Rich Text
Languages - String, Array
Social - String, Array

Congratulations, your template should look something like this at this point:

Next up, go to the entries tab and then click on the resume to create an entry, you can now write the actual resume data following the structure that you just defined in the template.

Simply edit the fields there and after doing that click on the status drop-down on the right side of the page, change it to published, and then update.

With that, you’ve successfully written your data and you’re ready to have it on your Next.js app.

But before that, you need to update your API key permissions. Navigate to settings and then the API key, click on edit and you should see permissions for the newly created Resume template.

Toggle the ones you need on, for this tutorial that will be “can get”. Without this permission, you will not be able to get resume data on your Nextjs frontend.

Fetching resume content from BCMS and rendering on the Next app.

So how do you fetch data from BCMS in your Next.js app?

Well, you saw a sneak peak, at the start of the project with the blog starter example. Now you’re gonna replicate the same thing but this time, you’re fetching the data for the resume.

First, I need to create the resume types to let the Typescript know what I am expecting to get when fetching the data. When I first created the data, the BCMS CLI automatically connected to the BCMS instance got the blog entry, and then generated the types for me which is great.

But that is not all… The CLI continues to generate types for me automatically when I add new templates and entries.

To get these auto-generated types from BCMS all you have to do is stop the dev server and start it again, and BCMS will pick those new templates and entries and generate types for them.

This is one of the great features BCMS offers developers to ease their tasks, so you don’t have to manually create types for your data, it is already handled for you. Really cool :).

Fetching the data

To fetch BCMS data for your Nextjs application on the page.tsx file, import the types auto-generated for you by BCMS.

import { ResumeEntry, ResumeEntryMetaItem } from '../../bcms/types/ts';

And then on your HomePage function, before the return statement, you get the Resume using the bcms client installed for you when you set up the app.

    const resume = (await bcms.entry.getAll('resume')) as ResumeEntry[];
    console.log(resume);

And you should be able to see the returned data in your terminal.

You can also log more fields to see what you can get. For example, I’m gonna log the meta-object as it is the object that holds our entry.

Great, now you can use the data in your app. So I'm going to replace the dummy data with that from BCMS. You can copy the finished code below.

import React, { Fragment } from 'react';
import { bcms } from './bcms-client';
import { ResumeEntry, ResumeEntryMetaItem } from '../../bcms/types/ts';
import { Metadata } from 'next';
import { notFound } from 'next/navigation';
import Image from 'next/image';
import Link from 'next/link';
import { BCMSImage } from '@thebcms/components-react';

const pageTitle = 'Resume - My Simple Resume';
export const metadata: Metadata = {
    title: pageTitle,
    openGraph: {
        title: pageTitle,
    },
    twitter: {
        title: pageTitle,
    },
};

const HomePage: React.FC = async () => {
    const resume = (await bcms.entry.getAll('resume')) as ResumeEntry[];
    if (!resume) {
        return notFound();
    }

    const data = {
        meta: resume[0].meta.en as ResumeEntryMetaItem,
    };

    const imgObj = resume[0].meta.en?.profile_picture;

    return (
        <div className="w-8/12 mx-auto mt-6 bg-white px-20 py-12">
            <header className="flex flex-row justify-between mb-4">
                <section className="name">
                    <h1 className="font-bold text-3xl">{data.meta.name}</h1>
                    <h3 className="text-2xl">{data.meta.title}</h3>
                </section>
                <section className="profile-photo mr-24">
                    <BCMSImage
                        clientConfig={bcms.getConfig()}
                        media={imgObj}
                        className="object-cover rounded-2xl w-28"
                    />
                </section>
            </header>
            <main className="details flex justify-between gap-10">
                <section className="basis-[60%]">
                    <h4 className="uppercase text-[#73808D] text-sm tracking-widest mb-1">
                        Experience
                    </h4>
                    {data.meta.work_experience.map((experience, index) => {
                        return (
                            <div className="mb-6" key={index}>
                                <h1 className="font-bold mb-1">
                                    {experience.job_title}
                                </h1>
                                <h3 className="mb-1">
                                    {experience.enterprise_name}
                                </h3>
                                <h4 className="text-[#73808D] text-sm">
                                    {experience.work_duration}
                                </h4>
                                <p />
                                <span
                                    dangerouslySetInnerHTML={{
                                        __html: experience.work_description
                                            .nodes[0].value,
                                    }}
                                />
                            </div>
                        );
                    })}
                    <h4 className="uppercase text-[#73808D] text-sm tracking-widest mb-1">
                        Education
                    </h4>
                    {data.meta.education.map((degree, index) => {
                        return (
                            <div className="mb-6" key={index}>
                                <h1 className="font-bold mb-1">
                                    {degree.degree_name}
                                </h1>
                                <h3>{degree.school_name}</h3>
                                <h4 className="text-[#73808D] text-sm">
                                    {degree.duration_and_location}
                                </h4>
                            </div>
                        );
                    })}
                </section>
                <section className="text-[#73808D] basis-[30%]">
                    <div className="contact mb-4">
                        <p>{data.meta.contact_information.email}</p>
                        <p>{data.meta.contact_information.phone_number}</p>
                        <p>{data.meta.contact_information.location}</p>
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Industry Knowledge</h3>
                        {data.meta.industry_knowledge.map(
                            (knowledge, index) => {
                                return <p key={index}>{knowledge}</p>;
                            },
                        )}
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Tools & Technologies</h3>
                        <span
                            dangerouslySetInnerHTML={{
                                __html: data.meta.tools_and_technologies
                                    .nodes[0].value,
                            }}
                        />
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Other Skills</h3>
                        <span
                            dangerouslySetInnerHTML={{
                                __html: data.meta.other_skills.nodes[0].value,
                            }}
                        />
                    </div>
                    <div className="mb-4">
                        <h3 className="font-bold">Languages</h3>
                        {data.meta.languages.map((language, index) => {
                            return <p key={index}>{language}</p>;
                        })}
                    </div>
                    <div className="mb-4 flex flex-col">
                        <h3 className="font-bold">Social</h3>
                        {data.meta.social.map((social, index) => {
                            return (
                                <Link key={index} href={social}>
                                    {social}
                                </Link>
                            );
                        })}
                    </div>
                </section>
            </main>
        </div>
    );
};

export default HomePage;

With that, you’ve successfully queried data from the BCMS backend and rendered it on your website. If you check your browser now, you will see the content being displayed.

Deployment

To deploy your Next.js app, you need to use a service called Vercel. It's a straightforward way to make your website live on the internet. Follow this tutorial to learn how to use Vercel.

Next steps

To sum it up, creating a resume using NextJS headless CMS is simple and powerful. BCMS headless CMS helps you manage your resume’s content, while Next.js makes sure your website works well.

The resume you've created is not just for show – it's a starting point for you to explore what BCMS can do. With BCMS, you can easily adapt your website to different needs and connect it with other tools.

You have created this one-page resume but can take it further by making it multiple. That means in the resume template, you can make it a non-single entry to create multiple resumes for different needs. For example, you could create a Java resume and then a UI design resume that you show to different recruiters.

BCMS makes this process really simple, by just toggling off a single entry in the template, you will be able to create multiple resumes, and then on your Nextjs app, you get those different resumes and display them on different URLs just like a blog works.

Well, with that, I will say happy coding, and let’s see what you can achieve with Nextjs and BCMS.

Mythbusting: Gatsby isn’t that bad. Maybe your expectations are.

Momcilo — Fri, 20 Dec 2024 15:52:02 +0000

It’s easy to hate Gatsby.js.

If you hang around developer communities long enough, you’ll hear the same complaints repeated:

"The builds are too slow."
"GraphQL is a nightmare."
"It’s over-engineered."

But let’s take a step back and look at these gripes with a fresh perspective.

Maybe, just maybe, the problem isn’t Gatsby. Maybe it’s the developers who are quick to throw in the towel.

The most common reasons developers think Gatsby is bad

Here’s why Gatsby isn’t as bad as some people make it out to be, and why you might need to rethink your approach before hopping on the hate train.

1. GraphQL: Not your enemy

One of the loudest complaints about Gatsby is its reliance on GraphQL. Developers say it’s overkill for fetching simple data, too complicated for beginners, and unnecessary.

But here’s the thing: GraphQL is incredibly powerful once you get the hang of it. Sure, it takes a little bit of learning, but once you get comfortable with it, you realize how flexible and efficient it can be.

GraphQL’s real power shows up when your site has complex, multi-source data requirements. Instead of fighting with multiple REST APIs or awkwardly looping through JSON files, you get a structured query language that retrieves exactly the data you need- nothing more, nothing less.

With GraphQL, you can pull exactly the data you need and no more, reducing over-fetching and improving performance. For complex content-heavy sites, this becomes a lifesaver, and let’s not forget that many modern apps are moving toward GraphQL anyway. So why not embrace it?

Pros:

Precision: You avoid over-fetching, and this reduces payload size.
Flexibility: Whether your data comes from Markdown, CMS, or external APIs, GraphQL abstracts it into a single data layer.

Cons:

Learning curve: Admittedly, if you’ve never touched GraphQL, it’s a headache at first. It's like learning SQL from scratch but in JSON format.

Solution: Stop trying to avoid it. Gatsby’s whole ecosystem thrives on GraphQL because it’s built to handle complex data structures. If you’re building a small, flat-file blog and complaining about GraphQL, maybe Gatsby isn’t the right choice. But if you’re building something content-heavy, it’s indispensable.

Pro Tip: Start small. Learn the basics of querying with Gatsby’s starter examples, then expand your knowledge. It’s worth it in the long run.

2. Build times: It’s called optimizing

Yes, Gatsby builds can get slow on larger sites. But most developers aren’t optimizing their builds properly before complaining. Out-of-the-box Gatsby provides a lot of optimizations: image optimization, code splitting, lazy loading—but it also expects you to take some responsibility for fine-tuning things.

There are ways to speed up those long builds:

Incremental builds: By leveraging Gatsby Cloud or configuring your infrastructure, you can take advantage of incremental builds that only rebuild what’s changed.
Selective plugins: Use only the truly necessary plugins, and keep an eye on what’s slowing things down. Many developers blindly install plugins and then wonder why things aren’t running smoothly.

Solution: Take control. Use Incremental builds in Gatsby Cloud or manually configure your build process to optimize only the sections that change. Get smarter with your queries—don’t pull in everything from GraphQL if you don’t need it.

Remember, Gatsby offers Selective plugins, so make sure you aren’t blindly installing packages that slow everything down.

Pro Tip: Use tools like Gatsby’s Build Analysis to track where your build time goes. You might be surprised that it’s not Gatsby itself, but a plugin or heavy content.

3. Gatsby plugins: Not the problem, your choices are

Another common complaint is Gatsby’s plugin ecosystem. Developers claim it’s bloated, confusing, and prone to breakage.

Here’s a harsh truth: Most plugins don’t break Gatsby. They break your site because you installed them without properly vetting them.

But let’s be honest: most of these issues arise from poor plugin choices or installing a plugin for something you don’t fully understand.

If you’re facing conflicts, breaking changes, or bugs from plugins, it might be time to reconsider how you’re using them.

Solution: Read the docs. Vet your plugins properly before installing them into a production environment. Make sure they’re actively maintained and compatible with the version of Gatsby you’re running.

Pro Tip: Don’t go plugin-crazy. Just because a plugin exists doesn’t mean you need it. Keep your plugin ecosystem lean, and only install what’s truly necessary.

4. Steep learning curve? Sounds more like laziness

A lot of developers complain that Gatsby has a steep learning curve, especially for those unfamiliar with React or GraphQL.

Here’s a reality check: if you’re in development, you’re constantly learning. Frameworks evolve. Tools change. If you’re stuck in a mindset where everything has to be easy, you’re going to hit a wall with any modern tool. Gatsby is no different.

Learning Gatsby does take effort, especially if you’re new to React or GraphQL. But let’s not act like other frameworks don’t have learning curves, too.

If you think Gatsby’s too hard, wait until you try integrating multiple data sources in Next.js or dealing with the more complex server-side rendering in Nuxt.

Gatsby teaches you more than just Gatsby.

By learning Gatsby, you improve your skills in React, GraphQL, and static site generation—three crucial areas for modern web dev.

Accept that development is a learning process. If you aren’t willing to invest the time to learn Gatsby, then maybe you’re not cut out for complex web projects. Frameworks evolve, and if you’re not evolving with them, that’s not Gatsby’s fault.

5. Alternatives are great—but that doesn’t make Gatsby bad

Yes, there are alternatives to Gatsby. Next.js, Nuxt, and SvelteKit—all offer different strengths and approaches. But let’s not pretend that using one of these tools automatically makes Gatsby bad.

Gatsby excels at what it was designed for blazing-fast static sites with built-in performance and SEO optimizations.

The fact that other tools exist doesn’t mean Gatsby is doing something wrong. Different tools for different jobs, right?

Use the right tool for the right job. Gatsby excels at content-heavy sites where SEO and performance are key. If you’re building an app with constant data refreshes, Gatsby probably isn’t the best choice, and that’s fine.

Learn more: Gatsby vs Next vs Nuxt: Key Features and Differences

6. SEO: Gatsby’s strength, not weakness

One of Gatsby’s biggest selling points is its SEO-friendliness. As a static site generator, it handles things like pre-rendering and meta tags out of the box, ensuring that your pages load fast and rank well. Yet, some developers claim that adding dynamic content and third-party integrations makes SEO a hassle.

Here’s the thing: that’s true of any static site generator. The moment you bring in client-side rendering or complex dynamic features, you have to put in extra work to ensure your SEO doesn’t tank.

Gatsby provides tools and guides to help you navigate this—it’s just a matter of understanding how to use them properly.

7. Gatsby is perfect for complex content-heavy sites

Developers often criticize Gatsby for being unsuitable for content-heavy sites due to several common concerns, which stem from issues around performance, scalability, and data management.

Here’s a breakdown of why many developers think Gatsby isn’t good for content-heavy sites:

Slow build times as content grows
GraphQL dependence
Slow image processing

If you’re working on a site with a ton of content, Gatsby is actually one of the best tools you can use. Gatsby site can pull data from multiple sources (APIs, Content management systems, Markdown, etc.) and stitch them together seamlessly is a godsend.

For developers dealing with large-scale content projects, Gatsby’s data layer and GraphQL integration make it easier to manage and query that content.

Instead of patching together REST APIs and traditional databases, Gatsby simplifies the process. It’s because of this flexibility that it’s favored by content-heavy sites like blogs, news platforms, and e-commerce stores.

Solution: Be strategic with your data fetching. Start with smaller queries and add complexity only when necessary. Gatsby gives you the tools to handle large-scale data elegantly, but it’s on you to optimize those queries and ensure you’re not pulling in more data than you need.

Pro tip: Use tools like Gatsby’s GraphiQL interface to test and refine your queries. This will save you from pulling unnecessary data, which can dramatically improve both performance and build times.

8. Developer experience: better than you think

Developers love to talk about DX (developer experience) and how it should be seamless and painless.

Gatsby isn’t perfect, but let’s not ignore the fact that it comes with some fantastic DX features:

Hot reloading: Update your content and see it instantly without refreshing.
Comprehensive documentation: Gatsby’s docs are pretty solid, covering everything from installation to troubleshooting.
Built-in performance optimizations: You don’t have to reinvent the wheel to make your site fast. Gatsby’s default performance tooling takes care of that.

The occasional hiccup doesn’t mean Gatsby’s DX is bad—it just means it’s complex. If you’re willing to understand how it works, it makes life easier in the long run.

So, maybe It’s not Gatsby after all

At the end of the day, Gatsby isn’t the monster some developers make it out to be. It’s a powerful, flexible, framework that helps you build fast, scalable, and optimized static sites. If you’re having a hard time with it, it’s worth considering whether the problem is the tool or how you’re using it.

Maybe the hate stems from frustration, but that doesn’t mean Gatsby is inherently bad. Like any tool, it requires learning, patience, and effort. And in many cases, the so-called “downsides” of Gatsby are solvable problems that might require you to adapt, learn, and improve.

Want to give a Gatsby a chance? Try headless BCMS as your Gatsby CMS or use free code starters to start your new open-source project. Find codes at our GitHub.

Why developers love to hate Gatsby.js instead of using it

Momcilo — Wed, 18 Dec 2024 15:16:27 +0000

Let’s be honest: sometimes, it’s easier to hate on something than to give it a fair shot. Hate Gatsby.js seems to be one of those tools in the development world that people either swear by or go out of their way to bash. But why does it attract so much shade?

The truth is, Gatsby makes it easy for developers to hate on it, and that says more about devs than it does about the framework itself.

Why is it easy to hate Gatsby.js

Here’s why it's easier to jump on the hate train instead of giving Gatsby the credit it probably deserves.

It's got "Overkill" written all over it

First, Gatsby is often seen as a massive over-engineering project wrapped in a trendy package. It’s the kind of tool that feels like it’s trying too hard to be “everything you’ll ever need.”

For simple static sites, Gatsby can be like showing up to a casual backyard BBQ wearing a tuxedo. Do we need GraphQL just to fetch some Markdown files? Probably not. But Gatsby insists on it anyway.

Gatsby treats GraphQL like a hammer for every nail. Need to pull in some data? Cool, here’s GraphQL—now go write a query even if a simple REST fetch would do. Sure, it’s “powerful,” but it’s also complete overkill for small projects. Most devs don’t need GraphQL for 99% of use cases. What they need is simplicity. But Gatsby insists on complexity like it’s a badge of honor.

It’s almost as if someone sat down and thought, “How can we make this more painful than it needs to be?”

And they did.

You thought Gatsby was a straightforward React framework? Think again. Between its convoluted Webpack config, Babel setup, and custom GraphQL layer, you’ll spend more time configuring than coding.

Gatsby is supposed to help devs build faster, but it feels more like it’s designed to make sure you stay buried under layers of tooling forever.

For many devs, the thought of wrestling with GraphQL and configuring a complex build pipeline for what should be a straightforward static site feels like a punishment, not a feature.

The Plugin hell

“Just install a plugin” — every Gatsby fan ever. Sure, Gatsby's plugin ecosystem looks great from the outside, but here’s the reality: you’re going to end up in dependency hell sooner or later. And by sooner, I mean on day one.

Installing plugins becomes a necessity rather than a choice, and before you know it, your project is bloated with dependencies you barely understand. And let’s not even talk about when these plugins break, which they often do, leaving you to sift through GitHub issues and Stack Overflow for some solution.

You want to build a simple blog, but suddenly, you’re stuck solving plugin version conflicts. You’ve got one plugin needing gatsby-plugin-sharp at version X and another plugin that breaks if you’re not on version Y.

Congratulations, your simple build now feels like you’re diffusing a bomb. Why are we doing this again?

It's like being trapped in IKEA with a complex piece of furniture that has missing screws and instructions in Swedish—yes, you’ll probably figure it out, but was it worth the headache?

Build time slog

Static site generation is supposed to make your life easier, right? Well, with Gatsby, that’s true... until it isn’t.

Gatsby loves to brag about its blazing speed—until you actually build something of substance. The more data you add, the more you’ll be wondering if Gatsby is secretly mining crypto while you wait.

A few blog posts? Fine, 10-second builds.

But the second you introduce real-world complexity like dynamic data or multiple data sources, the build times skyrocket. What’s that? Incremental builds? Sure, if they actually worked reliably.

As if local builds weren’t bad enough, Gatsby’s build times murder your CI/CD pipelines. Need to deploy updates frequently? Not with Gatsby. Unless your company is willing to wait 30 minutes every time you push a change, you might as well grab a deck of cards while your pipeline runs.

You can keep playing your fav card game because Gatsby doesn’t allow you to optimize the build process.

Gatsby has its own way of doing things, and if you don’t like it, tough luck. You’re stuck waiting through long build processes while Gatsby churns through every single page, even the ones that haven’t changed.

Why put up with this when you could be using a framework that doesn’t make you want to take up knitting while your builds process?

"Better" Alternatives

Next.js exists. Nuxt.js exists. SvelteKit exists. Heck, even Jekyll still exists. These are all frameworks that do a lot of what Gatsby does but without the overwhelming baggage.

They don’t force you into the same rigid structure. They don’t bog you down with unnecessary complexity for simple tasks. The moment you realize there’s something better—or at least more intuitive—for your specific use case, the Gatsby appeal quickly fades.

Gatsby’s not bad at what it does, but it's not exactly irreplaceable, either.

Read about all the differences: Gatsby vs Next vs Nuxt: Key Features and Differences

Developer Experience is not as smooth as promised

Let’s talk DX (developer experience), the buzzword we’re all sick of hearing but still care about.

Gatsby claims to provide a great developer experience with hot-reloading, local dev servers, and plenty of plugins to speed up common tasks. But then reality kicks in: hot-reloading doesn’t always work, the dev server crashes occasionally, and some plugins cause more headaches than they solve.

Hot-reloading failure: Hot-reloading is a lie Gatsby tells to keep you on the hook. You’ll spend more time waiting for hot-reloads than actually coding. And when it stops working (which it frequently does), you’ll be forced to restart your entire dev server, completely killing your flow.
Weird, random build errors: Ever been blindsided by Gatsby throwing an error for no clear reason? “Error in plugin 'gatsby-transformer-remark'. Please see your config.” But the config is fine. You didn’t change anything! The framework just decided it had enough of your project and now refuses to cooperate. You’ll spend hours debugging nonsense like this instead of building features.

When a framework promises you a seamless experience and then delivers something half-baked, as a developer, nothing's worse than a framework that promises a smooth experience but delivers frustration.

Challenging serverless and dynamic integrations

Gatsby shines when it's building out static sites, but things get murky when you need serverless functions, authentication, or dynamic data that updates in real time. Sure, you can get these things to work, but Gatsby often feels like it's working against you when you try to push it beyond static content.

Static first, dynamic last

Gatsby is built on the philosophy of static site generation, which means it’s designed to pre-build everything during the build process. That’s awesome for performance, but it’s terrible when you need dynamic functionality like user authentication, serverless functions, or live data fetching.

Real-time updates? Not happening.

Since Gatsby generates your site at build time, any data that changes after the build won’t be reflected until the next build. This means you’re stuck rebuilding your site every time you want to update content.

Server-rendering support… Maybe not the best feature

Gatsby tries to offer server-side rendering (SSR), but if you need dynamic routing, session-based data, or real-time user interaction, you’ll end up wrestling with Gatsby’s limitations or turning to Next.js, which handles SSR much more gracefully. Gatsby’s "SSR" support is more of a workaround compared to Next.js, where it’s been baked in from the beginning.

Why Gatsby's SSR is bad?

While Gatsby introduced SSR support with version 4, it’s still primarily optimized for static site generation (SSG). Here’s why Gatsby's SSR implementation is not up to par:

Performance: Gatsby’s SSR introduces additional server-side processing time. Static pages built ahead of time are fast, but SSR pages are rendered dynamically, which leads to slower response times and poor performance, especially for larger sites.
Cold start delays: Gatsby’s SSR can suffer from cold start delays, particularly on serverless platforms. These delays mean the first request to a page can take noticeably longer, which is a significant drawback for sites with real-time data or frequent content updates.
Plugins: Most of Gatsby’s plugins and tools are designed around static content. This means that many plugins don’t work as intended when using SSR, causing compatibility issues and headaches for developers trying to mix SSG and SSR workflows.
Data fetching: When switching to SSR, you have to move away from the well-documented graphql queries and use the more complex getServerData API. This introduces another layer of complexity when dealing with data fetching, especially if some pages are static and others are server-rendered.

As you can see it’s not impossible to handle dynamic content in Gatsby—but it sure doesn’t feel like it was designed for it.

SEO, but at what cost?

Gatsby is supposed to be a dream for SEO, especially since it’s built as a static site generator.

And sure, on paper, a fully pre-rendered static site should be an SEO dream: fast load times, pre-built HTML, and minimal JavaScript execution. But when you start adding dynamic content and third-party scripts without messing up your SEO becomes a challenge.

Here are the challenges:

Static-first SEO doesn’t play well with dynamic content

Gatsby’s static site generation is fantastic for SEO if your content never changes. But as soon as you start working with dynamic content, Gatsby’s SEO benefits become a lot harder to manage.

Dynamic content loaded client-side: Because Gatsby generates everything statically at build time, any content that’s fetched or rendered client-side isn’t available to search engine crawlers. This means that if your site depends on API data that’s pulled in via client-side JavaScript, search engines like Google won’t see it—leading to huge SEO blind spots.
Late-loading content: You might think, “Well, I’ll just load dynamic content on the client and use JavaScript for SEO tags.” Sure, but here’s the problem: crawlers aren’t guaranteed to execute JavaScript, or they might execute it late. By the time your client-side data has loaded, the crawler has already moved on, and your page ranks lower because the content it needs to index simply isn’t there. It’s a big gamble, and in many cases, a losing one.
Static tags in a dynamic world: With static content, your meta tags are easy to manage. You build your pages and generate your tags at build time. But when you add dynamic content—especially when pulling data from APIs—you need to generate these tags dynamically based on the data. Unfortunately, Gatsby isn’t built to regenerate these SEO tags after the initial build. This means you’ll have to add custom code or implement hacks using React Helmet or similar libraries to manually manage your dynamic SEO tags—adding another layer of complexity.
SEO for user-generated content: Let’s say you’re pulling in dynamic content, like blog posts or comments, from an API. You need each page to have unique meta descriptions and canonical URLs for proper indexing. With Gatsby, achieving this dynamically can be a pain, because the framework is designed to handle SEO at build-time, not at run-time.

Lazy-loading affecting SEO

Gatsby heavily relies on lazy-loading assets like images and JavaScript, which is great for performance but can hurt your SEO if not done correctly.

Images and JavaScript: Google cares about how quickly content loads, especially images. While Gatsby’s image plugin does offer optimized images with lazy-loading and responsive formats, these images may not load in time for search engine crawlers to index them properly. If Google sees placeholders instead of actual content, it can assume your page is incomplete or poorly optimized, harming your rankings. This is especially a problem with slower network connections or heavily dynamic pages.

Many developers spend more time tweaking their Gatsby configuration to handle SEO edge cases (lazy loading images, proper schema tags, etc.) than they would on any other platform.

Does all this hate Gatsbyjs make it dead

The hate towards Gatsby isn’t because it’s inherently a bad tool. It’s because developers love efficiency, and Gatsby often feels less efficient.

Sure, it’s easy to hate Gatsby for its shortcomings, but we need to acknowledge its strengths too—because yes, it has plenty:

Incredible static performance

When it comes to pure static site generation, Gatsby is a beast. Gatsby’s ability to pre-render everything at build time means that it delivers lightning-fast sites straight out of the gate. Once the build process is over (yes, it can be slow), Gatsby’s performance is hard to beat.

Plugin ecosystem—when it works

We’ve ranted about plugin hell, but let’s not forget that Gatsby’s plugin ecosystem is also one of its greatest strengths. If you’re building a standard static site, Gatsby has a plugin for nearly everything. From handling image optimization to adding SEO metadata, Gatsby's plugins can make development easier and faster, especially for developers who are less inclined to reinvent the wheel.

Extremely secure

Gatsby is arguably one of the safest frameworks you can choose, especially when it comes to deploying static sites. Since Gatsby generates static HTML, there’s no database or server-side processing, which means less surface area for security vulnerabilities.

No server, no problem: Traditional CMSs like WordPress are notorious for being hacked due to outdated plugins, brute-force attacks, and server exploits. Gatsby, on the other hand, doesn’t have a server to attack. Once the site is built and deployed, there’s practically no risk of common attack vectors like SQL injections or DDoS attacks because everything is already pre-rendered and cached.
Out-of-the-box SSL and encryption: Gatsby’s integration with platforms like Netlify and Vercel means you can automatically deploy your site with HTTPS encryption, which is crucial for SEO and user trust. This is one less thing to worry about when it comes to securing your site.

So, is Gatsby Dead?

Absolutely not. Gatsby is still alive and well, especially in niche markets where static site generation, performance optimizations, and complex data integrations are prioritized. When used for the right type of project, Gatsby is an incredibly powerful tool that can deliver results few other frameworks can match.

Why developers still choose Gatsby:

Performance beast for static sites: If you’re building a marketing site, a blog, or an eCommerce store with relatively static content, Gatsby’s performance is still hard to beat.
Extensive ecosystem: The plugin ecosystem is second to none, allowing developers to easily add advanced features like image optimization, SEO improvements, and integrations with CMS platforms.
Unified data layer with GraphQL: For complex projects with multiple data sources, Gatsby’s GraphQL layer can be a massive asset, simplifying the process of pulling data from different APIs, markdown files, and CMSs.

Find out: Why do these 15 devs still choose Gatsby.js over Next.js?

Maybe the real problem isn’t Gatsby. Maybe it’s because developers have grown accustomed to things being simpler, more intuitive, and less demanding.

Conclusion: Is it hate or is it frustration?

Maybe the hate isn’t really about the framework itself, but about the expectations Gatsby fails to meet for many developers. It’s not a bad framework, but it’s also not a universally loved one, and that’s okay. Not every tool is for everyone, and Gatsby might just be one of those things that’s easier to criticize than to fully embrace.

In the end, hating Gatsby is easy because the alternative—learning it, mastering its quirks, and making it work for you—feels unnecessarily hard. And when you have other options, why wouldn’t you take the path of least resistance?

Your Custom CMS is a big mistake that needs fixing

Momcilo — Mon, 16 Dec 2024 13:30:22 +0000

Building a custom CMS is the most reliable way to waste $100K - $200k in tech. I've watched dozens of companies do this. "Our needs are unique," they say. Two years later, their content team is stuck with a broken image uploader and their developers hate their lives. I know this intimately - as a co-founder of BCMS, I help companies escape their custom CMS nightmares every month.

Look, I love indie software. I've built and sold several products. But a custom CMS isn't scrappy engineering - it's organizational masochism.

Why you'll fail

Every custom CMS dies the same way:

You think you're special
You build something that can't handle file uploads properly 3.Your content team can't paste from Google Docs 4.Your developers are stuck maintaining garbage instead of building your product

I just talked to a CTO who spent $80K building a CMS that couldn't handle “draft” posts - a feature his marketing team needed on day one. Another built one where uploading a 10MB video would crash the server. Guess what? They're both switching to headless CMSs now.

The real cost of Custom CMS

Custom CMS costs:

Initial development (4 months): $40K
Part-time maintenance: $60K/year
Infrastructure: $3K/year
Unexpected fixes: $20K/year Total: $123K first year, $83K/year after

Headless CMS costs:

50 users × $10/month = $6K/year
Two weeks of integration: $15K (one-time) Total: $21K first year, $6K/year after
But money isn't the real cost. The real cost is time spent not building your actual product.

When a custom CMS makes sense

Only three reasons:

You have HIPAA requirements no existing CMS can handle (rare)
You're dealing with classified documents (very rare)
You're building a CMS product to sell (good luck competing with the dozens already out there, BCMS included)

How this ends

If you ignore this advice:

Month 3: "Just need to add image uploading"
Month 6: "Just need user roles"
Month 12: "Need to rebuild the editor"
Month 18: "Maybe we should look at existing solutions..."

I've seen this movie. It always ends the same way.

What to do instead

Accept you're needs are not so special
Pick a headless CMS (BCMS, for example)
Integrate it in a week
Build your actual product

The best CMS is the one your team forgets exists. The worst is the one you're still debugging two years later.

Every hour spent building a custom CMS is an hour your competitors spend building features their customers want. Choose wisely.

Why Tailwind Doesn't Suck

Momcilo — Tue, 19 Nov 2024 10:04:59 +0000

This is my response to this Reddit thread that blew up recently. After 15 years of building web apps at scale, here's my take:

CSS is broken.

That's it. I have nothing else to say.

Okay, here a few more toughts:

Not "needs improvement" broken. Not "could be better" broken. Fundamentally, irreparably broken.

After fifteen years of building large-scale web apps, I can say this with certainty: CSS is the only technology that actively punishes you for using it correctly. The more you follow its rules, the harder it becomes to maintain.

This is why Tailwind exists.

Tailwind isn't good. It's ugly. Its class names look like keyboard shortcuts. Its utility-first approach offends everyone who cares about clean markup. It violates twenty years of web development best practices.

And yet, it's winning.

Why? Because Tailwind's ugliness is honest. It's right there in your face. CSS hides its ugliness in a thousand stylesheets, waiting to explode when you deploy to production.

Here's what nobody admits: every large CSS codebase is a disaster. I've seen codebases at top tech companies. They all share the same problems:

Nobody dares to delete old CSS
New styles are always added, never modified
!important is everywhere
Specificity wars everywhere
File size only grows

The "clean" solution is to write better CSS, enforce strict conventions, and maintain perfect discipline across dozens of developers and thousands of components.

This has never worked. Not once. Not in any large team I've seen in fifteen years.

Tailwind skips the pretense. Instead of promising beauty, it promises predictability. Instead of global styles, it gives you local ones. Instead of cascading problems, it gives you contained ones.

"But it's just inline styles!" critics cry.
No. Inline styles are random. Tailwind styles are systematic. Big difference.

"But you're repeating yourself!"
Wrong. You're just seeing the repetition instead of hiding it in stylesheets.

"But it's harder to read!"
Harder than what? Then the ten CSS files you need to understand how a component is styled?

Here's the truth: in big apps, you don't write Tailwind classes directly. You write components. The ugly class names hide inside those components. What you end up with is more maintainable than any CSS system I've used.

Is Tailwind perfect? Hell no.

It's too permissive
Its class names are terrible
It pushes the complexity into markup

Its learning curve is steep (it still takes me 4-10 seconds to remember the name of line-height and letter-spacing utility class, every time I need it)

Its constraints are weak

But these flaws are fixable. CSS's flaws are not.

The best argument for Tailwind isn't Tailwind itself. It's what happens when you try to scale CSS. CSS is the only part of modern web development that gets exponentially worse as your project grows.

Every other part of our stack has solved scalability:

JavaScript has modules
Databases have transactions
Servers have containers

CSS has... hopes and prayers 🙏.

Tailwind is a hack. But it's a hack that admits it's a hack. That's more honest than CSS has ever been.

If you're building a small site, use CSS. It'll work fine. But if you're building something big, something that needs to scale, something that multiple teams need to maintain...

Well, you can either have clean code that doesn't work, or ugly code that does.

Choose wisely.

You can stop complaining about WordPress and start using BCMS 🎉

Momcilo — Thu, 24 Oct 2024 10:59:28 +0000

BCMS makes it easy to build modern websites:

Built-in content modern builder (aka Advanced Custom Fields)
Super fast, well designed interface
Full control over every line of code of your website
Easy media management with folders
Built-in multilingual support
Full control with a flexible API
Official Next, Gatsby, Nuxt code starters

It’s built to be fast, scalable, and give you fewer headaches. It's powerful like WordPress with 70 plugins installed, but fast, stable and intuitive. 😅

Also coming soon... more code starters for Svelte, Astro, more integrations that will make building for web even more powerful.

Get started here: https://app.thebcms.com