Given that many of our projects have been done with React static site generators the obvious answer would be one of them. With that being said, for us, the best actually refers to the SSG that works the best for a project in question. And when considering the project needs one (or more) of these static site generators is always in play.

We tried to explain that in our introduction to Jamstack post. The best thing about it is that it is not about a specific technology but a web dev approach with a ton of benefits both for us as devs and our clients and their businesses. On top of it all, we get to learn new stuff with every project we are involved in.

Indeed, we are a distributed team that works fully remotely from anywhere in the world. That means we are not looking for new folks who are based in Central Europe only. We’ve already started doing it - take a look at our Team page and meet our international bunch of Jamstack enthusiasts we have on board :).

There are plenty of different options on the market. Some git-based CMS like Forestry or NetlifyCMS are simpler, but some like Sanity or Contentful allows you to build really advanced layouts and structure and organize data in the way you want. I’d compare those CMS to Advanced Custom Fields in WordPress, you can create blocks, multiple nested fields, relations, create your own fields, and so on. I’d say you can build much more advanced and custom layouts than in WordPress and don’t lose your mind. I used to work on some larger, custom-designed projects in WordPress and even tho I love ACF I’ve always felt it’s a bit hacky.

The closest user experience to things like Visual Composer or Divi Builder is Storyblok - it gives editors a live preview similar to WordPress Page Builders. A very interesting project in that space is Tina CMS which enables real-time, on-page editing.

If you structure fields and components correctly in any Headless CMS you can create templates and give editors freedom to build custom pages without the need to custom-code them every time.

You can read more about those different CMS in our recent post - there are some screenshots and videos of the inside UI and editing experience.

At Bejamas we use a bunch of different tools, depends on the project and the animation we want to achieve. Basic animations and transitions can be done in vanilla CSS - Animate.css is a helpful tool. Sometimes we use Lottie for more advanced animations. Personally, I used GSAP in a couple projects and can recommend it. We’ve also used react-pose and the newest version developed by Framer called motion.

On the Bejamas website we use flat files (.mdx) as content source. We have integrated Forestry CMS (which is git-based) to make it easier to edit content for the marketing team. Navigation on the left is a custom-build component based on the list of files in headless-cms directory. Each file contains content of one CMS.

With the recent Next.js 9.3 update, it looks very promising as both SSG and dynamic, SSR dynamic pages. We’re testing it in a couple of projects. However, Gatsby plugins ecosystem is huge and still growing. It has its cons but overall it standardizes content query (everything should be fetched via source plugin - so you fetch content via internal GraphQL). Next.js is less opinionated in terms of how you should fetch data.

I really like Next’s approach to constant JS optimization. Bundle size gets smaller with every release. Gatsby seems to not care about this that much (there are some plans, but no ETA tho).

So - if you already are familiar with Gatsby and its ecosystem I’d pick it for simple blog/websites projects (that don’t need any dynamic pages). I’d bet on Next.js if you are entering the Jamstack world and want to use React-based SSG.

Yes we do! More about how we built our website you can read here.

First, the context - we use Gatsby, we need to generate ~3100 image thumbnails, execute ~70 queries and build 60 pages. It takes almost 14 mins on Vercel without Gatsby’s build caching. We’re experimenting with Gatsby Cloud and it looks very promising. Fresh build takes about 5-6 mins and concurrent (with build cache and already generated thumbnail) 3-4 mins.

Good question! Naming things is a tough nut to cract, especially in fast, evolving web-dev space. If we define Headless CMS as a CMS that is decoupled from the frontend then Forestry or Netlify CMS seem to fit since they don’t generate any templates nor HTML. They just edit the file in the repo. If you connect it with something like Gatsby, you can treat those flat files (md, mdx, yml, json and so on) as your “internal content API”. It’s true it’s not easy to make that API available everywhere, but often you don’t need that.

Forestry runs on managed servers and treats your repository as content source. You can switch it to other Git-based CMS or remove completly and your website will still work. It doesn’t generate HTML like WordPress and other “traditional” CMS do.

Vercel uses Cloudflare CDN under the hood, there is a way to bypass it and use Cloudflare explicitly what we did. The first reason is that we wanted to use other Cloudflare features like Workers which are available only when you use the official Cloudflare CDN. We use Cloudflare as both DNS Server and Proxy. Cache-headers can be managed in Cloudflare settings panel via Page Rules. Right now we manage them through the Cloudflare API in a Worker.