Gatsby has slick looking docs and a lot of VC money and as far as I can tell a painful development experience. For most use cases you'll still have to write a backend API to handle form submissions, 3rd party calls and other Ajax. What does Gatsby actually do other than package together a bunch of trendy web technologies with Wieden Kennedy designed documentation?
We publish content multiple times a week. It's taken a huge amount of effort and paying Gatsby a lot of money for their SaaS products to get a setup that any serious publisher (like a newspaper) would laugh at.
The whole product being built around static site generation is a huge limitation. Things like republishing at a reasonable cadence and previewing changes require massive kludges and huge amounts of infrastructure to make work.
Static site generation is a niche product. Gatsby are trying to replace dynamic server side rendering, and in the short term will win people over with the upsides. But long term people are going to hate the limitations.
But, you're right that Gatsby requires a lot of code. To get a simple static site setup, it's a lot of work. Plus it changes very fast. We stopped paying attention for a few months, and things broke on the next upgrade.
But, if web performance is the goal, Gatsby is hard to beat. In addition to pre-fetching, it also inlines every resource, images, CSS, the whole thing. So a single HTML fetch should be enough for a full first paint. That's a lot faster than a usual static site, which in turn loads all the additional resources before it can show the site to the user.
Non tech people often know about Gatsby and compare it to WordPress.
I have to warn decision makers that it promises a lot but adds complexity that wastes developer time.
There's lots of other SSGs that do the same thing, so Gatsby does not have any exclusivity on creating a performant static website.
Can't you do that much more simply with a simple static site and a service worker?
I have used Gatsby only for small projects, but developer-experience-wise, it's been fantastic, on par with Next.js and better than developer experience of Jekyll or Eleventy, I would say. No pain at all, if you know your way around javascript and react.
But of course the price you pay for that is that a hello world Gatsby app starts at around 60 kB of javascript. Also, service workers, which are nice in principle, but in inexperienced hands might result in stale content or even broken site. I sometimes visit the site of Kent C. Dodds. It's built with Gatsby. It's also using service workers, so every time I visit the site after a couple of weeks or so, the page greets me with the old content; and I have to refresh the page to get the new one. Occasionally, his service workers that have cached the entrypoint webpack file fail to fetch css or js files from previous builds listed there, and the site just shows blank nothingness. It's ironic, really.
Do you want to display markdon files?? Oh that would be plugin.
Ok I got the plugin. Can I display a Markdown now?
Not yet you must write a GraphQL!!! query to read the contents of your file.
I think you might be on to something; I don't even bother with projects without good docs or a readme.
Edit: Not sarcasm. I value my time.
If anyone who's selling software thinks their docs are only for users, and don't get read by prospective customers, they're missing out on customer prospects without even realizing. Many people even skip the homepage and everything else and jump straight to the docs to figure out what the product does, whom it's for, how it works, what it integrates with, and so on.
If I’ve understood your comment I don’t think this is still a problem as of Next 9.3. There have been some pretty big improvements since Next hit v9
https://nextjs.org/blog/next-9-3#next-gen-static-site-genera...
ended up sacking it off, creating a static html/css/vanilla site text right in tag and boom done in about 20 mins.
ridiculously over-engineered. use react if you want the madness, plain if you want to just do something normal
I personally am not that huge of a fan of the graphQl layer, we have been using it with basic use cases and still have run into issues with it.
Definitely not a revolutionary framework or tech, but for its use cases it does work.
The resulting sites are anything but static.
My biggest regret of 2020 so far is agreeing to use Gridsome for a site, promised by the docs and a dev that it was a static site with "only as much VueJS as was desired for additional functionality".
Yeah, I know now.
I had all the content in my mysql and accessible through a REST api. I had python scripts that would pull data from REST and generate .MD files which then Jekyll would convert to static sites. Everything worked fairly well except long build times for the 1M pages site which was expected.
I decided to try porting things to Gatsby because I thought I can get rid of the python script. Then I realized how useless Gatsby suddenly is.
It will take hours to call the REST APIs and create nodes. It would take huge amount of memory too often causing the process to crash even for sites that had just 10,000 nodes. The create pages step was even more horrible. If there is some error like a special char in the url it would just crash the whole process forcing me to build from scratch again which again took lot of time. I had to then try to figure out how to cache the data. Even then, memory crashes were frequent and Netlify free plan would not support the long build times.
I then decided not to use Gatsby for my use case and instead just use Google Cloud Run and PHP for the super large site and continue using Jekyll for all the < 1M pages sites with free Netlify plan.
Now, if you are going to raise lot of money from VC I would like to see you making products that make your customers happy and not engaging in some of engineering porn where you try to solve problems like using "react components" which in itself has no meaning to me.
I'm confused about Gatsby as well to be honest. It has a lot of buzz but Hugo does everything I need. It can download data from URLs too and, worst case, just write a short script that does this before triggering the static site generation.
Part of the appeal of static site generation for me is simplicity. I've already hit enough issues with Jekyll having versioning issues when I return to a site I've let sit for a while. I don't want to have to deal with versions and upgrading issues that'll be involved with using Node, Webpack, React etc.
I think that's the biggest difference. Gatsby spits out a bunch of html and js files that can be served anywhere. No database migrations, impossible for someone to install malware on your site, no server costs (static site hosts are multiple and free).
That's the big value prop to me. Hosting is simple, dev tools are familiar (npm and react), plus I don't have to mess with webpack.
(I agree that I have no clue how they'll make money, but I do really like their existing ecosystem).
So if you're an e-commerce business using Shopify, Contentful, and Algolia, then Gatsby is actually a very nice fit. You could do all of this in Next.js, but you'd be dealing with server-side proxying to the SaaS tools and all that goes with that (e.g. service downtime, adding 100ms+ latency to each request, caching etc.)
But with that said, I give Gatsby a lot of credit in pushing forward the idea of a cohesive React framework. I just think Next.js, Remix and other newcomers are ultimately going to achieve that way better than Gatsby.
I thought it was the combination of React plus a nice GraphQL interface. I would think that's a nice combination for your average startup.
Gatsby and NextJS (Vercel) are both backed by CRV[1,2]. It seems like a fairly competitive overlap. Would love to hear takes from folks on HN about the feasibility and comparison of Gatsby's and Vercel's business models and competitive overlaps.
[1] https://www.businesswire.com/news/home/20200527005268/en/Gat... [2] https://medium.com/crv-insights/from-next-to-now-to-21m-for-...
From my point of view, if they succeed in achieving that goal, that means Gatsby the open source project has failed, because it contradicts its purpose.
I can understand them raising a few million dollars, but $28M? Not so sure, I actually think the VC money will do more harm than good.
But I also think that 28mill is outrageously lot of money for what the service is. True SV scale :)
The main value proposition of static site generators COMPARED TO 1st generation CMS like Wordpress is that they don't require a database and are lightweight and portable.
It is common sense that not everyone will want to run their own database and a server, so a wordpress.com makes sense.
But static sites can be deployed anywhere and there already is a huge ecosystem of vendor independent and free static site hosting sites like Github (which is subsidized by Microsoft), Gitlab, etc.
For Gatsby to survive and thrive in this ecosystem that is completely different from the wordpress ecosystem, they will probably need to do a lot of things to create a lockin, in which case there is no point in using Gatsby. After all, all Gatsby does is just compile some files into static site. Nothing magic in there.
My thinking here is heavily influenced by this documentary I just watched:
I've just been triggered by your smiley face.
"Silicon Valley Scale" is an error for humanity, in my opinion.
However… after using Gatsby for a fairly simple site it didn’t take me long to realise that this approach add’s a fair bit of complexity and limitations. Prepare for long build times for simple changes, which becomes a bit silly once you hook up a CMS that triggers builds for each change. As a content editor having to wait 5 minutes for your change to be deployed kinda sucks. GraphQL for loading data often felt overkill and a lot of hassle. If you want to add something like a simple contact form you are encouraged to use external services which just get’s out of hand for what I want to be a simple self-contained site. The end result doesn't even feel that fast due to the React re-hydration that takes place.
I ended up switching back to a traditional server-side solution which provided a much faster experience (in both tests and perceived speed) and more flexibility. It turn’s out the browser is pretty good at caching static assets and you can achieve the same SSG benefits with Caching and a CDN without the restrictions.
I’m sure there are cases where Gatsby performs well, and it’s the best tool I’m aware of for bundling React pages in an SEO friendly, optimised way. But I think for the kind of project’s it’s useful for, something like Jekyll or Hugo may be more suitable. For more complex site’s that would actually benefit from React, it seems like the SSR alternative (Next) would be easier to scale.
The top-level marketing jargon is always the same: "Make your site in minutes, not weeks! Deploy globally! Uses modern tech"
Sure, that's ok.
But the 'How it works' visual on the page explains nothing really, it's just a pile of buzzwords.
The 'QuickStart' goes right into *command line installs of technology.
WTF DOES IT DO?
Are we point-and-click building hosted sites like Shopify? Do they even host? Is it just a web framework? A cloud-based dev environment?
Some people are attracted to 'new tech' like candy and will love to dig into this. I used to be this, but now after years of rabbit holes and a lot more experience, I've realized that the onus is on the 'maker' to explain, and frankly, my (your!) time is valuable.
Please take the time to make a small introductory section that uses a few words as possible to get the meaning across to a 'technically minded business person' or even a 'developer totally unfamiliar with the tech'.
Gatsby is a static[1] site generator of sorts. It compiles your source code/text into a HTML site at design time. So you don't have to rely on setting up a database and server for your website. It is not quite like other static site generators like Hugo or Jekyll. They use markdown files which are compiled to HTML. Gatsby instead uses javascript files with functions that return HTML that is rendered as a page. By using a programming language to define web pages, the designer gets some flexibility when creating a static site.
It is different from a dynamic[2] hosting application like Wordpress where you have a database entry which is queried and rendered into a page at run time.
[1]: https://en.wikipedia.org/wiki/Static_web_page [2]: https://en.wikipedia.org/wiki/Dynamic_web_page
A variation of what you wrote that should be on the landing page.
"Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps"
That being said, the path to monetization seems hairy (competitive market with many free options, the previously mentioned fact that Gatsby's overall goal is to generate portable files). Is there any way that this is some bizarre VC effort to fund open source or do something nice? Or is that excessively wishful thinking?
So with that, Wix & Squarespace become comparable models. Hypothetically.
SaaS for deploying and running Gatsby sites, with add-ons, competitive with Netlify and Vercel.
As more companies use Gatsby, they (and the VCs) are making a bet that some meaningful percentage of them are willing to pay money if it means reducing their development or maintenance burdens.
Seems like they're going the way of meteor though, so who knows.
I find it really hard to believe that they're powering 0.1% of the web at this point, that's gotta be millions of sites. The only way that figure is accurate is if they're counting all of the people spinning up tutorial sites.
My bet is that it's not .1% of web sites, rather .1% of web traffic.
Because web content is a 1/x curve with the top few taking up all the usage ... if they have even a couple 'semi big name clients' then they could be behind 0.1% of traffic.
And maybe by 'web' they mean just USA.
And maybe by 'powered' they mean, the company 'uses gatsby somewhere' so they claim all traffic from the company in their data.
Which is kind of like Simpsons episode logic, but hey.
We need the Simpsons writing team to get together with the 'Silicon Valley' folks and make cartoons that mock startup stuff like this.
* Edit: Excuse me, Vercel!
However, it's much too easy to join in with the typical HN cynicism to shiny new things. Maybe Gatsby will surprise us and become a contender within the CMS space before long.
- Very slow build times. It took me over a minute to build a personal blog. - Weird forced implementation of GraphQL. To display something as simple as an image I was forced to use GraphQL. Also your GraphQL can't be dynamically generated, meaning it's hard to make anything modular. And the GraphQL paths has a ton of extraneous nested fields (eg. `data.file.childImageSharp.fixed`) - Version upgrades were a pain in the ass and would often break my site. - My site actually seemed slow. For example, links don't work until the entire JS loads and executes, so if your internet isn't fast then your website basically isn't functional for the first 2-5 seconds despite the page being visible. - Very few themes (maybe be better now, but at the time the selection was awful, especially compared to Jekyll). No real concept of themes in the first place, switching from one theme to another requires an entire code rewrite. - Limited functionality built-in. For example, want tagging? You'll need to code that in.
Gatsby sits in an odd spot of not being simple enough to save you a lot of time or empower a non-technical person to manage (eg. like WordPress), but not flexible enough to do anything you want since it's an opinionated SSG framework. It's like you're getting all the complexity of a React/GraphQL application, without any of the flexibility of being able to pick your own stack.
Sure it has a nice plugin system, but beyond that since you need a developer to set up and maintain a Gatsby site anyways, I don't see any reason not to just use Next.js (which can export to static) since all Gatsby really does beyond that is converting markdown to HTML, which is just done through an npm library anyways. If writing a Next.js website is overkill, then why do you need to be devoting engineering resources to this in the first place? Why not just use some no-code solution like WordPress? Or if you really want a separate headless CMS, then Jekyll felt easier and faster to me with more theme options (though again it's been a year since I touched these, so I imagine things have improved).
Don't get me wrong I love SSGs as nothing beats the performance, ease of deployment, and low cost of static sites. But if I'm going to use a SSG framework, it better be dead simple and/or easy to customize, otherwise I might as well just use some off-the-shelf "no-code" solution (eg. WordPress, Wix, Squarespace), or use a framework like Next.js that let's me customize my stack instead of being locked into Gatsby's. Gatsby's $200m valuation makes absolutely no sense to me unless they're planning some drastic changes I'm not aware of.
I just don't see practical use :-) Too complex for non-geeks, too limiting for geeks.
Eventually, I embraced the complexity, and the plugin system really helps.
Oh, but I still hate the 'theme' feature. I prefer the old 'starter' way.
> Today, Next.js powers over 35,000 sites at companies like Uber, Nike, and Starbucks.
None of these are portable systems.
On the other hand, the whole reason for static site generators is its lightweightness. So by design it's hard for these vendors to have lockin....unless, they deliberately create lockins. Which is why i think this model is not really a good model. They created something that's valuable exactly because it frees people from getting locked in, but they will probably need to make money by trying their best to lock in users.
The only endgame I can see from this is these people using up all the VC money to give out freebies to attract as many users as possible, and then selling to Microsoft.
The question is whether that model is repeatable.
For Gatsby.js users the alternatives in a Gatsby-the-company-goes-under scenario would be limited to just Netlify and DIY (and maybe Vercel?). If the demand for managed-Gatsby grows then so will the supply, thus giving people more options in a worst-case scenario.
Our problems stem from the fact that Gatsby's architecture is based around assembling an in-memory model and GraphQL schema for all possible data nodes, and then generating pages by querying from that store.
These operations are dependent on each other, so Gatsby can't do things like fetch just the data needed for a single page. It's also error prone because it adds a whole bunch of complexity to everything they do: https://www.gatsbyjs.org/docs/gatsby-internals/
That kind of complexity is not needed for something that is inherently a pretty simple problem.
The same goes for Gatsby incremental builds. We don't want to run a web server, so instead we should pay to run a build server 24/7 so we can have a warm cache available when we need to build!?
The annoying part is that there is not reason a static site generator should have these limitations. Gatsby's entire revenue model is based on solving problems that only exist because of the bad architectural decisions in their open source product.
Now you don't need to do it as complex as Gatsby does, you could literally just GET the HTML file and throw away the result so that it is in the cache.
With Gatsby's approach, you only modify the js that renders the template. Then, if a site-wide change needs to be made, you make a single change in the js template.
With the static-HTML-served-from-directories approach, you would have to rebuild all the HTML for your entire site if you wanted a template change and a database to store all the articles/posts for you to rebuild the HTML.
Edit: + cloud infrastructure probably
Lol, talk about damning them with faint praise.
All of the CSS is loaded from the webpack runtime though.
Netlify already gives me everything I need for free at this scale. Once I move into their enterprise features the competition heats up.
That's usually a waste of time, however, compared to making sure your site is cache-friendly. As most projects have discovered, there are a lot of edge cases for making a JavaScript solution as fast or robust as the built-in browser behaviour.
I dont know if you read my comment to which you replied, but my point is that if you look closely they are completely different games. If the VCs thought they were getting into Wordpress2.0, they will find that they were terribly wrong. It's a completely different market with completely different market dynamics.
A business model doesn't need to be unique in order to be successful. Also Gatsby is open source, so I wouldn't expect to find profits falling out of the core library. They make their money through consulting and cloud ops.
> adds complexity that wastes developer time
Every framework comes with its own flavor of complexity. To blanket say that Gatsby wastes time ignores the real benefits it provides and the opportunity cost of getting those benefits through some other library (or even more daunting, writing and maintaining a homegrown framework).
If web performance matters to you or your business then effort focused in that direction is not a waste. The complexity of learning/developing with Gatsby/Next is significantly lower than getting those benefits without them.
I see a really bright future for slick, fast, well-documented solutions that significantly depart from the Wordpress/massive CMS model and rely on highly-modern technologies that developers enjoy working with. Couple something like Gatsby with a framework that makes design a lot easier too (e.g. Tailwind + Tailwind UI) and suddenly, as a developer, you're so much more capable than previously.
I dunno. This old Rails programmer is loving it. And if I can learn to love it, I think they've got a market.
My previous sites were built with Wordpress and before that I used AMFPHP and Flash (over 10 years ago!). This was a breeze compared to those sites.
I noticed that IDEO uses Gatsby for their site, so I'm starting to think that the main difference is PR/marketing.
* I've worked with Next, 11ty, jekyll, hugo, but not Gatsby, hence the interpretation. Gatsby feels like less boilerplate than Next. I'll check it out once I find an excuse to use it.
Microsoft owns github, npm, vscode, typescript...
I mean...
I think their model is more realistic as a superset of what Gatsby can offer, but I'm not convinced it justifies 100 million dollars of VC investment. BUT - I'm always off by a factor of 4x (projected costs, effort estimates) so if you think it's worth 25 million, then you should go for it!
[1] https://github.com/gatsbyjs/gatsby/issues/15080#issuecomment...
Those things (particularly the CI) are incredibly trivial to setup for someone who is technically proficient. It might be a hurdle for someone who is primarily a designer with a bit of HTML/CSS knowledge and a "copy and paste heavy" understanding of JS.
I think a large proportion of static sites are built by people in the second category, so the offering makes sense to me. If my reasoning is sound, that just leaves the major issue that this offering is incredibly easy to duplicate, and everyone from Github to CircleCI to Netlify could put in a week of dev time to roll out their own matching offering (if they don't already have this).
I think that looks like a pretty hard problem, i wouldn’t call their CI simple.
There's indeed little magic involved so Gatsby has to do a really good job to keep customers both integration and speed wise.
To me this is the "emperor has no clothes" about the whole ecosystem. The actual users don't care if it's a static file, a database CMS, or a herd of cats running around frantically typing up HTTP responses. So it's odd to me that the big selling point is "we did something neat in how we made our product!". Right, but what does it do to make your users life better than using ghost or wordpress, or whatever?
I know that some devs see it as a rails like thing to combine with graphql, but if I was going that route I personally wouldn't start with something that's ostensibly a static site generator.
Basically, the hosting can be unbundled from generating the site. And this is the territory which big companies like Amazon, Google, and Microsoft are already good at.
of course, Gatsby cloud won't want that, and the only way to solve that problem is to create artificial lockins. And when they do so (because they need to justify their valuation), people will leave.