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.
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.
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.
Compared to Wordpress, Ghost, and Webflow, it seems the market size for this is limited.
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.
I write all this as a 21-year veteran of web development-related work, and in the spirit of respectful disagreement.
> 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?
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.
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.
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.
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.
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 ?
Some problems that I found after some months of integrating it with an existing CMS:
* Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS.
Having this code executed in a Node process is expected because Gatsby is a static site generator, but this big split between the environment of development and production builds, paired with a growing codebase that keeps evolving, catches new developers on our team with multiple and surprising bugs.
* Debug complexity: JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode.
* Runtime requirements: as far as I remember, executing `gatsby build` on my development machine uses ~3.4 GiB of private RAM for the main node process, and it takes around 5 minutes if the local cache is cleared (it ends in around a minute with cache).
Its important to remember this when choosing in which server the build runs.
* Integration: Gatsby does not provide out of the box integration with CMS for content authoring (like for example, page drafts).
Now to be honest, the global idea seems good (static websites built with React), but I would wait a few more years until it becomes more mature to use it again for any future project.
I don't get it, is this some Gatsby limitation? I've been debugging JSX since the dawn of time with breakpoints, even with SSR and typescript
During the build, Gatsby compiles JSX and saves the result in a temporal folder. Some time after, it spawns several subprocesses that execute the mentioned resulting JS files (to render each page in the site).
What I meant with "the JSX code is hard to debug" is:
* The JSX code is actually run inside subprocesses, and NodeJS allows to debug a process if its run with the `--inspect` command line argument. But I did not found documentation in the Gatsby website about how to change the arguments of these subprocesses. Note that this only applies to production builds (development mode executes all JSX in the browser).
* From the text editor perspective, the breakpoints are defined in the original JSX source files, not the built ones. I understand that in theory line/column mapping can be done using map files, but I did not have time yet to investigate the cleanest way to make the IDE, Docker (not actually a Gatsby requirement), the temporal Webpack build directory, and Gatsby subprocesses to work together.
Gatsby's docs on debugging HTML builds  give you adhoc solutions for specific problems you may have, but 0 info on actually debugging.
FreeSewing.org runs on Gatsby. It generates made-to-measure sewing patterns, so I think that qualifies as beyond static-scrollable content.
While it's not magic, it is a powerful platform to build your frontend on. JAMStack is a godsend for small open source projects like us since you can just deploy to Netlify and walk away.
We do have a backend (using Express) but it's very minimalistic. Most things are simply handled client-side which means scaling up is a non-issue.
Obviously there are downsides to pushing such an amount of code to the client, but going with JAMStack isa choice we made that we can hardly blame Gatsby for.
I've since written 2 plugins for it for specific needs I had, and contributed some code left and right.I think that's testament to how it's not that hard to wrap your head around.
I've used other static site generators (Jekyl, Phenomic, and brief encounters with Hugo and Hexo) but Gatsby is the first that made me feel I wasn't fighting against it.
Gatsby makes sense for us, as it makes sense for others too. I would recommend it to anyone who is looking for a way to use JAMStack and is comfortable with using React.
I agree. Though I’d add that I found it too complex for a quick .md -> html site as well.
Next does a better job at complex things and one might as well use Hugo/Hexo for a .md blog. I don’t know how much can be found in between.
Out of interest, what's good about building static websites with React?
But the strengths show when you combine it with e.g. Gatsby which turns it into a hybrid website + app. For first time visitors, search engines, and people with JS disabled it's just static HTML, simple. But for most visitors (browsers, JS enabled etc), after the first load it turns into a webapp and any pageview only requires a single .json file to be pulled in, which can be prefetched (on link hover for example) as well. This gives it the performance characteristics of a single-page app.
As compared to which alternatives?
Though I never liked Gatsby.
It's popular, so I can't say it was a bad idea.
I guess I'll just say I must be old because it sounds like satire.
We were once tasked to build a website for a small publishing house. The site would have pages of books and of authors. Each book page would link to the page(s) of the book's author(s). Each author's page would have thumbnail(s) of this author's book(s). There was also to be an index page, which would contain various books, with names of respective authors, and links to each book's and author's page. It was almost like describing a simple relational database.
Except we wanted the site to be static, and the data about books and authors to be stored in yaml files on github. So book page, author page and index page needed to learn about each other at build time by reading the frontmatter of the yaml files.
Gatsby may not be the technology for building lightest-weight sites (no matter how much the Gatsby team emphasises their commitment to performance), but the developer experience when working with Gatsby is unsurpassable.
I've moved my site from Jekyll to Gatsby, and while there are some nice things, it's not been a clear win. My site is very significantly slower for first load, but slightly faster for all subsequent loads. The build is far less stable with Gatsby, there are ~5 dependency updates per day, things like Sass don't "just work" anymore, but on the other hand, there are a few more packages that do useful things that I didn't get in the Jekyll community.
I've been using React Static  for that now, where you just load the data in memory. I'd expected to discover in the process why GraphQL is so useful, but I did not. This might just be my limited point of view.
I guess as soon as you're dealing with lots and lots of data it might be useful, but the projects for which that is the case and which want a mostly-static site seem like they're a very small niche.
It seemed nice at first, but the way they tell you to deal with images and other resources is ridiculous overengineered and gets in the way.
If you throw real data at it, your builds explode from seconds to minutes.
Ill considered, chasing too many fads, and the inability to turn it all off if you don't need it.
That's what gatsby felt like.
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.
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 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.
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 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?
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.
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.
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!
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.
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.
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.
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 the next.js route if I ever have to build a site with similar technology.
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.
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!) 
> 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 , 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.
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
If existing solutions are near perfect for you, you are not the target audience.
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).
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.
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.
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 in Contentful and Netlify free tiers and have done so. We do pay $15/month for a service that does some form routing/templating magic for us - but that's the only cost these days.
In the end it took me around 6months to do something that would have taken an agency a month to fulfill. But, I also helped on a lot of random projects (it's amazing what people will let you be a part of when you are eager), and served as webmaster for the first site. During that time leadership at my company wasn't really ready to think about web, so in the end I have provided a great value - a huge cost savings for them over what they were spending and even what they otherwise would be today. I think a lot of people here would cringe to look at my code. It looks like what was written by who it was - someone learning as they went. But, nothing ever breaks, site hasn't been down once since replatforming and moving to netlify, site traffic has increased, we finally pass security audits, page load time went from 8seconds average to somewhere around 1-2 seconds on average. I spin up landing pages regularly, and have plans for meeting unique industry needs in a way that is doable and maintainable by just me.
At the end of the day I'm a novice who's making it work on my end mostly by force of will in an industry where a web presence is only just starting to matter. BUT none of it would be doable without Gatsby. Their community, documentation, and product are all amazing. I'm convinced that if my story didn't include Gatsby I wouldn't be provided the opportunities I currently.
If you want to be cynical you can interpret all of that as 'guy at shitty company, in shitty industry, where web really doesn't matter, uses Gatsby to make site that just works, and saves a marginal amount of money that definitely had to be spent (hosting costs) and a large amount of money that probably shouldn't have ever been spent (bloated web team and agency that sat on their asses).'
from not enough detail to waaaaaaayyyyyyyyyy too much
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.
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.
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.
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..."
Next.js is less opinionated.
About raising that series A, I hope they have a bigger plan in mind than hosting sites or yet another CMS. If the vision is the "reinvent" the way we work on static sites, I respect that, but I don't see a business case there.
For a very long time, I've been fond of Jekyll. It's mostly because my open source projects are hosted on GitHub and Jekyll is their go-to framework. There's nothing wrong per se with Jekyll. I was simply missing some features from React.
When I was working on React apps, the main benefits for me were: (i) component encapsulation and (ii) CSS Modules. It's easy to understand what a component does just by looking at it. If it gets too complicated, you can simply split it into another component. And CSS Modules are a life saver. The two hardest things in CSS are floats and naming things. That second part is solved now.
My issue with React however is the whole Webpack setup, and the fact that JS is required to run the website.
So when Gatsby appeared, I was pleasantly surprised to see it solved these issues. I ended up rebuilding my website with Gatsby, and I'm currently using it for 2 client projects.
My only issue with Gatsby is its reliance on GraphQL. I tried understanding the GraphQL concepts and purpose, especially with its weird syntax, but it feels over-engineered. Or at least, it doesn't feel like Gatsby needs GraphQL. So I'm not sure why it's so tightly tied to it. What I end up doing for fetching/storing data is using some static JSON files. It's easy to read, to port, and to parse.
I only use GatsbyJS.org the open source project, not GatsbyJS.com the service. But it seems to be similar to WordPress.org/WordPress.com, or what Ghost does. Even if the open source project somehow died, I wouldn't feel stuck with the framework ; since most of the codebase are React components, it'd be easy to port to another platform. That's another benefit.
Doesn't have VC money, though, but there's not that much development needed for my (and apparently yours) use cases either.
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
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 had a similar problem and solved it with Forestry and Netlify. Forestry has a nice web interface for writing posts; saving causes the changes to be committed to a GitHub repo. Netlify 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/
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/
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.
In a nutshell, it offers a better UI to edit your content on a Jekyll site by talking directly to the Github API.
It turns out Gatsby also exposes an imperative API that runs behind its fancy declarative API, and it's very similar to mine.
However, I wrote mine in 12 hours. Gatsby has a big team and millions of dollars and it's been in the works for many many years.
And still some weeks ago I tried to use Gatsby to generate a site with data from Trello and Instagram and couldn't, hit some bugs, but mainly hit an opaque and very complex API.
What is the core team wasting their time on?
Then I saw that the content preview feature was $50 / month - and it’s not even integrated yet with my CMS of choice.
How can teams accept to let go of such fundamental features? I love the React dev experience as much as the next guy, but I certainly can’t find a way to justify this to my clients...
You basically have two options:
(a) fetch them dynamically
(b) trigger a rebuild on product update
With (a) you have spinners and potentially worse SEO. With (b) you have to deal with a delay from hitting “Publish” to seeing the changes deployed in prod...
Again, these are all solved problems in just about every other eCommerce framework!
If you look at some of the Gatsby eCommerce prod examples you will see a few gorgeous sites (the Flamingo one for example) but they all have very few product references and features (no user accounts, etc)
All this is to say the possible use cases for Gatsby in eCommerce seem very narrow, though I would love to be proven wrong.
Or you can only list the product and make the buy button and items available come from an api, doable, but then you start to loose the simplicity of gatsby.
> Or you can only list the product and make the buy button and items available come from an api, doable, but then you start to loose the simplicity of gatsby.
And you still haven't solved the issue of delays between content changes and deployment... What if someone has made a bad mistake in content editing and you need to revert it? You're exposed to the whims of your build processes and infrastructure... There's no way I can sell to anyone who's played with Wordpress or Shopify "well, your changes might take anywhere from 3 to 15 minutes to be live..."
That's why I'm asking, how can product and engineering teams justify this kind of thing? I'm not being facetious, I'd love to hear their perspective.
YouTube example: https://youtube.com/watch?v=OqbJ5swVpDQ
Parse.ly also just released their new landing page all done with Gatsby.
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.
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!
"Static Site generator" seems to be the confusion. If I'm reading correctly gatsby is more a replacement for webpack than for jekyll or ghost. You use it as scaffolding to help build your front end. The docs show it compiling react, jsx, using various plugins like emotion etc. It all looks like it's supposed to be a better webpack.
Am I wrong?
Also, Gatsby uses Webpack and it doesn't expose compilation options in any meaningful way like webpack itself does (and it doesn't have a plug-and-play philosophy like Parcel either). I'm not a huge fan of webpack config API personally, but I certainly would never consider using Gatsby as an alternative generic purpose bundler!
You can use Gatsby as a replacement for Jekyll or Ghost, they do the same thing, i.e. output static HTML. However Gatsby uses React and GraphQL to achieve that result. While Jekyll uses markdown files for example.
Who should we reach out to about this funding for our open source project to integrate with Gatsby ecosystem? We have an open-source platform with tons of components like videoconferencing, events, rides etc. hosted for free on github.com .
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.
So the pattern is like this: open source project -> get funded by VC.
The other similar case is IPFS (open source project) -> Filecoin (get funded by VC).
Anyway, congratulation to the Gatsby team! :)
It's one of my biggest issues with software is that software is never done. It's always being torn down and replaced with something else.
And Gatsby JS work really well, as well.
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.
Of course, to be fair, Meteor is still in business after taking the same path (though it seems most efforts are directed at Apollo?)