This is extremely surprising, right? I clicked the headline thinking it was a shame some tech company chose the same name as a fairly popular static site generator. I guess when I see things like $50/mo for them to host a site, I just assume it's an extremely small team with a couple clients.
I'm very surprised that a static site generator can raise this much capital, but it suggests to me that 1) the security dilemmas of non-static but content driven sites are still big enough to warrant adoption of this methodology 2) potentially, there is something they are doing right in this space.
I'd really like to know what 2 is as there's a lot of other options in this space that are also free, open source, and seem to accomplish the same thing. What is the Gatsby sauce?
I've been using Gatsby to develop some sites and I suppose the benefit is you can largely develop like you would a frontend app and deploy like a static site. It is actually quite nice to use though the GraphQL takes a while to get used to.
It bakes in things that make the experience better. SPA routing and high lighthouse scores are nice, but if they take a lot of work to accomplish, they might not be worth it for a small media site. If they're as easy as WordPress, however, then you're giving WordPress some real competition.
I hear this, but is this a differentiator when compared to the other static site generators?
I was under the impression that Gatsby was just another interchangeable part of the so-called JAMstack...? Could you not get those wins using Pelican, or Hugo, or whatever?
2 - I'm not a developer, i just did a few wordpress themes, while looking at a static site generators i gave a try to gatsby because of the way it use images and it was a joy, i learned some javascript, discovered react, used a lots of things for the first time and it was just a great experience, lots of tools, good documentation, it was just fun for me.
> I'd really like to know what 2 is as there's a lot of other options in this space that are also free, open source, and seem to accomplish the same thing. What is the Gatsby sauce?
I just browsed around their site wondering the same thing, the conclusion I reached was that their main value proposition is the integrations they provide together with the automation and deployment pipeline as a service. But I must also say it is pretty unclear what you are actually buying with the $50/mo subscription; what do you get compared to just running the software on your laptop?
> I'm very surprised that a static site generator can raise this much capital
Why?
They charge $50/mo and maybe the recurring revenue checks out for preferential investors to feel comfortable with making a profit. If Gatsby can get their service included in a bunch of the domain name registration sites, pushing out Wordpress, then they get exponentially more customers!
The real question is what they plan to do with the $15 million, followed by why the founders wanted to give up that much of the company as the revenue is probably fine. I don't think they actually are scaling majorly, except sales people. I think they are going to be subsidizing open source development, another developer day care shop that ideally will have the byproduct of making the tooling they use even more easy to use.
> If Gatsby can get their service included in a bunch of the domain name registration sites, pushing out Wordpress, then they get exponentially more customers!
I don't follow this reasoning. The hosting sites that offer Wordpress, offer it because it is free. GatsbyJS is free. The service offered by Gatsby is not. Given the difference between $0 and $50/month, I don't see Wordpress going away anytime soon.
Raising capital isn't success. Profitability is success.
I think the main value of Gatsby is the community-generated recipes to plug and play...but is there value here?
If you have one very generic application, then maybe you save time upfront. But you are tied into this heavy wrapper around React that will probably cause you problems down the line. And you probably still need a backend. So I am not sure what value is being created?
If you specifically need to generate lots of sites, or you have some performance requirement (and data that doesn't change often) then maybe. But I wouldn't use it to build anything complex (i.e. that would tie me into their product) because building an app isn't that much harder. I am sure there is a niche use but I think most people aren't doing anything complicated with it (I use it that way).
I also don't really see how this could be a Wordpress killer (which is the intent of the fundraising presumably). Wordpress is totally end-to-end, it abstracts away all the right parts. This doesn't. $15m won't change that.
In theory, I think applications like Prismic or Contentful (I think it is) actually break up these tasks better. From your app, you have a (usually) simple API. And it reflects the division of labour in most companies i.e. that code and content are separate (before anyone says it: they aren't offering a different product to Gatsby, if it seems that way then that is the point).
Gatsby has existed as an open-source project for >4 years, but we just launched our CMS Preview in open beta about 3 months ago -- lots more to come on that front!
It's actually quite common to use Wordpress as a backend for a Gatsby site. So: build your UI in React with Gatsby, store your content with Wordpress.
There's an out-of-the-box Wordpress/Gatsby integration, and we recently hired Jason Bahl, the creator of WPGraphQL, to make that integration even better!
I considered signing up for them for a somewhat simple markdown-powered blog, but ultimately ended up writing my own solution because I couldn’t justify the cost. The documentation for the self-hosted solution seems designed to put you off doing it yourself.
My personal site is running Gatsby on Netlify, I haven't paid for anything except my domain. I'm not the biggest fan of Gatsby, but it's pretty decent for some projects.
I'm missing something from the picture I guess, but what service they offer for 50 bucks/month if you could host your static page built with Gatsby literaly anywhere for much less / free?
I have no idea how well the hosted service works, but Gatsby has been one of my favorite frameworks for a while, and I'm happy they're throwing some extra talent into making it awesome.
Thanks! We're really excited to be able to invest even more in open source. If there are particular features that would be helpful for you please open an issue on the repo!
> which promises that it allows these companies to do away with their old LAMP stack and move to a more modern stack, based on modern open-source tools and engineering practices.
Apache/Nginx - some web server will be used, though much as likely something more lightweight than Apache. No proxy_pass needed since Gatsby just generates a bunch of files you need to serve
MySQL - probably not unless married with a very complex backend
PHP - yeah that’s out
To understand Gatsby it’s crucial to understand that it’s using a significantly different architecture than traditional LAMP applications and monolithic CMSes
Just about every production Gatsby instance is either using static data source (list of markdown/json files) or a monolithic CMS on the backend via API. It's more of a modern frontend site framework rather than a true self-contained app.
Gatsby is popular among frontend React devs although I kind of balk at end to end solutions like this. Nice alternatives to Gatsby are React-static and next.js
I love Gatsby. We are about to release a new landing version of https://Standups.io entirely with it. Blog and help center. We got rid of intercom guide :)
Parse.ly also just released their new landing page all done with Gatsby.
You're getting questions about target market, and I'm pretty sure the answer is web development agencies, right? Any shop with a high volume of projects will need a development pipeline, stack, and ops story that is straight forward and fast to work with.
Yep! Right now we're seeing a mix of customers that's roughly 1/3 web development agencies, 1/3 e-commerce websites, and 1/3 B2C lead generation websites.
The value proposition of Gatsby to website agencies is working with modern tech & completing projects faster, and for e-commerce it's higher conversion rates which add $$ to the bottom line.
Your pricing model doesn't offer any benefit for paying annually; in fact, given the time value of money, it is a disincentive. Being paid up front means you can deploy that cash to grow.
Question tangential to Gatsby for those of you who use such static site builders as blogs: are there any good tools for writing/composing posts or are you all doing it by hand?
I have set up the same blog maybe 3 times and I always stop posting because I need to be in my coding environment to do so (and if I'm there, I might as well be working on code). I'd really like to find something that I could use to make a post on my gaming pc, for example, where I can add images easily (and have them resized properly). I feel like I should probably just set up a wordpress site, but wanted to know if I had other options.
I’ve got a site that requires non-technical people to post, and I’m looking into using Contentful or Netlify CMS as their content editing UI, which in turn triggers a build and deploy. (I use Middleman but Gatsby should be able to do the same.)
you can.. though, honestly, i'd advice against wordpress + gatsby. in my experience, because of various plugins required to do various things, the way media is fetched etc, and the highly difficult task of getting things working with schemas in wp.
also, wordpress builds tend to also take the longest.
if you enjoy hacking on wordpress and debugging weird issues, then this might be a good choice.
It's much easier to build a blog using prismic, contentful, or even the netlify cms kind of is nice for a basic "serverless" blog/cms.
honestly, i'd take markdown files in a bunch of folders any day over gatsby-source-wordpress.
Full disclosure: I‘m a Developer Evangelist for Contentful
A “Headless CMS” is one way to achieve what you’re looking to do. Contentful is one, there are others. Gatsby’s has source plugins for all popular ones.
I don't get it: Afaik contentful is a company offering a paid for CMS API, but it isn't a piece of software I can run?
But I must be wrong, or people wouldn't recommend this again and again when asked for a CMS.
I'd love to try it, where can I find it? Wasn't able to find it on github, npm, Google.
> I have set up the same blog maybe 3 times and I always stop posting because I need to be in my coding environment to do so
I had a similar problem and solved it with Forestry[0] and Netlify. Forestry has a nice web interface for writing posts; saving causes the changes to be committed to a GitHub repo. Netlify[1] watches the repo and rebuilds/redeploys the blog.
It sounds a bit complicated, but I've run this setup for 9 months now without any serious issues. To write and publish a new post, all I need to do is: login to Forestry, write the damn thing, and hit "save". The cost is $0.
I wrote a ms word transformer for GatsbyJS. I like it because it lets me add images and stuff and generates the content without having to muck with urls etc.
calcsam: How do you think about defensibility? One might think that because the underlying tech is open source, someone else can also spring up a hosting service. Is that not an issue because agencies would want the official hosting for the open source project because they want the reassurance?
Interestingly, a lot of open-source companies have built defensible businesses -- a list is over at http://oss.cash. Recent IPOs include Mulesoft, Elastic, Mongo, Fastly...
More specifically to Gatsby, we don't actually see ourselves in the hosting business, more in the "collaboration" business -- most websites have teams of nontechnical folks that are reviewing sites before they go live, creating and editing content, and so on. We're building Gatsby-specific collaboration tooling, starting with CMS Preview.
A good comparison here would be Github -- nobody thinks of Github as "Git hosting", they think of Github as the place where developers collaborate together on projects.
The real play must be to take a chunk out of medium right? “Companies that don’t like medium or Wordpress are rolling their own costly solutions, so here we are with the smooth transition”.
The problem is if they want to be profitable they will eventually have to incorporate the bad parts of medium and/or the bad parts of Wordpress and then we’re back to square one with some new minimal open source static site builder. This wheel is exhausting.
Big fan of static site generators and the whole JAMStack idea in general - I use Jekyll extensively - but after building a site with Gatsby, I found it too over-engineered.
React is great, and definitely has its place, but to set up React, GraphQL and all the surrounding tooling just to assemble some text files into a template seems like complexity for the sake of it.
For me, the fun of static sites - after years of building sites with CMSs like Wordpress and Drupal - is that they’re as close as possible to plain HTML, lightning-fast and very simple.
I'm one of the use cases that Sam mentions - B2C website. Replatforming our site with Gatsby, Netlify (hosting and more) and Contentful (headless CMS) has saved us hundreds of dollars a month in hosting - our site which receives 20,000 - 30,000 visitors a month now costs $0 to host. Additionally it is radically faster and more secure than it previously was. Being able to use React as needed has enabled us to manage some relatively complicated form handling/routing, get really creative around how we handle 'sites within the site' for a large sales team that we support, and easily create calculators and other tools for our customers.
And bonus - I'm a graphic designer by trade. For one reason or another a web team of 7+ people left my company over the course of 6months and I stepped in to fill the void. Just me, one person who had prior experience building the odd site (maybe one a year) with HTML, CSS. I literally learned javascript and React through Gatsby (I'd say I'm junior developer level at this point - which is actually a good fit for my company).
Gatsby is a great product (for many use cases), run by a generous team, surrounded by an equally generous community. I owe my career to Gatsby. My company is saving hundreds of thousands of dollars a year thanks to Gatsby. Stoked to see Gatsby's continued growth and success.
I definitely understand the disbelief, but this is the truth. I started visiting hacker news to try to familiarize myself with the tech world, learn new jargon, blah blah blah, and have always just lurked. I think so highly of Gatsby that I finally created an account just to say so.
Like I said, I come from a graphic design background. Mostly freelancing and working for different organizations that just needed an in house guy to do a little bit of everything. Low pay stuff in non-tech organizations - literally a small boutique in one case where I also managed retail workers. I never really got a good career off the ground for many reasons, one of which was probably the "great recession". Not a ton of demand for mediocre graphic designers who aren't very career oriented to begin with.
Probably around 4 years ago I got it in my head that maybe I could learn to build websites and either get a side hustle going or work my way into it. I did online courses, videos, etc., but never had the money or guts to jump into a code camp or something more legit, and honestly nothing really stuck.
Started a new graphic design gig around 3 years ago. The company was in Real Estate. Like I said - large sales team that really needs their own mini-sites within a site as the service we provide is really driven by their personal brands and relationships. As a designer on a small design team I mostly produced print ads for the sales folks - we were like a mini agency and a way of recruiting top talent. A strong corporate brand / web presence hasn't been necessary to create a successful company of just under 1000 employees, although everyone involves knows that it would only help the business. Pretty shortly into my time there I watched the web team (this includes a project manager, front end developer, ui/ux designer, 3 person SEO/analytics team, a content/data entry person, a middle manager for all of them, and some resources from the IT department) fall apart. That group wasn't really producing much - they refused to even build landing pages, didn't do any kind of SEM, etc. This is for a variety of reasons many of them political. Maybe this entire environment seems a little crazy, but I think this is far more common in many industries than people involved in tech might realize.
At some point an agency was brought in to manage the web presence, but they were very obviously neglecting our site. Managers in my department knew I had done some web in the past and used me to run around the agency. The agency kind of knew it, and even had me do stuff on their behalf - I didn't care it beat designing ads for local newsletters, and mailers. A really generous javascript developer at the agency mentioned Gatsby to me once, saying that he wanted to build everything on it, including the next iteration of our website. I could see the writing on the wall, so I decided to learn it thinking(hoping) that I might have to maintain a Gatsby site one day. I think 1.0 had just been released at that point. Not long after, they were fired and I was left holding the ball.
The site I inherited was built on wordpress. Because of the neglect it was many versions out of date, and rotting the way wordpress sites can when they aren't maintained. I did what I could to hold it together and doubled down on learning Gatsby and React. When I started replatforming our website it was a lot of false starts, I played with Hugo, headless wordpress in Gatsby, all kinds of schemes - honestly figuring it out as I went along. Eventually stuff started coming together. Each feature I was forced to build (was making an exact duplicate of the wordpress site) forced me to learn more about the toolset that was organically coming together - gatsby (which includes react and graphql), netlify, contentful, mailgun (remember that complicated form routing/logic), and more. I asked the IT dept, what the wordpress instance for our og site was costing us and learned it was $500+ a month. I did everything I could to keep us i...
To be fair:
There are lots of options for a headless cms - I'm extremely confident that I could easily move my data to another free or super cheap service - even back to a free wordpress site if need be (to use as headless cms).
Also lots of extremely cheap options for free or very cheap hosting of static sites. That would also be an incredibly easy move to make.
Not trying to fanboy
Not saying gatsby is right for every use case and every developer
Am saying that it makes a lot of sense for my specific use case and probably for a lot of this agency and old-school-business-website style work. I suspect it is a very large market that provides decent livelihoods for many millenials that skated, snowboarded, surfed, or played in bands as young adults (kind of serious)
I just wanted to share that as an personal experience that people can weigh against other viewpoints.
Am I more convincing, with a six year old account?
I'm the exact target market for Gatsby, and can confirm the benefits that GP gave. Perhaps I can tell you how I've been selling it to my clients. I work at an agency, which builds sites in the ~$100k range. Most of our clients are currently using something like Drupal, or an ancient proprietary CMS. The RFPs now often specify Drupal "or other open source CMS". We're now offering them Gatsby + headless Drupal, and it gives them some significant benefits. These are sites that are currently paying thousands per month on multiple load-balanced Drupal servers, or managed hosts like Acquila. Gatsby lets them switch to a single Drupal instance on something like Lightsail, firewalled to give access to just their admins. Gatsby can then build the site (using CodeBuild or Amplify) and deploy to S3, so their hosting fees are then tens of dollars in CloudFront egress plus Lightsail. They also don't need 24x7 Drupal support, because it doesn't matter if the server ges down in the middle of the night, because their site stays up, and they don't need instant Drupalgeddon patching because their server isn't public-accessible.
I think the classic JAMStack/Markdown features of Gatsby are a red herring. I love them for my own site, but no client will use them (even with Netlify CMS, unfortunately). However it gets developers like me to try it out, and hopefully realise the benefits that it can offer.
My biggest concern with Gatsby is the build time. Drupal is not exactly known for being fast, and as I understand it, Gatsby asks for the entire site's worth of content for every build, right? How has that worked out for you?
I have Drupal sites with dozens of entity types and tens of thousands of nodes. I feel like Gatsby would have us waiting for an hour-long build every time we want to post a new node.
It's tough to take this too seriously since it seems you created this name just to make this comment. What approaches did you try before 'owing your career to gatsby'?
check out my reply above - the owing my career to gatsby is very much about my specific story - a story that is probably very different from most hackernews contributors but maybe some aspects of it are more common for the lurkers here, of which I am one.
I would honestly be interested to know how many self taught people making things work building basic sites for unglamorous corners of the internet cruise this site.
To be honest I don't really feel welcome here because I'm not sophisticated (prob the best word for it) enough. But that's ok.
I run Hacker News. We're not interested in sophisticated; we're here for curiosity. If have that, which I'm sure you do, then you're welcome here, so please don't let a single comment make you feel otherwise.
Consider that the downside of your being wrong is that you drive a newcomer away from this community. That's surely not what you want, and definitely the opposite of what this place is for.
When I pitch my boss on Next.js s/he will ask how confident I am that Zeit is going to remain a profitable concern subsidizing active development for years to come.
Gatsby and Next.js are both site frameworks powered by React. They can both be used for static and dynamic sites with different conventions and features around routing, data management, and general app architecture.
Both are "hip" and will likely remain as the top 2 javascript based site frameworks for now, although whether you need either of them is an entirely different question.
TLDR: I just completed a large project built with Gatsby, and wouldn't recommend it to anyone. The technology is extremely complicated, and the end result quite inflexible.
Here's an idea of how the whole thing works when you have non-technical users:
1. You need some sort of Content Management System for non-technical users to be able to create content.
2. That CMS stores the content however it sees fit (db/files/whatnot) and provides an API to fetch it.
3. In gatsby, you build "source plugins" that fetch the content and fill it in an in-memory GraphQL sever.
4. Building the site entails fetching all content, feeding it to GraphQL, making a webpack build to run in nodejs, making a webpack build to run on the final site, and finally generating the HTML files.
If this doesn't sound so bad, here are some complaints in no particular order:
- There are no incremental builds. You must rebuild everything every time you want to publish a change. Our builds currently clock in at ~8min.
They've been saying they want incremental builds since 2 years ago. They are "just around the corner" since ~6 months ago. They "already did the hard part" ~4 months ago. They "will offer incremental builds sometime in the future but only in the cloud paid-for version" as of ~1 month ago.
- Users hate not being able to immediately see how their content will look like (especially if every time they publish there's a ~10min. delay to actually being able to see it). We had to setup a "preview" environment that is running gatsby in development mode. Gatsby the company just recently started selling this as a paid cloud service (we built it ourselves).
- Development mode does not serve html files like production builds do. The site behaves differently in that mode, and some issues only happen in actual builds. When you encounter one such issue, the feedback loop becomes "full build for every change" == ~10min of waiting to try every single change. This is a HUGE productivity killer.
- Gatsby generates html files. Then it hydrates that html in the client, using ReactDOM.hydrate. Sounds cool, but the React devs explicitly stated that prerendered content must match exactly what the client-side would render, and if it doesn't your site may completely break and it won't be considered a rehydration bug.
Now consider what happens if you try to use a component that changes appearance by doing size detection, or if you have some area that changes between "Hello <user>" or "log in" depending on whether the client is logged in, etc. BTW, these bugs only happen when you test actual builds, not in development mode of course (massive waste of time as per the point above).
- Gatsby hijacks NODE_ENV (setting it to "production" for actual builds and "development" for the development mode). This leaks into the many tools involved in the many things that happen while building (babel, webpack and all of their plugins, times two compilations, plus the rendering phase, etc). For instance, I've lost many hours trying to get a full, tree-shaken but unmangled build to no avail.
- Gatsby infers GraphQL types from the data you feed into it. It usually works, but when it doesn't it is painful to discover why (your queries return weird results) and fixing it means specifying your data types manually (something you already did once when you defined the database, again to define the models in the CMS, and yet again when you specified the API Gatsby uses to fetch the contents)
- Many months ago we went with CSS Modules because Gatsby sold it as a way to get the CSS required for each page inlined in the HTML itself. Fast-forward a bit, people where having issues with specificity (because of ordering) ... and now Gatsby inlines ALL of the site's css in each and every page. Our html's usually have more inlined CSS than actual HTML!
> Development mode does not serve html files like production builds do. The site behaves differently in that mode, and some issues only happen in actual builds. When you encounter one such issue, the feedback loop becomes "full build for every change" == ~10min of waiting to try every single change. This is a HUGE productivity killer.
This got me so many times. I was frustrated enough that I set up a headless chrome prerenderer to snapshot my gatsby-built site before every single deploy just so I could verify the html diff to make sure my site looked correct still.
The trust issues alone were enough to make me switch off of it.
> Users hate not being able to immediately see how their content will look like
Shameless plug: I'm building a product that does what Gatsby Preview does, except it's platform agnostic, and ties in tighter wth the feedback/review process. https://featurepeek.com
"now Gatsby inlines ALL of the site's css in each and every page"
Did this abruptly happen at some point? I've had attempts to migrate components from old repositories cause similar issues and all I could see is that something with the dependencies of that project (e.g. "tree-model" definitely seemed to cause issues) were forcing gatsby to be overly safe in terms of culling CSS.
Similarly we had issues with imports a component library, but upon inspecting other projects the same issue was happen with client side rendered apps, so it was down to how we built the library rather than Gatsby.
My experiences were pretty positive but I did encounter every issue you've listed and would probably try next.js next time just to know what I've been missing. Have you worked with it before doing similar stuff?
-------------
As far as Gatsby goes I think it occupies a definite niche but one that needs to communicated very effectively. You get:
- static web pages
- react ecosystem (very useful if all other company frontends are on react and there's a design system)
- some webapp functionality
The last one being key, more than _some_ and it's probably going to start becoming a headache juggling all the pieces.
> "now Gatsby inlines ALL of the site's css in each and every page" Did this abruptly happen at some point?
It happened in gatsby @2.1.3 (a minor "patch" release!) [1]
> would probably try next.js next time just to know what I've been missing. Have you worked with it before doing similar stuff?
Not at the same scale. However, just reading their docs gives me way more confidence in that they are explicit about what the thing does or doesn't do. For instance, they can do prerendering like gatsby but there are many warnings about it in the docs [2], and you can always fall back to per-request SSR on any page if prerendering doesn't work there.
Also it does away with the whole graphql thingy (you just get a `fetch` that works both server-side and client-side) and call the "backend" api directly.
I switched my personal Jekyll site to Gatsby 2 years ago. I ran into some minor bugs and even contributed 3 PRs that got merged. I loved working with it for a few weeks. Two months after switching, it too dawned on me how over-engineered it is. I switched off of it to a custom static site generator I made (admittedly it was also over-engineered), but I'm finally back to a simple static generator called zola [1] and it feels so refreshing.
Not only is Gatsby over-engineered, it's also bloated IMO. I think one of their main selling points it that page loads seem instant. Preloading other pages in the background seems needless to me when we're talking about a simple blog. Sure, it might be good for apps, but forcing my (few) visitors to download needless mbs on desktop or mobile seems like a bad user experience to me.
I like the look of Zola, and I bookmarked it when I saw the README pick a bone with Hugo's templating engine. Take a look at the Hugo Discourse forum and I can't imagine less than 99% of the topics are about Go/Hugo templating issues. The Hugo docs basically say "we use Go's template engine, go learn that confusing shit and then we'll tell you 5 different deprecated ways to get today's date if you are enough of a masochist."
It's not for the sake of it. It's so Gatsby didn't have to achieve much beyond wrapping some complicated frameworks to be useful. Basically, about 5 minutes into setting up Gatbsy, you go "Oh, so it's just React and GraphQL. Ok..."
Congrats to Kyle and the team. Been using Gatsby in prod for nearly a year now (v1 then migrated to v2), the team is super helpful and responsive to feedback and issues.
Gatsby is great; we use it for all our marketing sites because it doesn't hide content behind JavaScript like plain React so it's better for SEO. Gatsby would be great to compete with Netlify for static React app hosting.
I don't understand the hype around Gatsby and co. Here in France everyone uses wordpress/drupal + docker and boom. This combo works great and there is no need to reinvent the wheel.
Are you serious? Then why are you suggesting libraries? Or even languages? There's nothing stopping you from generating static files using machine instructions directly.
I don't get it: Afaik contentful is a company offering a paid for CMS API, but it isn't a piece of software I can run?
But I must be wrong, I people wouldn't recommend this again and again when asked for a CMS.
I'd love to try it, where can I find it? Wasn't able to find it on github, npm, Google.
I don't really like Gatsby's product, but I've got to admit that their business strategy makes a lot of sense. It's a pretty good three-step approach:
1. Convince the WordPress/enterprise crowd to switch over, both by touting the genuine benefits of static sites (security, scalability, TTFB performance, etc.) and by riding the Cool Kid Front-End Stack hype train.
2. Lock them in with an overly-complicated framework and build pipeline that requires organizations invest a lot of resources into switching. (Gatsby gets most of this for free by building on top of the Cool Kid Stack's nine-thousand-package NPM lasagna.)
3. Sell their captive audience expensive solutions to problems they wouldn't have with other frameworks. (See e.g. another commentor's discussion of incremental builds.)
This strategy might not contribute much to society, but neither do a lot of other startups--what matters to investors is that it'll probably make them a lot of money, assuming they execute it correctly.
> 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.
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.
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.
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?
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.
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 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.
> 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.
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.
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.
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)
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.
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 ?
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/
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.
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.
212 comments
[ 2.7 ms ] story [ 305 ms ] threadI'd really like to know what 2 is as there's a lot of other options in this space that are also free, open source, and seem to accomplish the same thing. What is the Gatsby sauce?
I was under the impression that Gatsby was just another interchangeable part of the so-called JAMstack...? Could you not get those wins using Pelican, or Hugo, or whatever?
I just browsed around their site wondering the same thing, the conclusion I reached was that their main value proposition is the integrations they provide together with the automation and deployment pipeline as a service. But I must also say it is pretty unclear what you are actually buying with the $50/mo subscription; what do you get compared to just running the software on your laptop?
Why?
They charge $50/mo and maybe the recurring revenue checks out for preferential investors to feel comfortable with making a profit. If Gatsby can get their service included in a bunch of the domain name registration sites, pushing out Wordpress, then they get exponentially more customers!
The real question is what they plan to do with the $15 million, followed by why the founders wanted to give up that much of the company as the revenue is probably fine. I don't think they actually are scaling majorly, except sales people. I think they are going to be subsidizing open source development, another developer day care shop that ideally will have the byproduct of making the tooling they use even more easy to use.
Any insight?
I don't follow this reasoning. The hosting sites that offer Wordpress, offer it because it is free. GatsbyJS is free. The service offered by Gatsby is not. Given the difference between $0 and $50/month, I don't see Wordpress going away anytime soon.
I think the main value of Gatsby is the community-generated recipes to plug and play...but is there value here?
If you have one very generic application, then maybe you save time upfront. But you are tied into this heavy wrapper around React that will probably cause you problems down the line. And you probably still need a backend. So I am not sure what value is being created?
If you specifically need to generate lots of sites, or you have some performance requirement (and data that doesn't change often) then maybe. But I wouldn't use it to build anything complex (i.e. that would tie me into their product) because building an app isn't that much harder. I am sure there is a niche use but I think most people aren't doing anything complicated with it (I use it that way).
I also don't really see how this could be a Wordpress killer (which is the intent of the fundraising presumably). Wordpress is totally end-to-end, it abstracts away all the right parts. This doesn't. $15m won't change that.
In theory, I think applications like Prismic or Contentful (I think it is) actually break up these tasks better. From your app, you have a (usually) simple API. And it reflects the division of labour in most companies i.e. that code and content are separate (before anyone says it: they aren't offering a different product to Gatsby, if it seems that way then that is the point).
Gatsby Preview / Gatsby Content Mesh is most likely the horse being bet on.
Automattic just raised $300 million dollars a week or so ago.
One vision of success, I'm very sure, is getting acquired by Automattic.
Gatsby has existed as an open-source project for >4 years, but we just launched our CMS Preview in open beta about 3 months ago -- lots more to come on that front!
There's an out-of-the-box Wordpress/Gatsby integration, and we recently hired Jason Bahl, the creator of WPGraphQL, to make that integration even better!
And Gatsby JS work really well, as well.
I considered signing up for them for a somewhat simple markdown-powered blog, but ultimately ended up writing my own solution because I couldn’t justify the cost. The documentation for the self-hosted solution seems designed to put you off doing it yourself.
LAMP stack is open source...
Apache - Gatsby doesn't run behind a load balancer (apache/nginx) with proxy_pass?
MySql - Gatsby doesn't persist data into a database (MySql/Postgres)?
PHP - I'll give you that PHP is out and node.js is in for backend development.
Apache/Nginx - some web server will be used, though much as likely something more lightweight than Apache. No proxy_pass needed since Gatsby just generates a bunch of files you need to serve
MySQL - probably not unless married with a very complex backend
PHP - yeah that’s out
To understand Gatsby it’s crucial to understand that it’s using a significantly different architecture than traditional LAMP applications and monolithic CMSes
Parse.ly also just released their new landing page all done with Gatsby.
The value proposition of Gatsby to website agencies is working with modern tech & completing projects faster, and for e-commerce it's higher conversion rates which add $$ to the bottom line.
And then he doesn't answer any.
Of course, to be fair, Meteor is still in business after taking the same path (though it seems most efforts are directed at Apollo?)
I have set up the same blog maybe 3 times and I always stop posting because I need to be in my coding environment to do so (and if I'm there, I might as well be working on code). I'd really like to find something that I could use to make a post on my gaming pc, for example, where I can add images easily (and have them resized properly). I feel like I should probably just set up a wordpress site, but wanted to know if I had other options.
https://www.gatsbyjs.com/guides/wordpress/
also, wordpress builds tend to also take the longest.
if you enjoy hacking on wordpress and debugging weird issues, then this might be a good choice.
It's much easier to build a blog using prismic, contentful, or even the netlify cms kind of is nice for a basic "serverless" blog/cms.
honestly, i'd take markdown files in a bunch of folders any day over gatsby-source-wordpress.
A “Headless CMS” is one way to achieve what you’re looking to do. Contentful is one, there are others. Gatsby’s has source plugins for all popular ones.
They have a nice getting started guide for Gatsby + Contentful: https://www.gatsbyjs.org/docs/sourcing-from-contentful/
[1] https://www.ronaldlangeveld.com
I had a similar problem and solved it with Forestry[0] and Netlify. Forestry has a nice web interface for writing posts; saving causes the changes to be committed to a GitHub repo. Netlify[1] watches the repo and rebuilds/redeploys the blog.
It sounds a bit complicated, but I've run this setup for 9 months now without any serious issues. To write and publish a new post, all I need to do is: login to Forestry, write the damn thing, and hit "save". The cost is $0.
0 - https://forestry.io/ 1 - https://www.netlify.com/
https://github.com/abhiyerra/gatsby-transformer-ms-word
In a nutshell, it offers a better UI to edit your content on a Jekyll site by talking directly to the Github API.
Or is it for another reason this isn't an issue?
More specifically to Gatsby, we don't actually see ourselves in the hosting business, more in the "collaboration" business -- most websites have teams of nontechnical folks that are reviewing sites before they go live, creating and editing content, and so on. We're building Gatsby-specific collaboration tooling, starting with CMS Preview.
A good comparison here would be Github -- nobody thinks of Github as "Git hosting", they think of Github as the place where developers collaborate together on projects.
The problem is if they want to be profitable they will eventually have to incorporate the bad parts of medium and/or the bad parts of Wordpress and then we’re back to square one with some new minimal open source static site builder. This wheel is exhausting.
React is great, and definitely has its place, but to set up React, GraphQL and all the surrounding tooling just to assemble some text files into a template seems like complexity for the sake of it.
For me, the fun of static sites - after years of building sites with CMSs like Wordpress and Drupal - is that they’re as close as possible to plain HTML, lightning-fast and very simple.
If existing solutions are near perfect for you, you are not the target audience.
And bonus - I'm a graphic designer by trade. For one reason or another a web team of 7+ people left my company over the course of 6months and I stepped in to fill the void. Just me, one person who had prior experience building the odd site (maybe one a year) with HTML, CSS. I literally learned javascript and React through Gatsby (I'd say I'm junior developer level at this point - which is actually a good fit for my company).
Gatsby is a great product (for many use cases), run by a generous team, surrounded by an equally generous community. I owe my career to Gatsby. My company is saving hundreds of thousands of dollars a year thanks to Gatsby. Stoked to see Gatsby's continued growth and success.
Specially considering the stories from other people here, which include a lot more technical detail.
Also the other users are not new accounts with just one comment (unlike the user above).
If it's just a static landing page I think the Jamstack/Gatsby/Gridsome would be fine.
If it's anything more complex though, you have my condolences. Ecommerce honestly sucks for the reasons others have mentioned.
I've almost finished a Shopify build with Nuxt.js and there have been so many hard learnings.
The more painful one was storing checkoutIds using SSR and cookies. I still don't know if it's best practice or not :/
Like I said, I come from a graphic design background. Mostly freelancing and working for different organizations that just needed an in house guy to do a little bit of everything. Low pay stuff in non-tech organizations - literally a small boutique in one case where I also managed retail workers. I never really got a good career off the ground for many reasons, one of which was probably the "great recession". Not a ton of demand for mediocre graphic designers who aren't very career oriented to begin with.
Probably around 4 years ago I got it in my head that maybe I could learn to build websites and either get a side hustle going or work my way into it. I did online courses, videos, etc., but never had the money or guts to jump into a code camp or something more legit, and honestly nothing really stuck.
Started a new graphic design gig around 3 years ago. The company was in Real Estate. Like I said - large sales team that really needs their own mini-sites within a site as the service we provide is really driven by their personal brands and relationships. As a designer on a small design team I mostly produced print ads for the sales folks - we were like a mini agency and a way of recruiting top talent. A strong corporate brand / web presence hasn't been necessary to create a successful company of just under 1000 employees, although everyone involves knows that it would only help the business. Pretty shortly into my time there I watched the web team (this includes a project manager, front end developer, ui/ux designer, 3 person SEO/analytics team, a content/data entry person, a middle manager for all of them, and some resources from the IT department) fall apart. That group wasn't really producing much - they refused to even build landing pages, didn't do any kind of SEM, etc. This is for a variety of reasons many of them political. Maybe this entire environment seems a little crazy, but I think this is far more common in many industries than people involved in tech might realize.
At some point an agency was brought in to manage the web presence, but they were very obviously neglecting our site. Managers in my department knew I had done some web in the past and used me to run around the agency. The agency kind of knew it, and even had me do stuff on their behalf - I didn't care it beat designing ads for local newsletters, and mailers. A really generous javascript developer at the agency mentioned Gatsby to me once, saying that he wanted to build everything on it, including the next iteration of our website. I could see the writing on the wall, so I decided to learn it thinking(hoping) that I might have to maintain a Gatsby site one day. I think 1.0 had just been released at that point. Not long after, they were fired and I was left holding the ball.
The site I inherited was built on wordpress. Because of the neglect it was many versions out of date, and rotting the way wordpress sites can when they aren't maintained. I did what I could to hold it together and doubled down on learning Gatsby and React. When I started replatforming our website it was a lot of false starts, I played with Hugo, headless wordpress in Gatsby, all kinds of schemes - honestly figuring it out as I went along. Eventually stuff started coming together. Each feature I was forced to build (was making an exact duplicate of the wordpress site) forced me to learn more about the toolset that was organically coming together - gatsby (which includes react and graphql), netlify, contentful, mailgun (remember that complicated form routing/logic), and more. I asked the IT dept, what the wordpress instance for our og site was costing us and learned it was $500+ a month. I did everything I could to keep us i...
I'd also state, that is, for now. These services will have to make money at some point.
To be fair: There are lots of options for a headless cms - I'm extremely confident that I could easily move my data to another free or super cheap service - even back to a free wordpress site if need be (to use as headless cms).
Also lots of extremely cheap options for free or very cheap hosting of static sites. That would also be an incredibly easy move to make.
Not trying to fanboy Not saying gatsby is right for every use case and every developer Am saying that it makes a lot of sense for my specific use case and probably for a lot of this agency and old-school-business-website style work. I suspect it is a very large market that provides decent livelihoods for many millenials that skated, snowboarded, surfed, or played in bands as young adults (kind of serious)
I just wanted to share that as an personal experience that people can weigh against other viewpoints.
I'm the exact target market for Gatsby, and can confirm the benefits that GP gave. Perhaps I can tell you how I've been selling it to my clients. I work at an agency, which builds sites in the ~$100k range. Most of our clients are currently using something like Drupal, or an ancient proprietary CMS. The RFPs now often specify Drupal "or other open source CMS". We're now offering them Gatsby + headless Drupal, and it gives them some significant benefits. These are sites that are currently paying thousands per month on multiple load-balanced Drupal servers, or managed hosts like Acquila. Gatsby lets them switch to a single Drupal instance on something like Lightsail, firewalled to give access to just their admins. Gatsby can then build the site (using CodeBuild or Amplify) and deploy to S3, so their hosting fees are then tens of dollars in CloudFront egress plus Lightsail. They also don't need 24x7 Drupal support, because it doesn't matter if the server ges down in the middle of the night, because their site stays up, and they don't need instant Drupalgeddon patching because their server isn't public-accessible.
I think the classic JAMStack/Markdown features of Gatsby are a red herring. I love them for my own site, but no client will use them (even with Netlify CMS, unfortunately). However it gets developers like me to try it out, and hopefully realise the benefits that it can offer.
I have Drupal sites with dozens of entity types and tens of thousands of nodes. I feel like Gatsby would have us waiting for an hour-long build every time we want to post a new node.
I would honestly be interested to know how many self taught people making things work building basic sites for unglamorous corners of the internet cruise this site.
To be honest I don't really feel welcome here because I'm not sophisticated (prob the best word for it) enough. But that's ok.
https://news.ycombinator.com/newsguidelines.html
Consider that the downside of your being wrong is that you drive a newcomer away from this community. That's surely not what you want, and definitely the opposite of what this place is for.
Next.js is less opinionated.
For example, I had thought Gatsby was the hip way to create static sites in 2019. Then another comment here mentioned it’s Next.js now.
Both are "hip" and will likely remain as the top 2 javascript based site frameworks for now, although whether you need either of them is an entirely different question.
Here's an idea of how the whole thing works when you have non-technical users:
1. You need some sort of Content Management System for non-technical users to be able to create content.
2. That CMS stores the content however it sees fit (db/files/whatnot) and provides an API to fetch it.
3. In gatsby, you build "source plugins" that fetch the content and fill it in an in-memory GraphQL sever.
4. Building the site entails fetching all content, feeding it to GraphQL, making a webpack build to run in nodejs, making a webpack build to run on the final site, and finally generating the HTML files.
If this doesn't sound so bad, here are some complaints in no particular order:
- There are no incremental builds. You must rebuild everything every time you want to publish a change. Our builds currently clock in at ~8min.
They've been saying they want incremental builds since 2 years ago. They are "just around the corner" since ~6 months ago. They "already did the hard part" ~4 months ago. They "will offer incremental builds sometime in the future but only in the cloud paid-for version" as of ~1 month ago.
- Users hate not being able to immediately see how their content will look like (especially if every time they publish there's a ~10min. delay to actually being able to see it). We had to setup a "preview" environment that is running gatsby in development mode. Gatsby the company just recently started selling this as a paid cloud service (we built it ourselves).
- Development mode does not serve html files like production builds do. The site behaves differently in that mode, and some issues only happen in actual builds. When you encounter one such issue, the feedback loop becomes "full build for every change" == ~10min of waiting to try every single change. This is a HUGE productivity killer.
- Gatsby generates html files. Then it hydrates that html in the client, using ReactDOM.hydrate. Sounds cool, but the React devs explicitly stated that prerendered content must match exactly what the client-side would render, and if it doesn't your site may completely break and it won't be considered a rehydration bug.
Now consider what happens if you try to use a component that changes appearance by doing size detection, or if you have some area that changes between "Hello <user>" or "log in" depending on whether the client is logged in, etc. BTW, these bugs only happen when you test actual builds, not in development mode of course (massive waste of time as per the point above).
- Gatsby hijacks NODE_ENV (setting it to "production" for actual builds and "development" for the development mode). This leaks into the many tools involved in the many things that happen while building (babel, webpack and all of their plugins, times two compilations, plus the rendering phase, etc). For instance, I've lost many hours trying to get a full, tree-shaken but unmangled build to no avail.
- Gatsby infers GraphQL types from the data you feed into it. It usually works, but when it doesn't it is painful to discover why (your queries return weird results) and fixing it means specifying your data types manually (something you already did once when you defined the database, again to define the models in the CMS, and yet again when you specified the API Gatsby uses to fetch the contents)
- Many months ago we went with CSS Modules because Gatsby sold it as a way to get the CSS required for each page inlined in the HTML itself. Fast-forward a bit, people where having issues with specificity (because of ordering) ... and now Gatsby inlines ALL of the site's css in each and every page. Our html's usually have more inlined CSS than actual HTML!
I can assure you I'm going t...
This got me so many times. I was frustrated enough that I set up a headless chrome prerenderer to snapshot my gatsby-built site before every single deploy just so I could verify the html diff to make sure my site looked correct still.
The trust issues alone were enough to make me switch off of it.
Shameless plug: I'm building a product that does what Gatsby Preview does, except it's platform agnostic, and ties in tighter wth the feedback/review process. https://featurepeek.com
Similarly we had issues with imports a component library, but upon inspecting other projects the same issue was happen with client side rendered apps, so it was down to how we built the library rather than Gatsby.
My experiences were pretty positive but I did encounter every issue you've listed and would probably try next.js next time just to know what I've been missing. Have you worked with it before doing similar stuff?
-------------
As far as Gatsby goes I think it occupies a definite niche but one that needs to communicated very effectively. You get: - static web pages - react ecosystem (very useful if all other company frontends are on react and there's a design system) - some webapp functionality
The last one being key, more than _some_ and it's probably going to start becoming a headache juggling all the pieces.
It happened in gatsby @2.1.3 (a minor "patch" release!) [1]
> would probably try next.js next time just to know what I've been missing. Have you worked with it before doing similar stuff?
Not at the same scale. However, just reading their docs gives me way more confidence in that they are explicit about what the thing does or doesn't do. For instance, they can do prerendering like gatsby but there are many warnings about it in the docs [2], and you can always fall back to per-request SSR on any page if prerendering doesn't work there.
Also it does away with the whole graphql thingy (you just get a `fetch` that works both server-side and client-side) and call the "backend" api directly.
[1] https://github.com/gatsbyjs/gatsby/issues/11072 [2] https://nextjs.org/docs#automatic-prerendering
Not only is Gatsby over-engineered, it's also bloated IMO. I think one of their main selling points it that page loads seem instant. Preloading other pages in the background seems needless to me when we're talking about a simple blog. Sure, it might be good for apps, but forcing my (few) visitors to download needless mbs on desktop or mobile seems like a bad user experience to me.
[1]: https://github.com/getzola/zola
It's not for the sake of it. It's so Gatsby didn't have to achieve much beyond wrapping some complicated frameworks to be useful. Basically, about 5 minutes into setting up Gatbsy, you go "Oh, so it's just React and GraphQL. Ok..."
(DTC e-commerce)
1. Convince the WordPress/enterprise crowd to switch over, both by touting the genuine benefits of static sites (security, scalability, TTFB performance, etc.) and by riding the Cool Kid Front-End Stack hype train.
2. Lock them in with an overly-complicated framework and build pipeline that requires organizations invest a lot of resources into switching. (Gatsby gets most of this for free by building on top of the Cool Kid Stack's nine-thousand-package NPM lasagna.)
3. Sell their captive audience expensive solutions to problems they wouldn't have with other frameworks. (See e.g. another commentor's discussion of incremental builds.)
This strategy might not contribute much to society, but neither do a lot of other startups--what matters to investors is that it'll probably make them a lot of money, assuming they execute it correctly.
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
If you just want a static site Gatsby is overkill.
I write all this as a 21-year veteran of web development-related work, and in the spirit of respectful disagreement.
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.
https://developers.google.com/web/tools/puppeteer/articles/s...
> 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 :)
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...
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
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?
https://news.ycombinator.com/newsguidelines.html
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.
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.
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.
You can setup a Next.js system with mostly regular React skills.
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.
Compared to Wordpress, Ghost, and Webflow, it seems the market size for this is limited.
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.
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.
I argue maintainability is the main reason for me to choose Gatsby over WP for projects where the choice makes sense.
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 ?
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.
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.