Gatsby raises $15M Series A for its modern web development platform

For a very long time, I've been fond of Jekyll. It's mostly because my open source projects are hosted on GitHub and Jekyll is their go-to framework. There's nothing wrong per se with Jekyll. I was simply missing some features from React.

When I was working on React apps, the main benefits for me were: (i) component encapsulation and (ii) CSS Modules. It's easy to understand what a component does just by looking at it. If it gets too complicated, you can simply split it into another component. And CSS Modules are a life saver. The two hardest things in CSS are floats and naming things. That second part is solved now.

My issue with React however is the whole Webpack setup, and the fact that JS is required to run the website.

So when Gatsby appeared, I was pleasantly surprised to see it solved these issues. I ended up rebuilding my website with Gatsby, and I'm currently using it for 2 client projects.

My only issue with Gatsby is its reliance on GraphQL. I tried understanding the GraphQL concepts and purpose, especially with its weird syntax, but it feels over-engineered. Or at least, it doesn't feel like Gatsby needs GraphQL. So I'm not sure why it's so tightly tied to it. What I end up doing for fetching/storing data is using some static JSON files. It's easy to read, to port, and to parse.

I only use GatsbyJS.org the open source project, not GatsbyJS.com the service. But it seems to be similar to WordPress.org/WordPress.com, or what Ghost does. Even if the open source project somehow died, I wouldn't feel stuck with the framework ; since most of the codebase are React components, it'd be easy to port to another platform. That's another benefit.

This is an entirely serious question. I've got multiple few-hundred-line projects in development at work replacing internal tools - yes, they solve 90% of the use cases but the remaining 10% were generally either ill-advised or theoretical - and I don't know either how to get teams of developers not to build bloated messes or how to communicate that my smaller product shouldn't be taken less seriously for having fewer LOC.

About raising that series A, I hope they have a bigger plan in mind than hosting sites or yet another CMS. If the vision is the "reinvent" the way we work on static sites, I respect that, but I don't see a business case there.

[1]: https://gohugo.io [2]: https://www.netlifycms.org/

We were once tasked to build a website for a small publishing house. The site would have pages of books and of authors. Each book page would link to the page(s) of the book's author(s). Each author's page would have thumbnail(s) of this author's book(s). There was also to be an index page, which would contain various books, with names of respective authors, and links to each book's and author's page. It was almost like describing a simple relational database.

Except we wanted the site to be static, and the data about books and authors to be stored in yaml files on github. So book page, author page and index page needed to learn about each other at build time by reading the frontmatter of the yaml files.

With Gatsby's graphql data layer doing so would be trivial, and the whole developer experience would have been highly satisfying. But we weren't allowed to use Gatsby, because the size of the main javascript file that Gatsby (coupled with Netlify CMS) would output was approximately 100 kB, and our tech lead had a strong aversion to large javascript files and to what he considered an overengineered framework. So we had to use Hugo instead. Which we did. Hugo, bless it, also allowed building relationships between data files at build time; but the way it did so was so unintuitive and its Go-based templating language was so cumbersome that I hated almost every moment of working with Hugo. Besides, barebones Hugo did not have a flexible enough static assets pipeline, so we had to write our own (gulp) scripts for bundling static assets. With Gatsby, that would have come out of the box.

Gatsby may not be the technology for building lightest-weight sites (no matter how much the Gatsby team emphasises their commitment to performance), but the developer experience when working with Gatsby is unsurpassable.