Comment by chrisweekly | Hacker News Reader

Comment by chrisweekly | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com