Politics aside, the largest problems I’ve had it with it revolve around the tension of organizing things in the CMS for the user vs configuring things for easy digestion in the SSG. If you set up the CMS how your, for example, non-tech savvy friend might expect it to look and then go build the front-end, you are almost certainty going to have a very bad time. This is because Netlify CMS’ widgets nest everything in deeply complex frontmatter by default, which makes sourcing and transforming it feel like a cumbersome chore.
In my discussions with other people about it, more than one person has said, “So it sounds like the biggest benefit is just that it’s free. Thanks, but I’ll pass. My company pays for the base tier of X”
EDIT: I’d just like to point out that I think I would/will use it again. The next time around, I’ll probably use almost exclusively folder collections. This breaks out the markdown into oddly organized bits in the CMS, but it makes it much easier to consume and combine in the build step.
Now, here's where the fun starts. Nowadays, most clients would like a level of configuration that goes a little bit further than a plain text box, right? That's really where things start to get sticky. Since you mentioned it, I'll use an FAQ as an example. With Netlify CMS + Gatsby, the best way to do this is probably to create a folder collection like I mentioned before with blog posts. That way, we can query all of them together and use them in any component we like. Here's where we hit a bit of a catch-22. What if I want to configure a heading and overview text for my FAQ? I can't add meta fields to collections themselves, so I have to put them somewhere else, presumably in a specific file in a file collection. This is a confusing experience for a non-tech savvy user, not to mention that it makes writing previews in the CMS more difficult. Now, some people might disagree with this approach altogether and opt to use a combination of list and object widgets in one file collection. That way, they can have their FAQ list right next to their FAQ "heading" and "subheading" fields. But if you do that, querying this information now becomes painful. You'll probably have to query by absolute file path to get the markdown node itself, then you'll have to de-structure content from one extra level deep in your data object, then once you've finally got your array, you'll have to map over it, then set the markdown body into the corresponding FAQ section. "Whatever, that's not that bad", you may be thinking, but here's the problem with that: nested markdown fields in frontmatter aren't transformed into HTML by gatsby-transformer-remark. You now have to manually go through and transform markdown to html yourself on a case-by-case basis in gatsby-node.js every time you want to use long-form text that requires formatting.
There are many other, smaller issues, but I think this is the most glaring. Granted, there are ways to work around this in Gatsby e.g. fragments or schema customization, but they all require intermediate to advanced knowledge of graphQL and Gatsby. Even as that knowledge becomes more commonplace, it's still just unnecessary extra labor. One could also argue that this is a problem with the netlify-cms source plugin or gatsby-transformer-remark, but I would suggest that regardless of how things are sourced, the presentation of content in the CMS itself is what's really broken here.
I hope this helps!
Also, I've run into trouble with simple things like setting an unique ID for each "Product" without typing it manually, like an incremental id. Datetime field with UNIX formater was the closest I found, but it was not foolproof enough.
The UI for these starters doesn't show off advanced stuff, but click on "Front Matter" and add complex fields/groups/blocks to get a feel for the UI.
My requirements at the time were:
- Can be integrated in a Vue static site generator
- Has a free plan (single user)
- Could be hosted for free at least during development
- Could have relations ("Post" can have a "Category" field
that list its content as options)
- Has a admin UI that a non-developer could figure out
There would be a lot involved and probably wouldn't be worth the effort when more dynamic solutions are already out there, but I think it would be doable.