GatsbyJS is an open source Javascript framework for building extremely fast websites.
Want better lead generation, customer engagement and increased brand visibility? Of course you do. And a number of companies have achieved all that and more thanks to Gatsby. It has an array of built-in features and optimizations for end-user performance — and because it’s written in Javascript, there are tools and libraries that help us decrease costs and increase productivity.
For example, we recommend developing a component library of UI (User Interface) elements. In return, it delivers:
Plus, because Javascript and Gatsby have such a popular development community, it’s easy to source new talent as your team grows.
Gatsby is one of the hottest front-end frameworks today. It brings innovative features to the table (data abstraction, server-side rendering, prefetching, etc.) but more importantly, its foundation is pure ReactJS.
This means that while we can take advantage of some of Gatsby’s best-in-class tooling today, we can confidently ensure that this investment will translate to the larger React community tomorrow.
According to stateofjs.com, React has been ranked as the most satisfying front-end framework for multiple years. There’s an active community of developers and evangelists pushing the limits of what this framework can do every day; GatsbyJS is one such example.
Hugo is another new next-gen SSG framework. While it’s super cool, you may have guessed (by the title of this article) that we prefer Gatsby. The primary difference between these two is the language underpinning the framework: Gatsby is written in JS and Hugo is written in Golang.
Both of these tools are considered “static site generators.” That means they generate static assets, which can easily be deployed to a Content Delivery Network (CDN). And while both are great candidates for the Jamstack, Gatsby has some key advantages over Hugo, primarily thanks to the JS ecosystem and NPM package registry.
The most effective argument for building a static website in Golang today is build speed, and Hugo has a clear advantage from this perspective. However, consider how much content exists on your site and how often it’s updated. You will likely find that the argument for server-side speed is much less compelling than the argument for client-side speed, which is where Gatsby really shines.
Consider the following features…
More than anything else, this is what makes Gatsby so crazy fast. Every time a build is run, Gatsby pre-renders each element on the page so that search engines can read the full text contents of your site without needing Javascript to render anything. Once loaded, your browser will “hydrate” the pre-rendered components so that your experience feels responsive.
Next, Gatsby will “prefetch” links in the background so that when a link is eventually clicked, the rendering of the next page load feels instant for the end user.
Gatsby uses GraphQL to access and normalize all data. This includes things like remote APIs, headless CMS systems, databases and even physical files such as Markdown files or image assets. This abstraction layer safeguards the end-user experience by only loading data strictly necessary to render the page. It also ensures that the underlying data providers can be swapped out with zero impact to the front end, making your application more maintainable long term.
PWAs are defined by an explicit set of industry best practices. They encourage applications delivered over the web to behave similarly to native apps. This serves to increase the performance and usability of your website through client-side caching, manifests and local storage. Gatsby provides first class support for configuring your website as a PWA, right out of the box.
Think about your website’s user interface: typically, there’s a consistent, repeatable set of elements and patterns that govern how it looks and how users interact with it. When these elements depend on one another, it's really easy to introduce regressions to your production environment. That’s risky. So how do we address this?
We recommend developing the user interface elements on your site as a “component-based” architecture.
To explain what this means, you can think of your website as a set of discrete, reusable elements (a button, a link, the search bar, etc.) where each element is a “component”. Each component contains everything it needs to render & function. The rules that govern what the component looks like and how it behaves are contained within the component and cannot be influenced from outside the component, or vice versa.
More complex UI components and patterns are simply groupings of smaller components and so on, with an emphasis on reusability. This is an extremely powerful pattern as it ensures we only have to maintain one source of code for all the “buttons” across the entire project.
As the project grows in size and complexity, the component parts that make up your website are isolated, testable and lend themselves well to powerful QA tooling — also written in Javascript.
It’s hard to conduct comprehensive QA at scale and most teams are moving too fast to catch everything anyway. Poorly organized CSS, turnover on your development team and evolving patterns can make long-term maintenance difficult and costly.
To reduce this risk, we recommend implementing an interactive component explorer called StorybookJS. This helps you visualize and test all the components that make up your user interface library. It can build confidence for your QA team and create valuable integrations with automated testing suites. For example, with percy.io integrated directly into your existing CI pipeline, you can be notified of visual regressions before they make it to production.
And because Storybook represents a living/breathing representation of your entire UI library, it also serves as a highly dynamic usage and implementation guide that you don’t have to maintain!
Also, Javascript.
The NPM ecosystem is vast and has countless solutions for most common UX problems.
While massive amounts of community contributions can be a hassle to sort through, think of them as a rich library of solutions for almost any case.
Community contributions allow developers to move faster and learn from existing patterns or solutions. Likewise, the NPM infrastructure’s deliverability lets your team ship and integrate your library as organizational needs evolve. And since we can now run Javascript on both client and server, the opportunity to eliminate context switching for your engineering team is a huge plus.
We like Gatsby… who are we kidding? We love Gatsby for all these reasons and more! It’s a perfect fit for delivering fast user experiences so an organization can meet a higher standard for customer engagement. The benefits of JS-based tooling through the Gatsby and React frameworks work best for end-user performance and long-term maintainability of an application.
As an added bonus, the community activity around Gatsby is palpable. The organization continues to provide innovative solutions such as Gatsby themes (e.g. abstract collections of plugins and config), Gatsby Cloud and Gatsby Preview, etc. They regularly host free webinars, traveling one day conferences and coding challenges to further engage the community. And they have some really cool socks too.
Sign up for our email newsletter. Nothing spammy about it. Just a monthly rundown of what we’re sharing.
