Monbanquet.fr and the great Gatsby
Back in December of 2018, I presented a talk (in French 🇫🇷 subtitled in English 🇬🇧) at the first Paris JAMstack conference. This is not a transcript of it but rather the written story of the feedback I gave.
A tale of a splash screen
In September, our company Monbanquet.fr had to make a departure from our then current website. Multiple needs prompted this decision. Business-wise, the goal was to clarify the site’s offering and have a straightforward way to order a banquet. Technically we wanted a performant, SEO optimized, good looking website. I mean, who doesn’t? Right, but in reality, it appears that these criteria are often the ones that go neglected when working with a deadline.
For those who don’t know Monbanquet.fr. We’re a French startup based in Paris and Lyon that aims to give the catering industry a renewed experience by working with local artisans such as butchers, bakers and cheese makers. Thanks to them, we offer incredibly fresh food for all your business events (breakfasts, cocktails, seminars and more).
But to have a truly modern and pleasant experience, we could not do without a website presenting our offering. The previous version was convoluted and quite complex to navigate. I won’t detail the re-design process as it's not the focus of the post but just know that we decided to drop the online ordering for now (as in “paying online”), because of the intrinsic complexity of a very localized offer. This would remove the need for intricate interactions such as geolocation and time-based filtering.
With that in mind, the order flow became pretty simple:
home page → event page (i.e: breakfast) → order modal → the order is sent to our sales management system.
Business decisions aside, the objective was to make the site as enjoyable as possible for obvious reasons. The previous iteration of the website was made with Angular@6.x.x and proved to be quite heavy on the network.
Here is an audit of it on 3G speeds
Indeed we shipped quite a bit of JS, including but not limited to: angular, ngrx (a redux like state management system), angularfire2 (the client for firebase), moment (a date manipulation library), lodash (an utility-belt function library).
And while this post is not meant to be a stab at Angular and its ecosystem (it’s good for many things, and we use it on our mission-critical Back Office), creating a performant and pleasant website with it has nothing to do with what I experienced with Gatsby later on.
Making a (good) website is hard.
This statement can vary depending on your definition of a “website”. But making a truly great website requires a lot of time and skills. Admitting you have the latter, the former is rarely an option. Either you have weeks and months in front of you, or you have a big team ready to tackle the challenge together, reducing the time it takes to bring your site live. When you have neither of it you’re stuck with a few options:
- Rely on a tool to build the website for you.
- Cut corners and impact the quality
Both of them are bad choices for a company that already has a *working* website. Here “working” being purely technical: it displays stuff and people can interact with it. Using a tool to re-create the website would probably not make us step up our game, in terms of design, ergonomics, and performance.
Making a good website should be as easy as making a bad one (if not easier).
This is not the case right now. To me, the main players of what makes a website enjoyable (if we omit business requirements):
- Speed, real and perceived
- UI and animations
I’ll talk about speed mainly but will come back a little bit on animations at the end of this post.
Going static
I looked at different solutions such as Server-Side Rendering and found out that going the static route could be a good fit for our needs: having a fast, SEO-friendly website that does not cost much to build and to operate. Our website had just a few pages to start with and minimal interactions. It would be a good testing ground for the technology.
As I mention in the talk, I did not dive into a comparative table of twenty-seven frameworks before settling on Gatsby, benchmarks are hard and time-consuming, and you’re never sure of the choice you’ve made. I already had tried Gatsby a few times on a personal project and the first thing that caught my attention was its simplicity. Setup was painless and I had a working page in less than 10minutes — npm install included. After doing a little more research these were the arguments that won me over.
- It’s react, just plain old react
- It’s static, no servers
- It has great documentation
- It has a growing and active community
- It is data agnostic (does not care where the content comes from)
This was enough for me to try it out a little more. Because being just React I could always reuse my components if something had to go wrong. But I was confident, seeing the community, and the great job of the Gatsby team to help people get started. Let’s dive in.
The Gatsby way
One of the interesting points of Gatsby is that it does not impose a data format. It does not care if your site’s content comes from a WordPress blog, a series of markdown files or any other API out there. It provides you with a simple way to write your source plugin. All of this data, no matter where it comes from, gets injected via GraphQL queries into your react components that make up your pages. In the end, all you have is a static public/ folder ready to be deployed. It’s plain simple HTML, CSS, and Javascript.
Here is how it works (from their home page)
GraphQL
I did not know GraphQL before, except from the tweets and articles, but it went like a charm, Especially thanks to the integration of graphiql, a playground that Gatsby spins up while you’re developing to help you tinker with queries.
A reaction I often get when I say Gatsby uses GraphQL is:
But, I don’t know GraphQL and I don’t want to spend time learning it, especially since it is a relatively new idea.
I understand the concern, and I like to think of Gatsby as just a well-put collection of tools to help you build your site faster. GraphQL is one tool that can make you more productive without impacting the way you code. You just write your query, and you get the result in a variable like any other which you can then pass as a prop to your react component. Besides, Gatsby guides you well into using it so it takes almost nothing to learn.
So how is GraphQL used in Gatsby and how does it help?
For me, it was the fact that no matter where the data came from (JSON files, APIs…) it was available from the same simple JSON-like interface. Using plugins, I fetched content both from Contentful and local files without having to implement HTTP requests, manage the file system and doing some plumbing to get it all aggregated into one coherent variable ready to be consumed by the application. Of course, this fetching and plumbing happens behind the scene and is done by plugins. I find this approach very clean in that it does not “pollute” your application with irrelevant and often verbose code. That said, you may want to create your own plugin for your needs, and it is surprisingly simple and well documented (or check out this live-coding 🇫🇷 by Nicolas Goutay).
The cherry on top, GraphQL is typed. For typing fans out there this is very convenient. When fetching your data, Gatsby will try to infer its type and create a GraphQL schema of it. It works pretty well (but has some limitations) and could, for example, help you create Typescript types with it.
<GatsbyLink> and prefetching
When talking about static generation I sometimes get a reaction in the likes of:
“This is going full-circle, we’re back to full-page server-side rendered website”.
This is not completely false but we want to take the best of both worlds of SSR & SPAs and GatsbyLink helps us do that. Instead of being a classic anchor tag, it’s a supercharged link (although it’s still an <a href=”…”>) that will load the page behind it in the background so it’s ready by the time you click the link.
This is done by fetching the next page as a Javascript bundle rather than an HTML document. The idea is to replace components on the fly without having to re-render the whole page.
You can see it in action as I hover the different links in the page.
<GatsbyImage> and resolutions
Another tool that Gatsby provides is a react component called gatsby-image. It allows you to take full advantage of image optimization techniques without the hassle.
If you tried to implement correctly image/picture tags before, you know the pain it can be to use a <picture> tag and srcset attribute with all resolutions files specified.
This does not only takes time to write but you also need to create the pictures with every size and resolution. Some online services can do it for you but what if you don’t want to use a costly service? Gatsby once again helps you here by leveraging its plugins. Using gatsby-plugin-sharp, all needed resolutions and sizes will be created and handed to you in a nice GraphQL fashion. In the end, the above code has been generated by this little snippet:
You may wonder why we should do all of this. Why not add a simple single <img src=”…”/> and basta? Well… simply because your users suffer from it. Images aren’t optimized for all devices, screen-sizes and network connections. While with gatsby-image, the browser can decide which source to show based on these criteria, providing a speedy user experience while Gatsby helps with the developer experience.
We have all the speed stuff sorted out yay! But wait, gatsby-image goes further. Not only does it choose the best available resolution, but it also loads it lazily and in a visually progressive way. There are two techniques available with gatsby-plugin-sharp and gatsby-image.
The first one is called traced-svg and consists of creating a contour of the picture you want to display as a placeholder while the real thing loads. Here you can see, as I reload the page, the SVG is briefly shown before the picture replaces it.
The second technique is called blur-up and is about in-lining a 20px version of your picture in the HTML as a data-URI before swapping it out with the correct resolution. This creates a sense of context for your users who can almost feel the picture while it loads, preventing the painful wait starring at a blank space or jumping content.
Here you can watch the blur-up effect in action as well as the lazy loading of pictures as they enter the viewport.
This work on perceived performance further improves the experience your users will have when using your website. And this is all done for you. No complex setup or manipulations.
Moaaaaar plugins
I know it feels scary and reminiscent of jQuery days when every lib out there was a jQuery plugin. With Gatsby, plugins are at the ecosystem’s core. They allow you to create and shape your content before it goes into your components.
One of the plugins that I find particularly helpful is gatsby-subfont-plugin. It “tree-shakes” any font character you don’t use out of the critical rendering path of your homepage. This is achieved by creating a version of the font that only contains the glyphs you actually use.
The full font is still loaded asynchronously afterward to handle any eventual dynamic content. But your first render should be significantly snappier and reduce FOUT. In the end, we shaved roughly 50kB of unused font characters on the first render, which is not negligible.
A note on animations/interactions
I’m just going to add a note regarding animations because this is the very first time I’ve enjoyed writing them. I feel that animations are often overlooked in projects because they appear superfluous or even unwanted. But they do improve the experience quite a bit and make the user feel at home.
Of course, animations for its own’ sake are stupid and destroy a site’s credibility and usability. However, subtle and timely ones can upgrade the experience to a meaningful and even delightful one. Helping the user figure out why stuff appears on the screen and where it comes from.
Usually, animations are a welcome addition in response to some user interactions and rarely wanted on their own. For example, you probably won’t animate a menu bar, randomly, out of nowhere for no reasons. But you could make it appear in various ways at the touch of a button.
This is what we did for our main navigation panel. On mobile, a left-side drawer is available to navigate between the website’s pages. If you try it out, you’ll notice that, contrary to many web-based side navigation panels, it doesn’t just pop into view, but gently glides over the main content area. Similarly, you can trigger it by touching the menu link or by dragging it from the left edge of the screen. A standard move, well expected by mobile users by now. But it has historically been hard to do properly on mobile. Until… react-spring.
This library has been a joy to use and a breath of fresh air. I won’t go into the details of implementation here (a subject for a later post) but just know that the Drawer component and all its interaction logic spans no more than 50 lines of code. This includes touch handling. We’ll publish the code as soon as it’s ready.
Adding and responding to user’s gestures has never been so simple and usually takes only a few lines (even more so with the release of react hooks). I recommend you take a close look at how to make your website feel more alive with these two packages, you won’t regret it. (Thanks so much Paul)
Build. Deploy. Repeat.
Now that we have got a good idea of how Gatsby helps developers creating a great and speedy user experience, how do we put this all together? How do we ship all of this marvel?
The answer depends on you, your choices, your stack, and your team. At Monbanquet.fr we settled on Contentful and Netlify. They are a great combo for our use cases. These are the arguments that got us enrolled:
Contentful
- It has a web-based interface
- It’s content-only, no styling
- It has a Gatsby plugin
- It’s a great place to host pictures
- It has a generous free-tier
Netlify
- The DX is amazing (getting the site online took 5min at most)
- It builds and deploys on each git push
- It has an URL for each commit build and each branch
- It has webhooks to trigger a build from outside
- It has branch-based split testing
- It has a generous free-tier
- Many more cool features we haven’t even tried yet. (Forms, identity…)
Our needs were simple yet difficult to find. We needed to have flexibility, thus Contentful would provide us with content uncoupled from the front-end development which would greatly help interaction with the marketing people in charge of the content. We also needed to get something out quickly, excluding any complex build system, or development process. And Netlify proved up to the task. So how does the development process look like now?
Contentful change → Triggers build on netlify via webhook→ site is deployed
Code change → Triggers build on netlify via git push → site is deployed
In my presentation, I mentioned that it cost us 0€. This is obviously excluding development time. Which was still relatively low. An (admittedly simple) website with only one person working on it took only 2 months (design included). It’s a pretty sweet deal if you’d ask me considering:
Performance… is checked. SEO… checked. Mobile interaction… native-like. Content management… checked. Hosting and build process… quick and easy. Learning time… almost zero. SaaS cost…0€.
Conclusion
Why does everybody love Gatsby? There could be many reasons but I, for one, like how it helps you get the most of modern web technology (prefetching, image and font optimizations…) which are often way too complicated to handle properly in a timely manner. Now you basically have a performance engineer in your team for free. Performance is not an after-thought anymore, it’s baked in. The barriers have fallen and you have no more excuses not to make a performant website.
Is the future of Monbanquet.fr static?
This is only the start of the adventure for the website. What started out as a small experiment is quickly becoming a live exploration and we’re proud to be playing our part in pushing the boundaries of front-end development, be it with static rendering or with lively interactions. Our road to a complete experience is still ahead and the next chapter is definitely going to blur the line even more between static and dynamic.
For instance, we’re on our way to offer online ordering, which includes a lot of e-commerce use cases. Product pages, baskets, search and more. You can guess how this becomes a little more complicated than writing a few pages. Problems will arise regarding the maximum number of pages we can generate in a reasonable time, authentication, and mixing up static pages with dynamic content. This will help us find the limits of static generation. A limit we want to probe if we wish to create a great experience for users and developers alike.
Thanks for reading!
Thank you Charly Poly for your review and help!
Follow our ongoing development on twitter @dot_louis & @monbanquet
The slides: https://slides.com/dotlouis/deck-13
The talk (in French 🇫🇷 subtitled in English 🇬🇧): https://www.youtube.com/watch?v=xLQ4to7Ubn0
#UX #UI #static #webdevelopment #gatsby #jamstack #speed #easy #react-spring #react-use-gesture #animations
