Category: platforms

On July 2, 2026, Zoom signed on to acquire Common Room, the company that gives revenue teams a person- and account-level read on buyer intent for customers like Atlassian, Anthropic, Autodesk, Notion, Okta, and Snowflake. Zoom hasn’t said what it’s paying, and it’s aiming to close within weeks.

On its own, that’s a headline. What makes it worth ten minutes of your time is everything sitting underneath it. This is the third independent GTM signal company folded into a bigger revenue platform in about a year, and Zoom itself has a documented, split track record on what happens next to a company it buys. One outcome, and the product you rely on keeps running exactly as it did the day before the announcement. The other, and it quietly stops existing within eighteen months.

If you run a DevTool GTM or content team, and especially if Common Room is already part of your stack, this is that story written for you specifically: what Zoom actually bought, what its own acquisition history predicts happens next, the part of this deal almost nobody covering it seems to have noticed, and a straight, non-salesy look at where Common Room and its alternatives stand today.

Not planning to read this top to bottom? Fair. Here’s where to jump:

• The two-minute recap: what Common Room actually is, and why Zoom wants it
• Zoom, déjà vu edition: two past acquisitions, two opposite endings, and what that predicts for Common Room
• The angle most of them are skipping: what actually changes when your buyer writes code for a living
• Should you be worried, and what to do either way: read this if you’re a Common Room customer
• The lineup of Common Room alternatives: Reo.Dev, UnifyGTM, 6sense, and Clay
• Frequently asked questions

What Common Room actually is

Common Room started in 2020 in Seattle, founded by Linda Lian, Tom Kleinpeter, Viraj Mody, and Francis Luu. It raised roughly $52.9M from Index Ventures, Greylock, and Madrona.

It started as a tool for tracking GitHub and Discord mentions. Over time, it grew into a full person-level and account-level read on buyer intent, pulling in community activity, product usage, and review-site signal. Building something Atlassian, Anthropic, and Snowflake all rely on is real work.

On July 2, 2026, Zoom signed a definitive agreement to buy it. In its own words, Zoom describes the deal as “a natural extension of Zoom Revenue Accelerator,” the product it built to listen in on and score sales conversations after a meeting gets booked. Bolt Common Room on, and the pitch is that a rep finds out who’s worth calling in the first place, before that meeting ever lands on a calendar.

Zoom’s track record: Two acquisitions, two different outcomes

That’s a clean-sounding thesis on paper, and whether it plays out that way is a separate question.

• Zoom bought Workvivo in 2023. It kept its name, its team, its product, and later became Meta’s own migration partner when Workplace shut down, about the strongest outcome an acquired product can get.
• Zoom bought Solvvy the year before that, and it went the other way entirely, folded into Zoom Contact Center as a feature until the standalone product stopped existing.

From what I noticed, the variable that seems to matter is buyer overlap.

• Workvivo’s buyer (HR) barely touched Zoom’s core buyer, which is likely why it kept running its own way.
• Solvvy’s buyer was a support leader who was already a Zoom Contact Center customer, and that overlap is likely why it got pulled inside.
• Whoever signs off on Common Room tends to be the same person who already champions Revenue Accelerator, which leans toward the Solvvy path. Worth watching, not a verdict.

What’s the part nobody is writing about

Common Room is the third GTM signal shop in about twelve months to lose its independence to a bigger revenue platform.

• Clari and Salesloft combined their forecasting and sales-engagement products in December 2025, calling it a unified “Predictive Revenue System.”
• Apollo bought Pocus in March 2026 to build what it calls an “AI-native GTM operating system.”
• A parallel version of the same story is playing out one lane over: Salesforce bought Qualified, then Fin, and HubSpot just picked up Warmly in June 2026.

Aimdoc, which has no stake in any of these deals, called it “the system of record buying the system of action.”

I’d put it more bluntly: everyone who owns the database is now buying the thing that watches what buyers actually do, because building that watching-layer from scratch takes years and buying it takes a term sheet.

Why every DevTool GTM team should be paying attention to the acquisition pattern

Buyer-intelligence platforms, Common Room included, are built to tell you who’s paying attention.

They were never built to explain why.

A star on a repo, a Slack mention, a pricing-page visit all tell you something lit up on a dashboard.

None of them tell you which blog post, which comparison page, which three-paragraph explainer in your docs actually moved that developer from curious to convinced.

That’s the layer we live in for a living, and it’s the layer this whole acquisition wave keeps skipping past.

It’s also a layer that’s changing shape faster than most GTM stacks can see. We wrote about this earlier in 2026: AI-referred sessions grew 527% year over year in the first half of 2025.

Our own 2026 developer marketing survey found 62% of dev marketing teams growing content budgets this year, with content ranking as the second-highest investment priority industry-wide.

Translate that into what actually happens on a Tuesday: a developer asks Cursor or Claude which auth library to use, or has an AI agent query your API reference through MCP before they’ve looked at it directly themselves.

That interaction can shape a buying decision completely, and it never shows up as a page view, a form fill, or, as far as we can tell today, a signal in Common Room or most of what’s competing with it.

Package installs, CLI activity, section-level documentation engagement, and AI agent evaluation through MCP are a genuinely different signal category from community and social monitoring, and it’s a category almost nothing in this acquisition wave has a dedicated answer for yet.

You can own every signal in the world and still be flying blind on the one question that actually matters, why anyone converted in the first place.

Should Common Room customers be worried?

Honestly, most shouldn’t be.

If your buyers live in general community engagement, review sites, and broad product usage, rather than package managers and terminals, Common Room’s breadth is a real strength, and that doesn’t change because Zoom now owns the cap table.

Whether Common Room keeps its Workvivo-shaped independence or its Solvvy-shaped absorption is genuinely unknown right now, and I’d be skeptical of anyone claiming certainty about it this early.

Where it’s worth a second look: if developer-native technical intent, installs, CLI activity, documentation engagement, AI agent evaluation, is the thing your funnel actually runs on, that layer was never Common Room’s specialty even before Zoom entered the picture.

What should you do if you’re using Common Room

Nothing about this deal forces a decision by Friday.

Integrations don’t get ripped out and roadmaps don’t get rewritten in the week after a press release goes out, whatever the urgency of some LinkedIn posts might suggest.

Still, doing a bit of homework now beats scrambling later once a feature you rely on quietly vanishes from a roadmap. A few things worth doing now:

• Check what your analytics can actually see
  • If a developer’s AI assistant fetched your docs through MCP this week, does anything in your stack know that happened? For most teams right now, the honest answer is no.
• Trace your best-performing content back to the signal it produced
  • A tutorial that drives installs and CLI activity is doing different, often more valuable, work than one that drives page views alone, and most content reporting can’t currently tell the two apart.
• If you run Common Room today, be honest about which of its jobs you actually use:
  • Community monitoring, general account context, or something closer to developer-specific intent.
  • They’re not the same job, and they don’t need the same answer.
• Ask whoever produces your technical content whether they’re thinking about the AI fetch layer at all
  • A lot of DevTool teams are still briefing content the way they did in 2022: for a keyword, for a human reader, measured by page rank.
  • That’s a real gap regardless of what happens to Common Room.

If that last audit point turns up a hole, that’s a conversation worth having either with us or with whoever owns your developer intent stack.

Common Room alternatives worth evaluating

Say an engineer at one of your target accounts has spent the last few weeks quietly evaluating you: pulled the package, had Cursor read your API reference twice while debugging an integration, and has your SDK running in staging right now.

None of that took a single website visit.

To UnifyGTM, 6sense, or Clay, that account doesn’t exist yet, not because any of them are bad at their jobs, but because none were pointed at this layer to begin with.

If your GTM stack has ever felt a step behind your best accounts, this layer is usually why, and Reo.Dev is the platform we’ve seen built specifically around it.

The case holds up in numbers, not adjectives: run a shared 35,000-contact list through a general-purpose identity engine and it resolves a GitHub profile for about 15 in 100 contacts.

Run it through an identity graph built around developer signals, GitHub handles, package registries, cloud sign-ups, and that climbs to roughly 4x, the difference between knowing who your engineers are and guessing at most of them.

It’s also the only platform here with a real answer for AI agents evaluating a product through MCP, a category most GTM platforms, Common Room included, don’t cover yet.

If your buyer sits in marketing ops, none of this should move your shortlist, and that’s a fine place to land.

But if you sell to technical buyers, and you’ve ever shipped genuinely good technical content with no real way of knowing which company’s engineers acted on it, then you should be looking at Reo.Dev.

Frequently asked questions

Is Common Room going away?

Nobody outside Zoom and Common Room can say for certain yet. Zoom’s own track record includes both outcomes: Workvivo stayed independent and became a real success story inside Zoom, while Solvvy got folded into Contact Center and stopped existing as its own product. We will have to wait and see how it unfolds in the coming quarters.

Does this acquisition affect how developers discover DevTool products?

Not directly, but it’s happening at the same time as a much bigger shift: a growing share of developer research now happens through AI assistants and agents rather than a human clicking through search results. That shift changes what content teams should measure and build, independent of who owns Common Room next quarter.

Should every Common Room customer look at alternatives?

No. If your buyer intelligence needs are mostly community and social monitoring, general account context, Common Room remains a legitimate, well-built option regardless of who owns it.

The teams worth prompting to look elsewhere are the ones whose funnel runs on developer-native technical intent specifically, something that was a gap in Common Room’s coverage before this deal too.

What is developer-native technical intent, and how is it different from what Common Room tracks?

Community and product-usage signals capture that someone clicked, starred, or mentioned something.

Developer-native signals, package installs, CLI and CI activity, section-level documentation engagement, AI agent queries through MCP, capture that an engineer is actually building with a product, often weeks before that same engineer ever posts in a community or fills out a form.

Why does a content agency have a take on a GTM software acquisition?

Because the two are more connected than most coverage of this deal treats them.

Buyer-intelligence platforms tell a GTM team who’s paying attention.

They don’t explain what got that person’s attention in the first place, and increasingly, a meaningful share of that attention is happening through AI agents reading content on a developer’s behalf, a layer that’s squarely inside what we watch for a living.

One of the first decisions any growth marketing team needs to make is which technical blogging platform and content management system to use. There are a lot of viable options, from well-known public platforms like Medium to specialized tools like Jekyll. You could even get your engineering team to build your own in-house platform on a headless CMS.

This question comes up a lot in calls with clients, so I wanted to round up some of the best writing platforms for running your technical blog, and share a little bit about why you might choose each of them. Note that we’ve also written detailed tutorials and comparisons for many of these, so be sure to check out the articles linked in each section.

Medium

One of the most popular blog platforms for developers out there is Medium. People often choose it because of the built-in distribution that receives millions of unique monthly visitors. The more eyeballs on your online blog platform, the better, right? Medium’s audience tends to skew towards articles relating to technology, startups, and all business topics, so that makes it very compelling for software engineering blogs.

Another positive that Medium presents is its Domain Authority (DA). DA gives us a statistical measure of how well your site will rank in search engines. Medium’s high DA means that you’ll be getting a lot of traffic organically because articles on Medium will likely be indexed and ranked faster than those on a brand new website. Finally, Medium allows  readers to add  comments and “claps” – basically “likes” – to each post, showing how popular each piece is.

The big drawback to Medium (and similar platforms like Dev.to or Hashnode) is that you don’t have full control over the ads and articles surrounding your content. You also don’t build domain authority on your site, so publishing on Medium alone won’t help your primary domain rank higher in Google.

For that reason, I recommend syndicating your content to Medium, but not publishing there exclusively.

Gatsby

Gatsby is an open source platform that generates blazing fast static sites and includes lots of features for search engine optimization and publication. Gatsby is purpose-built for developers and is based on React.js, making it familiar to many frontend developers.

A static site generator (SSG) like Gatsby is a great option for more technical users because the performance is fantastic and there’s no server vulnerabilities to worry about. Gatsby sites don’t have to deal with server requests because everything is pre-rendered when application is built and deployed.

Gatsby uses GraphQL to manage data through its vibrant plugin ecosystem. If you use something like Netlify in conjunction with Gatsby, you can easily manage your content with the use of these plugins. Or, you can use their gatsby-image and gatsby-plugin-favicon to easily process and size your images.

One of the biggest issues with Gatsby is searching large content libraries. Because there’s no server-side code, you have to do all that processing on the front-end, and that can get really slow if you have a lot of content. Finally, Gatsby takes some technical chops to work with, so it’s not appropriate for non-technical developer marketing teams.

If you’re using Gatsby, you might also want to check out our guide to creating Gatsby starters.

WordPress

Almost everyone has heard of WordPress as it’s probably the most widely-used blogging platform on the internet. The upside to this is that there is a huge ecosystem of plugins and themes to help you get started, but is it the best fit for a technical blog?

One that can be a bit confusing is what the difference between WordPress.com and WordPress.org. WordPress.org is where you’ll go if you’re hosting your own site with your own domain name, which I’d typically recommended. While you’ll have to manage your own updates, backups, deployments, and maintenance, you get much more flexibility and ownership of your content.

You can use WordPress.com if you don’t want to deal with the technical intricacies of WordPress.org or just want to get started as quickly as possible. If you want plugins, you’ll also have to pay $300 per year for their Business Plan.

If you’re interested in getting started developing with WordPress, check out our guide here. And, if you want to compare WordPress to our next platform, Jekyll, check out this post.

Jekyll

If you aren’t intimidated by HTML, CSS, Markdown, you might want to give Jekyll a shot. Jekyll doesn’t have a user-friendly back end like WordPress does, but if your team are mostly developers, they may be very comfortable with reading the technical docs and editing markdown files in Github anyway. You can see more of the differences between Jekyll and WordPress in this comparison, but the difference is substantial. Because Jekyll generates a static website (similar to Gatsby), you’ll find that it’s fast and takes very little effort on your end to optimize the user interface.

Jekyll uses Liquid and gives you a blank slate when it comes to templates. There will be little built-in code, so you’ll have to rely on Jekyll plugins or writing your own code. But, you can host it for free on GitHub Pages so your costs are basically nil. You’ll never have to worry about losing your content because it’s automatically backed up and stored in GitHub.

Finally, Jekyll’s been round for a while now, so there are plenty of fans out there creating free and paid themes as well as helping support the open source tool.

Like Gatsby though, the downside to Jekyll is that you’ll need to be at least somewhat technical to use it and maintain it.

Hugo

Yet another static site generator to consider is Hugo. It can go toe-to-toe with Jekyll and the two are generally compared against each other in reviews. The main advantage that you’ll find it has over any other SSG is its speed and thriving, active community. Another benefit is that it’s significantly easier to set up, especially when you compare it to Jekyll. As for content, it’s simply stored in text files within your project.

Hugo also supports a variety of formats, from Markdown to HTML or Asciidoc. Though it’s a bit of a newbie on the scene, there are still a variety of themes available thanks to its community of users. If you’re a beginner, you might find the template engine confusing. Also, there aren’t any extensions so you won’t have plugin support. Despite those issues, it’s still a very strong contender.

Ghost

Ghost has been around for quite some time but it’s not as well known as some of the others on this list.

Ghost is written in Node.js and relies on a minimal user interface. If all you’re looking for is a simple blogging platform, this one might be for you. Many people give a lot of praise for their live blog previewing which makes editing or writing code easier than some of the other platforms.

Ghost requires web hosting or one of its paid plans to deploy to the public. It uses Markdown, like many tech blogging platforms, and allows you to customize your themes to fit anything your heart desires.

The biggest downside, besides needing technical expertise to use and deploy is that there isn’t a free hosted plan. But its simplicity and growing feature-set is enticing.

Final Thoughts

The landscape of technical blogging platforms continues to improve and change every year, so I’d love to hear from you if you have any feedback on these platforms (or others). Reach out to us or find me on X to continue the conversation.

If you’ve enjoyed this, don’t miss our other Best Technical Blogs lists:

• The Best Software Development Blogs
• The Best Engineering Blogs
• The Best DevOps Blogs
• Best SaaS Marketing Blogs
• The Best Technical Writing Blogs
• Best Cybersecurity Blogs
• Best Data Science, Machine Learning, and AI Blogs
• Best Crypto and Cryptocurrency Blogs
• The Best Ruby Blogs
• The Best JavaScript Blogs
• The Best PHP Blogs
• The Best Golang Blogs for Learning Golang
• The Best C# Blogs
• The Best Computer Science Blogs
• Best Product Management Blogs
• The Best Python Blogs

React is commonly used for the frontend in static site generators like Gatsby and now WordPress. React DevTools is a set of developer tools with a multitude of features that can make your workflow more efficient and help you debug and optimize your code.

However, if you use Safari, you may be disappointed to learn that there is no browser extension for React DevTools like there is in Chrome and Firefox.

Fortunately, there is a solution. You can still use standalone React DevTools to connect to your site in Safari. This practical tool is also useful for debugging non-browser-based React applications, like React Native apps. It can help simplify the process of optimizing and debugging your code, making your workflow more efficient.

In this article, you’ll learn how to install and use the standalone version of React DevTools to debug a React application running in Safari. In addition, the article also highlights the differences between the standalone version and the Chrome extension, as well as some limitations of the tools.

Table of Contents

• Use Cases for Debugging React Apps
• Setting Up React DevTools for Safari Debugging
  • Prerequisites and Installation
  • Creating a React Demo Application
  • Connecting React DevTools to Safari
• Building a Debuggable Component Structure
  • Creating User Components for Testing
• Debugging and Inspecting Your App
• Advanced Debugging Features and Techniques
  • Component Inspection and Props Analysis
• What’s the Difference Between Standalone React DevTools and Browser Extensions?
• What Are the Limitations of Standalone React DevTools?
• Conclusion

Use Cases for Debugging React Apps

The standalone version of React DevTools is a separate application that provides a powerful set of debugging and inspection tools for React applications. It’s independent of any specific browser and can be used across various platforms and environments. This makes it a versatile option for developers who need to debug their React apps in different contexts.

Some of the use cases for the standalone version of React DevTools include:

• Debugging non-browser-based React apps: The standalone version of React DevTools is particularly useful when debugging React Native applications because it is platform-independent and can connect to apps running on iOS or Android devices. As of React Native 0.76 (released December 2025), React Native DevTools became the built-in debugger, replacing Flipper and integrating React Developer Tools directly. For React Native versions before 0.76, the standalone react-devtools package remains the primary debugging solution. For example, you can use it to determine why a specific component of your React Native app isn’t rendering correctly on an iOS device. You can use React DevTools to inspect the component tree, check component props and state, and identify issues with styling or logic that may be causing the rendering problem.
• Debugging React apps in Safari: Safari is a widely used browser, especially among macOS users. Although Safari has its own set of developer tools, it doesn’t have extensions or support for React applications like Chrome or Firefox. The standalone version of React DevTools can be used to debug React applications running in Safari, as it provides developers with a powerful set of tools to inspect components and diagnose issues. For instance, if a specific UI component in your React app doesn’t behave as expected when viewed in Safari, you can use React DevTools to inspect the component in question. You can check its state and props and identify any issues.
• Debugging server-rendered React apps: In most static site generators, React apps are server-rendered, which means components are rendered on the server side and sent as HTML to the client. In these scenarios, the standalone version of React DevTools can help you debug issues related to server-rendered components. For example, if you’re using a solution like Next.js or React Server Components to perform server-side rendering, you can use the standalone version of React DevTools to inspect the rendered components and identify issues related to data fetching, state management, or rendering logic.

Setting Up React DevTools for Safari Debugging

The following tutorial explains how to use the standalone version of React DevTools to debug a React application running in Safari. By the end, you’ll be equipped with the knowledge and tools you need to confidently debug your React application.

Prerequisites and Installation

To complete this tutorial, you’ll need:

• A Mac running Safari
• A code editor, such as Visual Studio Code
• Git installed on your machine
• Node.js and npm (the Node package manager) installed on your system

To verify the installation of Node.js and npm, execute these commands in your shell or terminal:

node --version
npm --version

If they aren’t installed, download and install Node.js, which also automatically installs npm. This tutorial uses Node version 18.12.1 and npm version 8.19.2, though any recent LTS version will work.

Note for 2026 Readers: This tutorial uses Create React App for demonstration purposes. However, Create React App was officially deprecated in February 2025. For new projects, the React team recommends modern build tools like Vite or frameworks like Next.js. The debugging techniques shown in this tutorial work identically regardless of which build tool you use—simply add the same <script> tag to your HTML entry point.

Creating a React Demo Application

You’ll first need to set up a basic React demo application, which you’ll run and debug in your Safari browser using the standalone version of React DevTools.

Create a new React project using Create React App by executing this command:

npx create-react-app react-sample-app

This command will generate a new folder with the specified name and populate it with boilerplate code for a React application.

Change the current directory to your newly created project folder by running the following command:

cd react-sample-app

Execute the following command to start the development server:

npm start

Your React application should now be live at http://localhost:3000/. Use your Safari browser to open the application:

Any modifications made to the source code will trigger an automatic page refresh.

Connecting React DevTools to Safari

To connect React DevTools to your app in Safari, you first need to install the standalone React DevTools package using npm from your terminal or shell:

npm install -g react-devtools

Note: As of February 2026, the latest version is 7.0.1. You no longer need to specify @^4 as the package has stabilized on v7.x with improved performance and React 19 support.

Run React DevTools with this command:

react-devtools

After you run the command, you’ll get the following screen telling you to add an additional script to your React DOM:

This tutorial uses the script with the localhost link (<script src="http://localhost:8097"></script>) to connect the React application, but the LAN IP address also works. Since you’re not working with a mobile application, the localhost link will work just fine.

Building a Debuggable Component Structure

Go to your source project and open the index.html file in the public folder. Add the localhost link just after the <head> tag, then open React DevTools. You should see the following in the Components section:

Creating User Components for Testing

Once you have connected React DevTools to your application, you can use the various features it provides. These features include the ability to inspect the component tree, examine component state and props, and profile component performance.

As the sample application doesn’t have many components, you’ll only see the App component in the tree. To explore more features of React DevTools, you’ll need to add more components.

To add a User component, create a file named User.js in the src folder and add the following code to it:

import React from 'react';
const User = ({ user }) => {
  return (
    <div className="user">
      <p>First Name: {user.firstname}</p>
      <p>Last Name: {user.lastname}</p>
      <p>Age: {user.age}</p>
      <p>DOB: {user.dob}</p>
    </div>
  );
};
export default User;

This component displays user information, such as first name, last name, age, and date of birth (DOB).

You’ll now create a UsersList component that utilizes the User component to display the list of users. Create a file named UsersList.js in the src folder and add the following code to it:

import React from 'react';
import User from './User';

const UsersList = ({ users }) => {
  return (
    <div className="users-list">
      {users.map((user) => (
        <User key={user.id} user={user} />
      ))}
    </div>
  );
};

export default UsersList;

To populate the list of users, you need to create some dummy data and wrap the UsersList component in the App component. To do this, replace the code in App.js with the following:

import React from 'react';
import UsersList from './UsersList';

const App = () => {
  const users = [
    { id: 1, firstname: 'John', lastname: 'Doe', age: 30, dob: '1993-02-15' },
    { id: 2, firstname: 'Jane', lastname: 'Doe', age: 28, dob: '1995-06-20' },
    { id: 3, firstname: 'Mark', lastname: 'Smith', age: 35, dob: '1988-10-05' },
  ];

  return (
    <div className="App">
      <h1>Users List</h1>
      <UsersList users={users} />
    </div>
  );
};

export default App;

Note: The App component renders the UsersList component, which in turn renders each User component for every user in the list.

The application in your Safari browser should look like the following:

Debugging and Inspecting Your App

Now that your application is ready, you can start debugging it with React DevTools.

If you open React DevTools, you should see your application tree. It begins with the App component at the top, followed by the UsersList component, and ends with the User component:

If you click the UsersList component in the tree, the props that are passed to the component will be displayed in the right pane. In this case, the props include the array of users from your dummy data:

Clicking a User component displays the props that it passes (the user object in this case). You can click any of three User components and check their relative props:

When you use React DevTools to debug your application, it’s important to understand the application tree and how it represents the component hierarchy. The application tree can help you quickly identify rendering issues and data flow by providing a visual representation of the components. You can inspect the props and state of each component to pinpoint bugs and troubleshoot issues that may arise.

Advanced Debugging Features and Techniques

Component Inspection and Props Analysis

React DevTools displays your application’s component hierarchy in a tree structure. Click any component to inspect its props, state, and hooks in the right panel. This visual representation helps identify data flow issues and rendering problems quickly.

Use the eye icon to highlight selected components in your browser with a blue outline, making it easier to locate specific UI elements.

The bug icon logs selected components to the browser console for detailed inspection. You can also search for components by name using the search bar, making navigation through complex component trees efficient.

The following image shows the results in the browser when you click the bug icon:

Using React DevTools, you can gain a better understanding of the structure and behavior of your applications. You can also more easily identify and fix bugs and performance issues. The standalone version is particularly useful because it can be used with any React application, whether it’s running locally or on a remote server, and it provides a separate, dedicated window for debugging purposes. Overall, the standalone version of React DevTools is a practical tool for developing and debugging React applications.

New in React 19.2 (October 2025): React DevTools now includes custom performance tracks in Chrome DevTools showing React’s scheduler priorities, render phases, and blocking operations. While this feature requires Chrome’s performance panel, Safari users can still access core profiling features through the standalone Profiler tab for component-level performance analysis.

What’s the Difference Between Standalone React DevTools and Browser Extensions?

If you use the standalone version of React DevTools, you’ll be able to use it with any browser, not just Safari. It also offers more customization options and flexibility compared to browser extensions. The following are some other differences between the two versions:

• Cross-platform compatibility: The standalone version of React DevTools is designed to work across various platforms, including browsers and devices, enabling a broader range of debugging and development possibilities. Browser extensions, on the other hand, are limited to working within specific browser environments (Chrome, Firefox, Edge).
• Ease of setup and connection: Browser extensions are designed to integrate seamlessly with the browser, so using the extension version makes it easy to detect and connect to React apps running in the browser.
• Updates and maintenance: These two versions of React DevTools may have different release schedules and update processes. Browser extensions typically update automatically with the browser’s extension updates, while the standalone version requires manual updates through npm (npm update -g react-devtools).

What Are the Limitations of Standalone React DevTools?

It’s also important to be aware that the standalone version of React DevTools has some limitations. For instance, the tool may not work as effectively with certain types of components, such as those built with third-party libraries. You may need to use additional tools or methods to gather the necessary information if the tool provides limited data.

The following are some of the most notable limitations:

• Browser-specific features: The standalone version of React DevTools may lack some browser-specific features, such as network request inspection, JavaScript debugging, or browser performance profiling. For these features, developers need to use the browser’s built-in developer tools or rely on other debugging solutions tailored for the specific browser.
• Integration with browser environment: The standalone version doesn’t have the same level of integration with the browser environment as the extensions. Certain tasks, like interacting with browser APIs or manipulating the DOM, may be more challenging or impossible to accomplish using the standalone version.
• Learning curve: Due to differences in features, interface, and setup process, developers may need to invest additional time in learning how to use the standalone version of React DevTools. This may slow down their development process, especially if they are already familiar with the Chrome extension.
• Safari’s Web Inspector provides JavaScript debugging, network monitoring, and DOM manipulation that complement React DevTools’ component-focused features.
• Performance and resource usage: The standalone version of React DevTools runs as a separate Electron application, which means it consumes additional system resources compared to browser extensions. This can impact performance on systems with limited resources, though modern Macs typically handle this well.

By keeping these limitations in mind, you can adjust your approach and optimize your code more effectively. For instance, you can use Safari’s native developer tools alongside React DevTools for comprehensive debugging coverage.

Conclusion

The standalone version of React DevTools offers a versatile solution for developers who need a powerful and flexible set of debugging tools, whether they’re working on React apps professionally or writing technical documentation.

This article introduced the standalone version of React DevTools and demonstrated how to use it to debug a React app running in Safari. You should now be comfortable with setting up, connecting, and using React DevTools to inspect and debug your React applications. With the knowledge from this article, you’ll be able to debug your React applications, regardless of the environment or browser they are running in.

You can find the code that was used in this article in this GitHub repository.

WordPress is the most popular content management system (CMS), supporting 41 percent of all websites worldwide.

Its easy-to-use interface and multiple plugins as well as other features make it a good choice for developers. You can customize a WordPress site in countless ways, providing a lot of flexibility for you and your clients.

If you’ve been considering using WordPress, now is a good time to start. In this article, you’ll learn more about how WordPress can help you as a developer and how you can use it to supercharge your products.

Why Do You Need WordPress as a Developer?

People around the world use WordPress to build blogs, portfolios, e-commerce stores, and other sites. Because of its huge userbase, there is a lot of demand for outstanding WordPress developers who can build custom solutions for clients and tweak the core software. WordPress developers can earn over $100,000 USD a year, making it a profitable side gig or full-time job.

As a developer, WordPress provides you with a lot of creative freedom. The software is very extensible, thanks to its multiple plugins and themes, and you can also easily develop whatever you want on top of the existing platform.

How to Get Started

For WordPress development, you should know the fundamentals of programming. Since developing for WordPress is similar to web programming, the languages used for both are basically the same.

You’ll need to know the following languages:

• HTML: The backbone of the internet. The markup language provides basic structure and layout to your web page, and you’ll use it every time you build a website.
• CSS: While HTML provides the layout of your website, CSS helps make your site look beautiful with colors, fonts, animations, and other elements. Frameworks like Bootstrap and Tailwind can be used to write code more quickly.
• JavaScript: Another language you’ll find on almost every website. It adds interactivity and logic to your web pages.
• PHP: The language on which the the base of WordPress is built. It’s a backend language, so you’ll be using it for a lot of the logic that runs behind your site on a server.
• SQL: The language that you’ll use to work with databases.

You’ll also need to get familiar with the elements of the WordPress platform, including plugins, themes, and child themes.

What Is a Plugin in WordPress?

Plugins are tools that can be used to extend the functionality of the WordPress platform. The variety of plugins is part of what makes WordPress so extensible and loved among users.

If you’re building an e-commerce store, for example, you’ll need to accept payments from customers. The core WordPress software doesn’t provide this functionality out of the box, but you can download a plugin from the WordPress marketplace to add the feature.

Plugins can also be used to add analytics, speed optimization, and design elements to your site. There are more than 59,000 plugins on WordPress, and there’s always room for more.

How Do You Create a Plugin in WordPress?

You can also create your own plugins. To do this, there are a few terms you should learn:

• Hooks allow you to access a specific point in the WordPress core and change its behavior. For example, there’s a hook for when a user activates the plugin, another for when the plugin is uninstalled, and so on. Hooks come in two forms: actions and filters.
• Actions allow you to execute your own code when a preexisting hook runs in WordPress. For example, if you want to share your post to social networks when the admin publishes it, you can write an action for that.
• Filters allow you to edit the content that WordPress returns upon running some hook. You can’t add anything to that response, but you can edit the response. This is useful when you need to edit the title or the content of a web page.

For more details, check the WordPress Developer Resources.

Creating a Plugin

To make a plugin, first create a local copy of WordPress on your machine and access your WordPress installation files using FTP or your hosting provider.

Create a directory in the /wp-content/plugins/ folder named after your plugin. In Unix, it would look like this:

wordpress $ cd wp-content/plugins
plugins $ mkdir plugin-name
plugins $ cd plugin-name

Create a new PHP file for writing the plugin code:

plugin-name $ touch plugin-name.php

Add this metadata at the top of your PHP file to tell WordPress what your plugin is about:

/*

Plugin Name: your-plugin-name

Plugin URI: your-plugin-website

Description: short-description-of-what-your-plugin-does

Version: plugin-version

Author: developer-name

Author URI: developer-website

License: plugin-distribution-license

Text Domain: unique-identifier

*/

Before you start coding your plugin, there are a couple of things you should know:

• You can create the plugin’s codebase from scratch, all in one file or divided over several files.
• You can also play around with existing plugins by forking them to your installation, or build on top of an existing plugin by adding features and fixing bugs.

Best Practices for Creating a Plugin

When creating a plugin, you should keep the following in mind:

• Use a unique prefix for all the functions, variables, and classes in your code to prevent it from getting mixed up with the code of other plugins.
• Use object-oriented programming (OOP) for better structure and readability.
• Use a well-defined folder structure to make it easier for others to contribute.
• Take plugin security seriously. Use measures like user capability checks, data sanitization, and nonces to prevent hacking.
• Use internationalization for easier accessibility for people from other countries.
• Build your plugin in a local staging environment instead of a production environment to avoid crashes and accidents.

What Is a Theme in WordPress?

After plugin development, the next most popular choice for developers is theme development. A WordPress theme provides users with a structure, layout, and other details like colors and fonts that they can use to further build their website. The themes you create allow the average user to build a website quickly without having to write a single line of code.

With a theme, you can give your website a unique look.

How Do You Create a Theme in WordPress?

Creating a WordPress theme is easy. First you’ll need to know how WordPress works behind the scenes to display web pages.

WordPress follows a hierarchy to find a template to display the URL the user is at. For example, if you’re on the page https://wordpress.org/my-url, this is how WordPress searches for the correct template:

• First, WordPress looks for a file called /theme-name/page-{slug}.php, or /theme-name/page-my-url.php in this example.
• If the above file isn’t found, WordPress instead uses the page ID and looks for /theme-name/page-{id}.php. If the page has an ID of 6, it looks for /theme-name/page-6.php.
• If the above is also missing, then WordPress looks for a generic template. For pages, it looks for page.php; for categories, category.php; and so on.
• Following that, singular.php is a generic file for rendering pages or posts. For category pages, WordPress instead looks for an archive.php file.
• Your index.php is the last option. This file cannot be absent from your theme (it’s compulsory), so there is no scope for searching further.

You should also be familiar with the Loop, WordPress’s system to iterate over your database to fetch and show the content specified in your theme’s code.

Classic Themes

Creating a Classic Theme

The following is a high-level process for creating a theme. It assumes that you’ve already set up a staging environment for development purposes.

First, open your website’s files and navigate to /wp-content/themes/. Create a directory named after your theme:

wordpress $ cd wp-content
wp-content $ cd themes
themes $ mkdir your-theme-name

In /wp-content/themes/your-theme-name/, create styles.css and index.php:

your-theme-name $ touch styles.css
your-theme-name $ touch index.php

These files are the bare minimum you need to build a theme. styles.css styles your website and shows metadata about your theme on the Themes page in WordPress, and index.php renders the frontend layout of your website.

Apart from these two files, you can create an optional functions.php file to contain PHP functions for all the fancy stuff on your website. JavaScript files, images, and other elements are optional too.

Finally, use PHP and HTML in these files to create your theme. You can either code the theme from scratch or use a starter framework like Underscores or Genesis.

What Is a Child Theme?

Child themes are themes that inherit functionality and styling from their parent theme. As a developer, you can create a parent theme and multiple child themes based on that parent theme, then extend and modify them freely.

The best part about using child themes is that you can change them without having to worry about those changes being overridden by an update. You can also safely update your parent theme while retaining the changes you made in your child theme.

Block Themes

Block themes are a new feature introduced in WordPress 5.9. They break the typical workflow of working with a theme. Instead, they use blocks, as the name suggests, and are a part of [Full Site Editing.] (https://developer.wordpress.org/block-editor/getting-started/full-site-editing/)

How Is a Block Theme Different from a Classic Theme?

There’s some fundamentals that are same for both, block themes, and classic themes. Like, both of them use the template hierarchy to display the desired files, both can use the theme.json file.

The differences are pretty visible as a developer though. Classic themes used PHP to display all the content and layout, whereas Block themes use HTML for the same purpose. PHP is used as a fallback in case WordPress can’t find the HTML file.
The WordPress Loop is also gone and the query loop block is used. It’s used to display posts/pages based on specified parameters.

In other words, block themes replace everything PHP based to blocks.

Why Use a Block Theme?

Block themes are better than Classic themes to develop due to various reasons like:
* Better loading performance.
* Accessibility features are automatically put in place without you, the developer, having to do extra work.
* Easier to edit for the user

How to Create a Block Theme?

Two things that are essential for creating any theme are: style.css and index.php. With Block themes, you need just one more required filed: index.html inside your templates folder.

Template parts like your header or footer are optional and can be placed in parts folder. You can also add additional files like you would with Classic themes.

After that, you can setup your theme inside functions.php by adding support for block features like this:

if ( ! function_exists( 'myfirsttheme_setup' ) ) :
/**
 * Sets up theme defaults and registers support for various WordPress features.
 *
 * Note that this function is hooked into the after_setup_theme hook, which runs
 * before the init hook.
 */
function myfirsttheme_setup() {
    // Add support for block styles.
    add_theme_support( 'wp-block-styles' );

    // Enqueue editor styles.
    add_editor_style( 'editor-style.css' );
}
endif; // myfirsttheme_setup
add_action( 'after_setup_theme', 'myfirsttheme_setup' );

You can also refer to this page.

Next, you can include CSS and JavaScript in your block themes too. The rest of process of coding the theme up is the same.

And, that’s just about it! Great job!

Read the full docs for a deeper dive down

Best Practices While Creating a Theme

Keep the following in mind while working on your theme:

• Use well-structured, error-free PHP and valid HTML.
• Create different folders for different types of files, like images, JavaScript, or templates.
• Familiarize yourself with the template hierarchy.
• Make sure to follow internationalization for your themes.
• Debug your WordPress theme with define('WP_DEBUG', true) before releasing it to the masses.
• Make sure that your theme is responsive and as fast as possible.
• Use child themes while modifying existing themes.

Hosting Your WordPress Website

Now that you’ve developed your WordPress website, you need to host it on a server. You can use WordPress to create your website, but it isn’t meant for hosting.

The following are some options for hosting your site.

WordPress.com

Remember that WordPress.org and WordPress.com are two different platforms.

WordPress.org is open source, free software that can be used to build websites. WordPress.com, on the other hand, is a complete solution that helps you build websites and host them. WordPress.org is open-source and it is maintained by the WordPress community that contributes to it. WorPress.com on the other hand is owned by a company called ‘Automattic’.

WordPress.com isn’t your usual WordPress hosting platform. It comes with enterprise-grade security, built-in tools for sharing, stats, and SEO; premium themes, best-in-class support, and it’s the fastest WordPress and WooCommerce host on the market. What else could you ask for?

There is a free, limited version and two paid tiers:

• WordPress Starter: $5/month
• WordPress Pro: $15/month

The paid plans come with a 14-day money-back guarantee too.

Apart from WordPress.com, some of the other hosts we recommend are:

• Bluehost: Powers over 2 million websites and has tools for beginners like 1-click installation, free domain name, email, FTP, and more.
• Dreamhost: One of the best web hosts for beginners with affordable plans and features like automatic updates, free SSL, free privacy protection, 1-click installations, automatic backups, etc.
• Siteground: If you’re looking to scale your WordPress website, Siteground can be on the top of your list. It comes with fine tuning for WordPress out of the box, automatic migrations, 24/7 support and more.

Conclusion

You should now have a good sense of how to create your own plugins and themes to customize and stylize your WordPress site. WordPress offers enough flexibility that you’re only limited by your imagination.

In addition to the above hosting options, there are plenty of other platforms on the market you can use to launch your site to the world.

Once you know the basics of WordPress development, you can create whatever type of site you like to meet the needs of any number of clients.

Writing a blog is one thing, but finding a place to publish it is quite another.

The sheer volume of online blogging platforms can be overwhelming at best. With hundreds of options with thousands of possibilities, narrowing down the list can be challenging. And if you happen to be looking for a technical blogging platform, you might feel a bit over your head.

The best blogging platforms are way more than a glorified PDF. The cream of the crop provides SEO support, forums for community comments, integrations with other tools, and even plugins that streamline your workflow. It pays to know what you need in advance, and choose a platform that scales alongside your blog and brand.

Making a great decision starts with getting great information. We’re going to take a step-by-step approach for looking at the most popular blogging platforms for your startup, including some pros, cons, and what to keep in mind. We’ll also walk through ways to narrow down your final criteria, especially if you’re having trouble sifting through the choices.

We’ll cover:

• What to know about modern blogging platforms
• 10 best blogging platforms for the technical blogger
• Choosing between multiple blogging platforms

What To Know About Modern Blogging Platforms

Before we get into the weeds, we need to talk about the two major types of modern blogging platforms: hosted and self-hosted.

Hosted blogging platforms allow you to keep your site, domain, and blog content under a single umbrella. WordPress and Squarespace are two very common examples of this.
Self-hosted blogging platforms allow you to use their software on your owned domains and web pages. Most of the options listed here have self-hosted options.

Although neither choice is better than the other, it’s important to note that hosted platforms may be slightly more efficient for technical companies. Not only do they look more professional to customers, but they are extremely flexible as well. Plus, you won’t run the risk of having your blog removed or struggling with security breaches along the way.

The criteria you choose for picking a blog platform will be between yourself and your business. However, you might want to consider the future growth of your brand, and the types of content you might be producing in 6 months, a year, or even 5 years. If you’re planning on partnering with freelancers or agencies, you’ll also want to consider the platform’s ease of use and manageability. It’s best to save yourself from as many headaches as possible!

10 Best Blogging Platforms For The Technical Blogger

If you’re looking to get up and running on a blog platform in a technical space, you’ve got plenty of options. These 10 providers have a long list of features and benefits, and can be easily adapted to meet a wide variety of needs.

WordPress

As a platform that powers more than 40% of the internet, WordPress is a powerhouse in the blogging space. It’s not hard to see why: users can create a blog with plugins, themes, content moderation, and more in just minutes.

WordPress is very straightforward, but not a development platform. Consider your technical needs before making any lasting decisions.

Gatsby

Static site generator GatsbyJS is fast and focused platform used by thousands of technical blogs. It’s not the most intuitive option on the list, but its tools and plugin metaverse are extremely helpful in the beginning stages of a blog.

You can choose to use the site’s preset templates to get started, or branch into creating your own Gatsby starters. Note that Gatsby is based on React rather than Vue, which is similar to Next.js. You can find the full Gatsby vs Next.js comparison here.

Hugo

Up-and-coming Hugo might be just a baby, but its speed simply cannot be matched. There are multiple hosting options available, as well as support for menu integration, image processing, site mapping, and live reloading. You can also create some beautiful Hugo themes with just a little bit of work.

Hugo is a static site generator much like Jekyll, but one that was written in Go rather than Ruby. Not sure which static site generator you prefer between Hugo vs. Jekyll? It might boil down to semantics.

Ghost

Another open source provider with excellent value, Ghost makes technical blogging quick and easy. Users can use their own themes to get started fast, or develop a headless CMS using Ghost’s API.

This is a platform that plays very well with others, as Ghost can be deployed with Docker for developer blogs. Its versatility is a boon for younger tech startups.

Hashnode

If you want to start writing ASAP, Hashnode is hands down one of the best options on the list. The platform is a community rather than a site generator, and allows you to house content on-site before migrating it to an owned domain.

This is a great option for technical bloggers that don’t yet have a personal domain. Start creating content and thought leadership immediately while fleshing out the rest of your blogging strategy.

Publii

Static site generators are extremely popular with devs for many reasons, including the services provided by Publii. This SSG lends itself extremely well to simple blogs, and works well with formats such as Markdown.

Publii also provides a wealth of SEO tools, and scores significantly higher than other platforms in its category. If you’re looking to create discoverable content, this might be a good option.

Github

While Github isn’t a blogging platform per se, it’s still a common and powerful way to share technical insights with the world. You can use it to build a personal blog site, create custom 404 pages, and much more.

Keep in mind that Github is one of the pricer options on the list. You’ll need to pay per user to access pages and wikis, among other things.

Squarespace

Like WordPress, Squarespace is a website builder that offers templates, hosting, and some limited CMS services. The templates themselves are particularly eye-catching and extremely simple to drag and drop into place.

Do keep in mind that this site is more known for its support to eCommerce brands and B2C. If you have a B2B SaaS, you might want to lean toward something more technical.

Webflow

People unfamiliar with technical website building often turn to Webflow for no-code templates and hosting services. The benefits are obvious: CMS options, gated blog content options, and SEO support.

However, Webflow is probably not right for you if you want more technical accessibility, especially as you scale.

Jeykll

The blogging platform provided by Jeykll works as a static site generator using your computer’s command line. It’s open-source and works with a variety of formats, including Markdown, Liquid, HTML, and CSS.

Jeykll is both efficient and minimalist, and fairly intuitive for technical users. But depending on your projected growth and future needs, you might find yourself needing a fuller suite of tools – including the ones offered by WordPress. We recently wrote a piece comparing the differences between Jeykll vs. WordPress, if you’re curious.

Choosing Between Multiple Blogging Platforms

There are (quite literally) dozens of different blog platforms available to choose from online. Thankfully, knowing your options is the first step toward making a final decision. From technical support to basic writing features, the option you end up picking should reflect your personal needs, business type, and customer expectations.

As you evaluate the various platforms available to you, ask yourself:

• What price are you willing to pay? How is that going to effect your options in the future? If you don’t have a domain yet, consider hosting or membership fees as well.
• How much technical support are you going to need? Can you settle for something less complicated (like Ghost)? Or will you need a solution that has lots of options?
• Is the end goal of your blog platform to make money? If so, start ruling out the options that don’t offer advertising.

At the end of the day, the blog platform you choose to use will have lasting implications on your content, your domains, and even your branding. Choose well and choose wisely; you owe it to your business to make the best possible decision.

If you still have some questions about choosing a blog platform, or if you’re not sure where to start with your technical content marketing plan, Draft.dev can help. We specialize in the design and execution of blog posts, tutorials, and other technically minded content that appeals to software engineers and decision-making devs in your industry.

Book a Discovery Call to learn more about your blogging needs and how Draft.dev can make a difference.

Ghost, an open source publishing platform built with Node.js, provides a good editing experience and integrations with popular apps and tools out of the box. Its extensive feature set allows users to set up a wide range of content-focused experiences, from developer blogs to newsletters, and other growth marketing endeavours.

Ghost can also be used as a headless content management system (CMS) and is compatible with the major frontend frameworks. There are detailed guides for setting up a custom frontend using any of the popular frameworks or static-site generators.

This tutorial will focus on setting up a local Ghost installation as a headless CMS for a Next.js frontend.

Why Use Ghost as a Headless CMS?

When you set up a new site with Ghost, you get a frontend configured with its default theme, Casper. The Casper theme is responsive and has dark-mode support, among other features. This ensures your readers get the best reading experience regardless of their device, browser, or aesthetic preferences.

Casper can also be modified to your brand’s needs. The Ghost admin provides settings that you can adjust as you like. But if you don’t want to use Ghost with the default frontend, its flexible architecture allows you to use a custom frontend.

The Ghost API serves content with properly formatted and SEO-optimized HTML. Ghost also supports and parses Markdown content correctly, so you can write your content in Markdown and publish from anywhere.

As a CMS, Ghost is designed to get out of your way when you’re performing most actions. The admin site provides access to features such as user subscriptions and email newsletters. Members can be imported from a CSV file or added manually by sending an email invite. You can also set up your site to collect payments from subscribers in a few clicks using Stripe, Ghost’s default payment integration.

You’ll find that the Ghost editor matches your content’s needs—simple or complex—without being visually distracting. This flexibility and simplicity makes Ghost a good option for a headless CMS service.

Implementing Ghost as a Headless CMS

You can install Ghost locally on your own server or use the paid hosted solution provided by Ghost (Ghost Pro). In this tutorial, you will be setting up a local installation because it is the easiest way to set up a Ghost site.

Prerequisites

Here’s what you’ll need to follow this tutorial:

• some knowledge of JavaScript
• some knowledge of React
• Node installed on your computer. Note that Ghost supports the last three long-term support (LTS) Node versions.
• npm or yarn installed on your computer

The source code for this tutorial can be found here.

Installing Ghost

Installing Ghost locally is fairly straightforward thanks to the Ghost command line interface (CLI) tool.

The Ghost CLI is a single binary that provides commands to make installing, updating, and troubleshooting Ghost installations easy. It is recommended that you install the CLI globally, especially because you will be reusing the tool across multiple projects.

You can install or update (if you already have it installed) the Ghost CLI by running the following command in your terminal:

# Install using npm
npm install -g ghost-cli@latest

# Install using yarn
yarn global add ghost-cli@latest

Running ghost -v when the installation is completed should give you an output similar to this:

Now that you have the CLI installed, you can install Ghost. The CLI provides a command for this: ghost install local. Without passing any options, running this command will set up a development installation of Ghost using the latest available version.

In your terminal, create a new directory where Ghost will be installed. You can name the directory whatever you like. For this tutorial, the directory will be named ghost-headless-cms:

# Creates a new directory
mkdir ghost-headless-cms

Next, cd into the newly created directory and run the command to install Ghost:

# Navigate to the `ghost-headless-cms` folder
cd ghost-headless-cms

# Install Ghost using the CLI
ghost install local

If everything goes well, you should have the following output in your terminal:

Note that the ghost install command concludes by starting or serving your Ghost site in the background. You can stop this process at any time by running ghost stop within the folder where you installed Ghost. In this case, this means running the following command(s):

# Navigate to the `ghost-headless-cms` folder
cd ghost-headless-cms

# Stop Ghost instance
ghost stop

# Start Ghost instance
ghost start

You can view your newly created Ghost site by visiting http://localhost:2368 in your browser.

After creating a Ghost site, you need to create a new user with administrator privileges. An admin user can create posts and pages, manage your site’s settings, and create custom integrations, as well as add authors, editors, contributors, or other administrators to the site.

To create an admin user, navigate to http://localhost:2368/ghost and fill in the required information.

Creating a Next.js App

Now that you have your Ghost site up and running, you can create your custom frontend. You’ll be working with Next.js, a React framework that is optimized for production. If you are unfamiliar with Next.js or need to refresh your knowledge, consult this Next.js Foundations course.

Note that this tutorial only covers fetching and displaying posts. You will get the most out of your custom frontend by re-implementing this list of features already handled by Ghost.

Next.js can be installed manually or automatically using the create-next-app script. This script takes care of everything related to setting up a new Next.js project, including, but not limited to, the following:

• installing next and react
• creating the necessary folders for serving pages and static assets
• setting up scripts for running a development server and building for production

To create a project, run the following command in your terminal:

# Install using yarn
yarn create next-app ghost-headless-frontend

# Install using npx
npx create-next-app ghost-headless-frontend

You can view the newly created app by running yarn dev or npm run dev from within the project root, and navigating to http://localhost:3000 in your browser.

cd ghost-headless-frontend

# Using yarn
yarn dev

# Using npm
npm run dev

With your Next.js app created, you can connect it to your Ghost site.

Connecting Ghost and Next.js

Working with Ghost as a headless CMS means making API requests from a JavaScript application. This can seem daunting, especially if you are not familiar with Ghost’s API documentation or working with APIs in general.

Fortunately, Ghost provides a JavaScript library that abstracts away these issues. You’ll use this library to retrieve posts from Ghost and render them in your app’s home page.

First, you’ll need to generate an API key from within your Ghost admin dashboard. This key is required to access content from a Ghost site externally. To obtain a key, navigate to your Ghost admin in your browser and ensure you are logged in with the credentials you created earlier.

Navigate to Settings → Integrations and create a custom integration using the button at the bottom of the page. You can name the integration whatever you like.

You will be redirected to a page showing you information about the integration. Take note of the string labeled “Content API key,” since you will be needing it later.

To get started with the Content API, make sure you’re in your Next.js project directory, then install the library using your package manager:

# Install using yarn
yarn add @tryghost/content-api

# Install using npm
npm install @tryghost/content-api

Next, add a folder named utils at the root of your project and create a file named index.js in the folder. This file will contain an instance of the Ghost Content API as well as functions for fetching bulk and single posts from your Ghost site.

mkdir utils
cd utils
touch index.js

Add the code below to the file you just created:

import GhostContentAPI from "@tryghost/content-api";

// Create an instance of the GhostContentAPI
const api = new GhostContentAPI({
  url: "http://localhost:2368",
  key: "6760baXXXXXXXXXXXX", // replace this with your API key
  version: "v4",
});

The API instance you just created exposes five properties, with each corresponding to content that can be fetched from a Ghost site: posts, pages, authors, settings, and tags. Each property in turn exposes two methods:

• browse for fetching bulk data
• read for fetching a single item matching a unique identifier (slug or ID)

Now add the code for fetching bulk and single posts from your Ghost site:

export const getPosts = async () => {
  try {
    return await api.posts.browse({
      limit: "all",
    });
  } catch (error) {
    console.error(error);
  }
};

export const getSinglePost = async (slug) => {
  try {
    return await api.posts.read({
      slug,
    });
  } catch (error) {
    console.error(error);
  }
};

To tie it all together, open the pages/index.js file and import the getPosts function. Then, making use of Next’s static-site generation feature, pass the posts retrieved as props to the Home component:

import Head from "next/head";
import { getPosts } from "../utils";

export async function getStaticProps() {
  const posts = await getPosts();
  if (!posts) {
    return {
      notFound: true,
    };
  }
  return {
    props: { posts },
  };
}

Finally, render the posts within the Home component:

export default function Home(props) {
  return (
    <div>
      <Head>
        <title>Create Next App</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <div className="posts-container">
        {props.posts.map((post) => (
          <div className="post-preview" key={post.id}>
            <h4>
              <a href={post.url}>{post.title}</a>
            </h4>
          </div>
        ))}
      </div>
    </div>
  );
}

With static-site generation, Next.js builds your app’s pages as static HTML that can be cached or served over a CDN.

You can reload your Next app to see the changes you’ve made so far. If everything is okay, you’ll see a link rendered with the text “Coming soon.”

Note that this link points to the default Ghost installation. Ideally, you’ll want to have greater control over how content from your Ghost site is rendered. In the next step, you’ll see how to use Next’s dynamic routing feature to render content for a single post in your Next app.

Rendering a Single Post

You were introduced to Next’s static-site generation feature when setting up the Home component. In this section, you’re going to use the same feature to generate static pages for posts from your Ghost site.

It is possible to create a dynamic route or page in Next by saving a file in the pages folder with the following format:

pages/[param].js

You have a parameter (a URL slug or entity ID) wrapped with brackets, which is passed to your page as a query parameter. The matched parameter can be accessed by using Next’s useRouter hook within a page, or from the context parameter in a getStaticProps function.

Make sure you are in the Next app’s root folder, then run the following commands to create a dynamic page that matches post slugs within a post folder:

mkdir -p pages/post
cd pages/post
touch "[slug].js"

You need to instruct Next.js on how to statically generate post pages. You can do this by exporting a function named getStaticPaths from your [slug].js file. Open this file and add the following code:

import { getPosts } from "../../utils";

export async function getStaticPaths() {
  const posts = await getPosts();

  const paths = posts.map((post) => ({
    params: { slug: post.slug },
  }));

  return { paths, fallback: false };
}

You can now fetch a single post and pass the data as props to the component that will render the posts. To do this, update the imports at the top of the file to include the getSinglePost function you created earlier and the Next Head component:

- import { getPosts } from "../../utils";
+ import { getSinglePost, getPosts } from "../../utils";
+ import Head from "next/head";

Add the code for getting the post data and rendering the component:

export async function getStaticProps(context) {
  const post = await getSinglePost(context.params.slug);

  if (!post) {
    return {
      notFound: true,
    };
  }

  return {
    props: { post },
  };
}

export default function Post(props) {
  return (
    <div>
      <Head>
        <title>{props.post.title}</title>
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <h1>{props.post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: props.post.html }} />
    </div>
  );
}

Finally, replace the anchor tag in the Home component with Next’s Link component. This takes care of client-side routing, allowing you to browse through pages within your Next app.

- <a href={post.url}>{post.title}</a>
+ <Link href={`/post/${post.slug}`}>{post.title}</Link>

Don’t forget to import the Link component at the top of your file like this:

import Link from "next/link";

You can reload your app in the browser to see the changes you’ve just made. Notice that the app now correctly loads posts within your Next app, instead of your Ghost site.

Creating Content

Creating content for your site is easy. Note that non-admin users can create content on your Ghost site, but there are restrictions on who can publish content. The image below illustrates the level of access each user has:

To create a new post, navigate to the Ghost admin site and select Posts from the left-sided menu. On mobile, this menu is at the bottom of the page.

Selecting New Post will take you to the editor page, where you can add a title and content:

You can see what your post will look like when published by selecting Preview from the top right corner on the editor. When you’re ready to go live with a post, select Publish from the editor or preview page. You can publish immediately or schedule a date in the future.

Conclusion

Now that you’ve set up your Ghost frontend with Next.js, take some time to play around with the Ghost CMS. As you can see, Ghost provides a solid framework to start content publishing but hands over the keys to your creativity on demand.

To check your work in this tutorial, consult the GitHub repo.

If you’re looking for content for your new website or blogging platform, consider Draft.dev. The technical marketing content company creates tutorials, blog posts, and other types of content for software startups around the world. Draft.dev ensures its content is technically accurate and high-quality, freeing up your team to focus on writing code. To learn more, schedule a call.

Ghost is one of the most popular open source blogging platforms. It boasts powerful features for almost everything related to blogging, such as editing, publishing, email newsletters, and offering paid subscriptions. Ghost offers pre-made themes that you can use to set up your blog quickly, but thanks to its extensive API, you can also use it as a headless CMS for your custom frontend.

You can install Ghost in several ways, one of which is Docker.

Deploying Ghost with Docker has many advantages. With Docker containers, you get a flexible and easily reproducible way to run your blog. It allows you to spin up another instance quickly when one fails or updates. On top of that, you get the same setup experience, regardless of if you’re in a development or production environment.

This article will guide you through the entire process of setting up a Ghost blog with Docker. You can find all configuration files from this tutorial in this GitHub repo.

Table of Contents

• Ghost’s Features
  • Simplicity and Ease of Use
  • Editing and Publishing Experience
  • Email Newsletters
  • Subscriptions and Memberships
• Setting Up Ghost with Docker
  • Installing Docker
  • Running the Ghost Image
• Setting Up Your Ghost Blog
• Exposing and Securing the Ghost Blog
  • Obtaining an SSL Certificate
  • Creating Custom Nginx Docker Image
  • Updating the Docker Compose Config
• Deployment Options
• Conclusion

Ghost’s Features

Before diving in, let’s first explore some of Ghost’s features in depth.

Simplicity and Ease of Use

As you’ll see in a bit, Ghost is very simple to set up, especially with the pre-made Docker image. On top of that, the other parts of the Ghost experience are easy to grasp, too. Everything from the content editor to the settings panel has a clean, minimal design.

Editing and Publishing Experience

The Ghost editor is one of the best in the business. It provides everything you need to create excellent content, including:

• Floating formatting menu.
• Image, HTML, and other content blocks.
• Media embeds for Twitter, YouTube, CodePen, and more.
• Markdown shortcuts.
• Reusable content snippets.

When you’re done writing, publishing is just a matter of providing some metadata and hitting the Publish button.

Email Newsletters

In addition to blogging, Ghost can also be used for email newsletters. With its built-in email design editor, members list, email analytics, and Mailgun integrations, you get a feature-complete solution for running your own newsletter right from your blog.

Subscriptions and Memberships

Thanks to its Stripe integration, a custom API, and a member administration dashboard, Ghost has everything you need to implement paid subscriptions and monetize your blog. You can create anything from a straightforward donation system to paywalled content or premium newsletters.

Setting Up Ghost with Docker

This guide assumes you’re running Ubuntu 18.04 or newer. To run Ghost in Docker, a minimum of 1 GB of RAM and a decent CPU are recommended.

Installing Docker

Before installing Ghost, you’ll need to install Docker Engine and Docker Compose. Be sure to uninstall any previous versions of Docker Engine that might be installed on your system:

sudo apt-get remove docker docker-engine docker.io containerd runc

Use apt to install all packages required by Docker:

sudo apt-get update
sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

Add Docker’s official GPG key to verify the integrity of the Docker packages:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Set up Docker’s stable repository as a package download source:

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install Docker Engine and Docker Compose, then verify the installation:

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose
docker --version
docker-compose --version

If everything was set up correctly, you should see version numbers for Docker Engine and Docker Compose in your terminal.

Running the Ghost Image

With Docker ready, you can now use it to download and run the Ghost image.

For Development

This is the easiest way to get the Ghost image up and running for development purposes. With this setup, the container is stateless, meaning all data will be lost if anything happens to it. Also, by default, the Ghost blog is using an SQLite database.

Run the Ghost image using the following command:

docker run -d --name my-ghost-blog -e url=http://localhost:2368 -p 2368:2368 ghost

This will create a container named my-ghost-blog using the official Ghost image provided by the Docker community. The Ghost blog will be accessible on port 2368.

While convenient and great for development purposes, this setup isn’t ready for production. For that, a bit more configuration is required.

For Production

Start by creating a dedicated directory, like my-ghost-blog, and a docker-compose.yml file inside it:

mkdir my-ghost-blog
cd my-ghost-blog
touch docker-compose.yml

Inside the file, define the configuration for Docker containers:

version: "3.3"
services:
  ghost:
    image: ghost:latest
    restart: always
    ports:
      - "2368:2368"
    depends_on:
      - db
    environment:
      url: http://localhost:2368
      database__client: mysql
      database__connection__host: db
      database__connection__user: ghost
      database__connection__password: ghostdbpass
      database__connection__database: ghostdb
    volumes:
      - /home/ghost/content:/var/lib/ghost/content

  db:
    image: mariadb:latest
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: your_mysql_root_password
      MYSQL_USER: ghost
      MYSQL_PASSWORD: ghostdbpass
      MYSQL_DATABASE: ghostdb
    volumes:
      - /home/ghost/mysql:/var/lib/mysql

With this config, an additional MySQL database container will be created using a MariaDB image. Additionally, a dedicated volume is added for the Ghost blog to provide stateful storage.

Now, execute the configuration with docker-compose up -d. You can now see the Ghost blog on port 2368.

Setting Up Your Ghost Blog

To get started with Ghost, go to http://localhost:2368/ghost. This is where your admin panel will be located. Going there for the first time, you should see a setup screen like the below:

Fill out the form, and you’ll be greeted with the dashboard.

To create your first post, click the + button next to Posts, which will take you to the post editor.

From inside the editor, you can write your blog post and set all of its metadata. When you’re done, click Publish to make your post public.

Exposing and Securing the Ghost Blog

Now, while the Ghost blog is up and running, there’s still some setup to be done on the backend. You’ll have to expose the app for outside access with a proxy like Nginx and secure it with an SSL certificate. This process will require a domain, which we’ll refer to as example.com.

Obtaining an SSL Certificate

To obtain an SSL certificate for your domain, you’ll first have to install the latest Certbot package with the Snapd package installer.

First, ensure Snapd is up-to-date and that no older versions of Certbot are installed:

sudo snap install core
sudo snap refresh core
sudo apt remove certbot

Next up, install Certbot and create a symlink to its installation path to ensure it’s accessible through the certbot command:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Finally, run the following command to generate and download the certificate for your domain:

sudo certbot certonly --standalone -d example.com

With the SSL certificate ready, you can move on to Nginx.

Creating Custom Nginx Docker Image

In this example, you’ll see how to run Nginx as a separate container with Docker Compose.

To get started, create a new nginx folder:

mkdir nginx
cd nginx

You have to alter the official Nginx image to include a custom Nginx config. To do so, create a file called ghost.conf to hold the custom Nginx config:

server {
  listen 80;
  listen [::]:80;
  server_name example.com;
  # Useful for Let's Encrypt
  location /.well-known/acme-challenge/ { root /usr/share/nginx/html; allow all; }
  location / { return 301 https://$server_name$request_uri; }
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name example.com;

  access_log /var/log/nginx/ghost.access.log;
  error_log /var/log/nginx/ghost.error.log;
  client_max_body_size 20m;

  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers on;
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:10m;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://ghost:2368;
  }
}

This configuration exposes the Ghost app running in a separate container (at http://ghost:2368), and includes the necessary configuration for the SSL certificate to work correctly.

Now, create a new Dockerfile where you’ll alter the Nginx default image:

FROM nginx:latest
RUN rm /etc/nginx/conf.d/default.conf
COPY ghost.conf /etc/nginx/conf.d

With the Dockerfile ready, you can now return to your Docker Compose configuration.

Updating the Docker Compose Config

If your Ghost blog is still running, you should first stop it with the docker-compose down command. As the configuration has already had a volume attached, all the data will persist through the reset.

Update the docker-compose.yml file to add a separate Nginx container, and remove the ports property from the ghost container:

version: '3.3'
services:

  ghost:
    image: ghost:latest
    restart: always
    depends_on:
      - db
    environment:
      url: https://example.com
      database__client: mysql
      database__connection__host: db
      database__connection__user: ghost
      database__connection__password: ghostdbpass
      database__connection__database: ghostdb
    volumes:
      - /home/ghost/content:/var/lib/ghost/content

  db:
    image: mariadb:latest
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: your_mysql_root_password
      MYSQL_USER: ghost
      MYSQL_PASSWORD: ghostdbpass
      MYSQL_DATABASE: ghostdb
    volumes:
      - /home/ghost/mysql:/var/lib/mysql
  nginx:
    build:
      context: ./nginx
      dockerfile: Dockerfile
    restart: always
    depends_on:
      - ghost
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /etc/letsencrypt/:/etc/letsencrypt/
      - /usr/share/nginx/html:/usr/share/nginx/html

With that done, run the app with docker-compose up -d once again. If everything is set up correctly, you should see your Ghost blog under https://example.com.

Deployment Options

Thanks to Docker’s popularity and flexibility, there are tons of options to choose from when it comes to hosting your app. A well-designed containerized app can run everywhere from virtual private servers to dedicated Docker cloud environments or Kubernetes clusters.

Some of the most popular Docker deployment platforms include:

• Amazon ECS
• DigitalOcean Managed Kubernetes
• Google Cloud Run
• Microsoft Azure ACI

Conclusion

In this post, you’ve learned how to leverage the flexible and reproducible architecture allowed by Docker to set up your own Ghost blog. The only thing left now is to fill it with excellent technical content. That’s where Draft.dev steps in.

Draft.dev is a company that provides high-quality technical content for all your needs. Check out our website and schedule a call to get your technical blogging game going!

Choosing the best frontend framework can be a daunting challenge. New technologies are created every year, especially in the frontend development environment, and you may worry about making the wrong choice.

In recent years two frameworks have dominated the frontend scenario, enabling thousands of applications to be built and appearing in most tech companies’ job requirements: React and Vue.

How you select between the two will depend on your needs. The key is in using the proper criteria to make your choice.

Criteria

There are many factors to consider in picking a framework. Here are some of the most important:

• Code structure
• Performance
• Scalability
• Learning curve
• Talent research

Let’s go into each factor in more detail.

Code Structure

React and Vue are similar in many ways, but there are a few differences to keep in mind.

React uses JSX, which makes it easier for JavaScript to embed HTML in React. JSX can be daunting for newcomers, but it also helps make React more semantic and more scalable.

Vue uses HTML templates. This is a common concept for a lot of developers, but the templates can pose limitations for enterprise-level applications due to their manageability.

React natively supports components, essential state management, and DOM manipulation tools. Other tools like Redux are separate and must be installed and integrated into your project.

Vue, meanwhile, has a highly active set of core solutions, like Vue Router and Vuex, which are constantly maintained and improved by the team behind the framework.

Learning Curve

Both frameworks use HTML, CSS, and JavaScript as their core technologies, but I find Vue significantly easier to grasp than React. React requires the use of JSX, which can be confusing for beginners as they learn a new approach to writing code and managing views.

Vue’s HTML templates are familiar to most developers, and the framework’s documentation is regarded as more detailed and wide-ranging than that of React.

Talent Research

Maybe you’re trying to pick a framework, not for a project but to base your career skills around. React proves to be the top option. The Stack Overflow 2021 Developer Survey shows React is the most popular framework choice, beating jQuery and well ahead of Vue.

The tech trends site BuiltWith also notes that projects built with React are more than double the projects made with Vue. So React may still be the best career choice.

Some famous apps built with React include:

• Facebook
• Instagram
• Netflix
• Khan Academy

While famous apps built with Vue include:

• Nintendo
• Behance
• GitLab
• Netlify

Bonus: Blogging

As a content creator, I’m interested in creating and hosting my own blogging platform. As a developer, I’m interested in how React and Vue would compare for this purpose.

One new development over the past few years is the static site generator (SSG), a software application that creates HTML pages based on raw data and a template. An SSG is an excellent technical choice for building a blog.

Both React and Vue support SSGs, but honorable mentions should go to Gatsby.js and Gridsome.

Gatsby is an open-source framework based on React and ideated to allow the creation of super-fast websites. It offers various tools like code-splitting, image optimization, and an internally generated GraphQL API for your project. It also features a rich collection of plugins for extending its support to other technologies.

Gridsome is similar to Gatsby, but it uses Vue as its core technology. It supports every headless CMS and every API. It also offers amazing support for PWAs, loading only necessary code into your website and allowing navigation to perform at top-tier levels.

For more info about comparing these tools, check out this article.

Conclusion

Clearly, each framework offers pros and cons for developers. Vue may not be the best choice for large applications, but it will be easier to begin using than React’s JSX. React is the most used framework in 2021 and the most desired by companies. Vue offers a more lightweight solution for your projects and can be more easily integrated into an existing project. Both frameworks, though, work with many other tools and can help you power your SSG page.

How you weigh this information depends on what your career goals are and what you need to accomplish with a current or future project. Keep your priorities in mind and you’ll be able to make the right choice for your needs.

React frameworks are software platforms that extend the capabilities of React web applications. Certain functionality needed in most blogs and websites (page routing and image optimization for example) don’t come packaged as part of the Create React app; they require libraries and complicated configuration to implement.

Next and Gatsby frameworks include this functionality as defaults, enabling React developers to easily build full sites without much upfront configuration. Additionally, since their individual parts were optimized to work together (vs. installing libraries that came from different places), you begin with an incredibly performant site.

When deciding between a Next or Gatsby framework, how do you determine which one is best? Let’s explore the key differences between the two. We’ll end with some questions to ask yourself to make the best choice.

Getting Started

Let’s begin with a look at what it’s like to start up a site and compare Next js vs Gatsby.

What is Gatsby js?

Gatsby is a free open-source static site generator that allows developers to build super fast websites and apps. Their site has extensive documentation, regular webinars and a large community of contributors that allows developers to connect and further their knowledge. 

In addition to comprehensive documentation, Gatsby’s website includes a mini-tutorial that shows new users that building and deploying a Gatsby blog or site takes just a few simple steps. Developers can start a basic site using the Gatsby CLI or choose a pre-styled template from Gatsby’s library of starter sites. Starter templates allow users to quickly spin up a beautiful and functional blog without having to fuss about design. Developers can also create their own Gatsby starters.

Though getting started is easy, customization can involve a bit of a learning curve. Gatsby relies heavily on GraphQL for page routing, fetching API information, and use of plugins (we’ll talk more about this later). If you’ve never worked with GraphQL before, it is worth it to take a quick tutorial to learn the fundamentals.

Why use Gatsby js?

What is Next js?

Similar to Gatsby, Next.js is a framework that gives the user the building blocks to build a website or app. It is open-source and gives you the tools to create and deploy new applications in a short time frame. 

Getting started with a Next app is as simple as typing in a command in your terminal. Next’s CLI tool create-next-app works the same way as create-react-app, allowing you to spin up a full app with added functionality such as image optimization and page routing included as a set of customizable defaults. From there, a fundamental understanding of React is all that is really necessary to build and customize your Next site.

Next.js website has comprehensive documentation with details about building a Next app using React or TypeScript. They even offer a free “Getting Started” tutorial to help walk new users through the first steps. Examples of how to use Next with dozens of other popular tools, libraries, and languages can also be found on their GitHub page.

Why use Next js?

SEO

React applications built without a framework like Gatsby or Next have notoriously poor SEO. They use client-side rendering (CSR) to render pages; passing HTML, CSS, and a script tag to the browser when it receives a request for a page. That script tag contains the instructions your browser needs to build all of the React content on your site. To properly index your site for search engines to find, web crawlers need to be able to read that content before your site is run. However, most web crawlers don’t run that browser script as they crawl, so they don’t get all the information about what’s on your page in time to index it.

Gatsby and Next solve this through the way that they handle page rendering. Both provide web crawlers with the full contents of your site before the page is run in the browser, making your site appear in Google search results.

Let’s talk about how both Next and Gatsby framework’s helps with SEO:

Gatsby

Gatsby uses static site generation (SSG) to pre-render pages. Before deploying a site built in Gatsby, your code goes through a build process where the full HTML site is prebuilt before it even gets a browser request. When a user visits a page built in Gatsby, Gatsby locates the page’s HTML file in your build folder and rehydrates the page in order to make it into a full React application.

After making any updates to your site, the build process needs to be run again in order for the CDN to have the most recent updates. Thus, Gatsby is better for sites that don’t change much during the day such as landing pages, company sites, and blogs.

Next

Next.js can be used for static site generation, but it was optimized for pure server-side rendering. Server-side rendering (SSR) has been done for years with languages like PHP and .NET, but Next allows us to leverage SSR using JavaScript with Node.js as the runtime server.

Next’s primary differentiator is its use of dynamic rendering (a fancy way of saying “the page is built when the browser requests it”). All of the information for your site (routes, page data, etc.) exists on a Node.js server. When you navigate to a Next.js page from your browser, the server goes to find the page you requested. It is at this time that the page is built, and the data is then sent to the browser for the user to see. For this reason, dynamic rendering is great for sites updated multiple times a day such as e-commerce stores and online forums.

Fetching and Handling Data

The biggest difference in the methods used to fetch your data will depend on whether your app is statically-generated or server-side rendered. Since statically-generated sites pre-build pages before they are rendered in the browser, they fetch any data they need at build time. By contrast, server-side generated sites fetch the data needed at run time.

Gatsby

Gatsby does not care which API your data comes from, but it will take and source whatever data it gets back and make it available to you as a GraphQL API. In order to access your data, however, you will need to write GraphQL queries in your code.

GraphQL is great in that it allows for fetching very specific data – like the names of all blog posts with a specific tag, for example. This is meant to improve performance by decreasing network usage. However if you are building a SSG Gatsby blog, all data is fetched at build time and there will be no impact on performance at runtime.

Next

Next is flexible when it comes to fetching data, leaving it up to users to decide the approach they would like to use. The only piece required when it comes to data fetching is the use of one of their lifecycle methods (getServerSideProps to enable SSR or getStaticProps for SSG) to get the initial props needed to pre-render the page data.

If you plan on fetching large amounts of data, SSR is the better option. Massive amounts of data can cause slow builds in SSG apps. Servers used in SSR, however, are much more powerful and capable of quickly and repeatedly performing these complex operations.

Plugins, Extensions, and Ecosystems

One reason why Gatsby and Next are so popular is that both easily integrate with other tools and languages you’re already familiar with. Through their partner ecosystems, Next and Gatsby frameworks allow you to further extend the capabilities of your apps without unexpected side effects.

Gatsby

Unless you’re using a starter, most additional features are not included in your Gatsby file. However, Gatsby is very much like WordPress in that it has an enormous ecosystem of plugins that allow you to easily enhance your Gatsby app with any functionality you would like to add. Compressing images, adding in the TypeScript compiler, and using a pre-built theme are all examples of capabilities available in Gatsby’s plugin library.

Through the plugin library, Gatsby has the largest partner ecosystem of any framework. Plugins are available for most tools and libraries you’re already working with, making integrating Gatsby with other tools very simple. If you want custom functionality or themes, you can also build a custom theme or plugin and host it in the plugin library.

Next

Functionality that has traditionally been difficult and time-consuming to add to React manually— like page routing, image optimization, and code splitting—come as out-of-box defaults that can be easily customized in your Next.js config file.

Next was created by Vercel, a popular deployment and collaboration platform. As a result, Next benefits from Vercel’s incredible ecosystem of partner tools. Next is, of course, optimized to work with Vercel but also works well with other tools and libraries you already use for hosting, styling, and building, making it easy to incorporate it into your tech stack.

Scaling – Next js vs Gatsby

Will you be the only person who touches your app, or will there be others who maintain it? Are you expecting loads of activity from daily users? The choice between Gatsby vs Next will depend on how large you expect to grow your app in the future.

Gatsby

Gatsby is best for personal blogs and smaller static sites. When apps become too large, they may become extremely slow during builds or may not build at all. On their scaling issues documentation page, Gatsby notes that “large” is typically defined by an app with over 100K pages or with large amounts of data being fetched from the GraphQL API.

Next

Next is lightweight and easy enough to be used by hobbyists to set up a Next js blog, but also powerful enough to scale for enterprise use. Large organizations with tens of thousands of daily website visitors including Netflix, Hulu, and Nike are running on Next apps hosted on Vercel. When building a large enterprise-scale application, you should reach for Next.js.

Hosting – Gatsby vs Next

Now that you’ve built your app, it’s time to host it somewhere for people to use and interact with. Let’s talk about where Next.js and Gatsby apps can be hosted:

Gatsby

During the build process, Gatsby generates static assets that can be used in the browser and hosted anywhere. You have the flexibility to decide which hosting platform is best for you: Netlify, Firebase, Azure, AWS, Vercel, or whatever your heart desires.

Next

Similar to Gatsby, Next’s SSG option generates static assets that can be hosted anywhere. However if you choose the SSR route, you have to find a Node.js server to host it. Vercel—the creator of Next.js—is of course optimized to do this. SSR is supported by most of your favorite hosting platforms as well (Firebase, Netlify, AWS), but make sure to use tutorials specific to SSR hosting when you are first learning.

Gatsby vs Next – Choosing Between the Two

Deciding between these two frameworks comes down to the following questions:

How often do my pages need to be updated?\
With dynamic routing, Next is optimized for apps with pages that need to be updated often, such as stores or apps listening for messages. By contrast, static sites need to be rebuilt every time they are updated. If you are creating a blog or site with pages that don’t change frequently, you can use Gatsby.

Am I building a blog or static site?\
Gatsby has long been known as a great tool for personal blogs and small static sites. As a result, it has an expansive plugin library with themes that will give you features you will need in your blog so that you don’t have to build them from scratch. If you’re building a small site or blog but don’t want to build every feature from scratch, Gatsby is a great option for you.

Does this app need to scale?Gatsby apps are known to run into errors and slow builds when they become too large or fetch large amounts of data. If your app will have more than 100K pages or will need to fetch large amounts of data (such as a store containing many products with variants), Next.js is your best option.

Conclusion

For optimizing large, enterprise-scale apps or sites with lots of updates, reach for Next.js. For small or static sites and blogs, Gatsby is the optimal choice. No matter which you choose, however, you can expect an optimized React app with out-of-the-box features for enhancing performance, integrating with the most popular third-party tools, and boosting SEO.

There is so much to consider when making a basic website. You have to think about how to get a domain name and where to get it. You need to work out the general costs of building and maintaining it, where you can host your content, and how much the hosting would cost, alongside actually doing the coding and getting all the assets together. You need to performance test it, make sure it is kept up-to-date, and configure a process to get code regularly deployed out. On top of all that, there are web-safety standards like configuring HTTPS instead of HTTP to ensure the connection is encrypted.

This can be confusing and overwhelming—especially if you aren’t familiar with software development or web development. Static site generators (SSG) were introduced to solve this problem: How do you easily create and maintain a website?

Publii is one such SSG. In this article, we’ll look at the general user experience, and take a high-level overview. We’ll cover some of the pros and cons and discuss who it’s best suited for.

This article is aimed at bloggers or marketers, so you won’t need any advanced developer knowledge to engage.

What Is a Static Site?

To accurately explain what SSGs actually do, you have to first understand what a static site is.

A static site is a site that will load the same way every time. It doesn’t greet you with your name or load personalized content. Nothing on the website changes unless the author specifically changes it.

SSGs are normally very non-technical, so coding experience is not essential. The interface is what’s known as a “point-and-click” experience, which means users set things up visually, rather than via code.

Due to their ease of use, their usage and prominence have increased quite significantly.

Publii

Publii’s About page describes it as a “fresh new app on the block that opens up fresh avenues for creating interesting, attractive static websites,” and briefly discusses how its two creators have “many years of accumulated academic and practical knowledge.”

Publii has been around since 2016, so it is mature with a large ecosystem around the product.

Some of its key benefits are summarized below:

• It’s safe. The app is “near-impenetrable” to hackers as it works locally, so you don’t need to worry about security updates and manually managing databases to store your work.
• It’s portable. Publii is just a desktop app so you can manage your website anywhere, and it allows multiple users to all collaborate on one website.
• It’s easy to migrate. If you’re moving from WordPress, it has a built-in WordPress importer to transfer your posts, pages and categories.
• It’s fast. The speed of Publii’s web pages is very impressive and they are designed with performance in mind.

We’ll dive into further details of some of these features later, and answer key questions to help you consider which SSG best suits your use case. We’ll cover:

• Set Up
• My Publii site
  • First impressions
  • UI
  • Creating posts
  • Speed profile
  • Search Engine Optimization (SEO)
• Deployment
• Support
• Security
• Limitations

Set Up

It’s really quick to get up and running with Publii. To start, simply go to Publii’s download page and download the desktop app.

There are options for MacOS, Windows and Linux depending on which operating system you use, but there are some minimum system requirements that you can find here.

My Publii Site

To actually get a feel for using Publii I made a really simple website, tweaked the UI a little, made some posts with filler text, profiled my site and deployed it out.

First Impressions

On first opening Publii I found it really intuitive. It has a really clear left-hand side (LHS) menu with all the options you may want to use (like adding authors, tagging your posts, creating new posts, or changing your UI, etc.)

I was able to quickly produce a basic site and view my changes with a Preview your changes button.

I filled out a few posts with some basic template text and looked at the different themes.

Each section was clearly laid out and had lots of sensible defaults prefilled so you don’t have to spend a long time configuring it to make full use of its features.

You are able to create multiple sites which is a great benefit, and I was surprised how much you could do completely offline.

UI

Making UI changes with Publii was seamless and easy. Your site is split out into lots of separate sections, so you just find the setting on Publii and change what you need. The Preview your changes button lets you really quickly iterate to achieve your desired design.

Creating Posts

My website was going to be a really simple blog. Publii offers three different options for generating posts: WYSIWYG editor, Block editor, or a Markdown editor. Having the three options gave me a flexible and convenient way to produce content that best suited me.

Developers tend to use Markdown, which is a way to add formatting elements to your text (like bold, italics, images, and headers).

If you aren’t familiar with Markdown, try the What You See Is What You Get (WYSIWYG) editor as it’s similar to traditional word processing with tools to control the whole flow of your content.

Speed Profile

Speed is a key concern for websites. If your website takes between one second to three seconds to load, the probability of users bouncing off your page increases by thirty-two percent; that bounce rate increases to ninety percent if a page takes more than three seconds.

So when I finished my website I used Google’s Lighthouse to profile the site’s speed.

It received a perfect score. Very impressive!

Search Engine Optimization (SEO)

SEO relates to things you can change on your website to try and optimize how discoverable you are to search engines like Google. I wanted to test Publii’s default SEO settings, so I made no changes before running a Lighthouse test:

It received a score of ninety out of a hundred, which is impressive, and I think I could have made it higher with some simple tweaks to the default settings.

Deployment

If you’re not familiar with developer technologies, the deployment process might be tricky. Everything up to this point has been very easy to do, and the deployment might be the hardest part, but it is by no means overly difficult.

You’ll have to choose which server you want to use, create any accounts you need depending on the platform, and follow the tutorial.

It took me around ten minutes, and the tutorial was really clear. I went with GitHub pages as I already have a GitHub account. The actual deployment took less than thirty seconds and then, after it was connected, whenever I previewed my changes I could simply “Sync” my current Publii changes to the server to get changes deployed out.

It’s well within the scope of a non-technical person, and I haven’t seen another SSG do this any better than Publii.

Support

An important part of creating anything is help if you ever get stuck. Publii has quite a few ways to help. Firstly, scattered throughout the relevant places are tutorials of how to do each new thing (like deploying out to servers).

If you can’t find it in the tutorial, or you can’t find the solution in their documentation, they also have a help Forum where you can ask any question you can’t find the answer to.

Security

Publii’s security is great. Many hacking attempts try to leverage code injection—this allows hackers to run malicious code on your website, but only if there is code currently running.

In static websites, you only send generated website files making the site “nigh impossible” to hack without gaining direct access to the server.

Limitations

The biggest limitation if you choose Publii is that it is a static site generator.

If you need a complex, dynamic website that lets users log in and purchase things, and on which you can change stock levels, Publii probably would not be your best choice. Publii isn’t trying to do too much and they have their use cases well laid out.
This post compares WordPress with Jekyll, another static site generator, highlighting the differences with dynamic sites.

Another potential weakness I noticed, from reading posts in the official Publii Forum, was that many users who wanted to configure their post URL’s a certain way could not because Publii doesn’t allow that. This use case won’t affect my example site, but it may be something to consider.

Conclusion

I was really impressed with Publii. It is open source, fast, and simple to use. The company has shared what’s on the roadmap for the coming years and you can learn more here, or review what has recently been added. You can quickly look at the effect of tweaking parts of your site, develop it offline, and go from idea to viewing a complete website incredibly fast. Publii listens to its users and it continues to improve with every new release.

I hope this review has been helpful.

JAMStack, which stands for JavaScript, API, and Markup, is the latest buzzword in the world of web development. It aims to drop the complexity of your system, and helps you to deliver better apps in less time. As with any new innovation in tech, there is a plethora of companies offering competing JAMStack options. How can you choose which is the right one for you?

There are two main types of JAMStack sites: static, in which assets are created at build time ahead of deployment, and directly served when the user creates the website; and dynamic, in which a server creates the content and assets every time a user lands on your site.

In this article, we’ll be focusing on static sites and comparing the two most popular solutions: Hugo and Gatsby. You’ll learn the advantages and disadvantages of each, and which one would be best for your specific use case.

Why Static Sites?

You may be wondering why we have chosen to focus on static sites, rather than dynamic. The static architecture delivers lightning-fast websites and, more than anything, less complex systems with a decoupled frontend where you can consume data from any data source.

What Is Gatsby?

To answer, ‘What is Gatsby’ in simple terms, we can refer to how Gatsby describes themselves, and that is as,  a static site generator  or “React-based open-source framework for creating websites and apps.” It has a complete build system that enables you to use web technology to create static files. You will write React code to make your site and consume data through a GraphQL layer. Gatsby will then build your site to create multiple static files that you can deploy.

More on ‘What is Gatsby?’

What Is Hugo?

Hugo (also known as Hugo js) describes itself as “the world’s fastest framework for building websites.” Hugo (SSG) is a static site generator written in Go with the idea of high performance in the build process. Hugo has its template language based on HTML that enables you to create your site. It also supports Markdown and other languages through plugins.

More on ‘What is Hugo?’

What Are the Key Differences?

When comparing the two tools, these are the key aspects you want to focus on:

• Learning curve
• Documentation
• Speed
• Security
• Flexibility
• Scaling
• Price
• Community

Learning Curve

For a developer, the learning curve is an important aspect to consider when selecting a tool; this will help you define how much time you will need to deliver value to your user.

Gatsby is built on top of React as the “templating” language, so if you know React and JavaScript in general, you are all set to start working with Gatsby. The next step in this curve is to understand how to work with graphql. Gatsby uses a graphql layer to collect the different data sources from various plugins to be consumed by your React code. However, Gatsby does provide many templates or ready-to-use “starters” that can help you avoid the complexity of React and graphql. Most of this can be found in the Gatsby docs resource on their website.

On the other hand, Hugo is built with Go, but you don’t necessarily need to know Go to use it. If you choose to use a pre-made template, then your work will be mostly related to TOML files for configuration and Markdown for the content files. Still, if you want to customize your site or build from the ground up, you need to know how to write your templates using Go’s templating system.

So the learning curve depends on your goal:

• Do you want to customize your site from the ground up? Then if you’re familiar with React, Gatsby will be a quick choice
• Do you want to get up and running with ease? Hugo js is a solid choice due to its hundreds of quick-start themes.

Documentation

Every time you are about to start a project with something new, it is a good idea to take a look at the state of the documentation of the chosen technology. As you’ll often have to refer to the official documentation to answer queries, you’ll want it to be easy to use and up to date.

Both the Hugo and Gatsby framework have good documentation that quickly drives you to their corresponding Quick Start guides to help you start.

Gatsby’s documentation is extensive. It has a full-featured tutorial and in-depth guide that runs you through all the nuances of the framework. A simple view of Gatsby’s documentation seems complete but also can be overwhelming.

Hugo’s documentation can be seen as a smaller collection of guides but still with a lot of in-depth information about the framework’s operation. More information can be found at the hugo docs page.

So, when looking at both Hugo and Gatsby docs,, there’s no clear winner, and it will simply depend on your familiarity with the technology.

Speed

One of the selling points of a JAMStack site is speed, but you need to split this concept into at least two different metrics. Build speed and Runtime Speed.

Gatsby says that the framework is “fast in every way that matters,” while Hugo preaches that they are the fastest tool out there.

Build Time Speed

Since we are talking from a developer perspective and both of these tools leverage the power of the build system to create static sites, the build time speed is a good metric that can be part of your decision.

In this race, Hugo is a clear winner without a doubt. Hugo was built to deliver “blistering speed,” and only takes around 1ms per page. And one of the biggest benefits of Hugo SSG is the lightning fast build time. Gatsby, on the other hand, takes a considerable amount of time in comparison.

Build time speed will depend on the number of pages to generate and the latency of the data sources. An excellent way to compare this speed is just by having the same amount of markdown files as a source for both frameworks, with Hugo SSG coming out on top every time.

Gatsby does offer incremental builds inside their cloud service that aim to provide better build times, but at the same time can lead to vendor lock-in.

Runtime Speed

Analyzing the runtime speed can be tricky and will depend on more variables than just the framework. But simply: Gatsby creates HTML pages from your React code to serve the essential app shell and then injects some JavaScript (including React library and any other 3rd party library) to continue the rendering process. This can be seen as slow since there is a JS bundle to load, but at the same time can be an advantage since through this process Gatsby offers other optimizations out-of-the-box such as: Progressive and responsive image loading, and inline critical CSS.

Hugo creates the static HTML pages from the Go templates and includes optional JS compiled with esbuild.

Here the comparison is challenging since simple load HTML and other static assets are fast for both solutions. Still, in some cases, the progressive enhancements offered by Gatsby can be useful or essential to a site, which gives it a slight edge.

Security

Both offer security as one of their selling points; Gatsby advertises that since they generate static HTML at build time, there is no server, avoiding malicious requests, DDOS attacks, or data exposures. But, the same is essentially true of the  Gatsby static site generator or any other SSG.

You could argue that since Gatsby heavily utilizes JavaScript, then a security issue could arise based on the number of unknown and uncontrolled npm packages involved.

Hugo has a documentation section to talk about the security model they offer. General Data Protection Regulation (GDPR) is an EU law on data protection and privacy, and Hugo docs  describe in detail how to configure your site to meet the regulations.

But in general words, an SSG holds its weight in terms of security from holes that can arise from 3rd party issues. As an example, this is a comment from a vulnerability issue found in postcss, which states:

The issue is not critical (it can affect only online tools like CodePen…)

So in terms of security, you can consider that both the Hugo and Gatsby frameworks have similar or even equal security features.

Flexibility

What is the level of customizability that each framework offers? Do Gatsby and Hugo let you create what you want, or are there limitations on design?

Here, both frameworks offer full features on customization; Gatsby’s framework allows you to create any component you wish with React and any UI library or CSS solution you prefer: tailwind, emotion, or just plain old CSS. Hugo is also free of design opinions, so you are free to implement any UI you wish with the tools available: Go templates and any CSS framework.

Both solutions are equally flexible, so it just depends again on what framework you are more familiar with: React for Gatsby, or Go for Hugo.

Scalability

Scalability is the ability of the framework to handle large and growing sites. Both solutions have their own take on how to confront the challenge.

Gatsby is known for a slow-building process that creates many different pages, so it can be tedious to work with big sites. They even have an entry in the documentation to address this topic in particular.

They mention that they have acknowledged that Gatsby has scaling issues when the application has more than 100K pages or when the graphql queries are too large. There’s even a GitHub issue about scalability where the engineering team recollects benchmark data.

One way they offer to solve this building scalability is with their cloud system, but this is an imperfect solution.

On the other hand, Hugo prides itself to be blazing fast for building thousands of pages, so we can say (again) that Hugo here is a winner if we’re looking purely at scalability of build.

But static sites are built, or updated, way less often than they are read, so the other important point on scalability is how well they behave under heavy load.

The JAMStack is, by default, almost infinitely scalable. Since SSG pre-render the assets, the Time to First Byte (TTFB) is minimal. Also, the files can be served through a CDN and be available almost instantly for the user (and use the great HTTP caching capabilities to make it even faster), therefore lowering the server requirements. Hugo and Gatsby fall into this category of frameworks, so their scalability features are on par. Still, if you consider the built time an essential metric for your scalability needs, then Hugo has the advantage.

Price

Another essential aspect to consider when reviewing tools for your marketing site (or any site for that matter) is price.

Both Gatsy and Hugo are free and open-source. You can download them and use them for free, and the only cost you’ll have to worry about is deployment.

To deploy a site built with Hugo or Gatsby, check some CDN services like AWS, Netlify, or Vercel. Most of these services have a free tier to enable you to start as fast as possible. The other possible cost is related to your data store or CMS, which depends on the service you are using.

So as both frameworks are free, this one is a tie.

Community

With every tool or technology, having an active community can be a huge bonus, particularly if you run into an issue that’s not covered by documentation. In this case, the Gatsby framework is a clear winner, with a thriving and growing community complete with global events and conferences.

Conclusion

Both Gatsy and Hugo do a great job in every category that matters for comparison, with Gatsby drawing an ever-so-slight edge in the community aspect. But, I think it all boils down to your development team’s experience: if your team is already experienced with javascript and React, then Gatsby is an excellent choice to start right away, and if JavaScript is not a tool you have under your belt, then the learning curve of Hugo js  will be lower, so it can be a great alternative.

There are many choices when it comes to building a website or blog, catering to every level of technical knowledge. It can be overwhelming, especially because once you’ve chosen one, you probably won’t want to migrate to another one in the near future.

This post compares two of the heavyweights: WordPress and Jekyll.

Both are open source and very capable platforms, but with significant usability differences. WordPress is a content management system (CMS) that creates dynamic websites, with tens of thousands of plug-ins that expand the functionality of the site. Jekyll is a static site generator, so you build sites by generating static files (such as HTML) with your computer’s command line, and as such, there isn’t a database.

While WordPress’s popularity isn’t likely to go away anytime soon, its position as an all-around system means there are instances where it offers more than you need. Like having a full toolbox when you just need a screwdriver. Jekyll, and other lightweight alternatives, offer a stripped-back experience that aims to provide only what you need, and no more.

This piece will compare WordPress and Jekyll on the following:
– Main features
– Security
– Speed
– Stability
– Flexibility
– Design
– Support

Main Features

The main difference between the two platforms is that WordPress is a CMS that builds dynamic sites, and Jekyll is a static-site generator reliant on command line-generated files.

Both can create simple blogs or full websites, with navigation and multimedia. As it lacks dynamic features, Jekyll can’t provide tailored recommendations or user comments.

Both platforms are also free and open-source, although there are various ways to spend money with WordPress. A self-hosted site will have hosting fees, which can vary widely, and you may choose to buy premium WordPress themes and plug-ins to get your site looking and working exactly as you want. Jekyll can be hosted for free on the GitHub servers.

One major difference between WordPress and Jekyll is who they appeal to. Jekyll is likely to be more appealing to the person with some coding knowledge who is happy to spend time on the command line. WordPress, by contrast, has a graphical user interface and a database, and it’s beginner-friendly once you’re past the initial learning curve that any new platform has.

Security

You may have heard horror stories about how WordPress sites get hacked or targeted by cyberattacks, which can give the impression that WordPress itself isn’t secure.

The good news is that this isn’t true. WordPress Core is run by a highly skillful team who release regular updates to fix any vulnerabilities and security threats. Just keeping your WordPress site updated will go a long way toward staying safe and secure.

WordPress also allows you to install a wide range of themes and plug-ins, tweaking every aspect of design and functionality. Unfortunately, these are not all equal. As they’re created by third-parties, there’s variety in how stable and secure they are. It’s a good idea to stick to reputable names and the official WordPress directories.

To further increase peace of mind, you can add security plug-ins such as Wordfence that regularly scan for malware.

The standard rules of online security come into play here: Use strong passwords, choose a secure hosting provider, and keep WordPress, plug-ins, and themes up to date.

As a static site generator, Jekyll doesn’t need regular updates. Unlike WordPress, there’s simply nothing for a hacker to exploit. Because Jekyll’s files are stored locally, your main risk is if someone gains access to your computer.

You can also store backups of the files in a cloud-based storage solution such as Dropbox, Google Drive, or iCloud. The static files take up trivial amounts of space, and if ever your site is compromised, you can simply download the files from the cloud and put them back on the server to regenerate your site.

Speed

While it’s not like comparing a Formula One car to a bicycle, this one isn’t exactly a fair fight. For all the speed optimizations WordPress offers, Jekyll loads static sites, which are fast.

That’s not to say WordPress is slow, however. It can also be very fast, particularly with a good hosting provider and a well-chosen speed plug-in. The size of your site will also play a part; loading a simple, small blog is different from loading a huge landing page with lots of images, videos, and other resource-heavy elements.

Nonetheless, there’s no getting away from the fact that WordPress is a dynamic site builder that loads from a database. Jekyll loads very small static files, and it can be sped up even further by using plug-ins such as ImageOptim API.

Stability

WordPress and Jekyll are both secure platforms. As already noted, WordPress Core is managed by a skillful and dedicated team, so new updates are regular and impactful.

One area where WordPress’s stability can be called into question is when there’s a significant spike in traffic. On a dynamic site, the content has to be processed, and queries are sent to the database on the server. Higher traffic means more and more demands on the server, which can result in extremely slow rendering times or the site crashing entirely. This doesn’t damage the site, but it can be a frustrating user experience.

Another point of consideration is that individual plug-ins can stop working properly on WordPress. This can sometimes affect the entire site, or it can cause specific components to stop working, such as widgets not loading correctly.

Static-site generators like Jekyll don’t have the problem caused by traffic spikes, because each page is pre-rendered, and the per-visitor demands on the server are much lower.

Flexibility

It could be argued that if you looked up “flexibility” in the dictionary, there should be a picture of the WordPress logo next to it. Remember Apple TV commercials for the iPhone’s App Store, the ones that said “There’s an app for that”? Well, it’s a similar story with WordPress—whatever you want to do, there’s probably a plug-in for it, from Google Analytics to Facebook Pixel.

You don’t necessarily have to rely on those plug-ins. If you’re comfortable with code, you can edit the CSS directly or add custom code without touching the main CSS file. Some companies, such as Thrive Themes, even let you create your own theme in a completely no-code environment. If that’s still more hands-on than you’d like, you can simply install one of the many, many thousands of free or premium themes available. And there are the very popular page builders, giving additional flexibility to individual pages without having to create your own theme. Elementor, Themify, and Thrive Themes are a few popular examples.

This flexibility also means WordPress can be almost anything you want it to be. Simple blog? Yes. Landing page with opt-in form? Absolutely. Membership plug-in with gated content? Easy. Forum? Not a problem. E-commerce website for selling digital or physical goods? Of course.

Jekyll is no slouch in the flexibility department either. Users with little or no coding experience will find it difficult, but experienced developers will be able to do almost anything through the code, from shifting the logo by a single pixel to nailing the overall design.

As a static site generator, Jekyll has limitations compared to WordPress. It’s not possible to create a forum on Jekyll directly, for instance, and although you could include e-commerce solutions, they’re suitable only for smaller projects.

Jekyll has a library of themes and plug-ins to choose from, but not nearly as many as WordPress offers.

Design

In many ways, this section will be largely influenced by your preference. Both WordPress and Jekyll sites can build beautiful sites in almost any design you want.

Some people will find it an advantage that WordPress has a graphical user interface and CMS, while others will prefer Jekyll’s command line interface.

Both display multimedia, although WordPress allows you to do some basic image editing on the platform, whereas Jekyll doesn’t. This might be a slight advantage for some.

There are a lot of themes and plug-ins available for both platforms, too, giving you a quicker way of getting the design you want without building it from scratch. WordPress does have a far bigger library of both, though, so the design edge may have to go to the CMS here.

Support

Jekyll has multiple support options: official documentation, discussions on the Jekyll Forum and StackOverflow, as well as a Gitter channel and IRC channel on Freenode. Aside from the documentation, the support is dependent on the community, which is an active one.

WordPress also has documentation, as well as official community forums. For sites hosted by WordPress, there is the option to talk to customer support on the phone. Because of its popularity, there are a lot of options for WordPress support, from hosting platforms to independent technical support companies.

Conclusion

WordPress and Jekyll are both mature and highly capable platforms. There are broad similarities between the two, but there’s enough of a difference in usability and features that picking the right one for you is likely to be a fairly easy decision to make.

If you’re not experienced with code, want a CMS or graphical user interface, or want access to all of the themes and official plug-ins, WordPress is probably going to be your preference. You’ll need to stay on top of updates to keep the site secure, and you may also want to consider paying for monthly tech support to ensure everything—including plug-ins—stays up to date and to benefit from security and malware scans and from better hosting to prevent downtime from traffic spikes.

On the other hand, if your ultimate preference is speed or security—and you’re comfortable with code and community support—Jekyll might be the way to go. The fact that it’s low-cost or free is persuasive, too.

In this article, I’ll be showing you how to create a custom error 404 page in GitHub Pages, a static site hosting service that allows you to publish and host your web pages through GitHub.

Table of Contents

• How Does GitHub Pages Work?
• Setting Up GitHub Pages for Your Website
  • Creating Your GitHub Pages Repository
  • Configuring Repository Settings
  • Benefits of Using GitHub Pages
• Why Is a 404 Page Important?
  • Understanding 404 HTTP Status Codes
• Essential Elements of Effective 404 Pages
• Creating Your Custom 404 Page in GitHub Pages
  • Step-by-Step Implementation
• Conclusion

How Does GitHub Pages Work?

To break that down quickly: a static site is a website made up entirely of HTML, CSS, and JavaScript files. Everything the site needs to render is contained within these files, so there’s no need for server technology like PHP, Node.js, or Python. If the static site needs extra data from a server, it makes an asynchronous HTTP request with tools like fetch api or axios. And you’ll probably want to make sure that static site has a 404 page.

Displaying a 404 error page on your site is sort of like delivering bad news—the tone and manner of your delivery can determine if the person receiving the news will either be upset or be ready to agreeably look for another solution. After putting in all the hard work finding the best blogging platform, you don’t want a 404 to let you down.”Fortunately, GitHub Pages makes creating one a walk in the park.

Setting Up GitHub Pages for Your Website

Hosting your site on GitHub Pages is as easy as signing into GitHub and creating a new repository.

Creating Your GitHub Pages Repository

Your repo name should have the following format: <your github username>.github.io.

Add files to your repo. You can do this either by creating the files locally and pushing to remote or by creating the files directly on GitHub.

Go to the Settings tab of your newly created repository.

Scroll down to the GitHub Pages section.

Here, you can choose the branch you want to serve your pages from, the root directory, and even select a Jekyll theme. If you already have a custom domain name, you can add it here.

By adding a custom domain name, you can access your site using yourdomainname instead of your github.io domain.

That’s all! Your site is now ready to be published. Visit <your github username>.github.io to see your new website.

Configuring Repository Settings

You can make changes to your site whenever you choose. They become available immediately after you push/merge to the branch you’ve chosen to serve your pages from.

Benefits of Using GitHub Pages

Using GitHub Pages for your static site gives you some nice perks:

• GitHub Pages is free to use. No coughing up extra cash just to host some basic web pages.
• You can use it to host websites like single-page applications or blogs.
• You can add a custom domain name to your site.
• You can enable HTTPS for your domain in just one click.
• You get the added advantage of managing your site with Git. Version-controlling your website becomes a piece of cake.

Why Is a 404 Page Important?

The 404 page is a famously dreaded sight across the internet. It’s a page that neither website users nor owners like to see, but it’s an unavoidable one. Its purpose is to inform a user that the page they’re looking for doesn’t exist.

Think about it: it isn’t every time you go into a store that you find everything you’re looking for. Certain items may be sold out or perhaps the store never sold them to begin with. That’s exactly what happens on the web. Perhaps the page’s URL changed, breaking an old link, or maybe the page was removed altogether. A user could have manually input the wrong URL to begin with. However a user has arrived at a particular URL, the requested web page doesn’t exist.

Understanding 404 HTTP Status Codes

Specifically, 404 is an HTTP status code for a “Resource Not Found” or simply “Not Found” error. It applies to all kinds of resources on the web, including HTML files, CSS files, JavaScript files, documents, images, and just about any other file that could be requested from a server.

How you as the webmaster choose to convey a 404 error is very important. It can either improve your user’s experience on your site or make it worse.

Essential Elements of Effective 404 Pages

At the end of the day, what’s on your 404 page is up to you, but I can give you a few tips to make it as palatable as possible for your users:

• First and foremost, a 404 page should return with an actual 404 HTTP status code. This is important so web crawlers like Google’s bot don’t incorrectly index an erroneous page as a valid page, as this can negatively impact your SEO.
• The 404 page should make it clear to the user that there’s a problem. This can be achieved by making the 404 or Not Found message prominent on the page.
• The page should offer a way out to the user. Unless you want the user stuck on your error page or want them to close your site immediately, your 404 page should provide them with a means to navigate away from the page. Add an obvious link to your site’s homepage to somewhere on the error page, or you can suggest links to pages that might be similar to what the user was looking for in the first place.
• You can provide a way for users to report a broken page, enabling you to quickly fix any issues.
• Add a search bar for users to find other things they might be looking for.
• Make the design pleasing to the eye. A 404 page is still a part of your website, so you should put as much thought into its design as you have for other valid pages. The page should carry elements of your brand, and not look like a desert island.

GitHub’s very own 404 page is a good example of what a 404 page should look like. The error code and message are both prominent on the page, and there’s a search bar to help you find other content.

If you don’t add a custom 404 page to your GitHub Pages site, then by default GitHub displays the following 404 page:

Not bad, eh? But not good enough for your brand.

Creating Your Custom 404 Page in GitHub Pages

Fortunately, GitHub also understands the importance of a 404 error page, and provides developers an easy way to add one to their GitHub-hosted pages. Let’s look at how you can add your own custom 404 page.

Step-by-Step Implementation

Create a new file in the root of your repository and name it 404.html.

Then go on to add content for the 404 page as follows:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Page Not Found</title>
    <link rel="preconnect" href="https://fonts.gstatic.com">
    <link href="https://fonts.googleapis.com/css2?family=Chango&family=Roboto:wght@300&display=swap" rel="stylesheet">
    <style>
        body{
            background-image: url("https://images.unsplash.com/photo-1616235132417-99f443954d2e?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=334&q=80");
            background-size: cover;
            font-family: 'Roboto', 'sans-serif';
        }
        main{
            display: flex;
            height: 100vh;
            justify-content: center;
            align-items: center;
            flex-direction: column;
        }
        .header404{
            font-family: 'Chango', cursive;
            font-size: 48px;
        }
        .content404{
            text-align: center;
        }
    </style>
</head>
<body>
    <main>
        <h4 class="header404">404</h4>
        <div class="content-404">
            Uh-oh! We couldn't find the page you are looking for.
        </div>
        <p>
            <a href="/">Check our home page</a>
        </p>
    </main>

</body>
</html>

Commit your changes, then try to visit a page that doesn’t exist on your site, eg,username.github.io/a-random-page-that-doesn't exist. A page like this should appear:

Conclusion

Hopefully, this article has shed some light on the importance of a 404 page and why you should put some effort into branding it as you would other pages of your website. When properly done, a 404 error page can be a good way to increase your website’s conversion rate.

Unlike many other host servers where you have to tinker with .htaccess or other kinds of configuration settings to handle 404 error pages, GitHub Pages makes it incredibly easy. All you need to do is add a single file, and you’re good to go.

If you’re stuck for ideas on what your 404 error page can look like, you can always look around for some 404 inspiration.

Static site generators create HTML sites characterized by predictable page layouts and content with regular presentation, such as blogs.

There are many frameworks that can leverage a programming language and allow you to reuse code and process assets for these HTML pages, but this article will compare two of the most popular: Hugo and Jekyll. (For a comparison of a static site and a dynamic site, see Jekyll vs WordPress)

Table of Contents

• Why Use Static HTML Pages?
• What is a Static Site Generator?
• What is Hugo?
  • Speed, More Speed
  • Hugo Bonuses
  • Hugo Feature Updates
• What is Jekyll?
  • The Template Situation
  • Quick Start Experience
  • Jekyll Updates
• Hugo vs. Jekyll
• Hosting a Static Website
• Which Static Site Generator Should I Choose?

Why Use Static HTML Pages?

Static site generators are appealing because they produce secure sites requiring little maintenance that are faster to serve than dynamically generated web pages. With dynamic web pages, a web framework installed on a server generates the page a user sees. A user makes a request, the server queries a database, pulls out the information users want to see, combines that data into an HTML page, then sends that page to a user.

With static HTML pages, the pages are pre-rendered, so the server doesn’t do any of the work of building the page. It only handles sending the appropriate page to the user. This means that static HTML pages are faster, and the computing requirements for the server are much smaller; important in cloud environments where you’re charged for computing power.

Static pages cut out the page generation, so the user receives their page much more quickly. Security risks are also smaller because there are fewer moving parts for attackers to infiltrate and exploit. Static HTML pages are easily cached, so they’re well suited to be served from content delivery networks (CDNs), making response times even faster.

Because static pages don’t require servers to perform calculations or query the database, you can deploy them using very simple, low-cost hosting options like an Amazon S3 bucket or GitHub Pages.

What is a Static Site Generator?

A static site generator (SSG) is a tool that builds HTML websites from raw data and templates during the build process. Rather than manually coding each HTML page, developers write content in simpler formats like Markdown, define templates for consistent layouts, and let the SSG combine these elements to produce a ready-to-serve website.

You could simply write an HTML page and put it on a server, hearkening back to the early days of the web, but static site generators make it much easier to create new pages that use existing templates or modify all of your existing pages at once.

One of the first static site generators to restart this trend in web development was Jekyll. Hugo joined in five years later.

Hugo and Jekyll allow users to create websites without the need for a traditional database. Hugo is known for its speed, boasting build times of less than one second, which can be attributed to its efficient architecture. Jekyll, on the other hand, is integrated with GitHub Pages, making it a convenient choice for users who wish to host their blogs directly on GitHub.

What is Hugo?

Hugo is a super fast, highly secure static site generator that positions themselves as a fun and modern website building tool. It is written in Go and sites can be hosted anywhere. One of the more standout features is that Hugo static sites don’t need a database on runtimes like Ruby, PHP or Python. According to their website, Hugo static site generator “is the fastest tool of its kind” listing average site builds speeds of under a second.

More information on “What is Hugo”.

Speed, More Speed

One of the major benefits of using the Hugo static site generator is its speed. Leveraging the focus on concurrency of the Go language means blogs with thousands of entries or tons of images will generate HTML more quickly. That matters if you’re running code anywhere you’re paying for computing power.

It also matters during development, because changes that you make to templates or content are re-rendered more quickly with Hugo. This speed difference is noticeable even at low page counts, but it becomes significant if you’re building a hundred pages of content.

Hugo Bonuses

Hugo offers support for internationalization, providing multiple ways to categorize content in different languages. Hugo also offers image processing, built-in menus, site mapping, and live reloading.

You can achieve the same result in Jekyll, but it’ll take more work to set up. In Jekyll, this functionality comes from plug-ins, but if you’re building complicated pages, it’s nice to have it built-in.

Hugo Feature Updates

Hugo has seen significant enhancements through 2024-2026, solidifying its position as a performance-focused generator:

Build Performance:

• “Million Pages Release”: Streaming builds allowing Hugo to handle sites with over a million pages
• Content Adapters: Pull content from remote data sources and APIs directly into builds
• Optimized Asset Pipeline: Enhanced JavaScript bundling with tree shaking and code splitting

Content Features:

• LaTeX and TeX Typesetting: Native mathematical notation support
• KaTeX Server-Side Rendering: Math equations rendered at build time
• Obsidian-Style Callouts: Markdown extensions for note-taking compatibility
• Enhanced Tailwind CSS Support: First-class integration with modern CSS frameworks

Developer Experience:

• Live Reloading: Instant preview updates during development
• Improved Image Processing: Convert, resize, crop, rotate, adjust colors, apply filters, overlay text, and extract EXIF data
• Advanced Multilingual Support: Comprehensive internationalization features
• Powerful Taxonomy System: Sophisticated content categorization

These updates show Hugo’s continued focus on speed and scalability while adding features that developers need for modern technical documentation and content-heavy sites.

What is Jekyll?

Jekyll is an open source static site generator written in Ruby by the co-founder of Github, Tom Preston-Werner. It translates plain text documents into static sites that can be used for informational based websites or blogs. It has built-in support for Github pages and is one of the more popular static site generators available.

More information on “What is Jekyll”

The Template Situation

One of the main benefits of the Jekyll framework is its ease of use, well-developed documentation, and broad support from major organizations like GitHub. Jekyll was released twelve years ago and helped kick off the new interest in static HTML sites. Hugo was released later and is less popular, so it has a less developed ecosystem of plug-ins and templates.

GitHub topics offers a whopping 1,500 themes to choose from for Jekyll, while there are only 550+ options offered on the Hugo themes pages (although, you can also create your own themes). Obviously, it’s much more likely you’ll find a theme with the look you want with Jekyll. Jekyll is supported by GitHub, so if you want a simple, no-cost deployment, Jekyll works seamlessly with GitHub Pages, so you can have a simple Jekyll blog up and online very quickly by following GitHub’s excellent documentation.

Quick Start Experience

Another difference between the Hugo and Jekyll frameworks is that creating a brand-new site with Jekyll by running the command jekyll new my-awesome-site installs a basic theme, while creating a new site with the hugo new site my-awesome-site command only generates the folder structure and an archetype file. With Jekyll, you’ll have something to work with right away, but with Hugo you’ll be looking at an empty screen waiting for you to add a theme or custom templates.

This can be great for a totally customized setup, but Jekyll has a much quicker path to seeing content you can work with.

Jekyll in 2026: Stability and Ecosystem

Jekyll continues development with regular updates through early 2026. While not adding major new features, Jekyll’s stability and mature ecosystem remain its core strengths:

Current State:

• Version Support: Supports Ruby 3.0+ (requires adding webrick gem for Ruby 3.0+)
• GitHub Pages Integration: Remains the only static generator with native, zero-configuration GitHub Pages support
• Active Maintenance: Regular bug fixes and security updates through January 2026
• Plugin Ecosystem: Extensive collection including jekyll-seo-tag, jekyll-feed, and jekyll-sitemap

Community Tools:

• JekyllPad: New visual, browser-based CMS for content management without technical complexity
• Gem-Based Themes: Simplified theme updates through RubyGems package management
• Remote Themes: Any GitHub-hosted theme can function as a gem-based theme

Strengths in 2026:

• Largest theme library of any static generator (1,500+ themes)
• Most extensive documentation and tutorial ecosystem
• Lowest barrier to entry for non-technical users
• Ideal for simple blogs, portfolios, and documentation sites under 1,000 pages

Jekyll’s “boring technology” approach appeals to teams valuing stability over cutting-edge features. The 17-year track record means fewer breaking changes and more predictable upgrades.

Hugo vs. Jekyll

With either generator, you can get a templated blog up and running in under thirty minutes. If you’re starting from nothing, Hugo is slightly easier to install. With Jekyll, you have to install a couple prerequisites like Ruby. Go comes as a precompiled binary bundled along with the Hugo installation.

For both Jekyll and Hugo frameworks, you’d normally write a content file like a blog post in HTML or Markdown. This content gets combined with HTML templates, which wrap and style the content, outputting an HTML file for display on the web.

Both frameworks allow developers to add variables to content, using the YAML markup language, and consume data files in common formats like JSON and CSV. Both frameworks also come with a number of features useful for a blog, like tags and the ability to route content files to finished HTML pages. They are also open source, so you can request changes and contribute improvements.

The first and most fundamental difference between the Jekyll and Hugo  frameworks is the language they’re written in. Jekyll is written in Ruby, a popular scripting language that was one of the first languages to come with an opinionated web framework, making it extremely popular for building websites quickly. Hugo is written in Go, which was developed at Google with an eye on concurrent execution, optimizing for deployment in cloud environments where computing power is distributed across many machines.

Each framework also has different preferences about what languages it works well with. Jekyll offers support for CoffeeScript and SASS/SCSS. Hugo supports TOML and JSON markdown in content files, but supporting SASS and SCSS might require some additional setup.

Hosting a Static Website

Both languages offer options for easy hosting, but Jekyll is the simplest. Jekyll and GitHub Pages have a close, long relationship, and deploying a Jekyll project to GitHub Pages is simple and fast, which can be a great option for trying out a blog with Jekyll.

Hugo also offers many hosting options. For both generators, you have two fundamental options:

1. You can run the site generator locally, then upload the results to a server. You can do this manually or instruct some service to grab your updated HTML.
2. You can install the static site generator on a computer in the cloud, tell that computer to run the content generation command, then serve the files that process creates. This is how services like Amazon Amplify, CloudCannon, and Netlify all work. These providers all have specific guides for deploying sites, but the deployment process is pretty painless when using either static site generator.

Which Static Site Generator Should I Choose?

Which Static Site Generator Should You Choose in 2026?

Both Jekyll and Hugo remain excellent choices for blogs and frontend-oriented sites, but your decision depends on specific project needs:

Choose Jekyll if you:

• Want the simplest possible setup with GitHub Pages free hosting
• Need extensive theme options (1,500+ available)
• Prefer Ruby-based tools or have Ruby developers on your team
• Are building a blog or portfolio under 1,000 pages
• Value ecosystem maturity and extensive documentation
• Want a CMS-like experience with tools like JekyllPad

Choose Hugo if you:

• Need fast build times for 100+ pages (rebuilds in under 1 second)
• Are building documentation sites or content-heavy projects
• Want modern features like LaTeX rendering and content adapters
• Prefer Go-based tools or want compiled binary simplicity
• Need multilingual support or advanced taxonomy systems
• Plan to scale to thousands of pages
• Value cutting-edge performance optimization

2026 Considerations:

• Build Speed: Hugo averages <1 second for most sites; Jekyll takes 30-60 seconds for 1,000 pages
• Learning Curve: Jekyll is gentler for beginners; Hugo requires understanding Go templates
• Deployment: Jekyll wins for GitHub Pages simplicity; Hugo requires GitHub Actions or third-party services
• Future-Proofing: Hugo receives more frequent feature updates; Jekyll focuses on stability

Migration: Moving between generators is possible but requires significant effort converting templates, front matter, and plugins. Choose carefully based on long-term needs.

For immediate blogging with minimal setup, Jekyll remains the best choice in 2026. For projects requiring performance at scale or advanced content features, Hugo’s speed and capabilities justify the steeper learning curve.

GatsbyJS is an open-source React-based, GraphQL powered static site generator. You can create blazingly fast websites in minutes using Gatsby, and many technical companies use it for their blogs.

Gatsby Starters are boilerplates that you, as a developer, can use to set up a new site with preconfigured tools and plugins instantly. You can modify and build on top of the starters to speed up your development process.

You might ask, why create your own starter? Why not just use an existing starter? There are a few reasons developers invest the time building a starter:

• To help other developers build a better site on Gatsby using unique features or designs.
• To showcase it in the official Gatsby Starter Library and gain recognition for your work.
• To promote your freelance services by creating a portfolio starter with your information. Every time someone uses your starter, they will see your portfolio.

Tutorial Overview

In this tutorial, I’ll show you how to build a Gatsby starter from scratch using MDX and Styled Components, the best CSS-in-JS tool. If you want to jump right into the code, check out the GitHub Repo here, and check out the deployed version here.

More specifically, here’s what I’ll cover in this tutorial:

• Prerequisites
• Setting Up Gatsby
• Using Styled Components with Gatsby
• Creating a Container Component
• Creating a Bio Component
• Creating an SEO Component
• Displaying Posts on Home Page
• Creating Pages from Data
• Creating a 404 Page
• Adding a Manifest to Your Gatsby Starter
• Adding a Sitemap
• Adding an RSS Feed
• Finishing the Starter

Prerequisites

Before we get started, you should have:

1. Knowledge of HTML, CSS, and JavaScript.
2. Basic knowledge of React, Gatsby, and GraphQL.
3. Node and NPM installed on your local dev machine.
4. Any code editor of your choice.
5. React Dev Tools (optional)

Setting Up Gatsby

{% raw %}
In this tutorial, you will use the Gatsby CLI tool to generate a Gatsby-powered site with minimal configurations quickly.

Run the following command in your terminal to create a Gatsby site with minimal configuration using Gatsby Hello World Starter.

gatsby new gatsby-starter-blog https://github.com/gatsbyjs/gatsby-starter-hello-world
cd gatsby-starter-blog
gatsby develop

You can read more about setting up your Gatsby development environment here.

gatsby-source-filesystem Plugin

The next step is to install the plugins you will use in this starter blog, the first of which is gatsby-source-filesystem. This plugin creates File nodes which point to the location of each file to the GraphQL query gets data from.

You can read more about sourcing from the file system here.

Run the following command in your project’s root directory.

npm install gatsby-source-filesystem

Now, update the gatsby-config.js file to use this plugin.

// gatsby-config.js
module.exports = {
  plugins: [
    {
    resolve: `gatsby-source-filesystem`,
    options: {
        name: `pages`,
        path: `${__dirname}/src/pages`,
    },
    },
    {
    resolve: `gatsby-source-filesystem`,
    options: {
        name: `posts`,
        path: `${__dirname}/src/posts`,
    },
    },
    {
    resolve: `gatsby-source-filesystem`,
    options: {
        name: `images`,
        path: `${__dirname}/src/images`,
    },
    },
  ],
};

In the above code, you have three instances of the gatsby-source-filesystem plugin for pages, posts, and images folder. All the JavaScript files like index.js reside in the pages directory, posts folder is where your articles are stored. The images folder is for any images or image resource you might need in your blog like your profile picture.

Now, create the posts and images folders inside the src directory. Run the following commands in the terminal.

cd src
mkdir posts
mkdir images
cd ..

gatsby-plugin-google-fonts Plugin

I like using Google Fonts as a free improvement over most operating systems’ standard font options. To use Google Fonts in Gatsby, install the gatsby-plugin-google-fonts plugin.

npm install gatsby-plugin-google-fonts

Update gatsby-config.js to use the gatsby-plugin-google-fonts plugin.

{
  resolve: `gatsby-plugin-google-fonts`,
  options: {
    fonts: ["Satisfy", "Montserrat", "JetBrains Mono"],
    display: "swap"
  }
}

Feel free to explore Google Fonts and import the fonts of your choice.

gatsby-plugin-sharp and gatsby-transformer-sharp Plugins

Optimizing images on your blog improves user experience by making response times faster. This in turn can help your blog’s ranking in search engines and makes your site more usable on mobile internet connections, so it’s important to optimize your images.

Run the following command to install the gatsby-plugin-sharp and the gatsby-transformer-sharp plugins that will help optimize the images in your starter.

npm install gatsby-plugin-sharp gatsby-transformer-sharp

gatsby-plugin-mdx Plugin

MDX is a variant of traditional markdown that lets you write JSX in your markdown files. With MDX you can style and customize your posts in the markdown file itself and can even load dynamic data in them.

Run the following command to install the gatsby-plugin-mdx.

npm install gatsby-plugin-mdx @mdx-js/mdx @mdx-js/react gatsby-remark-images

This plugin will allow you to create pages with .mdx and .md extensions in src/posts and process any Gatsby nodes with Markdown media types into MDX content.

Update gatsby-config.js to include the gatsby-plugin-mdx, gatsby-plugin-sharp and gatsby-transformer-sharp plugins.

// gatsby-config.js
module.exports = {
  plugins: [
    {
    resolve: `gatsby-source-filesystem`,
    options: {
        name: `pages`,
        path: `${__dirname}/src/pages`,
    },
    },
    {
    resolve: `gatsby-source-filesystem`,
    options: {
        name: `posts`,
        path: `${__dirname}/src/posts`,
    },
    },
    {
    resolve: `gatsby-source-filesystem`,
    options: {
        name: `images`,
        path: `${__dirname}/src/images`,
    },
    },
    {
    resolve: `gatsby-plugin-google-fonts`,
    options: {
        fonts: ["Satisfy", "Montserrat", "JetBrains Mono"],
        display: "swap",
    },
    },
    `gatsby-plugin-sharp`,
    `gatsby-transformer-sharp`,
    {
    resolve: `gatsby-plugin-mdx`,
    options: {
        extensions: [`.md`, `.mdx`],
        gatsbyRemarkPlugins: [
        {
            resolve: `gatsby-remark-images`,
            options: {
            maxWidth: 590,
            },
        },
        ],
    },
    },
  ],
};

Using Styled Components with Gatsby

Styled Components is an amazing CSS-in-JS tool that lets you write CSS in your JavaScript files. This makes it easy to manage all your styling without having any CSS files in your project.

There are many other benefits and advantages of CSS-in-JS like managing dead code elimination becomes easier with it, styles are scoped to a specific component. It also makes it easier to write unit tests. Many CSS-in-JS libraries also have built-in support for animations, source maps and caching.

Run the following command in the terminal to install the gatsby-plugin-styled-components plugin.

npm install gatsby-plugin-styled-components styled-components babel-plugin-styled-components

Update the gatsby-config.js file to include this plugin.

module.exports = {
  plugins: [
    // other plugins

    `gatsby-plugin-styled-components`,
  ],
};

Now create a global-styles.js file to add global styles and theme to the app. Global Styles as the name suggests are the styles that are scoped to the global level in your app. For example, if you define the font-size property as 3rem in global styles then the font size of all text will be changed to 3rem across your app.

A theme is an object or set of styles that you can define and access in your CSS-in-JS. For example, if you want to add dark mode to your app, you can define two nested objects in the theme object, one for light mode and another for dark mode. Each object will have properties like background color, font color, etc., and when the user clicks the dark mode button, it will toggle between the light and dark styles object.

You can read more about this here.

Run the following command in your terminal.

cd src
mkdir themes
cd themes
touch global-styles.js

Add the following code to the global-styles.js file.

// global-styles.js
import { createGlobalStyle } from "styled-components";

export const theme = {
  colors: {
    primary: "#363537;",
    primaryDark: "#313032",
    primaryDarker: "#2e2d2f",
    primaryDarkest: "#262527",
    primaryLight: "#3b3a3d",
    primaryLighter: "#3e3d3f",
    primaryLightest: "#464548",
  },
  fonts: "Montserrat, Verdana,sans,  serif",
  fontSizes: {
    small: "1em",
    medium: "1.5em",
    large: "2em",
  },
};

export const GlobalStyles = createGlobalStyle`
*, *:before, *:after {
    box-sizing: border-box;
    margin:0;
    padding:0;
  }

  html {
    scroll-behavior: smooth;
    font-family: ${(props) => props.theme.fonts};
    background-color:#f7f7f7;
    font-size: ${(props) => props.theme.fontSizes.medium};
    padding: 0 1rem;
  }

  h1,
  h2,
  h3,
  h4,
  h5,
  h6 {
    color: ${(props) => props.theme.colors.primaryDarkest};
    margin: 1rem 0;
  }
  h1 {
    font-size: 1.95rem;
    line-height: 2rem;
    font-weight: 400;
  }
  h2 {
    font-size: 1.5rem;
    line-height: 1.75rem;
    font-weight: 400;
  }
  h3 {
    font-size: 1.35rem;
    line-height: 1.625rem;
    font-weight: 400;
  }
  h4 {
    font-size: 1.15rem;
    line-height: 1.5rem;
    font-weight: 400;
  }

  h5 {
    font-size: 1.095rem;
    line-height: 1.375rem;
    font-weight: 700;
  }

  h6 {
    font-size: 1rem;
    line-height: 1.5rem;
    font-weight: 700;
  }
 `;

In the above code, you created a theme object with some basic CSS and used the createGlobalStyle function from styled-components to add global styles to the app.

To use the theme and global styles, you need to create a file named gatsby-browser.js in the project’s root directory. Run the following command in your project’s root directory.

touch gatsby-browser.js

Add the following code to the gatsby-browser.js file.

// gatsby-browser.js
import React from "react";
import { GlobalStyles, theme } from "./src/themes/global-styles";
import { ThemeProvider } from "styled-components";

export const wrapRootElement = ({ element }) => (
  <ThemeProvider theme={theme}>
    <GlobalStyles />
    {element}
  </ThemeProvider>
);

Here you use the wrapRootElement function from gatsby to wrap the entire root element with ThemeProvider wrapper component from styled-components, which provides a theme to all React components underneath itself via the context API.

You pass the theme object created in the global-styles.js file to the theme prop of the ThemeProvider component.

Then you pass the GlobalStyles component at the top of the React tree.

You can access the theme object attributes as props in any of the component like ${props => props.theme.fontSizes.medium};.

Start your development server by running the gatsby develop command and head over to http://localhost:8000/.

You will notice that the background-color, font, etc., of the app, has changed according to the CSS in the GlobalStyles component.

Creating a Container Component

Your Starter should have consistent styling and a common layout throughout the different pages or it will seem messy and result in bad user experience. In this section, you will create a Container component that will wrap your entire app with a navbar and a footer. The Container component is the common layout of your starter and contains other components such as a Footer component and a Navbar component.

Although it’s not a requirement for a Gatsby Starter to have such a Container component, you will find that by splitting code into different components, it becomes easier to manage and helps remove repeated code. For example, every page in your starter will have a footer, so instead of repeating the same code, make and use a separate Footer component in its place.

In the src directory, create a file named Container.js inside a folder named components by running the following command.

cd src
mkdir components
cd components
touch Container.js

Add the following code to Container.js.

// Container.js
import React from "react";
import styled from "styled-components";

const ContainerWrapper = styled.div`
  height: 100%;
  display: block;
  margin: auto;
  max-width: 640px;
`;
export const Container = ({ children }) => {
  return <ContainerWrapper>{children}</ContainerWrapper>;
};

This Container component defines the layout of your app.

Update the pages/index.js file to include the Container component like this.

// index.js
import React from "react";
import { Container } from "../components/Container";

export default function Home() {
  return <Container>Hello world!</Container>;
}

With your development server still running, navigate to http://localhost:8000/ to see your app with the new container.

Creating a Navbar Component

The next step is to create a navbar component and use it inside the Container component.

Run the following command inside the components directory to create the Nav.js file.

touch Nav.js

You will also need to install react-icons to add icons to your blog. This package includes some of the most popular icon libraries like Ant Design Icons, Bootstrap Icons, and more. Having different icons in your Starter can result in better user experience, and social media icons (Instagram, LinkedIn, Facebook) can help your readers connect with you on different platforms.

Install react-icons by running the following command.

npm install react-icons

Add the following code to Nav.js.

// Nav.js
import React from "react";
import { Link } from "gatsby";
import { FaRegMoon } from "react-icons/fa";
import styled from "styled-components";

const NavWrapper = styled.nav`
  font-size: 1.5rem;
  display: flex;
  justify-content: space-between;
  align-items: center;
  flex-direction: row;
  margin-top: 0.3rem 0.6rem;

  a {
    text-decoration: none;
    font-family: Satisfy;
    color: #6a5acd;
  }
  svg {
    font-size: 1rem;
    color: #4a4656;
    &:hover {
    color: #000;
    }
  }
  @media only screen and (max-width: 480px) {
    font-size: 1rem;
  }
`;
export const Nav = () => {
  return (
    <NavWrapper>
    {/* Replace with your Name */}
    <Link to="/">Ashutosh K Singh</Link>
    <FaRegMoon />
    </NavWrapper>
  );
};

In the above code, you use the Link component to add a link to the homepage, i.e., to the / page. Make sure to replace the text inside the Link component with your name. You can also use a logo instead of text.

Update the Container.js file to include this component like this.

// Container.js
import React from "react"
import styled from "styled-components"
import { Nav } from "./Nav"

const ContainerWrapper = styled.div`
  height: 100%;
  display: block;
  margin: auto;
  max-width: 640px;
`
export const Container = ({ children }) => {
  return (
    <ContainerWrapper>
    {" "}
    <Nav />
    {children}
    </ContainerWrapper>
  )
}

Head over to http://localhost:8000/ to see your app with the new navbar component and icon.

Creating a Footer Component

The next step is to create a Footer.js file to add a footer to the Container component. Run the following command inside the components directory to create the Footer.js file.

touch Footer.js

Add the following code to the Footer.js file.

import React from "react";
import {
  FaRegEnvelope,
  FaGithub,
  FaLinkedinIn,
  FaTwitter,
  FaFacebookF,
  FaInstagram,
  FaRss,
} from "react-icons/fa";
import styled from "styled-components";

const FooterWrapper = styled.footer`
  min-height: 12rem;
  justify-content: center;
  align-items: center;
  text-align: center;
  padding: 3rem 0;
  margin-bottom: 2rem;

  p {
    font-size: 0.8rem;
    font-weight: 300;
  }
  ul {
    text-align: center;
    li {
    display: inline-block;
    a {
        svg {
        color: #4a4656;
        &:hover {
            color: #8a2be2;
        }
        }
    }
    }
    li:not(:last-child) {
    margin-right: 40px;
    }
  }
`;
export const Footer = () => {
  const config = {
    email: `admin@ashusingh.me`,
    githubUsername: `lelouchB`,
    twitterUsername: `noharashutosh`,
    instagramUsername: `singhashutoshk`,
    siteUrl: `http://localhost:8000/`,
  };
  const linkedinUrl = `https://www.linkedin.com/in/ashutosh-singh-550a6a178`;
  const instagramUrl = `https://www.instagram.com/${config.instagramUsername}`;
  const mailToUrl = `mailto:${config.email}?Subject=Hello`;
  const twitterUrl = `https://twitter.com/${config.twitterUsername}`;
  const facebookURL = `https://facebook.com/`;
  const githubUrl = `https://github.com/${config.githubUsername}`;
  const rssFeed = `${config.siteUrl}/rss.xml`;

  return (
    <FooterWrapper>
    <ul>
        <li>
        <a href={mailToUrl} target="_top" title="Email">
            <FaRegEnvelope />
        </a>
        </li>

        <li>
        <a
            href={githubUrl}
            target="_blank"
            title="Contact Ashutosh at GitHub"
            rel="noopener noreferrer"
        >
            <FaGithub />
        </a>
        </li>
        <li>
        <a
            href={linkedinUrl}
            target="_blank"
            title="Contact Ashutosh on Linkedin"
            rel="noopener noreferrer"
        >
            <FaLinkedinIn />
        </a>
        </li>
        <li>
        <a
            href={twitterUrl}
            target="_blank"
            title="Contact Ashutosh on Twitter"
            rel="noopener noreferrer"
        >
            <FaTwitter />
        </a>
        </li>
        <li>
        <a
            href={facebookURL}
            target="_blank"
            title="Contact Ashutosh on Facebook"
            rel="noopener noreferrer"
        >
            <FaFacebookF />
        </a>
        </li>

        <li>
        <a
            href={instagramUrl}
            target="_blank"
            title="Contact Ashutosh on Instagram"
            rel="noopener noreferrer"
        >
            <FaInstagram />
        </a>
        </li>
        <li>
        <a
            href={rssFeed}
            target="_blank"
            title="RSS Feed"
            rel="noopener noreferrer"
        >
            <FaRss />
        </a>
        </li>
    </ul>
    <p>
        Handcrafted with{" "}
        <span role="img" aria-label="white_heart">
        🤍
        </span>{" "}
        by me
    </p>
    </FooterWrapper>
  );
};

The code above first imports all the different icons from react-icons and then creates an unordered list with all the icons. Inside the <li> tag, it uses <a>s to add different social links like Facebook, Instagram, etc.

One thing you may notice is the rssFeed, which points to http://localhost:8000/rss.xml. You can ignore this for now, but this is the route where you will create the RSS feed for your blog later in this tutorial.

Remember to replace the above links with your social handles and URLs.

Update the Container.js file to include this Footer component like this.

// Container.js
import React from "react";
import styled from "styled-components";
import { Nav } from "./Nav";
import { Footer } from "./Footer";

const ContainerWrapper = styled.div`
  height: 100%;
  display: block;
  margin: auto;
  max-width: 640px;
`;
export const Container = ({ children }) => {
  return (
    <ContainerWrapper>
    <Nav />
    {children}
    <Footer />
    </ContainerWrapper>
  );
};

Head over to http://localhost:8000/. Here is how your app will look now.

Creating a Bio Component

In this section, you will create a Bio component with an image and some information about the author. Having a bio will help readers connect with you on a more personal level. You can tell them about yourself, why you write articles, and where they can find your other work. A good bio section helps build a sense of trust between content creators like bloggers and the readers.

In this section, I’ll refer to an image named myAvatar.png inside the src/images directory. You can either replace this with your avatar or download the image used in this tutorial from here.

As you may remember, you installed gatsby-plugin-sharp and gatsby-transformer-sharp plugins in the above sections to optimize your images. Now you need to install the gatsby-image component to make use of those plugins.

Run the following command in your project’s root directory to install gatsby-image.

npm install gatsby-image

Run the following command inside the components folder to create a Bio.js file.

touch Bio.js

Add the following code to Bio.js.

// Bio.js
import React from "react";
import styled from "styled-components";
import Img from "gatsby-image";
import { useStaticQuery, graphql } from "gatsby";
import { GiDove } from "react-icons/gi";

const BioWrapper = styled.div`
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  text-align: center;
  margin-top: 0.4rem;
  svg {
    color: purple;
    font-size: 2rem;
  }
  h2 {
    margin-bottom: 0.5rem;
  }
  h3 {
    margin: 0.8rem 0;
    font-weight: 600;
  }
`;
export const Bio = () => {
  const data = useStaticQuery(graphql`
    query {
    imageSharp(fixed: { originalName: { eq: "myAvatar.png" } }) {
        id
        fixed(width: 250, height: 250) {
        ...GatsbyImageSharpFixed
        }
    }
    }
  `);
  return (
    <BioWrapper>
    <Img
        fixed={data.imageSharp.fixed}
        style={{ borderRadius: "50%", left: "0", top: "0" }}
        alt="My Avatar"
    />
    <h2>
        Hey Stranger <GiDove />
    </h2>

    <br />
    <p>
        My name is <b>Ashutosh</b>! I'm a JavaScript Developer & Technical
        Writer. I develop awesome stuff with JavaScript and love to write about
        them.
    </p>
    <h3>Latest Posts</h3>
    </BioWrapper>
  );
};

In the above code, you added a Hey Stranger message and a short bio. Make sure to update these paragraphs with your information.

Take a look at how you are fetching the myAvatar.png image.

 const data = useStaticQuery(graphql`
    query {
    imageSharp(fixed: { originalName: { eq: "myAvatar.png" } }) {
        id
        fixed(width: 250, height: 250) {
        ...GatsbyImageSharpFixed
        }
    }
    }
  `)

Here you are using the useStaticQuery hook and graphql imported from gatsby. useStaticQuery hook does not accept variables (hence the name “static”), and is used here to find with originalName: { eq: "myAvatar.png" }. Replace myAvatar.png with your image name. You can read more about ...GatsbyImageSharpFixed here.

You then pass this data.imageSharp.fixed to the Img component from gatsby-image like this.

<Img
  fixed={data.imageSharp.fixed}
  style={{ borderRadius: "50%", left: "0", top: "0" }}
  alt="Avatar"
/>

Update the pages/index.js file to include this Bio component.

// index.js
import React from "react";
import { Container } from "../components/Container";
import { Bio } from "../components/Bio";

export default function Home() {
  return (
    <Container>
    <Bio />
    </Container>
  );
}

Restart your development server and head over to http://localhost:8000/ to see the bio component on your blog’s home page:

Creating an SEO Component

SEO stands for Search Engine Optimization, it means that you are optimizing your website to rank better in the results on search engines like Google. There are many factors that affect your site rank on Google or other search engines like the web crawl accessibility, optimized keywords on each page, fast loading speeds, good user experience, and more.

Gatsby can help your site rank and perform better in search engines. Because Gatsby pages are server-rendered, the crawlers are easily able to access your site. You can also add meta information so the search engines can understand your content and know where to show your pages in search results. You can read more about SEO for Gatsby here.

In this section, you will create an SEO component that adds basic meta-tags like the title, description, or lang, etc., of the page in the <head> element.

Run the following command to install the gatsby-plugin-react-helmet plugin and the react-helmet library.

npm install gatsby-plugin-react-helmet react-helmet

Stop your development server and update the gatsby-config.js. Make sure to update the fields with your social handles and information.

// gatsby-config.js
module.exports = {
  siteMetadata: {
    title: `Gatsby Starter Blog`,
    author: {
    name: `Ashutosh Kumar Singh`,
    },
    description: `Gatsby Starter Blog built with MDX and Styled Components.`,
    image: `/cover.png`,
    siteUrl: `https://lelouchb-gatsby-starter-blog-demo.netlify.app/`,
    social: {
    twitter: `@noharashutosh`,
    },
  },
  plugins: [
    // plugins
    `gatsby-plugin-react-helmet`,
  ],
};

One thing that you might notice is the cover.png image in the image field. This image will be used in the social card preview of the site. This image is stored inside the static directory. You can either use a customized image or download the cover image used in this tutorial from here.

Head over to localhost:8000/__graphql and paste the following query in the left tab.

{
  site {
    siteMetadata {
    title
    description
    social {
        twitter
    }
    author {
        name
    }
    image
    siteUrl
    }
  }
}

Hit the run button. You will see an output similar to this.

{
  "data": {
    "site": {
    "siteMetadata": {
        "title": "Gatsby Starter Blog",
        "description": "Gatsby Starter Blog built with MDX and Styled Components.",
        "social": {
        "twitter": "@noharashutosh"
        },
        "author": {
        "name": "Ashutosh Kumar Singh"
        },
        "image": "/cover.png",
        "siteUrl": "https://lelouchb-gatsby-starter-blog.netlify.app"
    }
    }
  },
  "extensions": {}
}

This is the query that you will use with the useStaticQuery hook in the Seo.js file.

Create a file named Seo.js under the components directory.

cd components
touch Seo.js

Add the following code to the Seo.js file.

// Seo.js
import React from "react";
import PropTypes from "prop-types";
import { Helmet } from "react-helmet";
import { useStaticQuery, graphql } from "gatsby";

export const SEO = ({ title, lang, meta, description }) => {
  const { site } = useStaticQuery(
    graphql`
    query {
        site {
        siteMetadata {
            title
            description
            social {
            twitter
            }
            author {
            name
            }
            image
            siteUrl
        }
        }
    }
    `
  );

  const metaDescription = description || site.siteMetadata.description;
  const defaultTitle = site.siteMetadata?.title;
  const siteUrl = site.siteMetadata?.siteUrl;
  const image = site.siteMetadata?.image;

  return (
    <Helmet
    htmlAttributes={{
        lang,
    }}
    title={title}
    titleTemplate={defaultTitle ? `%s | ${defaultTitle}` : null}
    meta={[
        {
        name: `title`,
        content: title,
        },
        {
        name: `description`,
        content: metaDescription,
        },
        {
        property: `og:title`,
        content: title,
        },
        {
        property: `og:description`,
        content: metaDescription,
        },
        { property: "og:locale", content: lang },
        {
        property: "og:site_name",
        content: "Gatsby Starter Blog",
        },
        {
        property: `og:type`,
        content: `website`,
        },
        {
        property: `og:image`,
        content: `${siteUrl}${image}`,
        },
        {
        name: `twitter:card`,
        content: `summary_large_image`,
        },
        {
        name: `twitter:creator`,
        content: site.siteMetadata?.social?.twitter || ``,
        },
        {
        name: `twitter:title`,
        content: title,
        },
        {
        name: `twitter:description`,
        content: metaDescription,
        },
        {
        name: `twitter:image`,
        content: `${siteUrl}${image}`,
        },
    ].concat(meta)}
    />
  );
};

SEO.defaultProps = {
  lang: `en`,
  meta: [],
  description: ``,
};

SEO.propTypes = {
  description: PropTypes.string,
  lang: PropTypes.string,
  meta: PropTypes.arrayOf(PropTypes.object),
  title: PropTypes.string.isRequired,
};

You will not notice any change in the app since you have created the SEO component, but have not used it in any of the pages yet. You’ll see how to incorporate your SEO component in the next section.

Displaying Posts on Home Page

In this section, you will create dummy posts for the starter blog, query them in the pages/index.js file, and show them on the homepage.

For this tutorial, I chose to create a separate folder for each post. This folder includes the markdown file and the accompanying images, videos, etc. This is not strictly necessary, but having a single folder for all posts can become a little hard to manage as your blog scales and you have more images and media assets to incorporate.

Inside the src/posts directory, create a folder named my-first-post and inside it create a file named index.mdx. Add sample data to index.mdx from here.

The content inside --- is the frontmatter of the post and includes title, slug, date, tags, and excerpt of the post. You can also include other fields like keywords, cover_image, author, etc., in the frontmatter. You can refer to Gatsby documentation for the GraphQL query to fetch data from this post.

But first, you need to create a PostContainer component that will take all the fetched data as props and show them in a more styled manner. Run the following code to create a PostContainer component under the components directory.

cd src
cd components
touch PostContainer.js

Add the following code to the PostContainer.js file.

import React from "react";
import styled from "styled-components";
import { Link } from "gatsby";

const PostContainerWrapper = styled.div`
  margin-top: 1rem;
  padding: 1rem;
  display: flex;
  flex-direction: column;
  align-items: center;
  background-color: #fafafa;
  box-shadow: 2px 3px 4px 6px #ccc;
  border-radius:10px;
  text-align: center;

  h2 {
    font-size: 1.6rem;
    margin: 0.75rem 0;
    font-weight: 500;
    color: {$props=>props.theme.colors.primaryDarkest};
  }
  p {
    font-size: 0.8rem;
  }
  span {
    font-size: 0.75rem;
    margin: 0.2rem 0;
    font-weight: 400;
    color: #949494;
  }
`;

const ButtonWrapper = styled((props) => <Link {...props} />)`
  padding: 0.45rem 0.5rem;
  margin-top: 0.4rem;
  font-size: 0.9rem;
  background-color: #6a5acd;
  border-radius: 0.5rem;
  font-weight: 600;
  color: white;
  text-decoration: none;
`;

export const PostContainer = ({ title, date, excerpt, slug }) => {
  return (
    <PostContainerWrapper>
    <h2>{title}</h2>
    <span>{date}</span>
    <p>{excerpt}</p>
    <ButtonWrapper to={`posts/${slug}`}>Read More</ButtonWrapper>
    </PostContainerWrapper>
  );
};

In the above code, you passed title, date, excerpt, slug to the PostContainer component as props. You will notice that theRead More link does not work since you have not yet created the dynamic route it points to.

Update the index.js file to show the posts.

import React from "react";
import { graphql } from "gatsby";
import { Container } from "../components/Container";
import { SEO } from "../components/Seo";
import { PostContainer } from "../components/PostContainer";
import { Bio } from "../components/Bio";

export default function Home({ data }) {
  const posts = data.allMdx.edges;
  if (posts.length === 0) {
    return (
    <Container>
        <SEO title="All posts" />
        <Bio />
        <p>
        No blog posts found. Add markdown posts to "src/posts" (or the
        directory you specified for the "gatsby-source-filesystem" plugin in
        gatsby-config.js).
        </p>
    </Container>
    );
  }
  return (
    <Container>
    <SEO title="Gatsby Starter Blog" />
    <Bio />

    {posts.map((post) => (
        <PostContainer
        key={post.node.id}
        date={post.node.frontmatter.date}
        title={post.node.frontmatter.title}
        slug={post.node.frontmatter.slug}
        excerpt={post.node.frontmatter.excerpt}
        />
    ))}
    </Container>
  );
}

export const pageQuery = graphql`
  query AllPostsQuery {
    allMdx(sort: { fields: frontmatter___date, order: DESC }) {
    edges {
        node {
        frontmatter {
            slug
            title
            excerpt
            date(formatString: "MMMM DD, YYYY")
        }
        id
        }
    }
    }
  }
`;

The above code uses the GraphQL query discussed above to fetch posts data and pass them in the Home component as data prop. Then it checks if there are any posts present using an if statement and posts.length === 0. If posts.length > 0 then you use the .map() method on the posts array and pass the data to the PostContainer component.

Navigate to http://localhost:8000/ in the browser to see a snippet of your first post on the homepage.

Create another post inside the posts directory using your command line.

cd src
cd posts
mkdir markdown-syntax-guide
cd markdown-syntax-guide
touch index.mdx

Copy the code from GitHub to create another post named markdown-syntax-guide.

The above markdown file uses an image named mac.jpg stored inside the markdown-syntax-guide folder. You can download this image from here.

After saving this markdown file, the homepage will automatically update to show this post.

Creating Pages from Data

Next, you will create individual pages for each of your posts.

Stop your development server and run the following command to create a gatsby-node.js file inside your project’s root directory.

touch gatsby-node.js

This file is used to create pages dynamically, add nodes in GraphQL, or respond to events during the build lifecycle. You can read more about it here.

Add the following code in gatsby-node.js.

// gatsby-node.js
const path = require(`path`);

exports.createPages = async function ({ actions, graphql }) {
  const { createPage } = actions;
  const { data } = await graphql(`
    {
    allMdx(sort: { fields: frontmatter___date, order: DESC }) {
        edges {
        node {
            frontmatter {
            slug
            }
            id
        }
        }
    }
    }
  `);

  data.allMdx.edges.forEach((post) => {
    const slug = post.node.frontmatter.slug;

    createPage({
    path: `posts/${slug}`,
    component: path.resolve(`./src/templates/blog-post.js`),
    context: { id: post.node.id },
    });
  });
};

The above code uses a template file named blog-post.js inside the src/templates directory to create the posts’ page.

Run the following command to create the template blog-post.js file.

cd src
mkdir templates
cd templates
touch blog-post.js

Add the following code to blog-post.js.

// blog-post.js
import React from "react";
import { graphql } from "gatsby";
import { MDXRenderer } from "gatsby-plugin-mdx";
import { Container } from "../components/Container";
import { SEO } from "../components/Seo";
import styled from "styled-components";

const PostWrapper = styled.div`
  padding: 1rem;
  span {
    font-weight: 500;
  }

  p {
    font-size: 1.125 rem;
    font-weight: 400;
    color: #2e2d2f;
    margin: 0.625rem 0;
  }

  a {
    color: blue;
    text-decoration: underline;
  }
  strong {
    font-weight: 700;
  }
  em: {
    font-style: italic;
  }
  del {
    text-decoration: line-through;
  }
  blockquote p {
    font-style: italic;
    font-size: 1.125rem;
    line-height: 1.75rem;
    text-align: center;
    max-width: 36rem;
    margin: 3rem auto;
  }
  ul,
  ol {
    color: #2e2d2f;
    margin: 1rem 0 1rem 2rem;
  }

  li {
    margin: 0.25rem 0;
  }

  table {
    width: 100%;
    border-spacing: 0.25rem;
    border-collapse: collapse;
    font-size: 1rem;
  }
  table,
  th,
  td {
    border: 1px solid #000;
  }
  th {
    font-weight: 700;
  }
  td {
    padding: 0.15rem;
    text-align: left;
  }
`;

const TitleWrapper = styled.div`
  text-align: left;
  font-size: 2.1rem;
  font-family: JetBrains Mono;
  font-weight: 500;
  background: #0f2027;
  background: -webkit-linear-gradient(to right, #2c5364, #203a43, #0f2027);
  background: linear-gradient(to right, #2c5364, #203a43, #0f2027);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
`;

const Title = ({ title }) => {
  return <TitleWrapper>{title}</TitleWrapper>;
};

const DateWrapper = styled.span`
  text-align: left;
  font-size: 0.6rem;
  font-weight: 500;
`;

const Date = ({ date }) => {
  return <DateWrapper>{date}</DateWrapper>;
};
const TimeToReadWrapper = styled.span`
  text-align: left;
  margin-left: 1rem;
  font-size: 0.6rem;
  font-weight: 500;
`;

const TimeToRead = ({ timeToRead }) => {
  return (
    <TimeToReadWrapper>
    {timeToRead} {timeToRead > 1 ? `MINUTES` : `MINUTE`} TO READ
    </TimeToReadWrapper>
  );
};

const TagsWrapper = styled.div`
  display: flex;
  flex-direction: row;
  max-width: 480px;
  font-size: 0.6rem;
  font-weight: 600;
  color: #ff0099;
`;
const TagWrapper = styled.span`
  padding-right: 0.3rem;
  cursor: pointer;
`;

const Tags = ({ tags }) => {
  return (
    <TagsWrapper>
    {tags.map((tag) => (
        <TagWrapper key={tag}>{tag}</TagWrapper>
    ))}
    </TagsWrapper>
  );
};

const singlePost = ({ data }) => {
  return (
    <Container>
    <SEO
        title={data.mdx.frontmatter.title}
        description={data.mdx.frontmatter.excerpt}
    />
    <Title title={data.mdx.frontmatter.title} />
    <Date date={data.mdx.frontmatter.date} />
    <TimeToRead timeToRead={data.mdx.timeToRead} />
    <Tags tags={data.mdx.frontmatter.tags} />
    <PostWrapper>
        <MDXRenderer>{data.mdx.body}</MDXRenderer>
    </PostWrapper>
    </Container>
  );
};

export default singlePost;

export const pageQuery = graphql`
  query SinglePostQuery($id: String!) {
    mdx(id: { eq: $id }) {
    body
    frontmatter {
        date(formatString: "MMMM DD, YYYY")
        excerpt
        slug
        title
        tags
    }
    timeToRead
    }
  }
`;

Restart your development server and head over to http://localhost:8000/ and click on Read More on any post.

Alternatively, head over to http://localhost:8000/posts/markdown-syntax-guide for the post titled Markdown Syntax Guide.

Creating a 404 Page

A 404 page is the page that users see when they try to visit a non-existing URL on your website or when the server cannot find the requested URL. A good 404 page contributes to a better user experience by reducing bounce rate and maintains consistent branding and layout throughout the website.

It can show users that the URL they are trying to access doesn’t exist and redirect them somewhere else (like the home page), or it can show a few popular blog posts to help visitors find something else they might like. Gatsby comes with a prebuilt 404 page for non-existing routes, but it’s probably a good idea to add a custom 404 page to your blog.

Run the following command to create 404.js inside the src/pages directory.

cd src/pages
touch 404.js

Add the following code to the 404.js file.

// 404.js
import React from "react";
import { Container } from "../components/Container";
import { SEO } from "../components/Seo";

const NotFound = () => {
  return (
    <Container>
    <SEO title="404 Not Found" />
    <h1>NOT FOUND</h1>
    <p>You just hit a route that doesn&#39;t exist...</p>
    </Container>
  );
};

export default NotFound;

The above code uses the Container component to create a 404 page with a simple text that this route doesn’t exist. Head over to http://localhost:8000/404/ to see your new 404 page in action.

Adding a Manifest to Your Gatsby Starter

A Progressive Web Application enhances user experience based on the browser capabilities, makes your website installable as an app on mobile devices, supports caching and offline usage. A PWA also adds support for push notifications and has access to multiple native APIs such as camera, geo location, payments, etc.

Gatsby’s manifest plugin configures Gatsby to create a manifest.webmanifest file on every site build. Run the following command to install the gatsby-plugin-manifest plugin.

npm install gatsby-plugin-manifest

Stop your development server and update the gatsby-config.js file to include the gatsby-plugin-manifest plugin like this.

{
  resolve: `gatsby-plugin-manifest`,
  options: {
    name: `Gatsby Starter Blog`,
    short_name: `Gatsby`,
    start_url: `/`,
    lang: `en`,
    background_color: `#f7f0eb`,
    theme_color: `purple`,
    display: `standalone`,
    icon: `src/images/myAvatar.png`,
    icon_options: {
        purpose: `any maskable`,
        },
  },
},

Make sure to update the above fields with your blog data and color scheme. myAvatar.png is an image inside the src/images folder, so you can replace this with a photo of your choice.

Restart your development server by running the gatsby develop command in the terminal. Head over to http://localhost:8000/manifest.webmanifest where you will see a manifest file like this.

{
  "name": "Gatsby Starter Blog",
  "short_name": "Gatsby",
  "start_url": "/",
  "lang": "en",
  "background_color": "#f7f0eb",
  "theme_color": "purple",
  "display": "standalone",
  "cacheDigest": "d6541ebfd3ce17cfc7741d27bb585271",
  "icons": [
    {
    "purpose": "any maskable",
    "src": "icons/icon-48x48.png?v=d6541ebfd3ce17cfc7741d27bb585271",
    "sizes": "48x48",
    "type": "image/png"
    },
    {
    "purpose": "any maskable",
    "src": "icons/icon-72x72.png?v=d6541ebfd3ce17cfc7741d27bb585271",
    "sizes": "72x72",
    "type": "image/png"
    },
    {
    "purpose": "any maskable",
    "src": "icons/icon-96x96.png?v=d6541ebfd3ce17cfc7741d27bb585271",
    "sizes": "96x96",
    "type": "image/png"
    },
    {
    "purpose": "any maskable",
    "src": "icons/icon-144x144.png?v=d6541ebfd3ce17cfc7741d27bb585271",
    "sizes": "144x144",
    "type": "image/png"
    },
    {
    "purpose": "any maskable",
    "src": "icons/icon-192x192.png?v=d6541ebfd3ce17cfc7741d27bb585271",
    "sizes": "192x192",
    "type": "image/png"
    },
    {
    "purpose": "any maskable",
    "src": "icons/icon-256x256.png?v=d6541ebfd3ce17cfc7741d27bb585271",
    "sizes": "256x256",
    "type": "image/png"
    },
    {
    "purpose": "any maskable",
    "src": "icons/icon-384x384.png?v=d6541ebfd3ce17cfc7741d27bb585271",
    "sizes": "384x384",
    "type": "image/png"
    },
    {
    "purpose": "any maskable",
    "src": "icons/icon-512x512.png?v=d6541ebfd3ce17cfc7741d27bb585271",
    "sizes": "512x512",
    "type": "image/png"
    }
  ]
}

Now your Gatsby starter will function as a progressive web app, and users will be able to save it to their device’s home screen. You can also enable offline mode, push notifications, or any of the other features PWAs offer.

Adding a Sitemap

A sitemap is an XML file that lists a website’s essential pages, making sure search engines (such as Google) can find and crawl them all. In this section, I’ll show you how to add a sitemap to your Gatsby starter.

Stop your development server and install the gatsby-plugin-sitemap plugin by running the following command.

npm install gatsby-plugin-sitemap

Update gatsby-config.js to include this gatsby-plugin-sitemap plugin.

// gatsby-config.js
module.exports = {
  siteMetadata: {
    // siteMetadata
  },
  plugins: [
    // plugins
    {
    resolve: `gatsby-plugin-sitemap`,
    options: {
        output: `/sitemap.xml`,
        query: `
            {
            site {
                siteMetadata {
                siteUrl
                }
            }

            allSitePage {
                nodes {
                path
                }
            }
        }
        `,
        resolveSiteUrl: ({ site, allSitePage }) => {
        return site.siteMetadata.siteUrl;
        },
        serialize: ({ site, allSitePage }) =>
        allSitePage.nodes.map((node) => {
            return {
            url: `${site.siteMetadata.siteUrl}${node.path}`,
            changefreq: `daily`,
            priority: 0.7,
            };
        }),
    },
    },
  ],
};

The above GraphQL query fetches all the metadata of your blog as well all the existing routes. If you run this query in the GraphiQL playground, you will see an output similar to this.

{
  "data": {
    "site": {
    "siteMetadata": {
        "siteUrl": "https://lelouchb-gatsby-starter-blog.netlify.app"
    }
    },
    "allSitePage": {
    "nodes": [
        {
        "path": "/posts/markdown-syntax-guide"
        },
        {
        "path": "/posts/my-first-post"
        },
        {
        "path": "/dev-404-page/"
        },
        {
        "path": "/404/"
        },
        {
        "path": "/"
        },
        {
        "path": "/404.html"
        }
    ]
    }
  },
  "extensions": {}
}

You can test this sitemap by running the following command in the project’s root directory to create and serve your production build.

gatsby build && gatsby serve

Head over to http://localhost:9000/sitemap.xml

Adding an RSS Feed

Let’s say that I am an avid reader of your blog and I want to be notified of every new article that you publish so one way would be to visit your blog everyday and manually check for new articles. This task is tedious even for one blog but what if I want to be notified of many blog websites, manually checking is out of the box.

This is where the RSS feed comes to save the day, readers can use a RSS feed reader like feedly, Miniflux, RSS Owl, etc. and subscribe to your RSS feeds and be updated with latest articles.

Here is an example of someone subscribing to this starter blog RSS feed.

Earlier in this tutorial, you added an RSS feed icon in the footer that points to the /rss.xml route that didn’t exist yet. To create the RSS feed, you will use the gatsby-plugin-feed plugin.

npm install gatsby-plugin-feed

Stop your development server and update the gatsby-config.js file to include the gatsby-plugin-feed plugin.

{
  resolve: `gatsby-plugin-feed`,
  options: {
    query: `
    {
        site {
        siteMetadata {
            title
            description
            siteUrl
            site_url: siteUrl
        }
        }
    }
    `,
    feeds: [
    {
        serialize: ({ query: { site, allMdx } }) => {
        return allMdx.edges.map(edge => {
            return Object.assign({}, edge.node.frontmatter, {
            description: edge.node.excerpt,
            date: edge.node.frontmatter.date,
            url:
                site.siteMetadata.siteUrl +
                `/posts/` +
                edge.node.frontmatter.slug,
            guid:
                site.siteMetadata.siteUrl +
                `/posts/` +
                edge.node.frontmatter.slug,
            custom_elements: [{ "content:encoded": edge.node.html }],
            })
        })
        },
        query: `
        {
            allMdx(
            sort: { order: DESC, fields: [frontmatter___date] },
            ) {
            edges {
                node {
                excerpt
                html
                frontmatter {
                    title
                    date
                    slug

                }
                }
            }
            }
        }
        `,
        output: "/rss.xml",
        title: "Gatsyby Starter Blog RSS Feed",
    },
    ],
  },
},

{% endraw %}

There are two GraphQL queries in the above code: one for the site metadata and the other for all the posts. Like gatsby-plugin-sitemap, you will need to create a production build to see this plugin in action.

gatsby build && gatsby serve

Head over to http://localhost:9000/rss.xml, to see how the RSS feed will look.

Make sure to update the siteUrl in the gatsby-config.js file before deploying your blog so that the RSS feed’s URL is correct.

Finishing the Starter

At this point, you have created a working Gatsby blog, but you still have one more step to make it a shareable Gatsby starter. According to official Gatsby documentation, a starter should have a few specific files to work properly.

First, add a README.md to your project. This should contain a screenshot of the starter and a thorough explanation for users to configure and customize it.

Next, add a License to your project. BSD Zero Clause is generally preferred for Gatsby starters.

Finally, update the package.json file to include the license, description, author name, version, etc. You can see this starter’s package.json here.

Now you can submit your starter to the official Gatsby registry or simply share your starter with other developers on GitHub.

Summary

In this tutorial, you learned how to build a Gatsby starter from scratch using MDX, Styled Components, and various Gatsby plugins. This starter included blog posts, an author bio, search engine optimization plugins, an RSS feed, and more. Using this starter, other developers will be able to build their own Gatsby projects much faster.

You can explore the source code of this project on GitHub, or if you want to use the starter created here, run the following in your terminal.

gatsby new my-gatsby-blog https://github.com/lelouchB/gatsby-starter-blog

If you’re inspired to add features yourself, please do share and tag me – I’d love to hear about them!

Lately, developers are adopting static site generators like Hugo to quickly deliver content to their audience. Frameworks like these cut down on issues that pop up with scalability, version control, managing dependencies, and performance.

Hugo in particular offers tons of features right out of the box for creating fast, modern, and secure static websites. It’s written in Go, a powerful server-side scripting language, and offers a clean workflow for creating landing pages, portfolios, documentation, or blogs without a lot of extra layers of complexity.

Hugo also has plenty of themes ready to go right away, but a prebuilt theme probably isn’t going to match your brand’s vision. Most likely, you’re going to want a custom theme, something that affords you fine-grained control over things like color schemes, typography, and UI components.

In this article, I’ll walk you through how to quickly customize your Hugo site for your desired brand and aesthetic by building your own theme.

Table of Contents

• How to Create a Multi-author Hugo Blog Theme
  • Spinning Up a Hugo Site
  • Creating Your First Hugo Theme
  • Creating and Styling the Navigation Bar
  • Adding, Organizing, and Listing Blog Posts
  • Creating a Blog Post Template
  • Adding Support for Multiple Authors
  • Implementing Pagination in Hugo
  • Creating a Category Page with Taxonomies
  • SEO Optimization for Hugo Themes
• Next Steps and Advanced Customization

How to Create a Multi-author Hugo Blog Theme

Specifically, I’ll demonstrate how to create a multi-author blog theme in Hugo. I’ll cover paginating multiple blog posts, adding tags or categories, setting up support for multiple authors, and adding some SEO considerations to give your site more presence on the web.

Spinning Up a Site

Once you have Hugo installed (refer to the complete installation guide here) and a modern code editor (like VS Code), you’re ready to begin.

In a directory of your choice, create a new Hugo site by running the following command:

{% raw %}

hugo new site multiauthor-blog-site

Once a new Hugo project is created for you, navigate into the directory.

cd multiauthor-blog-site

Open the project in your editor and run the following command to spin a development server where you can see your changes live:

hugo server

Creating Your First Hugo Theme

With your brand-new site up and running, it’s time to start customizing the canvas.

Create a new theme inside the root directory by running hugo new theme blog-theme. This generates a folder called blog-themes inside the themes directory containing a bunch of files and folders. You’ll mostly be working with two directories: /blog-theme/layout, where all your HTML files will be present, and /blog-theme/static for static assets like images, CSS styles, and custom JavaScript.

It’s time to tell Hugo that you’ll be using this new theme for your site. Usually, those details go inside a configurational file config.toml in the root directory. Add a key theme with a value of your theme’s name (ie, blog-theme) as shown:

baseURL = "http://example.org/"
languageCode = "en-us"
title = "My New Hugo Site"
theme = "blog-theme"

Inside the baseof.html file (theme/blog-theme/layouts/default/baseof.html), add the following markup:

<!DOCTYPE html>
<html lang="{{ .Site.LanguageCode }}">
    {{- partial "head.html" . -}}
    <body>
        {{- partial "header.html" . -}}
        <main>
        {{- block "main" . }}{{- end }}
        </main>
        {{- partial "footer.html" . -}}
    </body>
</html>

The previous code creates some semantic elements for your site and references a site variable from your config.toml file in Hugo’s default templating language Go. If you look inside your /theme/blog-theme/layouts/partials folder, you’ll find a head.html file containing all the markup for your site’s <head> tag. Similarly, you can find a partial footer.html file to render a footer on your site.

The rest of the content of your site should go inside the <main> tags.

Add the following lines inside /theme/blog-theme/layouts/index.html to tell Hugo to insert the page content between the <main> tags in the baseof.html file:

{{ define "main" }}
{{ .Content }}
{{ end }}

Creating and Styling the Navigation Bar

The navigation bar allows users to easily visit different sections of your site.

Inside /theme/blog-theme/layouts/partials, you can find a header.html that acts as the default header for your site. Put all the HTML for the navbar inside this file. Hugo will automatically render it on your site.

<header>
    <nav class="navbar" role="navigation">
        <div class="navbar__left">
            <a href="/"><strong>blogsite.com</strong></a>
        </div>
        <div class="navbar__right">
            <a href="/blog">Blogs</a>
            <a href="/categories">Categories</a>
        </div>
    </nav>
</header>

The / link is to direct the user to your site’s homepage. You can leave the remaining links as it is for the moment.

Your navbar could look better, so let’s walk through how to add custom CSS styling to your theme. The static folder inside your theme holds all the static content related to your theme, including custom styles for your templates. So all stylesheets pertaining to your theme go inside the /theme/blog-theme/static/css folder.

Create a file called style.css and reference it inside your theme’s head.html file (/blog-theme/layouts/partials/head.html) as shown:

<link rel="stylesheet" href="/css/style.css" type="text/css" media="all" />

Hugo will push all your styles from this file onto your HTML pages.

You can create multiple stylesheets to break down your styles into logical modules. For brevity’s sake, let’s keep all the styles for this project inside style.css only.

body {
    background-color: #fcfcfc;
    color: #333;
    font-size: 125%;
    line-height: 1.5;
    margin: 0 auto;
    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
  }
  .content {
    margin-bottom: 2rem;
  }

 .navbar{
   display: flex;
   align-items: center;
   justify-content: space-between;
   height: 25px;
   background: gainsboro;
   padding: 10px;
 }
 .navbar__right{
   display: flex;
 }
  a{
    text-decoration: none !important;
    color: black;
  }
 .navbar__right a{
   text-decoration: none;
   font-size: 14px;
   margin-right: 10px;
   color: black;
   transition: all 100ms;
 }
 .navbar__right a:hover{
   text-decoration: underline;
   font-weight: bold;
 }
 main{
   margin: 0 200px;
 }

You can easily style other pages following the same pattern.

Adding, Organizing, and Listing Blog Posts

All the markdown files for your site go inside the content folder in the root directory of your project. Hugo renders the main content for your homepage from an _index.md file inside the content directory.

Create an _index.md as shown:

# Welcome to My Multi-Author Blog
Hola, devs! Welcome to my site.

If you visit http://localhost:1313, you can see a simple homepage for your site.

Inside the content directory, create a blogs folder where you can organize your blog posts. You can segregate them further based on the year of publication. The following command creates a new blog post in the designated directory with some metadata:

hugo new /blog/2020/fundamentals-design-principles.md

Inside that file, add some dummy content:

---
title: "Fundamentals of Design Principles"
date: 2020-12-27T22:37:51+05:30
draft: true
---
![](https://images.unsplash.com/photo-1516638022313-53fa45a84c7f?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=1050&q=80)
### Diving deeper into design principles and methodologies
Lorem...

While you’re at it, add a few more blogs with some content using the same process:

hugo new /blog/2020/java-spring-mvc.md
hugo new /blog/2020/hugo-themes.md

Hugo renders each individual blog post on the URL /blog/2020/java-spring-mvc by default. If you visit http://localhost:1313/blog/2020/java-spring-mvc, you can see the specific blog post.

Let’s create a page for your theme that lists all the blogs and allows a user to navigate to a particular post.

Recall that the navbar contains a route directing to /blogs, so you can render a list of all the blogs when the user visits /blogs. Hugo has a default directory where it looks for list type pages; this is where you can create a generic template for any kind of lists you want to render.

Inside /blog-theme/_default/list.html, add the following code, which simply iterates over the .Pages variable that contains a list of all child pages for /blogs. Inside the range loop, the current context (or the dot.) is always an individual page that’s used to generate the customized link.

{{ define "main" }}
<div class="container">
    <div class="section">
        <div class="content">
            <h1 class="title">{{ .Title }}</h1>
            {{ .Content }}
            {{ range .Pages }}
            <ul>
                <li><a href="{{ .Permalink }}">{{ .Title }}</a></li>
            </ul>
            {{ end }}
        </div>
    </div>
</div>
{{ end }}

Now, if you now go to http://localhost:1313/blog, you will see a list of all your blogs. Navigate to each blog by clicking an item on the list.

Creating a Blog Post Template

Next, let’s create a template for your theme that renders each new blog post exactly as you’d like it to appear.

Head over to the layouts folder (/theme/blog-theme/layouts) and create a folder named blogs with a file single.html inside it. This structure allows Hugo to render blogs faster, as it’s higher in the lookup order with respect to the single.html file present in the _default (/theme/blog-theme/layouts) directory.

{{ define "main" }}
<section class="section">
  <article>
    <div class="blog__container">
          <h1 class="blog__title">{{ .Title }}</h1>
            <div class="blog__details">
              <div class="author-image-container">
                  <img src="" alt="author-image" />
              </div>
              <div class="blog__info">
                <p>By  author name </p>
                <p><time>{{ .PublishDate.Format "January 2, 2006" }}</time> |
                    {{ .ReadingTime }} {{ if eq .ReadingTime 1 }} minute {{ else }}                              minutes {{ end }} read
                 </p>
              </div>
              <div class="blog__categories">
                Blog categories
              </div>
            </div>
          <div class="content">
            {{ .Content }}
          </div>
        </div>
  </article>
</section>
{{ end }}

The previous markup structures the contents of the blog post page by first rendering the blog’s title, followed by metadata like author name, image, an average read time, and related content categories.

Let’s style this markup:

.author-image{
  object-fit: cover;
  border-radius: 50%;
  width: 48px;
  height: 48px;
}
.blog__title{
  font-size: 32px !important;
  font-weight: bolder;
}
.blog__details{
  display: flex;
  align-items: center;
}
.blog__info{
  margin-left: 20px;
  flex: 1;
}
.blog__info p{
  margin-block-start: 2px;
  margin-block-end: 2px;
  font-size: 14px;
}
.blog__image > img{
  height: auto;
  width: 100%;
  object-fit: contain;
  margin: 10px 0;
}
.blog__categories{
  display: flex;
  align-items: center;
}
.category{
  padding: 5px 5px;
  background: #f07979;
  font-size: 12px;
  border-radius: 5px;
  width: auto;
  margin-right: 5px;
}
.category a{
  color: #fff;
}
.content img{
  height: auto;
  width: 100%;
  object-fit: contain;
  margin: 10px 0;
}

Go to /blogs and click on a blog post to see some structured content of that post. Since other details, like author information, haven’t been hooked yet, you’ll only see some boilerplate text.

Add some hard-coded categories for your blogs inside the config.toml file:

[params]
    categories = ["Web Development","Blogging","Web Design"]

You can now simply loop over these categories and render them inside the single.html.

Adding Support for Multiple Authors

Now your content is there, but there’s still no information about the author.

If you were building a single author template, you could create a variable for author name and image in the config.toml file and reference it inside the single.html file as you did for categories in the previous section. Since you want more than one author on your site, you need to add support for multiple authors in your theme.

Inside the root folder, head over to the data directory and create a JSON file with the name of the author (for example, siddhantvarma.json) with the following information in JSON format about the author:

{
    "name": "Siddhant Varma",
    "bio": "Howdy Guys! I'm a React and JavaScript Developer from India. I love watching             movies and creating content for developers",
    "avatar": "/img/authors/siddhantvarma.jpeg",
    "social": {
        "linkedin":"https://www.linkedin.com/in/siddhantvarma99/"
    }
}

Add more author information to your preference, like social media handles and external sites. You can use the following structure to organize your authors:

├── data
    └──authors
        └── siddhantvarma.json
        └── sammills.json
        └── randylev.json

Create as many authors as you like. Add an author key and value pair inside the metadata for each post as shown to associate an author with a particular blog post/ Yyou must ensure that the author’s name matches exactly the name of the JSON file for that author.

---
title: "Java Spring MVC"
date: 2020-12-27T20:08:49+05:30
author: randylev
---

Now each blog post is associated with a JSON file describing some details about that post’s author.

You can go back to single.html and render the author properties on the page along with the categories added in the previous section.

{{ define "main" }}
<section class="section">
  <article>
    <div class="blog__container">
      {{ $author := index .Site.Data.authors (.Params.author | default "default") }}
          <h1 class="blog__title">{{ .Title }}</h1>
            <div class="blog__details">
              <div class="author-image-container">
                <img src="{{ $author.avatar }}" class="author-image">
              </div>
              <div class="blog__info">
                <p>By
                  {{- if $author -}}
                      {{ $author.name }}
                  {{- end -}}
                </p>
                <p><time>{{ .PublishDate.Format "January 2, 2006" }}</time> |
                    {{ .ReadingTime }} {{ if eq .ReadingTime 1 }} minute {{ else }} minutes {{ end }} read</p>
              </div>
              <div class="blog__categories">
                {{ range $idx, $category := .Site.Params.categories }}
                  <div class="category"><a href="{{ "categories/" | relURL }}{{ $category | urlize }}">{{ $category }}</a></div>
                {{- end }}
              </div>
            </div>
          <div class="content">
            {{ .Content }}
          </div>
        </div>
  </article>
</section>
{{ end }}

And there’s your blog with some content, metadata, an author image, and categories. You can easily navigate to other blog posts and see how various author information is rendered.

Implementing Pagination

Ensure good user experience on your site by allowing a user to easily paginate through the blog posts. Hugo offers this feature right out of the box by providing the variables .PrevInSection and .NextInSection. These link to the previous and next page objects to implement simple pagination for your theme.

The following code renders two buttons at the end of each post and directs the user to the immediate previous and next post with respect to the current post.

    <div class="blog__navigate">
      <div class="blog__navigateButtons">
        <div class="blog__navigateButtons__previous">
          {{ with .PrevInSection }}
          <button><a href="{{ .Permalink }}">&#8592; Previous Post: {{ .Title }}</a>               </button>
          {{ end }}
        </div>
        <div class="blog__navigateButtons__next">
          {{ with .NextInSection }}
          <button><a href="{{ .Permalink }}">Next Post: {{ .Title }} &#8594;</a></button>
        {{ end }}
        </div>
      </div>
  </div>

Let’s style this layout inside style.css:

.blog__navigateButtons{
  display: flex;
  justify-content: space-between;
  align-items: center;
}

.blog__navigate{
  margin-bottom: 20px;
}
.blog__navigate button{
  border: none;
  outline: none;
  background: rgb(88, 123, 240);
  color: #fff;
  padding: 10px 20px;
  border-radius: 5px;
  cursor: pointer;
  transition: all 200ms;
}
.blog__navigate button:hover{
  transform: translateY(1.5);
  background: rgb(43, 92, 226);
}
.blog__navigate a{
  color: #fff;
}

Now you have a set of fully functional pagination buttons at the end of each post.

Creating a Category Page with Taxonomies

Categories are common on blogs for easy discovery of similar posts on your site. You already have some predefined categories inside config.toml file, so let’s create a separate category page that lists out all the categories and all the blogs associated with each one.

You need to associate blogs with your categories, so head to your markdown files and add some categories inside the metadata.

---
title: "How to create multi author blog site using Hugo"
date: 2019-03-20T18:42:38+02:00
description: "In this tutorial you're going to learn how to create a multi author blogging site in Hugo"
author: siddhantvarma
categories : ["Web Development","Web Design","Blogging"]
---

Hugo provides taxonomy, which classifies logical relationships between content. According to Hugo’s documentation, it offers default taxonomy support for categories and tags. This means you can easily set up a category taxonomy for your site.

Specify that you want to use the category taxonomy inside the config.toml file:

[taxonomies]
  category = "categories"

Inside your _default folder, create a file called taxonomy.html that ranges through the taxonomies, and then loops through each taxonomy to list out all the items pertaining to that taxonomy name. In this case, each taxonomy is a particular category, and blogs pertaining to each category are listed under that category as that taxonomy’s value.

{{ define "main" }}
<section class="section">
    <div class="container max-800px">
        <h1 class="title">
            {{ .Title }}
        </h1>
        <div class="categories">
            {{ range $taxonomyname, $taxonomy := .Site.Taxonomies }}

                 {{ range $name, $value := $taxonomy }}
              <div class="categoryCard">
                 <div class="categoryHeading"><p style="font-size:large">{{ $name }} </p></div>
                      <div class="category__detail">
                        {{ range $value.Pages }}
                            <p hugo-nav="{{ .RelPermalink}}"><a href="{{ .Permalink}}"> {{ .LinkTitle }} </a> </p>
                        {{ end }}
                      </div>
              </div>
              {{ end }}
            {{ end }}
          </div>
    </div>
</section>
{{ end }}

Apply some minimal styles to your template.

.categories{
  display: flex;
  justify-content: space-between;
}

.categoryCard{
  display: flex;
  flex-direction: column;
  width: auto;
  max-width: 200px;
  min-height: 200px;
  margin-right: 5px;
  height: auto;
  background-color: #fff;
  box-shadow: rgba(149, 157, 165, 0.2) 0px 8px 24px;
}

.categoryHead{
  text-align: center;
  background-color: #f07979;
  color: #fff;
  font-weight: bold;
}

.category__details{
 padding: 0 10px;
}

.categoryCard p{
  font-size: 14px;
}

Visit /categories via the navbar to see your category page.
Your blog’s category page

SEO Optimization for Hugo Themes

Finally, your theme should be optimized for search engines to ensure your site draws users. Two factors in particular affect SEO for your site:

• The SEO title
• The meta description

Your homepage’s title can be populated from your config.toml file. For other pages, a unique title and meta description should be dynamically generated to make these pages easily discoverable by search engines.

Use the following generic code inside your head.html file:

<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
    <title>{{ if not .IsHome }}{{ with .Title }}{{ . }} | {{ end }}{{ end }}{{ .Site.Title }}</title>
    <meta name="description" content="{{ with .Description }}{{ . }}{{ else }}{{ with .Summary }}{{ . }}{{ else }}{{ .Site.Params.description }}{{end }}{{ end }}">
    <link rel="canonical" href="{{ .Permalink }}" />
    <link rel="stylesheet" href="/css/style.css" type="text/css" media="all" />
    {{ template "_internal/opengraph.html" . }}
    {{ template "_internal/twitter_cards.html" . }}
</head>

The previous code checks whether you’re at a root route, then fetches the title from the config.toml file. For other subroutes, it uses a different title according to the page you’re currently on and appends the homepage title to it.

If you inspect each page’s <head> tag, you’ll notice a more specific and relevant title attached to it with an SEO-friendly meta description.

{% endraw %}

Next Steps and Advanced Customization

Use the theme you built here as a boilerplate for your own multi-author blog. Customize it even further according to the needs of your brand—extend taxonomies by adding tags and maybe create promotional pages, like an about page or a contact page. Now that you also understand how custom styling works in Hugo, add some media queries to make your site more responsive.

Hugo’s functionality simplifies the potentially daunting task of creating a custom theme, while offering you fine-grained control over your branding and the flexibility to accommodate change in the future.

There are many good reasons to start a blog for your startup: to update your customers, to generate content that ranks in search engines, or to establish your founders as subject matter experts. After you come up with some ideas, understand why you’re writing, and create a content plan, you need to decide on a blogging platform.

How to Choose the Right Blogging Platform for Your Startup

There are a few key factors that will influence your choice of a blogging platform. While I could devote an article to each of these, I’ll save that for another day, and just leave you with a brief summary.

Here are the five things I consider when choosing a blogging platform:

1. Cost to set up and maintain
2. Ease of use
3. Customizability
4. Distribution
5. Speed and scalability

You should weigh each of these factors based on your needs and the team who will be managing the blog.

Startup Blogging Platforms

Setting up a blog doesn’t have to be a headache – there are many platforms out there that will help you build a professional-looking one. Below I’ve collected a few of the best options for your startup’s blog in 2021.

Squarespace ($12) – Squarespace is my go-to recommendation for non-technical people who need a website. Squarespace works just as well for basic landing pages as it does for a full-featured website and blog.

hygraph ($0) – Brings your content to any platform or static site builder. With hygraph, you build the essential GraphQL infrastructure and they build a headless CMS for your content creators.

Jekyll ($0) – If you don’t mind writing a little HTML yourself, Jekyll is an awesome landing page and blogging platform. It can scale pretty much infinitely and it’s free to use with Github pages. You can also read our comparison with WordPress and our comparison with Hugo.

Gatsby ($0) – The new, hot static site builder has a great reputation among developers, and they’re growing quickly. If your tech team uses React, you might want to consider Gatsby.

Linkedin Publishing ($0) – Linkedin has a publishing tool that allows anyone to write blog posts that are immediately shared with their Linkedin network and profile. You don’t get any options for customizing your posts or calls to action, but it’s simple and gets automatic distribution.

ButterCMS ($24) – If you’d prefer to use a CMS as a backend and integrate your blog into your site, an option like ButterCMS would work. This works best with a static site builder or single-page application.

Cockpit ($0) – Cockpit is perfect if you need a flexible content structure but don’t want to be limited in how to use the content. You can use Cockpit for much more than blogging if you like.

Contentful ($0) – Like ButterCMS, Contentful can be used as a complete content management system with an API that will hook into your site. Both solutions are only recommended for developers.

Drupal ($0) – Free, open-source, and built on PHP, Drupal is a full-fledged content management system with a huge community. It’s more flexible than WordPress in many ways, but also requires more work to customize.

Ghost ($0) – An open-source NodeJS blogging platform, Ghost can be installed on your server or you can use Ghost Pro to let them serve it up. In either case, Ghost provides a nice-looking theme and great options for customizing your blog.

Medium ($0) – Medium has become really popular for startup blogs. While you don’t get to customize the look of your blog, it gets some free distribution on Medium.com.

Postach.io ($9) – Allows you to use Evernote as your blog’s backend.

Stitcher ($0) – A PHP-based static site generator. Offers the speed and flexibility of pure HTML for developers who might prefer PHP.

Tumblr ($0) – Tumblr is simple and customizable, plus you can make it work with your own subdomain. The community features also give you some built-in distribution although it’s less popular than Medium today.

Weebly ($0) – Weebly is a great all-in-one website and blog creator with many templates and tools to choose from.

Wix ($0) – Wix gives you everything you need for a stunning website or blog and it’s free.

WordPress.com ($0) – WordPress.com is a hosted blogging service. It makes setup easier, but allows for less flexibility and includes fewer plugin options than WordPress.org.

WordPress.org ($0) – While you’ll have to install WordPress on your own server, hosting is usually cheap. The biggest downside to WordPress now is the spam that shows up because it’s so popular.

Write.as ($0) – Quick, free (or cheap to upgrade), does custom domains, custom CSS, and it’s easy to create a bunch of blogs from one account if you upgrade.

---

Need help creating high-quality technical content once your blogging platform is live? Draft.dev specializes in authoritative blog posts and tutorials for developer-focused startups. Our network of 300+ technical writers helps companies scale content production without sacrificing quality or technical accuracy.

Ready to start planning your content strategy? Explore our guides on developing a content plan, technical writing best practices, and content promotion strategies.