Gatsby raises $15M Series A for its modern web development platform(techcrunch.com)
techcrunch.com
Gatsby raises $15M Series A for its modern web development platform
https://techcrunch.com/2019/09/26/gatsby-raises-15m-series-a-for-its-modern-web-development-platform/
212 comments
Yeah you look at hugo there are 0 npm dependencies while you can use it with react and and npm based build its optional which is nice. Now that the vast majority of browsers use script type="module" there is no longer a dire need for npm, es6 modules can now be used without a complex webpack process behind their inclusion.
It should be pretty easy to auto-generate static sites from wordpress.
Shifter and HardyPress already do so. That gets you all the advantages of static sites, combined with all the advantages of WordPress(ecosystem, tools, affordable labor, easy to use by clients).
Their only major limitation is that they generate/"compile" the whole site, and this takes time.
But that seems solvable by caching(in most cases) and by scaling(which may be easy with serverless). I think it's just a matter of time.
Shifter and HardyPress already do so. That gets you all the advantages of static sites, combined with all the advantages of WordPress(ecosystem, tools, affordable labor, easy to use by clients).
Their only major limitation is that they generate/"compile" the whole site, and this takes time.
But that seems solvable by caching(in most cases) and by scaling(which may be easy with serverless). I think it's just a matter of time.
A lot of WP features do not work in this case. The infra need to get this working is also not simple. And finally the code produced to get this to work (the mess of "hooks" called filters in WP iirc) does not at all resemble the clean React code base of my Gatsby website project.
I argue maintainability is the main reason for me to choose Gatsby over WP for projects where the choice makes sense.
I argue maintainability is the main reason for me to choose Gatsby over WP for projects where the choice makes sense.
Most WordPress plugins work with a statically generated WP site. For functionality that generally demands db communication, there are many services that have been created for use on static sites that can be used on WP too. We created a static tools directory for our users on Strattic so that they can easily find those types of services when moving their sites to Strattic, or building for Strattic: https://www.strattic.com/static-tools/
Sure, database driven WP features, don't work - As they should.
You just need to select your plugins from a smaller set, and use external services like disqus for database based service.
And i think with time that thinking could lead to a set of plugins with good security through isolation.
As for hosting complexity - for many sites, this could be hidden from the developer and the client.
And regarding code complexity - how often are custom wordpress plugins or themes(without a site builder) required ? and how much developer time does it take ?
You just need to select your plugins from a smaller set, and use external services like disqus for database based service.
And i think with time that thinking could lead to a set of plugins with good security through isolation.
As for hosting complexity - for many sites, this could be hidden from the developer and the client.
And regarding code complexity - how often are custom wordpress plugins or themes(without a site builder) required ? and how much developer time does it take ?
Interesting, however the price per month to have a useful site running is ~$20/month; there are plenty of free static hosting solutions for Gatsby, which are both fast and quite easy to use.
Did you mean "overly-complicated" as in for people who don't work in the industry and just speculate on trends?
Not OP but the mess that is node and its ecosystem is indeed overly-complicated
It's hidden away behind layers of stuff for the most part, but, I agree (and this is coming from someone who works with Gatsby every day); I recently added Typescript support as well so now, with the handful of packages we have in our monorepo, it's becoming a convoluted mess of webpack, babel, typescript, and the tooling in between like gatsby and storybook, which do configuration sliiightly different.
Honestly I got so frustrated with dealing with dependency hell the other day that I only half-jokingly said I was going to go back to writing vanilla ES5, whichever the last version that still works on IE is. It's just too much of an obscure headache, too much tooling and intermediary steps.
I can't get our error reporting tool to work properly because the source maps are a confusing jumble either.
Mind you this is aimed at the JS ecosystem in its current state; Gatsby itself has been great.
Honestly I got so frustrated with dealing with dependency hell the other day that I only half-jokingly said I was going to go back to writing vanilla ES5, whichever the last version that still works on IE is. It's just too much of an obscure headache, too much tooling and intermediary steps.
I can't get our error reporting tool to work properly because the source maps are a confusing jumble either.
Mind you this is aimed at the JS ecosystem in its current state; Gatsby itself has been great.
I've been writing my side project in vanilla es5. I use rollup for bundling, and nothing else. Life is great.
At least in the React eco-system I got the feeling that Gatsby does mostly it's own thing.
You can setup a Next.js system with mostly regular React skills.
You can setup a Next.js system with mostly regular React skills.
[deleted](3)
> Convince the WordPress/enterprise crowd to switch over
The Gatsby homepage mentions Wordpress as a possible data source. I don't evens see mention of their CMS on the front page. The only "service" I see them advertising there is Preview - which seems to be a development collaboration tool. I don't think they're convincing people to move away from Wordpress.
It's funny that the article talks about moving away from your monolithic "CMS system" (redundant?) so that you can use headless Wordpress or Drupal. In other words, you get to toss your monolithic content management system system so that you can keep your monolithic content management system system.
The Gatsby homepage mentions Wordpress as a possible data source. I don't evens see mention of their CMS on the front page. The only "service" I see them advertising there is Preview - which seems to be a development collaboration tool. I don't think they're convincing people to move away from Wordpress.
It's funny that the article talks about moving away from your monolithic "CMS system" (redundant?) so that you can use headless Wordpress or Drupal. In other words, you get to toss your monolithic content management system system so that you can keep your monolithic content management system system.
Yeah this isn't a Wordpress replacement; it's a framework for creating websites and / or hybrid websites, the way I see it. In that regard it competes with Next, Nest and Nuxt (I don't even know the last two, I lifted that from https://slides.com/seldo/jsconf-eu-2019#/60 ; are those all based on / similar to Next? They should fix their naming)
I believe Nuxt is the VueJS serverside framework version of Next. I've never heard of Nest before, that looks fairly new compared to Next/Nuxt.
Content managers like WordPress and have lots of experience with it. Using it as a backend is fine. Gatsby on the frontend has advantages (speed, security, etc). Combining the two makes a lot of sense.
Yes. It does. And it means you will use WP in a head-less setup.
The main problem is not using a large part of your WP codebase (so much for lean and mean) and that some features in WP dont work as expected.
Now you may want to keep WP up to date and the cost for this may be bigger then a head-less SaaS CMS.
The main problem is not using a large part of your WP codebase (so much for lean and mean) and that some features in WP dont work as expected.
Now you may want to keep WP up to date and the cost for this may be bigger then a head-less SaaS CMS.
This is the fundamental issue. Gatsby is a modern frontend framework that optimizes the visual experience and interactivity of a site, relying on React as the base tech. It's not an end-to-end solution though, and still requires a backend to provide the data itself, whether that's flat files at build time or a running CMS engine.
Compared to Wordpress, Ghost, and Webflow, it seems the market size for this is limited.
Compared to Wordpress, Ghost, and Webflow, it seems the market size for this is limited.
OMG what a great comment. I can't see your upvotes but I hope it was in the 1000s!
> I don't really like Gatsby's product
May I know why you don't like it and what alternatives you will recommend (if any)? I am considering Gatsby for building a site.
May I know why you don't like it and what alternatives you will recommend (if any)? I am considering Gatsby for building a site.
I can’t speak for the OP, but I like Hugo better than Gatsby as far as static site generators go. I think Hugo is easier to use and is a lot faster at generating sites. Gatsby does more than that, so it may be a good choice when you need something more than a static site generator; however, if I’m going to have to dick around with programming anyway I’d rather work with anything other than Node/JavaScript.
EDIT: I forgot to mention Zola, which I like quite well as far as static site generators go. It doesn’t have the support for multilingual sites that Hugo does, but its templating is much nicer, I think.
EDIT: I forgot to mention Zola, which I like quite well as far as static site generators go. It doesn’t have the support for multilingual sites that Hugo does, but its templating is much nicer, I think.
Yeah I dont think their target market is established enterprise commerce companies
I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content.
Some problems that I found after some months of integrating it with an existing CMS:
* Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS. Having this code executed in a Node process is expected because Gatsby is a static site generator, but this big split between the environment of development and production builds, paired with a growing codebase that keeps evolving, catches new developers on our team with multiple and surprising bugs.
* Debug complexity: JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode.
* Runtime requirements: as far as I remember, executing `gatsby build` on my development machine uses ~3.4 GiB of private RAM for the main node process, and it takes around 5 minutes if the local cache is cleared (it ends in around a minute with cache). Its important to remember this when choosing in which server the build runs.
* Integration: Gatsby does not provide out of the box integration with CMS for content authoring (like for example, page drafts).
Now to be honest, the global idea seems good (static websites built with React), but I would wait a few more years until it becomes more mature to use it again for any future project.
Some problems that I found after some months of integrating it with an existing CMS:
* Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS. Having this code executed in a Node process is expected because Gatsby is a static site generator, but this big split between the environment of development and production builds, paired with a growing codebase that keeps evolving, catches new developers on our team with multiple and surprising bugs.
* Debug complexity: JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode.
* Runtime requirements: as far as I remember, executing `gatsby build` on my development machine uses ~3.4 GiB of private RAM for the main node process, and it takes around 5 minutes if the local cache is cleared (it ends in around a minute with cache). Its important to remember this when choosing in which server the build runs.
* Integration: Gatsby does not provide out of the box integration with CMS for content authoring (like for example, page drafts).
Now to be honest, the global idea seems good (static websites built with React), but I would wait a few more years until it becomes more mature to use it again for any future project.
Now to be honest, the global idea seems good (static websites built with React)
Out of interest, what's good about building static websites with React?
Out of interest, what's good about building static websites with React?
If you're looking at purely static websites, then it's just a way to structure your application; matter of taste, I reckon, and there's plenty of alternatives on the market that go back twenty years if need be. That said, personally I'm quite fond of the component based approach to building websites - and React isn't the only player there.
But the strengths show when you combine it with e.g. Gatsby which turns it into a hybrid website + app. For first time visitors, search engines, and people with JS disabled it's just static HTML, simple. But for most visitors (browsers, JS enabled etc), after the first load it turns into a webapp and any pageview only requires a single .json file to be pulled in, which can be prefetched (on link hover for example) as well. This gives it the performance characteristics of a single-page app.
But the strengths show when you combine it with e.g. Gatsby which turns it into a hybrid website + app. For first time visitors, search engines, and people with JS disabled it's just static HTML, simple. But for most visitors (browsers, JS enabled etc), after the first load it turns into a webapp and any pageview only requires a single .json file to be pulled in, which can be prefetched (on link hover for example) as well. This gives it the performance characteristics of a single-page app.
> what's good about building static websites with React
As compared to which alternatives?
Personally, I find the splitting up of code into components, together with the power and expressiveness of jsx and its closeness to plain javascript, and the simplicity of updating the ui in response to changes of state to be a very compelling argument for react.
As compared to which alternatives?
Personally, I find the splitting up of code into components, together with the power and expressiveness of jsx and its closeness to plain javascript, and the simplicity of updating the ui in response to changes of state to be a very compelling argument for react.
I prefer React over any other templating lang I’ve used so far.
Though I never liked Gatsby.
Though I never liked Gatsby.
> JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode
I don't get it, is this some Gatsby limitation? I've been debugging JSX since the dawn of time with breakpoints, even with SSR and typescript
I don't get it, is this some Gatsby limitation? I've been debugging JSX since the dawn of time with breakpoints, even with SSR and typescript
To me its a bit tricky to summarize, so its a long answer.
During the build, Gatsby compiles JSX and saves the result in a temporal folder. Some time after, it spawns several subprocesses that execute the mentioned resulting JS files (to render each page in the site).
What I meant with "the JSX code is hard to debug" is:
* The JSX code is actually run inside subprocesses, and NodeJS allows to debug a process if its run with the `--inspect` command line argument. But I did not found documentation in the Gatsby website about how to change the arguments of these subprocesses. Note that this only applies to production builds (development mode executes all JSX in the browser).
* From the text editor perspective, the breakpoints are defined in the original JSX source files, not the built ones. I understand that in theory line/column mapping can be done using map files, but I did not have time yet to investigate the cleanest way to make the IDE, Docker (not actually a Gatsby requirement), the temporal Webpack build directory, and Gatsby subprocesses to work together.
During the build, Gatsby compiles JSX and saves the result in a temporal folder. Some time after, it spawns several subprocesses that execute the mentioned resulting JS files (to render each page in the site).
What I meant with "the JSX code is hard to debug" is:
* The JSX code is actually run inside subprocesses, and NodeJS allows to debug a process if its run with the `--inspect` command line argument. But I did not found documentation in the Gatsby website about how to change the arguments of these subprocesses. Note that this only applies to production builds (development mode executes all JSX in the browser).
* From the text editor perspective, the breakpoints are defined in the original JSX source files, not the built ones. I understand that in theory line/column mapping can be done using map files, but I did not have time yet to investigate the cleanest way to make the IDE, Docker (not actually a Gatsby requirement), the temporal Webpack build directory, and Gatsby subprocesses to work together.
Gatsby does ssr in batch during build time. The pages are rendered in a pool of worker processes. I haven't found a way to tell gatsby to attach my debugger when launching those processes.
Gatsby's docs on debugging HTML builds [1] give you adhoc solutions for specific problems you may have, but 0 info on actually debugging.
Gatsby's docs on debugging HTML builds [1] give you adhoc solutions for specific problems you may have, but 0 info on actually debugging.
> Not recommend in a project that requires more than a scrollable site
I agree. Though I’d add that I found it too complex for a quick .md -> html site as well.
Next does a better job at complex things and one might as well use Hugo/Hexo for a .md blog. I don’t know how much can be found in between.
I agree. Though I’d add that I found it too complex for a quick .md -> html site as well.
Next does a better job at complex things and one might as well use Hugo/Hexo for a .md blog. I don’t know how much can be found in between.
> I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content.
FreeSewing.org runs on Gatsby. It generates made-to-measure sewing patterns, so I think that qualifies as beyond static-scrollable content.
While it's not magic, it is a powerful platform to build your frontend on. JAMStack is a godsend for small open source projects like us since you can just deploy to Netlify and walk away.
We do have a backend (using Express) but it's very minimalistic. Most things are simply handled client-side which means scaling up is a non-issue.
Obviously there are downsides to pushing such an amount of code to the client, but going with JAMStack isa choice we made that we can hardly blame Gatsby for.
I've since written 2 plugins for it for specific needs I had, and contributed some code left and right.I think that's testament to how it's not that hard to wrap your head around.
I've used other static site generators (Jekyl, Phenomic, and brief encounters with Hugo and Hexo) but Gatsby is the first that made me feel I wasn't fighting against it.
Gatsby makes sense for us, as it makes sense for others too. I would recommend it to anyone who is looking for a way to use JAMStack and is comfortable with using React.
FreeSewing.org runs on Gatsby. It generates made-to-measure sewing patterns, so I think that qualifies as beyond static-scrollable content.
While it's not magic, it is a powerful platform to build your frontend on. JAMStack is a godsend for small open source projects like us since you can just deploy to Netlify and walk away.
We do have a backend (using Express) but it's very minimalistic. Most things are simply handled client-side which means scaling up is a non-issue.
Obviously there are downsides to pushing such an amount of code to the client, but going with JAMStack isa choice we made that we can hardly blame Gatsby for.
I've since written 2 plugins for it for specific needs I had, and contributed some code left and right.I think that's testament to how it's not that hard to wrap your head around.
I've used other static site generators (Jekyl, Phenomic, and brief encounters with Hugo and Hexo) but Gatsby is the first that made me feel I wasn't fighting against it.
Gatsby makes sense for us, as it makes sense for others too. I would recommend it to anyone who is looking for a way to use JAMStack and is comfortable with using React.
A static page framework that shoves content into a client side graphql store and then extracts bits out to render a page?
It's popular, so I can't say it was a bad idea.
I guess I'll just say I must be old because it sounds like satire.
It's popular, so I can't say it was a bad idea.
I guess I'll just say I must be old because it sounds like satire.
I don't really get the GraphQL part yet either. I really like the concept of static sites with instant client-side page transitions, but for the vast majority of those, it doesn't seem like putting all the data into a GraphQL database before inserting it into the templates solves a problem?
I've been using React Static [1] for that now, where you just load the data in memory. I'd expected to discover in the process why GraphQL is so useful, but I did not. This might just be my limited point of view.
I guess as soon as you're dealing with lots and lots of data it might be useful, but the projects for which that is the case and which want a mostly-static site seem like they're a very small niche.
[1] https://react-static.js.org/
I've been using React Static [1] for that now, where you just load the data in memory. I'd expected to discover in the process why GraphQL is so useful, but I did not. This might just be my limited point of view.
I guess as soon as you're dealing with lots and lots of data it might be useful, but the projects for which that is the case and which want a mostly-static site seem like they're a very small niche.
[1] https://react-static.js.org/
I still prefer Hugo 1000x over this, especially because I don't have to deal with npm
That's what the lemmings said before they jumped the cliff ;-)
Let me offer a real-world example.
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.
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.
I've had a lot of good experiences with Jekyll, and I'm fairly sure that the problem you've described would have worked nicely with it. Extending it is also really straightforward, you just put a few lines of Ruby in a file in the right place.
I've moved my site from Jekyll to Gatsby, and while there are some nice things, it's not been a clear win. My site is very significantly slower for first load, but slightly faster for all subsequent loads. The build is far less stable with Gatsby, there are ~5 dependency updates per day, things like Sass don't "just work" anymore, but on the other hand, there are a few more packages that do useful things that I didn't get in the Jekyll community.
I've moved my site from Jekyll to Gatsby, and while there are some nice things, it's not been a clear win. My site is very significantly slower for first load, but slightly faster for all subsequent loads. The build is far less stable with Gatsby, there are ~5 dependency updates per day, things like Sass don't "just work" anymore, but on the other hand, there are a few more packages that do useful things that I didn't get in the Jekyll community.
The really dumb part is that GraphQL has more restrictions than JSON on property names, so you can't actually render arbitrary JSON data with gatsby without breaking the GraphQL schema and getting a ton of errors.
It seemed nice at first, but the way they tell you to deal with images and other resources is ridiculous overengineered and gets in the way.
If you throw real data at it, your builds explode from seconds to minutes.
Ill considered, chasing too many fads, and the inability to turn it all off if you don't need it.
That's what gatsby felt like.
It seemed nice at first, but the way they tell you to deal with images and other resources is ridiculous overengineered and gets in the way.
If you throw real data at it, your builds explode from seconds to minutes.
Ill considered, chasing too many fads, and the inability to turn it all off if you don't need it.
That's what gatsby felt like.
I totally agree with you on the images part, I've been working with Gatsby for a while now and their own image implementation is dreadful. Thankfully you can just use the standard React method.
Gatsby co-founder here. We're super excited for this so we can make Gatsby even more awesome. Happy to answer any Qs!
You're getting questions about target market, and I'm pretty sure the answer is web development agencies, right? Any shop with a high volume of projects will need a development pipeline, stack, and ops story that is straight forward and fast to work with.
Yep! Right now we're seeing a mix of customers that's roughly 1/3 web development agencies, 1/3 e-commerce websites, and 1/3 B2C lead generation websites.
The value proposition of Gatsby to website agencies is working with modern tech & completing projects faster, and for e-commerce it's higher conversion rates which add $$ to the bottom line.
The value proposition of Gatsby to website agencies is working with modern tech & completing projects faster, and for e-commerce it's higher conversion rates which add $$ to the bottom line.
"Happy to answer any Qs!"
And then he doesn't answer any.
And then he doesn't answer any.
Your pricing model doesn't offer any benefit for paying annually; in fact, given the time value of money, it is a disincentive. Being paid up front means you can deploy that cash to grow.
What needs to be done in Gatsby after so many years of intense development? Is it really so complicated to finish a program that generates HTML sites?
Congrats Sam!
This is extremely surprising, right? I clicked the headline thinking it was a shame some tech company chose the same name as a fairly popular static site generator. I guess when I see things like $50/mo for them to host a site, I just assume it's an extremely small team with a couple clients.
I'm very surprised that a static site generator can raise this much capital, but it suggests to me that 1) the security dilemmas of non-static but content driven sites are still big enough to warrant adoption of this methodology 2) potentially, there is something they are doing right in this space.
I'd really like to know what 2 is as there's a lot of other options in this space that are also free, open source, and seem to accomplish the same thing. What is the Gatsby sauce?
I'd really like to know what 2 is as there's a lot of other options in this space that are also free, open source, and seem to accomplish the same thing. What is the Gatsby sauce?
Raising capital isn't success. Profitability is success.
I think the main value of Gatsby is the community-generated recipes to plug and play...but is there value here?
If you have one very generic application, then maybe you save time upfront. But you are tied into this heavy wrapper around React that will probably cause you problems down the line. And you probably still need a backend. So I am not sure what value is being created?
If you specifically need to generate lots of sites, or you have some performance requirement (and data that doesn't change often) then maybe. But I wouldn't use it to build anything complex (i.e. that would tie me into their product) because building an app isn't that much harder. I am sure there is a niche use but I think most people aren't doing anything complicated with it (I use it that way).
I also don't really see how this could be a Wordpress killer (which is the intent of the fundraising presumably). Wordpress is totally end-to-end, it abstracts away all the right parts. This doesn't. $15m won't change that.
In theory, I think applications like Prismic or Contentful (I think it is) actually break up these tasks better. From your app, you have a (usually) simple API. And it reflects the division of labour in most companies i.e. that code and content are separate (before anyone says it: they aren't offering a different product to Gatsby, if it seems that way then that is the point).
I think the main value of Gatsby is the community-generated recipes to plug and play...but is there value here?
If you have one very generic application, then maybe you save time upfront. But you are tied into this heavy wrapper around React that will probably cause you problems down the line. And you probably still need a backend. So I am not sure what value is being created?
If you specifically need to generate lots of sites, or you have some performance requirement (and data that doesn't change often) then maybe. But I wouldn't use it to build anything complex (i.e. that would tie me into their product) because building an app isn't that much harder. I am sure there is a niche use but I think most people aren't doing anything complicated with it (I use it that way).
I also don't really see how this could be a Wordpress killer (which is the intent of the fundraising presumably). Wordpress is totally end-to-end, it abstracts away all the right parts. This doesn't. $15m won't change that.
In theory, I think applications like Prismic or Contentful (I think it is) actually break up these tasks better. From your app, you have a (usually) simple API. And it reflects the division of labour in most companies i.e. that code and content are separate (before anyone says it: they aren't offering a different product to Gatsby, if it seems that way then that is the point).
> Raising capital isn't success. Profitability is success.
Automattic just raised $300 million dollars a week or so ago.
One vision of success, I'm very sure, is getting acquired by Automattic.
Automattic just raised $300 million dollars a week or so ago.
One vision of success, I'm very sure, is getting acquired by Automattic.
It doesn't look like Gatsby itself is what is the main selling point, and I'd argue, the VC doesn't think Gatsby itself is either.
Gatsby Preview / Gatsby Content Mesh is most likely the horse being bet on.
Gatsby Preview / Gatsby Content Mesh is most likely the horse being bet on.
I've been using Gatsby to develop some sites and I suppose the benefit is you can largely develop like you would a frontend app and deploy like a static site. It is actually quite nice to use though the GraphQL takes a while to get used to.
It bakes in things that make the experience better. SPA routing and high lighthouse scores are nice, but if they take a lot of work to accomplish, they might not be worth it for a small media site. If they're as easy as WordPress, however, then you're giving WordPress some real competition.
I hear this, but is this a differentiator when compared to the other static site generators?
I was under the impression that Gatsby was just another interchangeable part of the so-called JAMstack...? Could you not get those wins using Pelican, or Hugo, or whatever?
I was under the impression that Gatsby was just another interchangeable part of the so-called JAMstack...? Could you not get those wins using Pelican, or Hugo, or whatever?
2 - I'm not a developer, i just did a few wordpress themes, while looking at a static site generators i gave a try to gatsby because of the way it use images and it was a joy, i learned some javascript, discovered react, used a lots of things for the first time and it was just a great experience, lots of tools, good documentation, it was just fun for me.
> I'd really like to know what 2 is as there's a lot of other options in this space that are also free, open source, and seem to accomplish the same thing. What is the Gatsby sauce?
I just browsed around their site wondering the same thing, the conclusion I reached was that their main value proposition is the integrations they provide together with the automation and deployment pipeline as a service. But I must also say it is pretty unclear what you are actually buying with the $50/mo subscription; what do you get compared to just running the software on your laptop?
I just browsed around their site wondering the same thing, the conclusion I reached was that their main value proposition is the integrations they provide together with the automation and deployment pipeline as a service. But I must also say it is pretty unclear what you are actually buying with the $50/mo subscription; what do you get compared to just running the software on your laptop?
> I'm very surprised that a static site generator can raise this much capital
Why?
They charge $50/mo and maybe the recurring revenue checks out for preferential investors to feel comfortable with making a profit. If Gatsby can get their service included in a bunch of the domain name registration sites, pushing out Wordpress, then they get exponentially more customers!
The real question is what they plan to do with the $15 million, followed by why the founders wanted to give up that much of the company as the revenue is probably fine. I don't think they actually are scaling majorly, except sales people. I think they are going to be subsidizing open source development, another developer day care shop that ideally will have the byproduct of making the tooling they use even more easy to use.
Any insight?
Why?
They charge $50/mo and maybe the recurring revenue checks out for preferential investors to feel comfortable with making a profit. If Gatsby can get their service included in a bunch of the domain name registration sites, pushing out Wordpress, then they get exponentially more customers!
The real question is what they plan to do with the $15 million, followed by why the founders wanted to give up that much of the company as the revenue is probably fine. I don't think they actually are scaling majorly, except sales people. I think they are going to be subsidizing open source development, another developer day care shop that ideally will have the byproduct of making the tooling they use even more easy to use.
Any insight?
> If Gatsby can get their service included in a bunch of the domain name registration sites, pushing out Wordpress, then they get exponentially more customers!
I don't follow this reasoning. The hosting sites that offer Wordpress, offer it because it is free. GatsbyJS is free. The service offered by Gatsby is not. Given the difference between $0 and $50/month, I don't see Wordpress going away anytime soon.
I don't follow this reasoning. The hosting sites that offer Wordpress, offer it because it is free. GatsbyJS is free. The service offered by Gatsby is not. Given the difference between $0 and $50/month, I don't see Wordpress going away anytime soon.
How much of that $50/month do you think may be on offer to entice those hosting sites to try to upsell?
Thanks for the feedback!
Gatsby has existed as an open-source project for >4 years, but we just launched our CMS Preview in open beta about 3 months ago -- lots more to come on that front!
Gatsby has existed as an open-source project for >4 years, but we just launched our CMS Preview in open beta about 3 months ago -- lots more to come on that front!
Big fan of static site generators and the whole JAMStack idea in general - I use Jekyll extensively - but after building a site with Gatsby, I found it too over-engineered.
React is great, and definitely has its place, but to set up React, GraphQL and all the surrounding tooling just to assemble some text files into a template seems like complexity for the sake of it.
For me, the fun of static sites - after years of building sites with CMSs like Wordpress and Drupal - is that they’re as close as possible to plain HTML, lightning-fast and very simple.
React is great, and definitely has its place, but to set up React, GraphQL and all the surrounding tooling just to assemble some text files into a template seems like complexity for the sake of it.
For me, the fun of static sites - after years of building sites with CMSs like Wordpress and Drupal - is that they’re as close as possible to plain HTML, lightning-fast and very simple.
> complexity for the sake of it.
It's not for the sake of it. It's so Gatsby didn't have to achieve much beyond wrapping some complicated frameworks to be useful. Basically, about 5 minutes into setting up Gatbsy, you go "Oh, so it's just React and GraphQL. Ok..."
It's not for the sake of it. It's so Gatsby didn't have to achieve much beyond wrapping some complicated frameworks to be useful. Basically, about 5 minutes into setting up Gatbsy, you go "Oh, so it's just React and GraphQL. Ok..."
If Gatsby did not feel different and not offered what Jekyll / Hugo / Zola offer, what would be the point?
If existing solutions are near perfect for you, you are not the target audience.
If existing solutions are near perfect for you, you are not the target audience.
What itch is Gatsby scratching?
I'm one of the use cases that Sam mentions - B2C website. Replatforming our site with Gatsby, Netlify (hosting and more) and Contentful (headless CMS) has saved us hundreds of dollars a month in hosting - our site which receives 20,000 - 30,000 visitors a month now costs $0 to host. Additionally it is radically faster and more secure than it previously was. Being able to use React as needed has enabled us to manage some relatively complicated form handling/routing, get really creative around how we handle 'sites within the site' for a large sales team that we support, and easily create calculators and other tools for our customers.
And bonus - I'm a graphic designer by trade. For one reason or another a web team of 7+ people left my company over the course of 6months and I stepped in to fill the void. Just me, one person who had prior experience building the odd site (maybe one a year) with HTML, CSS. I literally learned javascript and React through Gatsby (I'd say I'm junior developer level at this point - which is actually a good fit for my company).
Gatsby is a great product (for many use cases), run by a generous team, surrounded by an equally generous community. I owe my career to Gatsby. My company is saving hundreds of thousands of dollars a year thanks to Gatsby. Stoked to see Gatsby's continued growth and success.
And bonus - I'm a graphic designer by trade. For one reason or another a web team of 7+ people left my company over the course of 6months and I stepped in to fill the void. Just me, one person who had prior experience building the odd site (maybe one a year) with HTML, CSS. I literally learned javascript and React through Gatsby (I'd say I'm junior developer level at this point - which is actually a good fit for my company).
Gatsby is a great product (for many use cases), run by a generous team, surrounded by an equally generous community. I owe my career to Gatsby. My company is saving hundreds of thousands of dollars a year thanks to Gatsby. Stoked to see Gatsby's continued growth and success.
This sounds way too good to be true.
Specially considering the stories from other people here, which include a lot more technical detail.
Also the other users are not new accounts with just one comment (unlike the user above).
Specially considering the stories from other people here, which include a lot more technical detail.
Also the other users are not new accounts with just one comment (unlike the user above).
Am I more convincing, with a six year old account?
I'm the exact target market for Gatsby, and can confirm the benefits that GP gave. Perhaps I can tell you how I've been selling it to my clients. I work at an agency, which builds sites in the ~$100k range. Most of our clients are currently using something like Drupal, or an ancient proprietary CMS. The RFPs now often specify Drupal "or other open source CMS". We're now offering them Gatsby + headless Drupal, and it gives them some significant benefits. These are sites that are currently paying thousands per month on multiple load-balanced Drupal servers, or managed hosts like Acquila. Gatsby lets them switch to a single Drupal instance on something like Lightsail, firewalled to give access to just their admins. Gatsby can then build the site (using CodeBuild or Amplify) and deploy to S3, so their hosting fees are then tens of dollars in CloudFront egress plus Lightsail. They also don't need 24x7 Drupal support, because it doesn't matter if the server ges down in the middle of the night, because their site stays up, and they don't need instant Drupalgeddon patching because their server isn't public-accessible.
I think the classic JAMStack/Markdown features of Gatsby are a red herring. I love them for my own site, but no client will use them (even with Netlify CMS, unfortunately). However it gets developers like me to try it out, and hopefully realise the benefits that it can offer.
I'm the exact target market for Gatsby, and can confirm the benefits that GP gave. Perhaps I can tell you how I've been selling it to my clients. I work at an agency, which builds sites in the ~$100k range. Most of our clients are currently using something like Drupal, or an ancient proprietary CMS. The RFPs now often specify Drupal "or other open source CMS". We're now offering them Gatsby + headless Drupal, and it gives them some significant benefits. These are sites that are currently paying thousands per month on multiple load-balanced Drupal servers, or managed hosts like Acquila. Gatsby lets them switch to a single Drupal instance on something like Lightsail, firewalled to give access to just their admins. Gatsby can then build the site (using CodeBuild or Amplify) and deploy to S3, so their hosting fees are then tens of dollars in CloudFront egress plus Lightsail. They also don't need 24x7 Drupal support, because it doesn't matter if the server ges down in the middle of the night, because their site stays up, and they don't need instant Drupalgeddon patching because their server isn't public-accessible.
I think the classic JAMStack/Markdown features of Gatsby are a red herring. I love them for my own site, but no client will use them (even with Netlify CMS, unfortunately). However it gets developers like me to try it out, and hopefully realise the benefits that it can offer.
My biggest concern with Gatsby is the build time. Drupal is not exactly known for being fast, and as I understand it, Gatsby asks for the entire site's worth of content for every build, right? How has that worked out for you?
I have Drupal sites with dozens of entity types and tens of thousands of nodes. I feel like Gatsby would have us waiting for an hour-long build every time we want to post a new node.
I have Drupal sites with dozens of entity types and tens of thousands of nodes. I feel like Gatsby would have us waiting for an hour-long build every time we want to post a new node.
To be fair, I think the guy above you might be talking about different use cases.
If it's just a static landing page I think the Jamstack/Gatsby/Gridsome would be fine.
If it's anything more complex though, you have my condolences. Ecommerce honestly sucks for the reasons others have mentioned.
I've almost finished a Shopify build with Nuxt.js and there have been so many hard learnings.
The more painful one was storing checkoutIds using SSR and cookies. I still don't know if it's best practice or not :/
If it's just a static landing page I think the Jamstack/Gatsby/Gridsome would be fine.
If it's anything more complex though, you have my condolences. Ecommerce honestly sucks for the reasons others have mentioned.
I've almost finished a Shopify build with Nuxt.js and there have been so many hard learnings.
The more painful one was storing checkoutIds using SSR and cookies. I still don't know if it's best practice or not :/
I definitely understand the disbelief, but this is the truth. I started visiting hacker news to try to familiarize myself with the tech world, learn new jargon, blah blah blah, and have always just lurked. I think so highly of Gatsby that I finally created an account just to say so.
Like I said, I come from a graphic design background. Mostly freelancing and working for different organizations that just needed an in house guy to do a little bit of everything. Low pay stuff in non-tech organizations - literally a small boutique in one case where I also managed retail workers. I never really got a good career off the ground for many reasons, one of which was probably the "great recession". Not a ton of demand for mediocre graphic designers who aren't very career oriented to begin with.
Probably around 4 years ago I got it in my head that maybe I could learn to build websites and either get a side hustle going or work my way into it. I did online courses, videos, etc., but never had the money or guts to jump into a code camp or something more legit, and honestly nothing really stuck.
Started a new graphic design gig around 3 years ago. The company was in Real Estate. Like I said - large sales team that really needs their own mini-sites within a site as the service we provide is really driven by their personal brands and relationships. As a designer on a small design team I mostly produced print ads for the sales folks - we were like a mini agency and a way of recruiting top talent. A strong corporate brand / web presence hasn't been necessary to create a successful company of just under 1000 employees, although everyone involves knows that it would only help the business. Pretty shortly into my time there I watched the web team (this includes a project manager, front end developer, ui/ux designer, 3 person SEO/analytics team, a content/data entry person, a middle manager for all of them, and some resources from the IT department) fall apart. That group wasn't really producing much - they refused to even build landing pages, didn't do any kind of SEM, etc. This is for a variety of reasons many of them political. Maybe this entire environment seems a little crazy, but I think this is far more common in many industries than people involved in tech might realize.
At some point an agency was brought in to manage the web presence, but they were very obviously neglecting our site. Managers in my department knew I had done some web in the past and used me to run around the agency. The agency kind of knew it, and even had me do stuff on their behalf - I didn't care it beat designing ads for local newsletters, and mailers. A really generous javascript developer at the agency mentioned Gatsby to me once, saying that he wanted to build everything on it, including the next iteration of our website. I could see the writing on the wall, so I decided to learn it thinking(hoping) that I might have to maintain a Gatsby site one day. I think 1.0 had just been released at that point. Not long after, they were fired and I was left holding the ball.
The site I inherited was built on wordpress. Because of the neglect it was many versions out of date, and rotting the way wordpress sites can when they aren't maintained. I did what I could to hold it together and doubled down on learning Gatsby and React. When I started replatforming our website it was a lot of false starts, I played with Hugo, headless wordpress in Gatsby, all kinds of schemes - honestly figuring it out as I went along. Eventually stuff started coming together. Each feature I was forced to build (was making an exact duplicate of the wordpress site) forced me to learn more about the toolset that was organically coming together - gatsby (which includes react and graphql), netlify, contentful, mailgun (remember that complicated form routing/logic), and more. I asked the IT dept, what the wordpress instance for our og site was costing us and learned it was $500+ a month. I did everything I could to keep us in Contentful and Netlify free tiers and have done so. We do pay $15/month for a service that does some form routing/templating magic for us - but that's the only cost these days.
In the end it took me around 6months to do something that would have taken an agency a month to fulfill. But, I also helped on a lot of random projects (it's amazing what people will let you be a part of when you are eager), and served as webmaster for the first site. During that time leadership at my company wasn't really ready to think about web, so in the end I have provided a great value - a huge cost savings for them over what they were spending and even what they otherwise would be today. I think a lot of people here would cringe to look at my code. It looks like what was written by who it was - someone learning as they went. But, nothing ever breaks, site hasn't been down once since replatforming and moving to netlify, site traffic has increased, we finally pass security audits, page load time went from 8seconds average to somewhere around 1-2 seconds on average. I spin up landing pages regularly, and have plans for meeting unique industry needs in a way that is doable and maintainable by just me.
At the end of the day I'm a novice who's making it work on my end mostly by force of will in an industry where a web presence is only just starting to matter. BUT none of it would be doable without Gatsby. Their community, documentation, and product are all amazing. I'm convinced that if my story didn't include Gatsby I wouldn't be provided the opportunities I currently.
If you want to be cynical you can interpret all of that as 'guy at shitty company, in shitty industry, where web really doesn't matter, uses Gatsby to make site that just works, and saves a marginal amount of money that definitely had to be spent (hosting costs) and a large amount of money that probably shouldn't have ever been spent (bloated web team and agency that sat on their asses).'
from not enough detail to waaaaaaayyyyyyyyyy too much
Like I said, I come from a graphic design background. Mostly freelancing and working for different organizations that just needed an in house guy to do a little bit of everything. Low pay stuff in non-tech organizations - literally a small boutique in one case where I also managed retail workers. I never really got a good career off the ground for many reasons, one of which was probably the "great recession". Not a ton of demand for mediocre graphic designers who aren't very career oriented to begin with.
Probably around 4 years ago I got it in my head that maybe I could learn to build websites and either get a side hustle going or work my way into it. I did online courses, videos, etc., but never had the money or guts to jump into a code camp or something more legit, and honestly nothing really stuck.
Started a new graphic design gig around 3 years ago. The company was in Real Estate. Like I said - large sales team that really needs their own mini-sites within a site as the service we provide is really driven by their personal brands and relationships. As a designer on a small design team I mostly produced print ads for the sales folks - we were like a mini agency and a way of recruiting top talent. A strong corporate brand / web presence hasn't been necessary to create a successful company of just under 1000 employees, although everyone involves knows that it would only help the business. Pretty shortly into my time there I watched the web team (this includes a project manager, front end developer, ui/ux designer, 3 person SEO/analytics team, a content/data entry person, a middle manager for all of them, and some resources from the IT department) fall apart. That group wasn't really producing much - they refused to even build landing pages, didn't do any kind of SEM, etc. This is for a variety of reasons many of them political. Maybe this entire environment seems a little crazy, but I think this is far more common in many industries than people involved in tech might realize.
At some point an agency was brought in to manage the web presence, but they were very obviously neglecting our site. Managers in my department knew I had done some web in the past and used me to run around the agency. The agency kind of knew it, and even had me do stuff on their behalf - I didn't care it beat designing ads for local newsletters, and mailers. A really generous javascript developer at the agency mentioned Gatsby to me once, saying that he wanted to build everything on it, including the next iteration of our website. I could see the writing on the wall, so I decided to learn it thinking(hoping) that I might have to maintain a Gatsby site one day. I think 1.0 had just been released at that point. Not long after, they were fired and I was left holding the ball.
The site I inherited was built on wordpress. Because of the neglect it was many versions out of date, and rotting the way wordpress sites can when they aren't maintained. I did what I could to hold it together and doubled down on learning Gatsby and React. When I started replatforming our website it was a lot of false starts, I played with Hugo, headless wordpress in Gatsby, all kinds of schemes - honestly figuring it out as I went along. Eventually stuff started coming together. Each feature I was forced to build (was making an exact duplicate of the wordpress site) forced me to learn more about the toolset that was organically coming together - gatsby (which includes react and graphql), netlify, contentful, mailgun (remember that complicated form routing/logic), and more. I asked the IT dept, what the wordpress instance for our og site was costing us and learned it was $500+ a month. I did everything I could to keep us in Contentful and Netlify free tiers and have done so. We do pay $15/month for a service that does some form routing/templating magic for us - but that's the only cost these days.
In the end it took me around 6months to do something that would have taken an agency a month to fulfill. But, I also helped on a lot of random projects (it's amazing what people will let you be a part of when you are eager), and served as webmaster for the first site. During that time leadership at my company wasn't really ready to think about web, so in the end I have provided a great value - a huge cost savings for them over what they were spending and even what they otherwise would be today. I think a lot of people here would cringe to look at my code. It looks like what was written by who it was - someone learning as they went. But, nothing ever breaks, site hasn't been down once since replatforming and moving to netlify, site traffic has increased, we finally pass security audits, page load time went from 8seconds average to somewhere around 1-2 seconds on average. I spin up landing pages regularly, and have plans for meeting unique industry needs in a way that is doable and maintainable by just me.
At the end of the day I'm a novice who's making it work on my end mostly by force of will in an industry where a web presence is only just starting to matter. BUT none of it would be doable without Gatsby. Their community, documentation, and product are all amazing. I'm convinced that if my story didn't include Gatsby I wouldn't be provided the opportunities I currently.
If you want to be cynical you can interpret all of that as 'guy at shitty company, in shitty industry, where web really doesn't matter, uses Gatsby to make site that just works, and saves a marginal amount of money that definitely had to be spent (hosting costs) and a large amount of money that probably shouldn't have ever been spent (bloated web team and agency that sat on their asses).'
from not enough detail to waaaaaaayyyyyyyyyy too much
500 -> 15 dollars a month. So not really 0.
I'd also state, that is, for now. These services will have to make money at some point.
I'd also state, that is, for now. These services will have to make money at some point.
You're absolutely right, not really 0.
To be fair: There are lots of options for a headless cms - I'm extremely confident that I could easily move my data to another free or super cheap service - even back to a free wordpress site if need be (to use as headless cms).
Also lots of extremely cheap options for free or very cheap hosting of static sites. That would also be an incredibly easy move to make.
Not trying to fanboy Not saying gatsby is right for every use case and every developer Am saying that it makes a lot of sense for my specific use case and probably for a lot of this agency and old-school-business-website style work. I suspect it is a very large market that provides decent livelihoods for many millenials that skated, snowboarded, surfed, or played in bands as young adults (kind of serious)
I just wanted to share that as an personal experience that people can weigh against other viewpoints.
To be fair: There are lots of options for a headless cms - I'm extremely confident that I could easily move my data to another free or super cheap service - even back to a free wordpress site if need be (to use as headless cms).
Also lots of extremely cheap options for free or very cheap hosting of static sites. That would also be an incredibly easy move to make.
Not trying to fanboy Not saying gatsby is right for every use case and every developer Am saying that it makes a lot of sense for my specific use case and probably for a lot of this agency and old-school-business-website style work. I suspect it is a very large market that provides decent livelihoods for many millenials that skated, snowboarded, surfed, or played in bands as young adults (kind of serious)
I just wanted to share that as an personal experience that people can weigh against other viewpoints.
It's tough to take this too seriously since it seems you created this name just to make this comment. What approaches did you try before 'owing your career to gatsby'?
Please follow the site guidelines, which ask you to Assume good faith:
https://news.ycombinator.com/newsguidelines.html
Consider that the downside of your being wrong is that you drive a newcomer away from this community. That's surely not what you want, and definitely the opposite of what this place is for.
Consider that the downside of your being wrong is that you drive a newcomer away from this community. That's surely not what you want, and definitely the opposite of what this place is for.
check out my reply above - the owing my career to gatsby is very much about my specific story - a story that is probably very different from most hackernews contributors but maybe some aspects of it are more common for the lurkers here, of which I am one.
I would honestly be interested to know how many self taught people making things work building basic sites for unglamorous corners of the internet cruise this site.
To be honest I don't really feel welcome here because I'm not sophisticated (prob the best word for it) enough. But that's ok.
I would honestly be interested to know how many self taught people making things work building basic sites for unglamorous corners of the internet cruise this site.
To be honest I don't really feel welcome here because I'm not sophisticated (prob the best word for it) enough. But that's ok.
I run Hacker News. We're not interested in sophisticated; we're here for curiosity. If have that, which I'm sure you do, then you're welcome here, so please don't let a single comment make you feel otherwise.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
busted!
Yes, Gatsby even seems to be controversal in the React eco-system.
Next.js is less opinionated.
Next.js is less opinionated.
[deleted]
Another advantage of developing close to plain HTML is that you’re free from the js next-shiny-thing hamster wheel.
For example, I had thought Gatsby was the hip way to create static sites in 2019. Then another comment here mentioned it’s Next.js now.
For example, I had thought Gatsby was the hip way to create static sites in 2019. Then another comment here mentioned it’s Next.js now.
Next is not a static site generator, as I understand it. It's a framework for React that includes server-side rendering of HTML, among other things.
Gatsby and Next.js are both site frameworks powered by React. They can both be used for static and dynamic sites with different conventions and features around routing, data management, and general app architecture.
Both are "hip" and will likely remain as the top 2 javascript based site frameworks for now, although whether you need either of them is an entirely different question.
Both are "hip" and will likely remain as the top 2 javascript based site frameworks for now, although whether you need either of them is an entirely different question.
VuePress / Gridsome are taking over.
Which, in the JavaScript community, means they’ll be irrelevant in 3, 2, 1.
The difference with Next.js and Gatsby seems to be that Next uses well known React idioms and Gatsby does it's own thing.
TLDR: I just completed a large project built with Gatsby, and wouldn't recommend it to anyone. The technology is extremely complicated, and the end result quite inflexible.
Here's an idea of how the whole thing works when you have non-technical users:
1. You need some sort of Content Management System for non-technical users to be able to create content.
2. That CMS stores the content however it sees fit (db/files/whatnot) and provides an API to fetch it.
3. In gatsby, you build "source plugins" that fetch the content and fill it in an in-memory GraphQL sever.
4. Building the site entails fetching all content, feeding it to GraphQL, making a webpack build to run in nodejs, making a webpack build to run on the final site, and finally generating the HTML files.
If this doesn't sound so bad, here are some complaints in no particular order:
- There are no incremental builds. You must rebuild everything every time you want to publish a change. Our builds currently clock in at ~8min.
They've been saying they want incremental builds since 2 years ago. They are "just around the corner" since ~6 months ago. They "already did the hard part" ~4 months ago. They "will offer incremental builds sometime in the future but only in the cloud paid-for version" as of ~1 month ago.
- Users hate not being able to immediately see how their content will look like (especially if every time they publish there's a ~10min. delay to actually being able to see it). We had to setup a "preview" environment that is running gatsby in development mode. Gatsby the company just recently started selling this as a paid cloud service (we built it ourselves).
- Development mode does not serve html files like production builds do. The site behaves differently in that mode, and some issues only happen in actual builds. When you encounter one such issue, the feedback loop becomes "full build for every change" == ~10min of waiting to try every single change. This is a HUGE productivity killer.
- Gatsby generates html files. Then it hydrates that html in the client, using ReactDOM.hydrate. Sounds cool, but the React devs explicitly stated that prerendered content must match exactly what the client-side would render, and if it doesn't your site may completely break and it won't be considered a rehydration bug.
Now consider what happens if you try to use a component that changes appearance by doing size detection, or if you have some area that changes between "Hello <user>" or "log in" depending on whether the client is logged in, etc. BTW, these bugs only happen when you test actual builds, not in development mode of course (massive waste of time as per the point above).
- Gatsby hijacks NODE_ENV (setting it to "production" for actual builds and "development" for the development mode). This leaks into the many tools involved in the many things that happen while building (babel, webpack and all of their plugins, times two compilations, plus the rendering phase, etc). For instance, I've lost many hours trying to get a full, tree-shaken but unmangled build to no avail.
- Gatsby infers GraphQL types from the data you feed into it. It usually works, but when it doesn't it is painful to discover why (your queries return weird results) and fixing it means specifying your data types manually (something you already did once when you defined the database, again to define the models in the CMS, and yet again when you specified the API Gatsby uses to fetch the contents)
- Many months ago we went with CSS Modules because Gatsby sold it as a way to get the CSS required for each page inlined in the HTML itself. Fast-forward a bit, people where having issues with specificity (because of ordering) ... and now Gatsby inlines ALL of the site's css in each and every page. Our html's usually have more inlined CSS than actual HTML!
I can assure you I'm going the next.js route if I ever have to build a site with similar technology.
Here's an idea of how the whole thing works when you have non-technical users:
1. You need some sort of Content Management System for non-technical users to be able to create content.
2. That CMS stores the content however it sees fit (db/files/whatnot) and provides an API to fetch it.
3. In gatsby, you build "source plugins" that fetch the content and fill it in an in-memory GraphQL sever.
4. Building the site entails fetching all content, feeding it to GraphQL, making a webpack build to run in nodejs, making a webpack build to run on the final site, and finally generating the HTML files.
If this doesn't sound so bad, here are some complaints in no particular order:
- There are no incremental builds. You must rebuild everything every time you want to publish a change. Our builds currently clock in at ~8min.
They've been saying they want incremental builds since 2 years ago. They are "just around the corner" since ~6 months ago. They "already did the hard part" ~4 months ago. They "will offer incremental builds sometime in the future but only in the cloud paid-for version" as of ~1 month ago.
- Users hate not being able to immediately see how their content will look like (especially if every time they publish there's a ~10min. delay to actually being able to see it). We had to setup a "preview" environment that is running gatsby in development mode. Gatsby the company just recently started selling this as a paid cloud service (we built it ourselves).
- Development mode does not serve html files like production builds do. The site behaves differently in that mode, and some issues only happen in actual builds. When you encounter one such issue, the feedback loop becomes "full build for every change" == ~10min of waiting to try every single change. This is a HUGE productivity killer.
- Gatsby generates html files. Then it hydrates that html in the client, using ReactDOM.hydrate. Sounds cool, but the React devs explicitly stated that prerendered content must match exactly what the client-side would render, and if it doesn't your site may completely break and it won't be considered a rehydration bug.
Now consider what happens if you try to use a component that changes appearance by doing size detection, or if you have some area that changes between "Hello <user>" or "log in" depending on whether the client is logged in, etc. BTW, these bugs only happen when you test actual builds, not in development mode of course (massive waste of time as per the point above).
- Gatsby hijacks NODE_ENV (setting it to "production" for actual builds and "development" for the development mode). This leaks into the many tools involved in the many things that happen while building (babel, webpack and all of their plugins, times two compilations, plus the rendering phase, etc). For instance, I've lost many hours trying to get a full, tree-shaken but unmangled build to no avail.
- Gatsby infers GraphQL types from the data you feed into it. It usually works, but when it doesn't it is painful to discover why (your queries return weird results) and fixing it means specifying your data types manually (something you already did once when you defined the database, again to define the models in the CMS, and yet again when you specified the API Gatsby uses to fetch the contents)
- Many months ago we went with CSS Modules because Gatsby sold it as a way to get the CSS required for each page inlined in the HTML itself. Fast-forward a bit, people where having issues with specificity (because of ordering) ... and now Gatsby inlines ALL of the site's css in each and every page. Our html's usually have more inlined CSS than actual HTML!
I can assure you I'm going the next.js route if I ever have to build a site with similar technology.
"now Gatsby inlines ALL of the site's css in each and every page"
Did this abruptly happen at some point? I've had attempts to migrate components from old repositories cause similar issues and all I could see is that something with the dependencies of that project (e.g. "tree-model" definitely seemed to cause issues) were forcing gatsby to be overly safe in terms of culling CSS.
Similarly we had issues with imports a component library, but upon inspecting other projects the same issue was happen with client side rendered apps, so it was down to how we built the library rather than Gatsby.
My experiences were pretty positive but I did encounter every issue you've listed and would probably try next.js next time just to know what I've been missing. Have you worked with it before doing similar stuff?
-------------
As far as Gatsby goes I think it occupies a definite niche but one that needs to communicated very effectively. You get: - static web pages - react ecosystem (very useful if all other company frontends are on react and there's a design system) - some webapp functionality
The last one being key, more than _some_ and it's probably going to start becoming a headache juggling all the pieces.
Similarly we had issues with imports a component library, but upon inspecting other projects the same issue was happen with client side rendered apps, so it was down to how we built the library rather than Gatsby.
My experiences were pretty positive but I did encounter every issue you've listed and would probably try next.js next time just to know what I've been missing. Have you worked with it before doing similar stuff?
-------------
As far as Gatsby goes I think it occupies a definite niche but one that needs to communicated very effectively. You get: - static web pages - react ecosystem (very useful if all other company frontends are on react and there's a design system) - some webapp functionality
The last one being key, more than _some_ and it's probably going to start becoming a headache juggling all the pieces.
> "now Gatsby inlines ALL of the site's css in each and every page" Did this abruptly happen at some point?
It happened in gatsby @2.1.3 (a minor "patch" release!) [1]
> would probably try next.js next time just to know what I've been missing. Have you worked with it before doing similar stuff?
Not at the same scale. However, just reading their docs gives me way more confidence in that they are explicit about what the thing does or doesn't do. For instance, they can do prerendering like gatsby but there are many warnings about it in the docs [2], and you can always fall back to per-request SSR on any page if prerendering doesn't work there.
Also it does away with the whole graphql thingy (you just get a `fetch` that works both server-side and client-side) and call the "backend" api directly.
[1] https://github.com/gatsbyjs/gatsby/issues/11072 [2] https://nextjs.org/docs#automatic-prerendering
It happened in gatsby @2.1.3 (a minor "patch" release!) [1]
> would probably try next.js next time just to know what I've been missing. Have you worked with it before doing similar stuff?
Not at the same scale. However, just reading their docs gives me way more confidence in that they are explicit about what the thing does or doesn't do. For instance, they can do prerendering like gatsby but there are many warnings about it in the docs [2], and you can always fall back to per-request SSR on any page if prerendering doesn't work there.
Also it does away with the whole graphql thingy (you just get a `fetch` that works both server-side and client-side) and call the "backend" api directly.
[1] https://github.com/gatsbyjs/gatsby/issues/11072 [2] https://nextjs.org/docs#automatic-prerendering
> Users hate not being able to immediately see how their content will look like
Shameless plug: I'm building a product that does what Gatsby Preview does, except it's platform agnostic, and ties in tighter wth the feedback/review process. https://featurepeek.com
Shameless plug: I'm building a product that does what Gatsby Preview does, except it's platform agnostic, and ties in tighter wth the feedback/review process. https://featurepeek.com
That's actually pretty cool.
> Development mode does not serve html files like production builds do. The site behaves differently in that mode, and some issues only happen in actual builds. When you encounter one such issue, the feedback loop becomes "full build for every change" == ~10min of waiting to try every single change. This is a HUGE productivity killer.
This got me so many times. I was frustrated enough that I set up a headless chrome prerenderer to snapshot my gatsby-built site before every single deploy just so I could verify the html diff to make sure my site looked correct still.
The trust issues alone were enough to make me switch off of it.
This got me so many times. I was frustrated enough that I set up a headless chrome prerenderer to snapshot my gatsby-built site before every single deploy just so I could verify the html diff to make sure my site looked correct still.
The trust issues alone were enough to make me switch off of it.
I switched my personal Jekyll site to Gatsby 2 years ago. I ran into some minor bugs and even contributed 3 PRs that got merged. I loved working with it for a few weeks. Two months after switching, it too dawned on me how over-engineered it is. I switched off of it to a custom static site generator I made (admittedly it was also over-engineered), but I'm finally back to a simple static generator called zola [1] and it feels so refreshing.
Not only is Gatsby over-engineered, it's also bloated IMO. I think one of their main selling points it that page loads seem instant. Preloading other pages in the background seems needless to me when we're talking about a simple blog. Sure, it might be good for apps, but forcing my (few) visitors to download needless mbs on desktop or mobile seems like a bad user experience to me.
[1]: https://github.com/getzola/zola
Not only is Gatsby over-engineered, it's also bloated IMO. I think one of their main selling points it that page loads seem instant. Preloading other pages in the background seems needless to me when we're talking about a simple blog. Sure, it might be good for apps, but forcing my (few) visitors to download needless mbs on desktop or mobile seems like a bad user experience to me.
[1]: https://github.com/getzola/zola
I like the look of Zola, and I bookmarked it when I saw the README pick a bone with Hugo's templating engine. Take a look at the Hugo Discourse forum and I can't imagine less than 99% of the topics are about Go/Hugo templating issues. The Hugo docs basically say "we use Go's template engine, go learn that confusing shit and then we'll tell you 5 different deprecated ways to get today's date if you are enough of a masochist."
I evaluated Gatsby, among other solutions, for our company's website. We use React in production for a large application, nothing new there, but for a static site, I thought it had an overly-complicated build pipeline. In the end, we went with Hugo[1], never regretted, huge fan of static site generators and Netlify CMS[2].
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/
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/
I really love Gatsby. It combines the best of both worlds: static sites and React.
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.
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.
I posted a similar sentiment elsewhere on this page. The project that really hit the sweet spot for me, in this regard, is React Static: https://react-static.js.org/
Doesn't have VC money, though, but there's not that much development needed for my (and apparently yours) use cases either.
Doesn't have VC money, though, but there's not that much development needed for my (and apparently yours) use cases either.
Honest question, but why is React unique in offering component encapsulation? I see this more of a structural paradigm than something a framework allows for or limits against.
It’s probably not unique in that aspect. I just happen to have quite a bit of experience in React. And that “componentization” only made sense to me when I started using React.
I think it's something about developers who only use React that think React is extremely unique. I hear stuff like this all the time, "How do you use redux with Angular" like redux couldn't possible apply to anything else. Pretty much all the frameworks provide a component based architecture, this isn't a unique thing to react. You choose react for it being extremely popular, JSX, relatively small footprint (unless you start using it as a framework).
> which promises that it allows these companies to do away with their old LAMP stack and move to a more modern stack, based on modern open-source tools and engineering practices.
LAMP stack is open source...
LAMP stack is open source...
The implication in the sentence is that LAMP is an old open-source stack, whereas Gatsby is new open-source
Linux - Gatsby doesn't run on Linux?
Apache - Gatsby doesn't run behind a load balancer (apache/nginx) with proxy_pass?
MySql - Gatsby doesn't persist data into a database (MySql/Postgres)?
PHP - I'll give you that PHP is out and node.js is in for backend development.
Apache - Gatsby doesn't run behind a load balancer (apache/nginx) with proxy_pass?
MySql - Gatsby doesn't persist data into a database (MySql/Postgres)?
PHP - I'll give you that PHP is out and node.js is in for backend development.
Linux - probably
Apache/Nginx - some web server will be used, though much as likely something more lightweight than Apache. No proxy_pass needed since Gatsby just generates a bunch of files you need to serve
MySQL - probably not unless married with a very complex backend
PHP - yeah that’s out
To understand Gatsby it’s crucial to understand that it’s using a significantly different architecture than traditional LAMP applications and monolithic CMSes
Apache/Nginx - some web server will be used, though much as likely something more lightweight than Apache. No proxy_pass needed since Gatsby just generates a bunch of files you need to serve
MySQL - probably not unless married with a very complex backend
PHP - yeah that’s out
To understand Gatsby it’s crucial to understand that it’s using a significantly different architecture than traditional LAMP applications and monolithic CMSes
Just about every production Gatsby instance is either using static data source (list of markdown/json files) or a monolithic CMS on the backend via API. It's more of a modern frontend site framework rather than a true self-contained app.
Ah, that would make more sense.
Question tangential to Gatsby for those of you who use such static site builders as blogs: are there any good tools for writing/composing posts or are you all doing it by hand?
I have set up the same blog maybe 3 times and I always stop posting because I need to be in my coding environment to do so (and if I'm there, I might as well be working on code). I'd really like to find something that I could use to make a post on my gaming pc, for example, where I can add images easily (and have them resized properly). I feel like I should probably just set up a wordpress site, but wanted to know if I had other options.
I have set up the same blog maybe 3 times and I always stop posting because I need to be in my coding environment to do so (and if I'm there, I might as well be working on code). I'd really like to find something that I could use to make a post on my gaming pc, for example, where I can add images easily (and have them resized properly). I feel like I should probably just set up a wordpress site, but wanted to know if I had other options.
> I have set up the same blog maybe 3 times and I always stop posting because I need to be in my coding environment to do so
I had a similar problem and solved it with Forestry[0] and Netlify. Forestry has a nice web interface for writing posts; saving causes the changes to be committed to a GitHub repo. Netlify[1] watches the repo and rebuilds/redeploys the blog.
It sounds a bit complicated, but I've run this setup for 9 months now without any serious issues. To write and publish a new post, all I need to do is: login to Forestry, write the damn thing, and hit "save". The cost is $0.
0 - https://forestry.io/ 1 - https://www.netlify.com/
I had a similar problem and solved it with Forestry[0] and Netlify. Forestry has a nice web interface for writing posts; saving causes the changes to be committed to a GitHub repo. Netlify[1] watches the repo and rebuilds/redeploys the blog.
It sounds a bit complicated, but I've run this setup for 9 months now without any serious issues. To write and publish a new post, all I need to do is: login to Forestry, write the damn thing, and hit "save". The cost is $0.
0 - https://forestry.io/ 1 - https://www.netlify.com/
forestry seems like a brilliant project, thanks for sharing!
Full disclosure: I‘m a Developer Evangelist for Contentful
A “Headless CMS” is one way to achieve what you’re looking to do. Contentful is one, there are others. Gatsby’s has source plugins for all popular ones.
They have a nice getting started guide for Gatsby + Contentful: https://www.gatsbyjs.org/docs/sourcing-from-contentful/
A “Headless CMS” is one way to achieve what you’re looking to do. Contentful is one, there are others. Gatsby’s has source plugins for all popular ones.
They have a nice getting started guide for Gatsby + Contentful: https://www.gatsbyjs.org/docs/sourcing-from-contentful/
I'm using Ghost + Gatsby for my personal website / blog [1].
[1] https://www.ronaldlangeveld.com
[1] https://www.ronaldlangeveld.com
I use [Forestry](https://forestry.io). I migrated from Wordpress, and needed a way for my non-technical family members to continue editing their blogs. Details at https://dev.clintonblackburn.com/2019/03/31/wordpress-to-jek....
You can use wordpress as your CM. Write posts and they appear in your Gatsby site. Contentful is probably a better option though...
https://www.gatsbyjs.com/guides/wordpress/
https://www.gatsbyjs.com/guides/wordpress/
you can.. though, honestly, i'd advice against wordpress + gatsby. in my experience, because of various plugins required to do various things, the way media is fetched etc, and the highly difficult task of getting things working with schemas in wp.
also, wordpress builds tend to also take the longest.
if you enjoy hacking on wordpress and debugging weird issues, then this might be a good choice.
It's much easier to build a blog using prismic, contentful, or even the netlify cms kind of is nice for a basic "serverless" blog/cms.
honestly, i'd take markdown files in a bunch of folders any day over gatsby-source-wordpress.
also, wordpress builds tend to also take the longest.
if you enjoy hacking on wordpress and debugging weird issues, then this might be a good choice.
It's much easier to build a blog using prismic, contentful, or even the netlify cms kind of is nice for a basic "serverless" blog/cms.
honestly, i'd take markdown files in a bunch of folders any day over gatsby-source-wordpress.
I wrote a ms word transformer for GatsbyJS. I like it because it lets me add images and stuff and generates the content without having to muck with urls etc.
https://github.com/abhiyerra/gatsby-transformer-ms-word
https://github.com/abhiyerra/gatsby-transformer-ms-word
Seems like an ugly hack compared to all the "cool" tech mentioned here. But well done, I'll be the first one to star it!
That's why I built Jekyll+: https://github.com/Wiredcraft/jekyllplus#readme
In a nutshell, it offers a better UI to edit your content on a Jekyll site by talking directly to the Github API.
In a nutshell, it offers a better UI to edit your content on a Jekyll site by talking directly to the Github API.
This looks great, thank you!
You could use gitlab pages + netlify cms + gatsby; The Gatsby docs have an example: https://www.gatsbyjs.org/docs/sourcing-from-netlify-cms/
I had the same dilemma when I wanted to launch a food blog last year. I ended going with Ghost on a digital ocean $5/mo droplet.
We also integrate with Gatsby if you want the best of both worlds :) https://ghost.org/docs/api/v2/
I’ve got a site that requires non-technical people to post, and I’m looking into using Contentful or Netlify CMS as their content editing UI, which in turn triggers a build and deploy. (I use Middleman but Gatsby should be able to do the same.)
take a look at prismic as well.. it has some nice features for "normies" .. although it is missing a bunch of nice features from contentful.
In a dozen of hours I wrote Sitio[1]. Sitio generates static pages with React templates and if wanted they also become alive React components at the client. It has a simple imperative API, no GraphQL, no Webpack, any kind of datasource can be easily plugged (in fact I did plug many).
It turns out Gatsby also exposes an imperative API that runs behind its fancy declarative API, and it's very similar to mine.
However, I wrote mine in 12 hours. Gatsby has a big team and millions of dollars and it's been in the works for many many years.
And still some weeks ago I tried to use Gatsby to generate a site with data from Trello and Instagram and couldn't, hit some bugs, but mainly hit an opaque and very complex API.
Why?
[1]: https://github.com/fiatjaf/sitio
It turns out Gatsby also exposes an imperative API that runs behind its fancy declarative API, and it's very similar to mine.
However, I wrote mine in 12 hours. Gatsby has a big team and millions of dollars and it's been in the works for many many years.
And still some weeks ago I tried to use Gatsby to generate a site with data from Trello and Instagram and couldn't, hit some bugs, but mainly hit an opaque and very complex API.
Why?
[1]: https://github.com/fiatjaf/sitio
No webpack is a big win. Thinking Gatsby is this fun & easy thing and then realizing you're going all-in on the current npm/JS insanity is not a good feature.
I have this great badge at the repository: [Webpack free]
https://camo.githubusercontent.com/fdcb107fde40edb15afb7e80f...
https://camo.githubusercontent.com/fdcb107fde40edb15afb7e80f...
Worse: all the datasources were provided by plugins written by third-party indie developers working for free (and for that reason they weren't perfect, of course).
What is the core team wasting their time on?
What is the core team wasting their time on?
Congrats to Kyle and the team. Been using Gatsby in prod for nearly a year now (v1 then migrated to v2), the team is super helpful and responsive to feedback and issues.
(DTC e-commerce)
(DTC e-commerce)
I’ve been playing with Gatsby on toy projects, and recently I’ve considered using it in prod in an eCommerce site.
Then I saw that the content preview feature was $50 / month - and it’s not even integrated yet with my CMS of choice.
How can teams accept to let go of such fundamental features? I love the React dev experience as much as the next guy, but I certainly can’t find a way to justify this to my clients...
Then I saw that the content preview feature was $50 / month - and it’s not even integrated yet with my CMS of choice.
How can teams accept to let go of such fundamental features? I love the React dev experience as much as the next guy, but I certainly can’t find a way to justify this to my clients...
Apologies for the double comment but another flaw I’ve seen with Gatsby in eCommerce has to do with fetching the product listings...
You basically have two options: (a) fetch them dynamically (b) trigger a rebuild on product update
With (a) you have spinners and potentially worse SEO. With (b) you have to deal with a delay from hitting “Publish” to seeing the changes deployed in prod...
Again, these are all solved problems in just about every other eCommerce framework!
If you look at some of the Gatsby eCommerce prod examples you will see a few gorgeous sites (the Flamingo one for example) but they all have very few product references and features (no user accounts, etc)
All this is to say the possible use cases for Gatsby in eCommerce seem very narrow, though I would love to be proven wrong.
You basically have two options: (a) fetch them dynamically (b) trigger a rebuild on product update
With (a) you have spinners and potentially worse SEO. With (b) you have to deal with a delay from hitting “Publish” to seeing the changes deployed in prod...
Again, these are all solved problems in just about every other eCommerce framework!
If you look at some of the Gatsby eCommerce prod examples you will see a few gorgeous sites (the Flamingo one for example) but they all have very few product references and features (no user accounts, etc)
All this is to say the possible use cases for Gatsby in eCommerce seem very narrow, though I would love to be proven wrong.
I don't see a good fit between and ecommerce site and gatsby, on an ecoomerce site you may have to change your pages depending on the stock, and disable the buy button when there's no stock for an item. What are you going to do? redeploy the site on every purchase?
Or you can only list the product and make the buy button and items available come from an api, doable, but then you start to loose the simplicity of gatsby.
Or you can only list the product and make the buy button and items available come from an api, doable, but then you start to loose the simplicity of gatsby.
Yea, essentially what I'm saying in my a vs b scenario.
> Or you can only list the product and make the buy button and items available come from an api, doable, but then you start to loose the simplicity of gatsby.
And you still haven't solved the issue of delays between content changes and deployment... What if someone has made a bad mistake in content editing and you need to revert it? You're exposed to the whims of your build processes and infrastructure... There's no way I can sell to anyone who's played with Wordpress or Shopify "well, your changes might take anywhere from 3 to 15 minutes to be live..."
That's why I'm asking, how can product and engineering teams justify this kind of thing? I'm not being facetious, I'd love to hear their perspective.
> Or you can only list the product and make the buy button and items available come from an api, doable, but then you start to loose the simplicity of gatsby.
And you still haven't solved the issue of delays between content changes and deployment... What if someone has made a bad mistake in content editing and you need to revert it? You're exposed to the whims of your build processes and infrastructure... There's no way I can sell to anyone who's played with Wordpress or Shopify "well, your changes might take anywhere from 3 to 15 minutes to be live..."
That's why I'm asking, how can product and engineering teams justify this kind of thing? I'm not being facetious, I'd love to hear their perspective.
I have no idea how well the hosted service works, but Gatsby has been one of my favorite frameworks for a while, and I'm happy they're throwing some extra talent into making it awesome.
Thanks! We're really excited to be able to invest even more in open source. If there are particular features that would be helpful for you please open an issue on the repo!
For those who like React static sites but dislike the complexity of Gatsby and GraphQL, check out react-static.
https://github.com/react-static/react-static
YouTube example: https://youtube.com/watch?v=OqbJ5swVpDQ
https://github.com/react-static/react-static
YouTube example: https://youtube.com/watch?v=OqbJ5swVpDQ
I checked their website and I still don't get what it actually is. I'm familiar with Hugo (compiles .md files to static site), Forestry (CMS for Hugo and other static site generators) and Netlify (to deploy that static site). Where does it sit, and how is it different?
I love Gatsby. We are about to release a new landing version of https://Standups.io entirely with it. Blog and help center. We got rid of intercom guide :)
Parse.ly also just released their new landing page all done with Gatsby.
Parse.ly also just released their new landing page all done with Gatsby.
I wonder who the market for Gatsby is.
I considered signing up for them for a somewhat simple markdown-powered blog, but ultimately ended up writing my own solution because I couldn’t justify the cost. The documentation for the self-hosted solution seems designed to put you off doing it yourself.
I considered signing up for them for a somewhat simple markdown-powered blog, but ultimately ended up writing my own solution because I couldn’t justify the cost. The documentation for the self-hosted solution seems designed to put you off doing it yourself.
My personal site is running Gatsby on Netlify, I haven't paid for anything except my domain. I'm not the biggest fan of Gatsby, but it's pretty decent for some projects.
I'm missing something from the picture I guess, but what service they offer for 50 bucks/month if you could host your static page built with Gatsby literaly anywhere for much less / free?
Web development agencies, for one
very curious about this as well, given that price point and targeting the developer market
What cost? Gatsby is free.
So, a Wordpress competitor? I'm curious to hear more.
No. More closely compared to Jekyll.
It's actually quite common to use Wordpress as a backend for a Gatsby site. So: build your UI in React with Gatsby, store your content with Wordpress.
There's an out-of-the-box Wordpress/Gatsby integration, and we recently hired Jason Bahl, the creator of WPGraphQL, to make that integration even better!
There's an out-of-the-box Wordpress/Gatsby integration, and we recently hired Jason Bahl, the creator of WPGraphQL, to make that integration even better!
Reading through the comments I get the impression there is a mis-understanding of what gatsby is. It might be my misunderstanding but ...
"Static Site generator" seems to be the confusion. If I'm reading correctly gatsby is more a replacement for webpack than for jekyll or ghost. You use it as scaffolding to help build your front end. The docs show it compiling react, jsx, using various plugins like emotion etc. It all looks like it's supposed to be a better webpack.
Am I wrong?
"Static Site generator" seems to be the confusion. If I'm reading correctly gatsby is more a replacement for webpack than for jekyll or ghost. You use it as scaffolding to help build your front end. The docs show it compiling react, jsx, using various plugins like emotion etc. It all looks like it's supposed to be a better webpack.
Am I wrong?
I think you might be wrong in your understanding. Webpack is a bundler, which Gatsby uses.
You can use Gatsby as a replacement for Jekyll or Ghost, they do the same thing, i.e. output static HTML. However Gatsby uses React and GraphQL to achieve that result. While Jekyll uses markdown files for example.
You can use Gatsby as a replacement for Jekyll or Ghost, they do the same thing, i.e. output static HTML. However Gatsby uses React and GraphQL to achieve that result. While Jekyll uses markdown files for example.
I think "static site generator" is a more apt description than "webpack replacement". The React code in Gatsby is SSR'ed only (in production mode, anyways) making writing idiomatic dynamic client-side React code very awkward.
Also, Gatsby uses Webpack[1] and it doesn't expose compilation options in any meaningful way like webpack itself does (and it doesn't have a plug-and-play philosophy like Parcel either). I'm not a huge fan of webpack config API personally, but I certainly would never consider using Gatsby as an alternative generic purpose bundler!
[1] https://github.com/gatsbyjs/gatsby/blob/561d33e2e491d3971cb2...
Also, Gatsby uses Webpack[1] and it doesn't expose compilation options in any meaningful way like webpack itself does (and it doesn't have a plug-and-play philosophy like Parcel either). I'm not a huge fan of webpack config API personally, but I certainly would never consider using Gatsby as an alternative generic purpose bundler!
[1] https://github.com/gatsbyjs/gatsby/blob/561d33e2e491d3971cb2...
The real play must be to take a chunk out of medium right? “Companies that don’t like medium or Wordpress are rolling their own costly solutions, so here we are with the smooth transition”.
The problem is if they want to be profitable they will eventually have to incorporate the bad parts of medium and/or the bad parts of Wordpress and then we’re back to square one with some new minimal open source static site builder. This wheel is exhausting.
The problem is if they want to be profitable they will eventually have to incorporate the bad parts of medium and/or the bad parts of Wordpress and then we’re back to square one with some new minimal open source static site builder. This wheel is exhausting.
“Matthews says Gatsby (the company) is now contributing about $3 million per year to open-source projects that include the core Gatsby tools and the plugin ecosystem around it.”
Who should we reach out to about this funding for our open source project to integrate with Gatsby ecosystem? We have an open-source platform with tons of components like videoconferencing, events, rides etc. hosted for free on github.com .
Who should we reach out to about this funding for our open source project to integrate with Gatsby ecosystem? We have an open-source platform with tons of components like videoconferencing, events, rides etc. hosted for free on github.com .
I don't really know what Gatsby is good at because I've never been target customer of it. But judging on website and docs I think its power lies in simplicity: people want to get shit together and call a day. This tool allows that. It probably won't live long, but that's not a problem, right? Most websites built with it are short lived: promotion www, sales, register forms etc.
I have tutorials on Gatsby and have used it quite a bit. I don't recommend it. I can't understand why this is getting funding? People are so much better off with a CMS like Django or Wordpress. Hell, they could use static HTML, Apache and Quill.JS and nothing else is needed. Maybe sub Quill with TinyMCE or CKEditor. There is nothing overly special about Gatsby.
The history of Gatsby is interesting. If my memory serves me well, it was started as an open source project. Then the developers of this open source project got funded by VC.
So the pattern is like this: open source project -> get funded by VC.
The other similar case is IPFS (open source project) -> Filecoin (get funded by VC).
Anyway, congratulation to the Gatsby team! :)
So the pattern is like this: open source project -> get funded by VC.
The other similar case is IPFS (open source project) -> Filecoin (get funded by VC).
Anyway, congratulation to the Gatsby team! :)
If history is any judge, four years from now, it will no longer be modern. And those people who have spent time and money investing into gatsby will be looking to leave for something else.
It's one of my biggest issues with software is that software is never done. It's always being torn down and replaced with something else.
It's one of my biggest issues with software is that software is never done. It's always being torn down and replaced with something else.
What's a good, mature headless CMS that "just works" and is compatible with Gatsby/GraphQL?
Gatsby is great; we use it for all our marketing sites because it doesn't hide content behind JavaScript like plain React so it's better for SEO. Gatsby would be great to compete with Netlify for static React app hosting.
So alternatively why not a less coupled system? Hasura + hyperapp, etc + ...?
Doesn't generate static pages.
I've enjoyed using Gatsby in a hybrid approach to combine marketing and a web app for MVPs. It's allowed me to get up and running quickly and haven't run into any major issues so far.
I recommend people checkout Gridsome. It’s a similar product but for Vue.
And we at https://simulify.com are making a UI for react based static sites. Pls join our alpha.
calcsam: How do you think about defensibility? One might think that because the underlying tech is open source, someone else can also spring up a hosting service. Is that not an issue because agencies would want the official hosting for the open source project because they want the reassurance?
Or is it for another reason this isn't an issue?
Or is it for another reason this isn't an issue?
Interestingly, a lot of open-source companies have built defensible businesses -- a list is over at http://oss.cash. Recent IPOs include Mulesoft, Elastic, Mongo, Fastly...
More specifically to Gatsby, we don't actually see ourselves in the hosting business, more in the "collaboration" business -- most websites have teams of nontechnical folks that are reviewing sites before they go live, creating and editing content, and so on. We're building Gatsby-specific collaboration tooling, starting with CMS Preview.
A good comparison here would be Github -- nobody thinks of Github as "Git hosting", they think of Github as the place where developers collaborate together on projects.
More specifically to Gatsby, we don't actually see ourselves in the hosting business, more in the "collaboration" business -- most websites have teams of nontechnical folks that are reviewing sites before they go live, creating and editing content, and so on. We're building Gatsby-specific collaboration tooling, starting with CMS Preview.
A good comparison here would be Github -- nobody thinks of Github as "Git hosting", they think of Github as the place where developers collaborate together on projects.
Does anyone know why Gatsby uses GraphQL? I don't understand how a static site benefits from GraphQL.
[deleted]
Congratulations, now build some great things with that funding .
Gatsby is popular among frontend React devs although I kind of balk at end to end solutions like this. Nice alternatives to Gatsby are React-static and next.js
Gatsby is about 3 years old. I wonder how it would have worked out if in 2007 DHH and co had pivoted from Basecamp to Rails Inc and raised funding?
Of course, to be fair, Meteor is still in business after taking the same path (though it seems most efforts are directed at Apollo?)
Of course, to be fair, Meteor is still in business after taking the same path (though it seems most efforts are directed at Apollo?)
Congrats guys!
1. Convince the WordPress/enterprise crowd to switch over, both by touting the genuine benefits of static sites (security, scalability, TTFB performance, etc.) and by riding the Cool Kid Front-End Stack hype train.
2. Lock them in with an overly-complicated framework and build pipeline that requires organizations invest a lot of resources into switching. (Gatsby gets most of this for free by building on top of the Cool Kid Stack's nine-thousand-package NPM lasagna.)
3. Sell their captive audience expensive solutions to problems they wouldn't have with other frameworks. (See e.g. another commentor's discussion of incremental builds.)
This strategy might not contribute much to society, but neither do a lot of other startups--what matters to investors is that it'll probably make them a lot of money, assuming they execute it correctly.