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