HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
gatsbyjs
gatsby
JavaScript2015–2026
gatsbyjs / gatsby

gatsby

React-based framework with performance, scalability, and security built in.

Web DevelopmentSecurity & PrivacyLanguages & Compilers
Explore on GitHubRead Hacker News discussions
40Distinct people
50Mentions
2Explicit recommenders
55.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

React-based framework with performance, scalability, and security built in.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I recommend gatsbyjs (react.js based static generator) and it has plugin for Drupal and Wordpress. Here is the location of the Drupal plugin:…

dberhane used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year50 dated mentions

Observed mentions: 2015-07-22 22:01:21 UTC to 2026-02-01 23:19:55 UTC.

02468102015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 3 submissions, 0 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC330
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC817
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC808
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC1019
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC514
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC817
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

50 sources
omnicognate·Feb 1, 2026
I figured they were doing something like Ink, but interesting to know that they're actually using Ink. Do you have any evidence that's the case? It doesn't answer the question, though. Ink throttles to at most 30fps (not 60 as the 16ms quote would suggest, though the at most is far more important). That's done to prevent it churning out vast amounts of ASCII, preventing issues like [1], not as some sort of display sync behaviour where missing the frame deadline would be expected to cause tearing/jank (let alone flickering). I don't mean to be combative here. There must be some real explanation for the flickering, and I'm curious to know what it is. Using Ink doesn't, on it's own, explain it AFAICS. Edit: I do see an issue about flickering on Ink [2]. If that's what's going on, the suggestion in one of the replies to use alternate screen s
Read the rest
ounds reasonable and nothing to do with having to render in 16ms. There are tons of TUI programs out there that manage to update without flickering. [1] https://github.com/gatsbyjs/gatsby/issues/15505 [2] https://github.com/vadimdemedes/ink/issues/359
In What I learned building an opinionated and minimal coding agent
syndicatedjelly·Jul 4, 2024
I use Django, HTMX, and TailwindCSS for a side project. The Django framework matches my mental model of web development best. HTMX offers AJAX-based server-side interaction for very, very cheap. And TailwindCSS is a breath of fresh air for styling HTML. The application is hosted on a Digital Ocean server - I'm experimenting with both Docker containers on Ubuntu servers, as well as the DigitalOcean App Platform (comparable to AWS ECS). The app platform is easier to set up, but seems to have some slight performance disadvantages versus a custom Docker instance with an nginx container to route requests. For background, I got into web development via standard HTML/CSS/javascript, then jQuery, and more recently moved on to React-based frameworks (Gatsby, NextJS). My opinion is that React-based frameworks have raised the level of abstraction to
Read the rest
o high and attempt to solve problems that 99.9% of web applications don't have - such as optimizing web KPIs like First Contentful Paint and painting a picture-perfect SEO story. These things matter when you're afraid your user base might run away from your application and never return if you don't serve them something within the first 250 milliseconds of landing on a page. If your user base consists of more than just the reptilian brain, I would suggest you return to the basics and write web apps that take advantage of the core HTML5 spec. There are a huge number of features available in native HTML in 2024 - why isn't the web dev community knowledgeable about those features, let alone using them? The advantages of "minimalist coding" are numerous: 1 - A better, portable understanding of how the web actually works - be a long-term developer, not a short-term frameworker[^1] 2 - Agility in coding - refactors are not a thing to be afraid of when the code base is small and manageable. 3 - Minimal external dependencies, especially with the hell that is the npm world. My Django project has a total of 8 production dependencies - half of which could probably be removed if I wrote a couple hundred more lines of code. Compare that to the hundreds+ dependencies that a boilerplate React-based framework project will hoist upon you. I admit, pip in the Python world is not great - but I can get my brain around the problem and deal with it. 4 - Long-term maintainability - Older tools have staying power. If a tool has been around for 20 years and is still maintained, chances are it will stay around for another 20 years. Compare that to the latest flavor-of-the-day framework that might stop being supported when a big company decides to fire that team and shut down support for the service (e.g., Gatsby after being purchased by Netlify). Waking up and finding out your web app will no longer run ever again is a miserable feeling[^2] [^1]: https://archive.ph/XSPRr [^2]: https://github.com/gatsbyjs/gatsby/issues/38696
In Ask HN: Recommended front end stack for complete beginner?
meesles·Jul 6, 2021
Agreed with many other posters here - the execution was messy and definitely lacked the calm and collected attitude I'm used to seeing when looking at new standards being discussed. I was also unimpressed with the tone of the issues/PRs opened. As an adult, one of the many lessons we learn is that if you want people to do something you want, you should be friendly, constructive, and positive - not calling out people on bad behaviors. I definitely don't want to encourage ignoring issues and letting people get away with things, but in this context a change in attitude would have brought much more success IMO Also I found it really weird that this has just bubbled up to the front page when the original PRs for this project were opened in 2019[1]. Why is this popping back up now? [1] https://github.com/gatsbyjs/gatsby/pull/19528
In Console Do Not Track – Proposal for a standard environment variable
technion·Jun 23, 2021
React itself can be fine, but most of the ecosystem doesn't. Next.JS: https://github.com/vercel/next.js/issues/256 Gatsby: https://github.com/gatsbyjs/gatsby/discussions/10890 Create React app (a solution exists, but is not enabled by default): https://stackoverflow.com/questions/58354362/inline-script-b... Google tag manager involves jumping through hoops the people running GTM usually won't jump through: https://developers.google.com/tag-manager/web/csp
In CSP bypass: How one Chrome XSS bug took 2.5 years and an HTML spec change to fix
swyx·May 24, 2021
all CLIs that do substantial work should have dry runs. more examples I've collected: - Angular CLI https://malcoded.com/posts/angular-fundamentals-cli/#--dry-r... - AWS CLI https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-h... - Rspec https://relishapp.com/rspec/rspec-core/v/3-8/docs/command-li... - Serverless framework https://forum.serverless.com/t/dry-run-with-serverless-frame... at netlify we didnt do a dry run but Netlify Dev is close: https://news.ycombinator.com/item?id=19615546 I'm requesting one at Gatsby: https://github.com/gatsbyjs/gatsby/discussions/16384
In In praise of --dry-run
tmsh·Dec 12, 2020
Top-scored projects: https://commondatastorage.googleapis.com/ossf-criticality-sc... For JS: node│https://github.com/nodejs/node│JavaScript│73│0│3226│10│64.7│63│1517│2055│4.1│10499… react-native│https://github.com/facebook/react-native│JavaScript│71│0│2866│5│50.5│15│778│1694│3… react│https://github.com/facebook/react│JavaScript│91│0│1609│6│20.9│6│692│973│3.8│333619… gatsby│https://github.com/gatsbyjs/gatsby│JavaScript│67│0│3873│3│83.3│2│2181│2526│1.9│118… three.js│https://github.com/mrdoob/three.js│JavaScript│130│0│1694│8│64.3│12│606│801│3.1│229… bootstrap│https://github.com/twbs/bootstrap│JavaScript│113│0│1360│7│21.7│9│729│912│2.1│14966… material-ui│https://github.com/mui-org/material-ui│JavaScript│76│0│2256│7│53.8│43│1561│1826│2.… odo
Read the rest
o│https://github.com/odoo/odoo│JavaScript│79│0│1761│4│131.1│0│6105│7104│1.9│50311│0.… next.js│https://github.com/vercel/next.js│JavaScript│50│0│1415│5│54.6│426│1596│2194│3.0│43… Rocket.Chat│https://github.com/RocketChat/Rocket.Chat│JavaScript│67│0│773│4│28.8│135│1242│2002… cypress│https://github.com/cypress-io/cypress│JavaScript│70│0│235│5│27.7│29│934│1573│2.5│7… amphtml│https://github.com/ampproject/amphtml│JavaScript│64│0│1055│8│56.7│118│1317│1848│1.… amphtml│https://github.com/ampproject/amphtml│JavaScript│64│0│1055│8│56.7│118│1317│1848│1.… amphtml│https://github.com/ampproject/amphtml│JavaScript│64│0│1055│8│56.7│118│1317│1847│1.… that's a bug for 'amphtml' rite?
In Finding Critical Open Source Projects
adamschwartz·Aug 24, 2020
Gatsby is pretty powerful but also quite complicated and has a fair amount of issues to deal with. For example it was pretty unergonomic to set up support for deploying to a `pathPrefix` [1] while retaining the ability to develop locally [2]. Nevertheless, we were able to make it work and have been relatively happy with Gatsby overall. Absolutely! The docs are dual MIT and Apache licensed [3] so have at it. One note: we have not yet completely teased apart the so-called “engine” from our particularly implementation itself. This is something we’re planning to do, in part because we need to to support our other docs sites. You may find it easier to work with once we’ve done that. That being said, you can also just fork the repo, change the content and branding, and things should mostly “just work”. Of course if you run into issues along the
Read the rest
way, we’d be glad to have contributions back to the project itself. Good luck! [1]: https://git.io/JUJsy [2]: https://github.com/gatsbyjs/gatsby/issues/16040 [3]: https://github.com/cloudflare/workers-docs-engine
In New and improved Workers Docs
city41·May 28, 2020
The kicker with Gatsby is it’s actually not compatible with GitHub or any hosting where you can’t control caching headers. Gatsby relies on page-data.json files to not be cached[1] in order to work correctly. This is not possible with GitHub pages. After deploying a new version of the site, some users will use a cached version of page-data.json which can cause them to see a flash of the new data that quickly gets replaced with the old data. It can also cause the site to throw a JS exception in some cases. [1] https://github.com/gatsbyjs/gatsby/issues/15080#issuecomment...
In Gatsby raises $28M Series B led by Index Ventures

Showing the 15 most recent of 50 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.