Lately, most of the people argued against a framework like React, Angular or Vue for your personal website. Since then, tools on top of those frameworks -- like Gatsby.js for React.js -- emerged to form static website development effortless. So if there's no actual demand, why does a static website generator like Gatsby.js do so well?
A couple of months back i started the plan to migrate my website to Gatsby.js and that i must say: i really like it. It takes considerably all the pain away that I had to affect before. Most personal websites aren't only HTML + CSS anymore. they are available with an upscale set of advanced CSS/HTML + JavaScript for lazy image loading, route prefetching, service workers, analytics, and offline capabilities. and that is merely the tip of the iceberg. What about performance, SEO, and social media?
GATSBY.JS IS BUILT ON REACT.JS
I start with the foremost obvious benefit: Gatsby.js is formed on top of React.js. As an a minimum of intermediate React developer, you're feeling immediately comfortable with it. You structure your pages as components, implement a repertoire of UI components, style your components with CSS modules or styled components, and update state with sense . But also as a non React developer -- coming from another framework of choice -- you'll not have a troublesome time to know how things work if you're comfortable with JavaScript.
Note: i do not recommend to seek out out React.js while learning Gatsby.js. The latter comes with many things on top that you simply simply should learn in separation. Learning both frameworks in one step will blur the lines between React and Gatsby. to not mention the plugin system, GraphQL, and thus the parts related to Node.js. **Get an honest grasp about React.js first before learning Gatsby.js.
GATSBY ROUTER
Gatsby comes as a full-blown framework to form static websites. Whereas in React you've to know all the essential libraries to complement React as its core, Gatsby comes with many things directly .
For instance, Gatsby ships with a integrate Router and thus the Gatsby team decides which React Router makes most for his or her environment. As a developer, you are doing not need to care about it like during a clear React application. The implementation of the routing in Gatsby is different from React. it's two modes to form routes: static and dynamic routes.
• Static Routes: Every component within the src/pages folder becomes automatically a route.
• Dynamic Routes: The createPage API allows you to form dynamic routes.
Most of your routes are getting to be static anyway, so it is not getting easier as just implementing a component for it. Then you merely need to use the Gatsby Link component to supply your user elements to interact with. That's only the beginning for routing in Gatsby though. Under the hood, Gatsby applies improvements for you. as an example , it catches routes that are going nowhere, preloads other pages of routes linking to those pages, and prevents a browser refresh when navigating from page to page. Basically Gatsby Routing comes with all the improvements you'd expect an application to possess by default.
GATSBY.JS PLUGINS
Gatsby Plugins make it possible to introduce pre-defined features on a fine-grained level to your project. a set of plugins is additionally called Gatsby Theme. Plugins accompany their default configuration, but also can be overridden with options from your side. Whether you would like to possess analytics (e.g. Google Analytics) or error tracking (e.g. Sentry) for your website, you'll introduce it with a plugin and a couple of lines of code:
module.exports = {
plugins: [
{
resolve: 'gatsby-plugin-sentry',
options: {
dsn: process.env.GATSBY_SENTRY_DSN,
},
},
{
resolve: `gatsby-plugin-google-analytics`,
options: {
trackingId: process.env.GATSBY_GOOGLE_ANALYTICS,
head: false,
anonymize: true,
respectDNT: true,
},
},
],
...
};
From the very beginning, Gatsby.js presented itself with a well-structured plugin system. A clean API and thus great adoption rate lead from one plugin to a different . Nowadays, there's a huge ecosystem of Gatsby.js plugins to settle on from for your Gatsby.js site. Many of the subsequent benefits (images, markdown, third-party integrations) of using Gatsby.js tie back to its powerful plugin ecosystem.
GRAPHQL IN GATSBY.JS
GraphQL is usually seen as alternative to REST. However, whereas REST is usually used for client-server communication via HTTP, GraphQL is simply a question language independently of the communication protocol and data representation. Essentially GraphQL are often used anywhere where a client requests data. Gatsby makes use of those GraphQL circumstances to question all of its internal (e.g. files) and external (e.g. third-party APIs of integrations) data. GraphQL becomes the interface between Gatsby and every one its data sources.
import React from 'react';
import { graphql } from 'gatsby';
export default ({ data }) => (
<div>
<h1>{data.site.siteMetadata.title}</h1>
</div>
);
export const query = graphql`
query {
site {
siteMetadata {
title
}
}
}
`;
Note: GraphQL is another aspect which makes it difficult to find out Gatsby.js as a beginner. Like React it comes with its own ecosystem, best practices, and libraries. However, in Gatsby.js you're only using GraphQL from a client's perspective, so once you begin to consider Gatsby's data sources as a graph, you're good to use it. However, I'd recommend people to find out GraphQL on the side to urge a far better understanding of it.
Once you begin your Gatsby.js application, you'll open up GraphiQL, an explorative GraphQL client which comes with Gatsby, to traverse through all of your data that's aggregated by Gatsby. This starts by having access to pictures and markdown via GraphQL, but also by accessing third-party APIs which accompany Gatsby's plugin system (see integrations).
After all, it takes a while to regulate to the present new mindset of using GraphQL for all of your data sources -- essentially having all of your data available just one GraphQL query away -- but once you get wont to it, it becomes a pleasure to figure with.
IMAGES IN GATSBY.JS
The performance of your website influences your SEO score and therefore the UX of your website. If you're showing larger images in your blog posts or on your landing pages, you'll not get around performance optimizations for them. Before I began to use Gatsby.js, I had to implement features like lazy loading or source sets for responsive images myself. Once implemented everything worked great, but I always felt that this implementation detail shouldn't be in my hands. Every other website needs these features, so why isn't there an easy abstraction for it? Gatsby solves this problem perfectly for you with Gatsby Images and their Image Plugins.
import React from 'react';
import { graphql } from 'gatsby';
import Img from 'gatsby-image';
export default ({ data }) => (
<div>
<h1>Hello gatsby-image</h1>
<Img sizes={data.file.childImageSharp.sizes} />
</div>
);
export const query = graphql`
query {
file(relativePath: { eq: 'blog/react-gatsby-js.jpeg' }) {
childImageSharp {
sizes(maxWidth: 900) {
...GatsbyImageSharpSizes
}
}
}
}
`;
Lazy loading and responsive image source sets are a thing of the past. Everything is applied under the hood for you. Also the well-known Blur Effect kicks certain people visiting your website making lazy loading of images not a dealbreaker for UX. And this scratches only the surface of Gatsby Image which handles various image formats and offers an upscale API. Don't worry about commonly used image features anymore, because Gatsby takes care of them.
GATSBY THEMES & WEBSITE SPECIFIC CONTENT
Basically Gatsby Themes structure a group of Gatsby Plugins while being represented as a plugin themselves. you'll also combine multiple Gatsby Themes. This way, it's possible to publish Gatsby Themes with the main target on certain topics (e.g. Analytics, MDX) which may then be weaved into your Gatsby configuration with all the remaining plugins.
module.exports = {
plugins: [
// your themes
{
resolve: "my-gatsby-analytics-theme",
options: {},
},
// other plugins
{
resolve: `gatsby-source-contentful`,
options: {
spaceId: process.env.GATSBY_CONTENTFUL_SPACE_ID,
accessToken: process.env.GATSBY_CONTENTFUL_ACCESS_TOKEN,
},
},
],
...
};
Gatsby's plugin system, themes and content distribution makes it possible to create one Gatsby website which is employed by quite one party. If you're taking it one step further, you'll extract all content to a CMS. It aligns perfectly with the DRY principle if you would like to serve quite one complex static website with Gatsby. One perfectly build Gatsby Website to serve all of them .
IT'S BLAZING FAST ...
The most important mantra of Gatsby.js: "[it] helps developers build blazing fast websites and apps". The statement holds true for building the web site even many data is fetched from third-party APIs, many logic is weaved into your gatsby-node.js file, and much of various pages get created. as long as the build crashes i might wish that there would be a default rollback.
The statement holds also true for the perceived performance of users visiting your website. Lazy image loading, preloading of pages, and responsive image source sets improve the UX tremendously. If you're performing a Google Lighthouse Audit with the Gatsby.js defaults, it's not a surprise anymore that your scores are above average.
GATSBY PWA and repair WORKERS
It has been never easier to make a Progressive Web Application (PWA). Just another aspect to think about to drive your Website Audit Scores up. Essentially you would like only two plugins in Gatsby.js to form it work:
module.exports = {
plugins: [
{
resolve: `gatsby-plugin-manifest`,
options: {
name: `My Gatsby Website`,
short_name: `My Gatsby Website`,
start_url: `/`,
background_color: `#f7f0eb`,
theme_color: `#a2466c`,
display: `standalone`,
},
},
`gatsby-plugin-offline`
],
}
While the previous Gatsby Plugin gives your application a manifest to form it installable on a user's home screen, the later plugin installs a service worker to form your application perform offline. It's everything that's needed to form your application a PWA from a technical perspective. And Gatsby makes this damn easy.
GATSBY SEO
Implementing SEO in Gatsby isn't much different from the other static website generators. you would like to understand structured data and meta tags to enhance your website's SEO by default -- independently from your content which comes with its own keyword optimizations etc.
Structured Data: Sprinkle it everywhere in your React components where it is sensible . as an example , if you show the author of your blog post somewhere on the page, there exists structured data for it. If you display a date somewhere, there exists structured data for it. Or if you display HTML elements for navigation, there's structured data for it.
Meta Tags: Usually you've got one React component that takes care about all the SEO aspects for the meta tags. If a user visits a page on your website, this components receives props about the page's title, description, and keywords. But there's more thereto like preview images for Twitter and Facebook. Everything associated with SEO and social media can find yourself during this component.
GATSBY COMMUNITY
The Gatsby.js community pushes the boundaries of static website generators. They work on the bleeding edge with their integrations, performance optimization, and MDX for markdown. It happens that you simply run into problems, because they're just within the making within the Gatsby.js ecosystem, but if you open a problem on GitHub, you'll always end up surrounded by helpful people.
Whereas Gatsby.js gives you a full-blown framework with all the expected defaults (routing, image handling, plugin system), you continue to use React.js under the hood to make pages and UI components. It merges an abstraction with a concrete world perfectly into one solution for static websites. Many other static websites are way behind the innovations Gatsby.js brings on the table -- most significantly being API first driven. And it'll just recover with a striving community, plugin ecosystem and themes.
Top comments (1)
I don't use Gatsby because I feel like it has needless complexity compared to
nextorzero