There are an awful lot of libraries that want to help you animate things on the web. These aren’t really libraries that help you with the syntax or the technology of animations, but rather are grab-and-use as-is libraries. Want to apply a class like “animate-flip-up” and watch an element, uhhh, flip up? These are the kind of libraries to look at.
I wholeheartedly think you should both 1) learn how to animate things in CSS by learning the syntax yourself and 2) customize animations to tailor the feel to your site. Still, poking around libraries like this helps foster ideas, gets you started with code examples, and might form a foundation for your own projects.
Let’s take a look at the landscape of them. Some libraries have different approaches: only take what you need classes, Sass mixins, light JavaScript libraries for adding/removing classes, etc. But they are all essentially “CSS animation libraries.” (Some of them are kinda funny having “CSS3” in the title, which kinda dates them. People just don’t say that anymore.)
While animations can both be fun and create useful interactions, it’s worth remembering that not all users want them when browsing the web. See Eric Bailey’s “Revisiting prefers-reduced-motion, the reduced motion media query” for information on how to accommodate users who prefer little or no motion.
You pick an animation you like and it gives you a class name you can use that calls a keyframe animation (you copy and paste both). The point is you just take what you need.
Tachyons itself is an atomic CSS library with a ton of utility classes for essentially designing anything by adding classes to what you need. tachyons-animate extends those by adding “Single purpose classes to help you orchestrate CSS animations.” It can be used alone, but even the docs suggest it can be used in combination with other animation libraries since helper classes are generically useful.
A collection of CSS3 powered hover effects to be applied to links, buttons, logos, SVG, featured images and so on. Easily apply to your own elements, modify or just use for inspiration. Available in CSS, Sass, and LESS.
In September 2018, I was just a few months into my journey of learning web development. As I’m sure is the case with many new developers, it was a big task for me to learn not only the basic skills required, but also keeping current with the fast-moving industry. Just as I was getting to the level where it felt as though I could build a simple website, I started to realize that it was only the first step.
Opening up a few HTML pages stored locally on my laptop felt like a million miles away from being able to say to someone, “Hey, check out my website, live on the actual internet!”
But I did it! And the best part is that it wasn’t as scary, difficult or expensive as it first felt like it’d be.
It all started with me sending Chris an email, which he used to write an awesome article explaining everything in plain English.
At this point, I didn’t have a fully coded website — just an idea for a basic site that I was using to teach myself as I went along. I used the ongoing progress of my site as a push to learn how to get a live website quicker. But I’m sure you could do the whole thing with an HTML document that just says “Hello, world!”
I built my site using Gatsby, a static site generator powered by React. Building a website with these tools in a modular way felt really natural to me. The concept of reusable parts is something I’m familiar with in my career as a physical product designer and mechanical design engineer. It means that you can build in stages, like Lego, brick-by-brick, until you eventually have a life-sized castle you can invite your friends to visit!
This isn’t a guide. It’s my personal experience in the process of getting a website from my laptop to being live on the internet. Hopefully it’ll give you some hope that it’s possible and achievable, even by someone who has no formal training in web development and who has only been doing it for 12 months!
Domain registrars
Before I ever bought a domain, it seemed like a pretty serious thing to do. Owning a domain means being responsible for it. People will go to that address and eventually see content that you’ve put there.
I don’t know if everyone has the same experience, but I spent weeks deciding on a domain name before going for it. It almost became an obsession of mine for a while, searching online for acronym generators to try and be clever, spending hours on dictionary.com trying to find synonyms that were cool. In the end, I settled for my name and what I do: joshlong.design. I still smile a little when I see my name in the address bar.
Since reading Chris’ article, I’ve actually bought two domains from two different providers: a .com and a .design. I realize that I went against Chris’ advice of consolidating domain names at a single registrar, but I needed to shop around a bit to get a good deal on my .design domain. I only own two domain names — and one of them I don’t actually have any plans for just yet — so keeping on top of where I bought them isn’t a task. In fact, I don’t remember the last time I needed to login and manage the domain I use on a daily basis!
Buying a domain name was as simple as any other online shopping transaction. Nothing really huge or scary about it. I bought my .com through Namecheap, and my .design through Google Domains, and the process was pretty similar for both. All they needed was my name, address and payment details. Pretty standard stuff!
I don’t remember Google trying to sell me a load of extra packages. They seemed happy with me just buying a domain, though they did offer me free WHOIS protection which I snapped up because I didn’t want my contact details freely available for anyone who’s feeling nosey. However, as Chris warned might happen, the other registrar I went through tried really hard to sell me some extras like hosting, email, a VPN (whatever that is!) and SSL certificates.
Google Domains checkout is happy just to sell the domain name.Namecheap tries to sell you all the additional services they offer before getting to the checkout.
I didn’t go for any of those extras. I already had a hosting plan, and you can use an alias through Gmail to “fake” having a me@mycoolsite.com email address. I honestly have no idea why I’d need a VPN, and the hosting I was going to go for gave me a free SSL certificate through Let’s Encrypt. So just the domain name, please!
Hosting
As Chris suggested it would be, choosing a host was a tad trickier than choosing and buying a domain name. But in the end, the web technology I used to build my site kind of guided me in a particular direction.
My site is built with Gatsby, which means it outputs straight-up static assets, basically as HTML and JavaScript files. That means that I didn’t need a host that offered a server (in my most super smart authoritative voice), especially for WordPress with a MySQL database and Apache server, 6 cores @ 3.6 Ghz, 4GB RAM, 5TB bandwidth, 5 IP Addresses and 500GB SSD Storage, etc.
All that jargon goes straight over my head. All I wanted to do was upload my files to the internet and go to my domain to see them all compiled and shiny. Should be easy, right?
Well it turns out that it actually was that easy. As there’s been so much hype around it recently, I thought I’d take a look at Netlify.
Netlify is recommended by Gatsby. They have really good documentation, and for my uses I felt as though I could comfortably stay within the free tier that they offer. In fact, at the moment I’m using 0.08% a month of the total bandwidth the free tier offers. Winning! Although maybe that means I’m not doing enough to get people to my site…
A quick aside about GitHub: I’m no expert at it and I don’t really know any of the etiquette it entails. All I did was sign up, create a new repository and follow the instructions that they give you. After that, every time I made a change to my site, I used the buttons in my code editor (VS Code) to commit and push my changes. It works, but I have no idea if it’s the correct or best practice way of doing it! I’m starting now, though, to understand how to use Git through the command line. I had no idea at all how to do it when I started, but I still muddled through it — and you can too!
Back to Netlify.
I signed up for an account (no credit card details required) and added a new site to Netlify by telling it about the GitHub repository where it was stored. When you’ve connected your repository, you can watch Netlify doing its thing deploying your site.
Part of the Netlify’s deploy process is that it shows your website going live in real time. That’s useful for debugging if something goes wrong, or just to watch and get excited like an impatient puppy waiting for a biscuit.You also get a deploy summary to quickly see what files were uploaded during deployment.
After my site was deployed to the randomly generated URL Netlify gives you, I followed their instructions for adding a domain I had registered elsewhere. They make it so easy!
I assume the instructions will be different for different hosts, but basically, Netlify gave me some server addresses which I then had to go back to my domain registrar to enter them in. These addresses are referred to as nameservers, so look out for that word!
Netlify gives you your nameserver addresses and super easy to understand documentation to set them up with your domain registrar
Once I entered my Netlify nameservers into Google Domains, Google knew where to look to send people who type my domain name into their browser’s address bar. All I had to do after that was wait for some internet magics to happen in the background. That took around three hours for me but can take anywhere from 10 minutes to 24 hours from what I hear.
After that was done, I could type my shiny new domain name into the address bar and — just like that — I’m looking at my own site, hosted live on the internet!
Content Management Systems
The world of Content Management Systems (CMS) is vast, and confusing, but it can also be completely irrelevant to you if you want it to be. I felt so liberated when I realized you don’t have to worry about it. It was one less thing in my list of things to do.
My Gatsby site posts and pages (my content) was just a directory of markdown files and my CMS was my text editor. Chris and Dave talked about the idea of this in a recent episode of ShopTalk Show.
My website content is managed right in my text editor, VS Code.
Because I wanted to have a standard structure for different types of posts and pages, I eventually started using NetlifyCMS which is an open-source CMS which can be included in your site real fast. (Chris also did a video recently about NetlifyCMS for his confer-reference site… see what I did there?!) Now I can create blog posts and drafts from anywhere in the world, straight from my website, as long as I have an internet connection!
The same content managed through NetlifyCMS, which offers a great UI and GitHub integration
Asset Hosting (CDNs)
A Content Delivery Network (CDN), as Chris explained in his article, is basically somewhere on the internet where you store the files you need for your website to run, HTML, CSS, images, etc. When your website needs them, it goes to the CDN and grabs the files for your site to use.
From what I’ve read, it’s good practice to use a CDN, and because of the hosting decision I made, it’s not something I have to worry about – it’s included by Netlify as standard, for free!
Netlify has it’s own CDN where all of the files for your website are stored. When someone goes to your website, Netlify goes to its CDN and grabs the files. It’s amazingly quick, and makes your site feel so much smoother to navigate.
It’s a long journey, but you can do it!
There was a point, before I set off on the journey of getting my website live, where I tried to convince myself that it’s fine to just have local websites, as my career isn’t in web development. The reason for that was because the path felt like it would be difficult, long and expensive.
In fact, it was none of those things! You could get a website live on the internet for £0.99 (~$ 1.25 for you Americans) or less if you find a deal on a domain name. The domain name was my only expense because for the path I took for hosting, asset management and content management.
At a super basic level, the path looks like this..
If you happen to use the same vendor to buy your domain name and your hosting, you can skip the nameserver step. (Netlify sells domains too!)
It’s definitely possible for anyone to get their website live on the internet. There’s a process that you need to follow, but if you take your time, it can be relatively straightforward. It’s a really wonderful feeling, getting a thing you built in front of people, and it’s honestly something that I thought I’d never be able to do. But it’s certainly within everyone’s reach!
Something I’ve come to really admire over this process (and thousands of Google searches) is the willingness of everyone in the web community to collaborate and help, accepting me and my questions as I tried to learn what I was doing. It’s something that I wish was more common in my own industry.
I’d love to hear other people’s experiences getting their first website live. What were your pitfalls and triumphs? Was it as scary as it first seemed?
I recently drew up a wireframe for a code beautifier. The next day, I decided to turn it into a real tool. The whole project took less than two days to complete.
I’d been thinking about building a new code beautifier for a while. The idea isn’t unique, but every time I use someone else’s tool, I find myself reapplying the same settings and dodging advertisements every single time. 🤦🏻
I wanted a simple tool that worked well without the hassle, so last week I grabbed some paper and started sketching one out. I’m a huge fan of wireframing by hand. There’s just something about pencil and paper that makes the design part of my brain work better than staring at a screen.
I kicked off the design process by hand-drawing wireframes for the app.
I was immediately inspired after drawing the wireframe. The next day, I took a break from my usual routine to turn it into a something real. 👨🏻💻
I knew I wanted the code editor to be the main focus of the tool, so I created a thin menu bar at the top that controls the mode (i.e. HTML, CSS, JavaScript) and settings. I eventually added an About button too.
The editor itself takes up most of the screen, but it blends in so you don’t really notice it. Instead of wasting space with instructions, I used a placeholder that disappears when you start typing.
The Dark Mode UI is based on a toggle that updates the styles.
At the bottom, I created a status bar that shows live stats about the code including the current mode, indentation settings, number of lines, number of characters, and document size in bytes. The right side of the status bar has a “Clear” and “Clean + Copy” button. The center has a logo shamelessly plugging my own service.
I don’t think many developers really code on phones, but I wanted this to work on mobile devices anyway. Aside from the usual responsive techniques, I had to watch the window size and adjust the tab position when the screen becomes too narrow.
I’m using flexbox and viewport units for vertical sizing. This was actually pretty easy to do with the exception of a little iOS quirk. Here’s a pen showing the basic wireframe. Notice how the textarea stretches to fill the unused space between the header and footer.
If you look at the JavaScript tab, you’ll see the iOS quirk and the workaround. I’m not sure how to feature detect something like this, so for now it’s just a simple device check.
Handling settings
I wanted to keep the most commonly used settings easy to access, but also expose advanced settings for each mode. To do this, I made the settings button a popover with a link to more advanced settings inside. When a setting is changed, the UI updates immediately and the settings are persisted to localStorage.
The most common settings are contained in a small panel that provides quick access to them, while advanced settings are still accessible via a link in the panel.
I took advantage of Vue.js here. Each setting gets mapped to a data property, and when one of them changes, the UI updates (if required) and I call saveSettings(). It works something like this.
function saveSettings() { const settings = {}; // settingsToStore is an array of property names that will be persisted // and "this" is referencing the current Vue model settingsToStore.map(key => settings[key] = this[key]); localStorage.setItem('settings', JSON.stringify(settings); }
Every setting is a data property that gets synced to localStorage. This is a rather primitive way to store state, so I might update the app to use a state management library such as Vuex later on.
To restore settings, I have a restoreSettings() function that runs when the app starts up.
function restoreSettings() { const json = localStorage.getItem('settings'); if (json) { try { const settings = JSON.parse(json); Object.keys(settings).forEach(key => { if (settingsToStore.includes(key)) { this[key] = settings[key]; } }); } catch (err) { window.alert('There was an error loading your previous settings'); } } }
The function fetches settings from localStorage, then applies them one by one ensuring only valid settings in settingsToStore get imported.
The Advanced Settings link opens a dialog with tabs for each mode. Despite having over 30 settings total, everything is organized and easy to access so users won’t feel overwhelmed.
Clicking the “Advanced Settings” link opens up language-specific preferences and shortcuts.
Applying themes
Dark mode is all the rage these days, so it’s enabled by default. There’s also a light theme for those who prefer it. The entire UI changes, except for popovers and dialogs.
I considered using prefers-color-scheme, which coincidentally landed in Firefox 67 recently, but I decided a toggle would probably be better. Browser support for the color theme preference query isn’t that great yet, plus developers are weird. (For example, I use macOS with the light theme, but my text editor is dark.)
The app with Light Mode UI enabled.
Defining features
Coming up with feature ideas is fairly easy. It’s limiting features for an initial release that’s hard. Here are the most relevant features I shipped right away:
Beautifies HTML, CSS, and JavaScript code
Syntax highlighting with tag/bracket matching
Paste or drop files to load code
Auto-detects indentation preference based on pasted code or dropped file
Light and dark themes
Clean and copy in one click
Keyboard shortcuts
Most JS Beautify options are configurable
Settings get stored indefinitely in localStorage
Minimal UI without ads (just an unobtrusive plug to my own service) 🙈
I also threw in a few easter eggs for fun. Try refreshing the page, exploring shortcuts, and sharing it on Facebook or Twitter to find them. 😉
The tools and libraries I used
I’m a big fan of Vue.js. It’s probably overkill for this project, but the Vue CLI let me start building with all the latest tooling via one simple command.
vue create beautify-code
I didn’t have to waste any time scaffolding, which helped me build this out quickly. Plus, Vue came in handy for things like live stats, changing themes, toggling settings, etc. I used various Element UI components for things like buttons, form elements, popovers, and dialogs.
The editor is powered by CodeMirror using custom styles. It’s a well-supported and fantastic project that I can’t recommend enough for in-browser code editing.
The library that does all the beautifying is called JS Beautify, which handles JavaScript, HTML, and CSS. JS Beautify runs on the client-side, so there’s really no backend to this app — your browser does all the work!
JS Beautify is incredibly easy to use. Install it with npm install js-beautify and run your code through the appropriate function.
import beautify from 'js-beautify'; const code = 'Your code here'; const settings = { // Your settings here }; // HTML const html = beautify.html(code, settings) // CSS const css = beautify.css(code, settings) // JavaScript const js = beautify.js(code, settings)
Each function returns a string containing the beautified code. You can change how each language is output by passing in your own settings.
I’ve been asked a few times about Prettier, which is a comparable tool, so it’s worth mentioning that I chose JS Beautify because it’s less opinionated and more configurable. If there’s enough demand, I’ll consider adding an option to toggle between JS Beautify and Prettier.
I’ve used all of these libraries before, so integration was actually pretty easy. 😅
This project was made possible by my app, Surreal CMS. If you’re looking for a great CMS for static websites, check it out — it’s free for personal, educational, and non-profit websites!
Oh, and if you’re wondering what editor I used… it’s Visual Studio Code. 👨🏻💻
This isn’t our first rodeo! I started ARTIFACT back in 2013 with Christopher Schmitt and Ari Stiles (the team behind the legendary In Control and CSS Dev conferences). At that time, the sudden avalanche of web-enabled mobile devices was throwing the web design community for a loop. How do we best leverage the recently-introduced Responsive Design techniques to adapt our designs to a spectrum of screen sizes?! What does that do to our workflows?! What happens to our beloved Photoshop comps?! How do we educate our clients and structure our billing cycles?! It was an exciting time when we needed to adjust our processes quickly to take on a radically new web viewing environment.
After four events in 2013 and 2014, ARTIFACT took a little hiatus, but we are back for a five-year reunion in 2019. We are returning to a landscape where a lot of the challenges we faced in 2013 have been figured out or, at the very least, have settled down (although there is always room for innovation and improvement).
Is our work making the web better done? Not by a long shot! Now that we’ve got a handle on the low-bar requirement of getting something readable on all those screens, we can focus our energy on higher-order challenges. How do we make our sites work easier for people of all abilities? How do we make our content, products, and services welcoming to everyone? Does our code need to be so bloated and complicated? How can we make our sites simpler and faster? How can I put new tools like CSS Grid, Progressive Web Apps, static sites, and animation to good use?
To that end, this time around ARTIFACT is expanding its focus from “designing for all the devices” to “designing for all the people.” Simply put, we want a web that doesn’t leave anyone out, and we’ve curated our program to address inclusivity, performance, and the ways that new possibilities on the web affect our workflow.
A web for everyone
Inclusive design—including accessibility, diversity, and internationalization—has been bubbling to the top of the collective consciousness of the web-crafting community. I’m incredibly encouraged to see articles, conference talks, and podcasts devoted to improving the reach of the web. At ARTIFACT, inclusivity is a major theme that winds its way throughout our program.
Photo by Jopwell from Pexels
Benjamin Evans will talk about his efforts as the Inclusive Design Lead at AirBnB to create a user experience that does not alienate minority communities.
Accessibility expert Elle Waters will share best practices for integrating accessibility measures into our workflows..
We’ll also hear from David Dylan Thomas on how to recognize and address cognitive bias that can affect content and the overall user experience.
Even better performance
Visitors may also be turned away from our sites if pages take too long to load or use too much data. We know performance matters, yet sites on the whole grow more bloated with every passing year. Tim Kadlec (who knows more about performance than just about anybody) will examine the intersection of performance and inclusion in his talk “Outside Looking In” with lots of practical code examples for how to do better. We’ll also look at performance through the lens of Progressive Web Apps (presented by Jason Grigsby of Cloud Four). In fact, improving performance is a subtext to many of our developer-oriented talks.
Leveraging the modern browser
In the Good News Department, another big change since the first ARTIFACT is that browsers offer a lot more features out of the box, allowing us to leverage native browser behavior and simplify our code (Viva Performance!). Chris Ferdinandi will be demonstrating exactly that in his talk “Lean Web Development,” where he’ll point out ways that taking advantage of built-in browser functionality and writing JavaScript for just the interactivity you need may make a big framework unnecessary. Better native browser features also means un-learning some of our old coping mechanisms. We’ll get to delight at all the polyfills and workarounds that have been kicked to the curb since 2012 in Dave Rupert’s tale of “The Greatest Redesign Ever Told,” and we’ll see what best practices make sense going forward.
Workflow and process
One thing that hasn’t changed—and likely never will—is that never-ending hamster wheel of trying to keep up with an ever-changing web development landscape. I’m guessing that if you are reading CSS-Tricks right now, you know that feeling. The methods we use to build the web are always evolving with new tools, approaches, and possibilities, which is why best practices for adapting our workflows and processes have always been a central focus at ARTIFACT. This year is no different. Jen Simmons will share her thinking process for designing a CSS grid-based layout by live-coding a site before our very eyes. Design systems, which have become a cornerstone of large-scale site production, get the treatment in talks by Kim Williams, Dan Mall, and Brad Frost. (Dan and Brad are also running their acclaimed “Designer + Developer Collaboration Workflow” workshop on October 3.) Divya Sasidharan will show off the possibilities and performance advantages of static sites in her “JAMstackin” presentation, and we’ll get a glimpse of the future of web animation from Sarah Drasner. (She’s bringing her popular “Design for Developers” workshop on October 3 as well).
The web can always do better to serve the people who use it. We’re proud to provide an occasion for designers and developers who care about putting their users front and center to mingle and share ideas. And yes, there will be milkshakes! The very best milkshakes.
Šime posts regular content for web developers on webplatform.news.
In this week’s roundup: datepickers are giving keyboard users headaches, a new web component compiler that helps fight FOUC, we finally get our hands on styling list item markers, and four steps to getting webmentions on your site.
Using plain text fields for date input
Keyboard users prefer regular text fields over complex date pickers, and voice users are frustrated by the native control (<input type="date">).
Previously, I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc. — it has tested well.
Stencil is a “web component compiler” that can be used to pre-render web components (including Shadow DOM) or hide them until they are fully styled to avoid the flash of unstyled content (FOUC).
This tool also makes sure that polyfills are only loaded when needed, and its Component API includes useful decorators and hooks that make writing web components easier (e.g., the Prop decorator handles changes to attributes).
import { Component, Prop, h } from "@stencil/core"; @Component({ tag: "my-component" }) export class MyComponent { @Prop() age: number = 0; render() { return <div>I am {this.age} years old</div>; } }
When the CSS display: list-item declaration is applied to an element, the element generates a marker box containing a marker, e.g., a list bullet (the <li> and <summary> elements have markers by default).
Markers can be styled via the ::marker pseudo-element (useful for changing the color or font of the marker), but this CSS feature is currently only supported in Firefox.
I’m assuming most of you have already heard about Gatsby, and at least loosely know that it’s basically a static site generator for React sites. It generally runs like this:
Data Sources → Pull data from anywhere.
Build → Generate your website with React and GraphQL.
Deploy → Send the site to any static site host.
What this typically means is that you can get your data from any recognizable data source — CMS, markdown, file systems and databases, to name a few — manage the data through GraphQL to build your website, and finally deploy your website to any static web host (such as Netlify or Zeit).
The Gatsby homepage illustration of the Gatsby workflow.
In this article, we are concerned with the build process, which is powered by GraphQL. This is the part where your data is managed. Unlike traditional REST APIs where you often need to send anonymous data to test your endpoints, GraphQL consolidates your APIs into a self-documenting IDE. Using this IDE, you can perform GraphQL operations such as queries, mutations, and subscriptions, as well as view your GraphQL schema, and documentation.
GraphQL has an IDE built right into it, but what if we want something a little more powerful? That’s where GraphQL Playground comes in and we’re going to walk through the steps to switch from the default over to GraphQL Playground so that it works with Gatsby.
GraphiQL and GraphQL Playground
GraphiQL is GraphQL’s default IDE for exploring GraphQL operations, but you could switch to something else, like GraphQL Playground. Both have their advantages. For example, GraphQL Playground is essentially a wrapper over GraphiQL but includes additional features such as:
Interactive, multi-column schema documentation
Automatic schema reloading
Support for GraphQL Subscriptions
Query history
Configuration of HTTP headers
Tabs
Extensibility (themes, etc.)
Choosing either GraphQL Playground or GraphiQL most likely depends on whether you need to use those additional features. There’s no strict rule that will make you write better GraphQL operations, or build a better website or app.
This post isn’t meant to sway you toward one versus the other. We’re looking at GraphQL Playground in this post specifically because it’s not the default IDE and there may be use cases where you need the additional features it provides and needs to set things up to work with Gatsby. So, let’s dig in and set up a new Gatsby project from scratch. We’ll integrate GraphQL Playground and configure it for the project.
Setting up a Gatsby Project
To set up a new Gatsby project, we first need to install the gatsby-cli. This will give us Gatsby-specific commands we can use in the Terminal.
npm install -g gatsby-cli
Now, let’s set up a new site. I’ve decided to call this example “gatsby-playground” but you can name it whatever you’d like.
gatsby new gatsby-playground
Let’s navigate to the directory where it was installed.
cd gatsby-playground
And, finally, flip on our development server.
gatsby develop
Head over to http://localhost:8000 in the browser for the opening page of the project. Your Gatsby GraphQL operations are going to be located at http://localhost:8000/___graphql.
The GraphiQL interface.
At this point, I think it’s worth calling out that there is a desktop app for GraphQL Playground. You could just access your Gatsby GraphQL operations with the URL Endpoint localhost:8000/___graphql without going any further with this article. But, we want to get our hands dirty and have some fun under the hood!
Since we’re not going to be relying on the desktop app, we’ll need to do a little bit of Environmental Variable setup.
Environmental Variables are variables used specifically to customize the behavior of a website in different environments. These environments could be when the website is in active development, or perhaps when it is live in production and available for the world to see. We can have as many environments as we want, and define different Environmental Variables for each of the environments.
Gatsby supports two environments: development and production. To set a development environmental variable, we need to have a .env.development file at the root of the project. Same sort of deal for production, but it’s .env.production.
To swap out both environments, we’ll need to set an environment variable in a cross-platform compatible way. Let’s create a .env.development file at the root of the project. Here, we set a key/value pair for our variables. The key will be GATSBY_GRAPHQL_IDE, and the value will be playground, like so:
GATSBY_GRAPHQL_IDE=playground
Accessing Environment Variables in JavaScript
In Gatsby, our Environmental Variables are only available at build time, or when Node.JS is running (what we’ll call run time). Since the variables are loaded client-side at build time, we need to use them dynamically at run time. It is important that we restart our server or rebuild our website every time we modify any of these variables.
To load our environmental variables into our project, we need to install a package:
The develop script instructs the env-cmd package to load environmental variables from a custom environmental variable file (.env.development in this case), and if it can’t find it, fallback to .env (if you have one, so if you see the need to, create a .env file at the root of your project with the same content as .env.development).
And that’s it! But, hey, remember to restart the server since we change the variable.
yarn start // npm run develop
If you refresh the http://localhost:8000/___graphql in the browser, you should now see GraphQL playground. Cool? Cool!
GraphQL Playground with Gatsby.
And that’s how we get GraphQL Playground to work with Gatsby!
So that’s how we get from GraphQL’s default GraphiQL IDE to GraphQL Playground. Like we covered earlier, the decision of whether or not to make the switch at all comes down to whether the additional features offered in GraphQL Playground are required for your project. Again, we’re basically working with a GraphiQL wrapper that piles on more features.
Resources
Here are some additional articles around the web to get you started with Gatsby and more familiar with GraphiQL, GraphQL Playground, and Environment Variables.
The irony of web performance is that the average page weight of a site continues to go up year after year, despite us being more aware of the problem and having more tools at our disposal to fight it than ever.
To paraphrase Seinfeld, “we know how to fight page weight issues; we just don’t use the tools we have to fight page weight issues.”
That’s why Jetpack provides powerful features for all users at any plan level. They made it so that performance is integrated right into managing content on a WordPress site.
One of those things is lazy loading images. Lazy loading is an excellent technique to defer loading images until they are actually needed. So, an image never loads until the user actually scrolls to where it comes into display. That could potentially save a ton of server requests and precious bytes when waiting for a page to load. Jetpack includes lazy loading, even on free plans, so everyone has access to this performance boost.
And what’s the point of lazy loading anything if you don’t have somewhere to host the files? Well, Jetpack also offers unlimited static file and image hosting for every plan level. No more wondering how much storage is left on your server! You get an unlimited amount of space to store anything you need. That’s pretty awesome!
It gets even more awesome. That’s because the unlimited storage is part of a CDN that is designed to serve images from high-speed dedicated data centers that make downloads as fast and smooth as possible. Again, that’s free to everyone!
That makes Jetpack a super resource for combatting performance issues on a WordPress site. Hey, we use Jetpack here at CSS-Tricks and it’s a linchpin for so much of how this site works and operates. The performance benefits are a nice perk but it’s worth checking out everything it has to offer because there’s likely so much more you can leverage.
