I just don't get Gatsby. It feels over-engineered for the small static site use cases it is the best tool for and definitely not a good alternative to dynamically generated pages from other frameworks like Next.js, Rails, Django, etc. Maybe the engineers that preceded me on the Gatsby project I worked on took a wrong turn but we ended up with long build times and ever growing complexity around the create pages function. I just couldn't figure out what value Gatsby was supposed to be delivering that was better than any of its competitors.
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 use Gatsby with Contentful for our marketing site and blog. It's been a nightmare.
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.
I've been involved in a site that has over 10k pages and it worked fine. Sanity has a preview feature and Gatsby incremental builds are available now (which I haven't used yet) but should bring your build times down significantly.
We use Gatsby preview. It frustrates me that we are paying a lot of money for a substandard solution to a problem that shouldn't exist.
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.
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.
AFAIK, the thing that sets Gatsby apart is the integration of the built static site and React to do pre-fetching. The output from Gatsby is not just HTML, it's HTML + React javascript, with data loaded from JSON files. That means that once the site has loaded, Gatsby can pre-emptively fetch all the linked pages, both React components and data, to give instantaneous second click page loads. That's a pretty impressive feature in the wild, the second click is neck snappingly fast. I'm not sure if this is an option in other things like nuxtjs or not.
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.
> Nextjs does the same thing. That's not a business model.
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.
It's also just plain fun to use, IMO. I built a site using Gatsby for a product I'm helping with (https://greeter.ai/) and it was a really fun and enjoyable experience. The site is blazing fast. The ease of React integration, Node modules, Gatsby plugins, etc., further add to developer productivity and enjoyment.
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.
It’s funny, because I did just as your post suggests and built my latest personal site using Gatsby and Tailwind and it was an overall positive experience. I loved that I didn't have to do any design (although, sure, you could argue that might be a negative in terms of the result) and the build/deploy process was really simple with Netlify.
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.
Yeah, I was reading that and thinking that you can replace every instance of Gatsby with Next.js and the text would still hold.*
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.
NextJS might be open source but it's from a company (recently renamed do) Vercel, before known as Zeit.co, which has also a lot of VC dollars behind it's belt.
Web performance doesn't need any of that. Browsers are very good at parsing HTML and CDNs are a commodity now. A directory of HTML files is about as fast as it gets, no preloading necessary (and you avoid all that JS payload too).
It really depends on your network connection. If it is fast fetching a small HTML page is nearly instant, if it
s not then it will be noticeable compared to locally cached data.
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.
What if you want to make a site-wide change (e.g. GDPR mandates a cookie banner)?
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.
That's great but isn't a site that must be statically built and deployed to add a new page a niche use case for todays web? You can't use it for a site like HN, a content hub, a social media site, so many use cases that rely heavily on dynamic content from a database. And yes technically you can use it for those things but you're building the static front end with lots of page building logic and complex graphQL queries and ALSO a database backend with your content or CMS as a service like maybe contentful? That's a lot of complexity and unique architecture to maximize for the time to first paint metric. It seems like the Gatsby use case is agencies, branding, advertising campaigns. Which definitely is a sizable market, but sizable enough for what kind of returns on a $28M round?
Gatsby has a lot of optional functionality built with plugins. Server-side rendering is among them. I built a product on top of Gatsby, so far it works fantastic.
What do you mean by SSR with Gatsby? Dynamic rendering at the time of page request, or rendering static HTML at build time? If the former, can you share some links?
> Gatsby can pre-emptively fetch all the linked pages, both React components and data, to give instantaneous second click page loads. That's a pretty impressive feature in the wild, the second click is neck snappingly fast.
Can't you do that much more simply with a simple static site and a service worker?
You don't even need the service worker: just use preload hints for the related content and, if you're really convinced you need to, fetch the content so you can replace the page on a click.
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.
Congratulations on the cash, but after trying it out recently, Gatsby feels like it was made as a dare to make the process of displaying a bit of HTML and CSS on the page as complicated as possible.
> Gatsby has slick looking docs and a lot of VC money and as far as I can tell a painful development experience.
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.
Gatsby still has a pretty good UX compared to Java though. You probably do not want to use Enterprise Java with its dependency injection and inversion of control systems even on a good day.
I agree, I tried Gatsby to set up a simple static site and it just felt massively overengineered, and despite loving GraphQL I found their GraphQL layer to be more of a hindrance than a help. Moved to NextJS and it's a breath of fresh air, there's no looking back now. Their new getStaticProps interface is so simple yet very powerful.
Can't tell if that's sarcasm or not. I've 100% seen startups lose prospects and deals because the docs weren't great.
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.
Good documentation is immensely valuable. Likely an absolute must have to be a huge ecosystem like node, rails, etc. But extensive documentation certainly can't replace being a simple, well organized and elegant tool for the job. Last I checked the Gatsby docs felt more complete than the Next.js docs. Writing this out makes me want to head over to to the Next.js repo and start contributing.
If I recall correctly that’s what Patrick Collison said about one of the reasons why Stripe grew so quick as they had such useful docs. Good, robust documentation is crucial for any software project or business.
I can totally see why. Stripe’s docs are really the best I’ve seen. Not only are the docs good but the API is very logical and well made, definitely much better than their competitors like Authorize.Net.
We use Gatsby for our landing[0] (and are also in the process of moving the main SaaS dashboard to it) and the experience has been nothing but amazing. Page loads almost instantly with little manual optimization required and compile time rendering makes deployment really simple - unlike Next.js you do not have to fiddle with production SSR using serverless functions or a separate node server. The only issue with Gatsby is that compile-time SSR errors are not exposed during normal development live reload so everything needs to be compiled twice, once for development and once to test that the production build can be generated without error.
used gatsby for my portfolio website and recently wanted to add a p5 sketch into it and went round the houses for about 2 hours as i did an update which broke everything.
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
Currently working on a project using gatsby, have had some big wins but other things have been a pain. The single biggest feature you get is SSR rendering for an application built in react. There are lots of little goodies like Gatsby Image and Gatsby Link that are actually really awesome.
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.
Technically it doesn't. Unless developers add a bunch of logic to run in JS after the page loads (e.g. React's useEffect), everything it needs to render should work just fine without JS enabled.
This is my biggest complaint with these supposedly static site generators.
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".
I think you have got it right. I own dozens of static websites from 100 pages to 1M pages. I am the ideal customer for a company like Gatsby.
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.
Have you tried testing other generators for sites with 1M pages? How about Hugo?
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.
A million statically generated pages seems to be an interesting use case (also your use of cloud run suggests it's not high traffic). Is this common at all though?
> other frameworks like Next.js, Rails, Django, 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).
It helps if you think of Gatsby as part of the "Headless" architecture, which presupposes that your app/website is just a veneer on top of other 3rd party tools/SaaS.
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.)
I’m a Gatsby fan and have built several sites with it. But I do recognize it’s a dead end at its core. Its main use case is data driven static sites, and it does that case very well. But when it tries to extend beyond that, the results are mixed.
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.
This was my experience as well. I thought it might be aimed at news sites with content in WordPress as a faster alternative front-end. It certainly positions itself as "for everyone", but it felt wildly over engineered when I used it for a small static site.
Does the commercial offering from Gatsby offer hosting? I couldn't figure it out from the https://gatsbyjs.com page.
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.
Haven't really used Gatsby but vercel is magical. Like once you link up your GitHub repo, the fact that everything works so smoothly is delightful. A lot of other platforms try to compete with vercel on ease of use (heroku) but doesn't even come close. Next.js + vercel seems like cheating honestly
it's kind of ironic that the main value proposition of static site generators like Gatsby is that it's just a file so it's portable and you can take them anywhere, instead of getting locked into server/client based database systems, yet here they are, trying to monetize by building the "the best way to build and maintain Gatsby sites".
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.
it's different from wordpress, for the reason I mentioned above.
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.
The kicker with Gatsby is it’s actually not compatible with GitHub or any hosting where you can’t control caching headers. Gatsby relies on page-data.json files to not be cached[1] in order to work correctly. This is not possible with GitHub pages. After deploying a new version of the site, some users will use a cached version of page-data.json which can cause them to see a flash of the new data that quickly gets replaced with the old data. It can also cause the site to throw a JS exception in some cases.
Or only partially replaced, such that some React components get updated and some don't so if you have i.e. a list of stuff with text and pictures, the text will get updated but the pictures will not. It's a mess
Sounds like their offering will basically consist of some fairly simple CI and some static hosting, right?
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).
From what i know, their CI offering tries to aim for very quick build times. Quick as in quick enough to actually allow dynamic looking website to be built with gatsby statically (eg. site rebuilt on every user post). Even their pricing reflects this, they charge by how many times the site is updated, regardless of build time.
I think that looks like a pretty hard problem, i wouldn’t call their CI simple.
> For Bob the marketing guy, it's just another tool to create a website.
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.
Bob the marketing guy couldn't care less where he hosts his Gatsby generated HTML website (at the end of the day it's just an HTML/JS/CSS bundle). He can just take that HTML and host it somewhere where it's FREE or provides much better quality.
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.
I think we need to take over evaluations as a serious signal of danger in the economy. They are a signal of the advancing size of the financial class - which I think will have massively negative consequences.
My thinking here is heavily influenced by this documentary I just watched:
I Initially thought Gatsby was great. As someone who enjoys using React, being able to use it for web sites in a way that’s well optimized and SEO friendly was appealing.
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.
Yet again another company with mangled communications, please, please, would be Engineers making products, make sure that you communicate 'what it is' above all else.
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'.
I agree. The website is constricting its audience.
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.
If you can't take the time to figure out what it does, then you're not the target market. It's really not that hard. It's a web framework for building static sites. As it says right in the hero of the site:
"Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps"
Gatsby's really fun to use developing small apps, and their docs make it easy to get started with Gatsby, React AND front-end in general. They've created a good overall experience for beginners, which could create a decent user base.
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?
Could someone explain what Gatsby's path is to eventually making a lot of money? I'm always a bit wary of open source frameworks that claim to be all about their community getting funded with lots of venture capital.
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.
> Gatsby says it aims to be the platform behind 1% of websites by 2024; it claims it currently supports 0.1%.
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.
I don't think enough people are thinking about what will happen when these companies do eventually run out of money (both Next.js and Gatsby). Not just to their hosting services, but to the open source tech driving the platform itself. Meteor never gained much traction but it sat in a similar parallel of hoping to provide hosting services and just burnt money away. Next.js* however has gained a lot of traction, but it's worrying to monetize these open source style tools that a lot of companies are building fundamental infrastructure on. I don't know if this kind of open source > paid hosting business model has paid off in other similar spaces. Are there examples?
Next.js is used by enough big companies that I’m not too worried about it. If Vercel the company were to close shop, there are plenty of large teams with a vested interest in keeping the next.js project alive. Also, at some point, improvements are nice but not strictly necessary. It would be fine if next.js went into maintenance mode and just optimized speed or kept up with new react / browser features.
open source => paid hosting model makes sense when the tech is heavy and not easily portable anyway. For example, confluence develops kafka and makes money with kafka cloud. Mongodb develops mongodb and makes money with their cloud, etc.
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 Gatsby model is Wordpress. Be the default choice, be open source, run a thriving hosting business and empower a huge economy around theming and extending your main product.
The actual question is whether that model is the same as the wordpress model.
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.
I agree with you. My comment was meant as a reflection of what I imagine Gatsby's thinking to be. I am really impressed with the technology but quite baffled by the business model at a $200M valuation.
wordpress crushed a lot of proprietary and far more difficult to use options - is that still the case for Gatsby? With 50+ million in VC capital is this a billion dollar market segment today?
WordPress seems to have worked out well. If the company (wordpress.com) goes under, the platform (wordpress.org) will stay alive and well. The companies that relied on wordpress.com can just migrate to any other premium WP service, such as WP Engine.
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.
Wordpress requires some degree of setup, with the end users simply accessing the installed web application. With Gatsby, if you're at the point where you're ready to deploy, you've already done most of the technical work yourself, so the value add is far diminished vs managed Wordpress hosting.
this is true in some sense; the value of JAM-stack apps is that they are portable and deployment is vastly simplified and requires limited resources (web-accessible file storage). How much value-add is there to be captured?
Netlify already gives me everything I need for free at this scale. Once I move into their enterprise features the competition heats up.
I’ve used Gatsby for generating my wife’s static blog. It’s as simple as adding a new Markdown file, and building. The React workflow makes customising layouts and interactions much easier for those familiar with the ecosystem. For anything more than that, I’d stick to a dynamic framework.
$28M seems like an awful lot for a static site generator. The issue I see Gatsby facing is that the poor developer experience will catch up with them, regardless as to whether they expand their ecosystem (plugins etc). If the developer experience isn't improved, I doubt their money will convince '1%' of all websites development teams to make the switch. Especially if this thread is a good approximation of the mood towards developing with gatsby.
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.
Thanks for pointer to the next.js raise, this significantly increases the odds I'll use them - the last few times I'd checked the project's commit history, it looked like the lion's share were from one guy who could disappear at any time due to a better job, a girlfriend, or getting hit by a bus.
I think their strategy is to commoditize the Next.js and Gatsby differentiation; They host all JAM-stacks pretty equally. The add a lot of paid dynamic add-ons that are hard to do statically (and that they told you were BAD_THINGS at the start) like form processing and user management.
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!
I like Netlify but I suspect it's much easier for Gatsby and Next to add Netlify-like functionality to their offerings than the reverse. I suspect one is unlikely to need both (Gatsby SaaS or Next SaaS) and (Netlify SaaS), which doesn't bode well for Netlify.
I used Gatsby about a year ago for a personal blog, but ended up abandoning it for the following reasons:
- 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 initially got very frustrated with Gatsby. Most new web frameworks makes things easier and faster. Gatsby is not about making a website easier to make. Its about making really fast websites easier to make. Its complicated: you need to use GraphQL to load an image, and you need to choose the right query based on what component you're using.
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.
I get it. Funding saving life on earth isn't predictable like some $10/month SAAS like this. Doesn't make the pain that humans choose money over earth every time less painful.
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?