For example, we recommend developing a component library of UI (User Interface) elements. In return, it delivers:
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…
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.
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!
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.
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.