That you can point to their documentation about their data collection practices, which are explained in concise English with opt-out instructions, and that this is apparently detailed to the user on install, strongly suggests Gatsby is not spyware.
Telemetry can be very valuable to open source projects which have extremely limited resources. The Adium project used telemetry to decide when they could drop support for PowerPC processors and old versions of macOS[0]. Homebrew uses it to track which of its thousands of packages are the most problematic to install[1].
Sounds like spyware to me to do that without opt-in. Projects that do that wont take your privacy seriously.
They transmit your unique identifier to Google every time you run brew, which effectively provides Google with your coarse location tracklog via client IP geolocation.
Data collection like this that is done without the consent of the user is extremely unethical, rude, and in some jurisdictions actually illegal. The fact that the data they steal is useful to them is not relevant and your bringing it up is telling.
It actually has nothing to do with whether or not I agree with it, and everything to do with whether or not they obtain consent to exfiltrate this information. Neither Homebrew nor Gatsby obtain the consent of the user to transmit their spying data.
YASSB processes HTML, (S)CSS, JavaScript/TypeScript, JSX/TSX, JSON, MarkDown and many other files and combines them into beautiful static websites.
I am the creator of YASSB, I'd love to hear what you think about it!
[1] [https://yassb-foss.github.io/](https://yassb-foss.github.io/...
I like Gatsby's createPage API that lets you programatically create pages from source data at any url, rather than the "traditional" approach of binding views to URL patterns. It's useful for some kinds of static sites that might have a radically different template or data source/model for multiple pages that fit the same URL pattern.
Gatsby's use of GraphQL, which can be a pain especially as you scale larger, is nice how it lets you query just the fields you need, so your dehydrated data remains pretty minimal. It's something that I've struggle with when building a site with NextJS - I would have to set up and create my own GraphQL server.
Gatsby is a weird one because it has these "advanced" features that really benefit larger sites (or sites with larger ambitions), but Gatsby really can't handle large sites or data.
Hell, just throw in some PHP if you want dynamic bits and pieces. Your fancy netlify/cloudflare/vercel setup may not like it but your infinitely cheaper shared host/VPS provider will.
If you still wanted static output, you could probably serve it locally and then let wget crawl it for you.
Here's the complexity part that tools try to solve.
Looks like a great tool for migrating an existing dynamic site into a more static workflow, but it's not exactly the workflow I was replying to.
It's actually the opposite. Static site hosting is so much easier to optimize, that it costs just few cents a month, if anything at all (I never went beyond Netlify's free plan).
There you go. Go beyond Netlify's free plan and it can get pretty expensive.
I can do exactly the same with a cheap VPS running apache and PHP and a deploy is little more than an SCP or FTP upload away. I don't have to worry about a build pipeline at all.
I'm not aiming this at you, but in general I'd love to see how newer engineers would tackle things like deployment if they couldn't rely on some SaaS offering.
Or are we talking about static sites that are static because they do all the server side stuff on the browser, and you're pulling down things like react and graphql to render a blog post?
pip install pelican; git init . ; pelican-quickstart; vim pelicanconf.py # to set the theme
pelican . && git add -A && git commit -m "post title" && git push
But I think you overestimate the time to "setup the CI workflow" actually takes. It's just a text file where you put the commands above, so it can run on the server instead of your machine. There's no black magic to it.
> I don't have to worry about a build pipeline at all.
Of course you do; it's just that your build pipeline runs every time someone accesses your site.
> I'm not aiming this at you, but in general I'd love to see how newer engineers would tackle things like deployment if they couldn't rely on some SaaS offering.
I've done that too. I created a bare git repo on the server, with a post-receive hook that checkouts "master" and runs the static site generator. Then I had Nginx serve the directory.
The biggest value was I could share a lot of components between my app and marketing site. Even though most of the marketing site was static content, Gatsby made it incredibly easy to introduce well integrated custom features.
I never hit of the point of needing a full CMS (the site wasn't large enough), so it was great for my needs. Not sure why anyone would use it if they're going full CMS, though.
If the true goal of the devs is to do the fun first 25% of the work, then the signs that a particular job hasn't been finished are unwelcome. A stale-bot sweeps most problems under the rug and, as we see in the discussion here, discourages reporting in the first place. The numbers look better, the devs get to feel like things are under control, and they get to rush on to the next shiny thing.
And perhaps it works one layer deeper, too. Their website's all about "fast, fast, fast"! They advertise the ability to "create a complete website in the time it usually takes to build a prototype". I would read a claim like that suspiciously: when I build prototypes, I leave out things that are important for sustainability. But the things I think are "finishing the job right" seem to others as tedious and uninteresting things to be skipped if possible. So perhaps the devs have found themselves an audience like themselves that are fine with a high level of brokenness as long as they get the feeling of moving forward quickly?