Category: platforms

One of the first decisions any developer 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 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.

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. 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.

How to Debug a React App in Safari

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

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.

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 Standalone React DevTools to Your App in 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@^4

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.

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 a User Listing

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.

Additionally, you can pin the location of a selected component in your browser by clicking the eye icon in React DevTools:

Once this has been activated, it will highlight the component in light blue in your browser:

You can also log the selected component in the console by clicking the bug icon in React DevTools:

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.

Differences between Standalone React DevTools and the Chrome Extension

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 the Chrome extension. 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. Chrome extensions, on the other hand, are limited to working within the Chrome browser environment.
• Ease of setup and connection: Chrome 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. The standalone version of React DevTools often requires manual configuration to connect to the target app, which can be more time-consuming and error-prone.
• Updates and maintenance: These two versions of React DevTools may have different release schedules and update processes. Chrome extensions typically update automatically with the browser, while the standalone version may require manual updates.

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.
• Performance and resource usage: The standalone version of React DevTools may have different performance characteristics and resource usage compared to the Chrome extension version. Depending on the specific tools and configurations used, developers may experience varying levels of performance and resource consumption, which can impact their development experience.

By keeping these limitations in mind, you can adjust your approach and optimize your code more effectively. For instance, you can use alternative tools or workarounds to gather the information you need.

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 browser-based React apps or non-browser-based applications like React Native apps.

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 exclusive paid-for articles.

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.

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.