> 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.

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.

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.

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.

I've been writing my side project in vanilla es5. I use rollup for bundling, and nothing else. Life is great.

Care to elaborate? In what regard?

The other comment does a good job illustrating

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.

I take issue with your tone and cynicism, and disagree w/ your premise. Your sarcasm and condescension aren't helpful. And there's no way your "couple hundred lines of code" addressed more than a fraction of the real-world use cases addressed by Gatsby. You cast aspersions on a huge swath of your peers who work with the best tools at hand to solve difficult problems... it's not just arrogant, it's ignorant. IME it's the ultimate poser/hipster move to denigrate modern web dev (your so-called "Cool Kid Stack"), while ignoring the ways in which the world has changed (and become more complicated and challenging) since you formed your ideas about simple HTML-generating scripts being sufficient to meet the requirements of a modern web application. The true "continuous source of churn and maintenance work" is the problem space -- endlessly diverse clients on radically heterogenous devices with highly variable network conditions, and end-user expectations that only ever ratchet in the direction of faster, more secure, more reliable, more polished experiences. I feel your pain about keeping up with tools that can empower teams to address these challenges; but to suggest that the stack is to blame, that the complexity is unnecessary and arises from self-interested outfits looking to build a moat? Nonsense.

I write all this as a 21-year veteran of web development-related work, and in the spirit of respectful disagreement.

As someone who has both used Gatsby and written custom static HTML generators, I do feel that Gatsby is far more complex than it needs to be.

> there's no way your "couple hundred lines of code" addressed more than a fraction of the real-world use cases addressed by Gatsby

Gatsby on its own doesn't actually do much. There are plugins to do most useful things. Here's an example: https://www.gatsbyjs.org/packages/gatsby-remark-prismjs/

That is the "blessed" solution for code highlighting. Notice how you have to install 2 different NPM packages, add a bunch of ad-hoc configs (which don't have API docs) then add a bunch of Gatsby specific CSS. Do you see a section about embedding code highlighting in React? No? That's because it doesn't support it (meaning you have to hack it with `dangerouslySetInnerHtml` if you want code highlighting directly in a React subtree, such as a custom layout for a homepage containing a code snippet). The alternative if you were to write a custom script would be to just take 5 minutes to slap prism.js itself in the layout file (which amounts to adding a link tag and a script tag - something a beginner HTML developer can do)

And don't even get me started on migrating from Gatsby 2 to 3 :)

They have some legitimate reasons for the Gatsby specific CSS -- specifically because everything needs to be available at build time, and I assume the prismjs library depends on browser APIs that may not exist at build time.

It's also not too surprising to hear that it doesn't support code highlighting out of the box in React given it's a plugin for Gatsby's remark plugin.

However, because we added prismjs as a dependency, you can still use it in React without hacking it with `dangerouslySetInnerHtml` so no idea where you got that idea from: https://pathof.dev/blog/code-highlighting-in-react-using-pri...

The problem is that the way Gatsby uses React is different from the way most people use React. If you just use Prism the way you linked, you'll get an error about the DOM not being there (because with Gatsby, the code is running in Node). You need to use the `Prism.highlight()` API (which takes a string and returns a string) and AFAIK the only reasonable way to consume the output of that from React is through dangerouslySetInnerHtml.

I'd be happy if you could point me to a way to use Prism w/ Gatsby that isn't as hacky.

The React-on-server aspect actually has a somewhat profound impact on what you can do. For example, if you have a newsletter subscription component in some other project, there's an almost 100% chance that it won't work in Gatsby because it likely relies on some DOM-related API like onSubmit or onClick

> And don't even get me started on migrating from Gatsby 2 to 3

I would actually love to get you started on this point. I have not heard of Gatsby 3. As far as I'm aware, Gatsby v2 is the latest. How do you migrate to 3?

Oops, I meant from 1 to 2. I recalled there being three majors, but got mixed up because the first is the 0.x not 1.x

Except a couple hundred lines of code could address the issues that Gatsby addresses.

The posters here aren't wrong. It is an overhyped, overbloated, overconfig heavy stack that ultimately renders static html.

I have used them, they are exactly as these posters say.

do you have any suggestions for people like myself, who aren't interested in or are not capable of building their own proprietary static site generator? Any tools that meet similar needs to those that gatsby meets that you would recommend and why?

Just out of interest; what are the needs Gatsby needs that you need? Static site generation can be done with WP plugins, I guess most other CMS's also have plugins for it and there are many (way too many) open source static site generators. So you are not just talking about that; what needs does it fulfill for your case that you want to use Gatsby for. I am asking as I have read the comments and the homepage and to me it looks to fulfill a strange niche: to make a static content site 'with the latest tech' and you have to be a programmer to do it. Feels to me like the worst of all those worlds besides not having to deploy anything, but that's also normal these days (wordpress.com, wix etc). What is the business case for my company to prefer this?

What language / stack do you know or use the most? go to staticgen.com and filter by your preferences. I used sculpin as it's really simple and for static landing pages you don't have to mess with many things. I tried gatsby, and to include an script on the head (the gtm js) you have to use a plugin or escape the script and include on helmet. I also used docfx indirectly to make automatic documentation pages for dotnet apis and it worked flawlessly, however I didn't have to do anything special on it, which is where the problems start to appear.

For almost any stack, you could use Puppet and headless chrome, it's a fairly simple setup. Pump it thru headless chrome and store the static output.

https://developers.google.com/web/tools/puppeteer/articles/s...

Wordpress has plugins that can export the site as a static site.

The whole reason to replace a library with your own code is that that couple hundred lines only has to support the subset of features you need from something like Gatsby.

> I wrote one once, and it was a couple hundred lines of code.

This demonstrates a complete misunderstanding of the problem domain

edit: rather than cheapshot with a throwaway comment i'll expand on this - from my experience what Gatsby provides is an open source pluggable info processing pipeline.

I'm really interested in seeing it develop as a replacement for some of the larger and much more expensive and proprietary internal knowledge and content management systems which provide a ton of plugins to tap into resevoirs and allow you to process/publish internally

I use Gatsby and I like it, but the alternative is a few hundred lines of code if you're doing what Gatsby says it does (eg a static site generator for markdown files). The fact Gatsby can do much more doesn't mean everyone who uses it is doing the other stuff.

If you just want a static site Gatsby is overkill.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

The frustrating thing is, how, precisely, are you supposed to teach that every bit of complexity isn't necessary, the world hasn't changed, and a few-hundred-line solution works fine?

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

I totally agree that it's a legitimate concern. I share it. From an internet comment point of view, the first thing is to steer clear of, say, the top 5 "you suck" sorts of comment. Because if you fall into one of those, or get interpreted that way, then you're not teaching anybody anything, just putting someone down and encouraging worse from others.

If you know more and have something to teach—and accidental software complexity is an extremely under-taught topic—the burden is on you to establish a context in which real communication is possible. How do you do that? I'm not sure; we could probably exchange notes on this for hours.

It's a dismissal for sure, but the original comment doesn't read as shallow to me.

Well, it's not really targeted at actual developers.

You need to know JS to use Gatsby, so... seems like development to me?

> 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.

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.

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.

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.

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 ?

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.

Yeah I dont think their target market is established enterprise commerce companies

OMG what a great comment. I can't see your upvotes but I hope it was in the 1000s!