It's often a requirement that non-devs be able to edit the website. WordPress is okay if you have a site that you don't really care about and isn't worth hacking, or if you can afford to pay Wordfence $99/mo and take the time to make it reasonably performant.

Gatsby is not a CMS. It would be very nice to have a well-designed and supported CMS that is actually secure and efficient by default.

> How much more complicated can it get then "Here is HTML, CSS and JS put it on a webserver."?

My favorite so far is the combination of WordPress and Gatsby in such a way that you get the worst of both worlds. E.g. building a single page requires creating 10-20 posts in WP, with zero ability to see what changes will look like without actually deploying the site. All this complexity instead of just setting rel="preload".

> WordPress is okay if you have a site that you don't really care about and isn't worth hacking

Unfortunately all sites are worth hacking to host phish kits (fake login pages for phishing), and hosting one will get your website added to browser warn lists and flagged by search engines. There seem to be automated bots scanning for vulnerable WordPress sites so it's possible to become a target without much attention from the attacker.

This is true, but I would hope that readers here know enough to at least keep WordPress up-to-date. Most attacks target old exploits. There are millions of small WordPress sites that may never get hacked if they stay updated. If you become big enough, however, you become a much more likely target for zero-days. In that case, you probably don't want to be running WordPress any more than you want to be running Windows.

Totally agreed. There is room for something better. More modern than foundations than Wordpress without going too far into the JavaScript black hole.

We agree as well. Thats why we made tipe. We are focused on deeper, low code / no code integrations with frameworks that still allow fluid customizations.

Gatsby and Jekyll are technical tools. The audience of a CMS and the audience of a command line program to consume a file system directory of yaml are different people.

Additionally, something like GitHub/GitLab/Gitea is at the minimum required to even make that existing pain-in-the-ass workflow work.

Try updating your jekyll site from your phone without using GitHub, for example.

This is what I wondered as well.

Given that there are things like:

Contentful, Ghost, Strapi, etc., which either have a REST API for content, and/or other API for customizing the interface for non-devs, or are developer-oriented.

I'm surprised something like this received funding... makes me think, "Snap, I guess I can get funded too?"

It's not about shortage of tools so much as such a big market that there's always room for more. I'm not really sure where the line is these days of useful new vs developer toy but that's often the case. I think this is a good thing.

I would like to make a plug for Statamic who I have no affiliation with other than being a happy customer that added a bit of customization years ago: https://www.pixlee.com/blog/how-we-allow-anyone-to-make-and-...

One of Sitecore's sells (.NET CMS) is non-technical users can manage content and control the layout of the page WYSIWYG style. Developers still work on it, but it's less about app and page development and more about component and tools development.

The key is allowing non-technical folks to work without much training. I don't think anyone has found the right balance yet.

With tipe, this is possible. You as a developer have complete control over what non technical people can edit. From layouts to actual text on a page. You opt into what you want to be dynamic. Snd with our instant preview feature, your team can see their changes fast.

A follow-up question, if you happen to see this: How does Tipe handle experience management, as opposed to content management?

Since headless CMSes became popular 5-6 years ago (in large part thanks to Contentful), a lot of companies have moved to them based on the promise of separation of concerns, "omnichannel" publishing and better developer experience.

But what a lot of people missed was that a traditional CMS like Sitecore or Wordpress etc provides not only content management (for structured content) but also experience management (for pages and layouts). And in larger orgs, these two things are often managed by different teams, but both are driven by business users, not necessarily developers.

Headless CMSes typically only provide structured content management - by design - and so experience management ends up needing to be built into the consuming applications, which vastly increases their complexity (not to mention how you manage updates over time - developers now need to be involved), and that doesn't scale well.

Or it gets shoe-horned into the CMS as a less-than-ideal type of structured content, and becomes hard to manage by non-technical folks.

How do you see Tipe being used for experience management?

Well said. We like to call that the magic of a CMS. Headless cms' are all so disconnected which ruins the magic. We want to maintain that illusion, like you're back in the wordpress days. So experience management is huge for us and we're putting much effort and research into it. Also allowing the community to build and share with others because we're open source.

I am certified with Sitecore 6.5, However I haven't worked with it regularly in over 4 yeras so things have probably have changed (I've heard Sitecore 9 is very different than 6-8).

One of the problems with the WYSIWYG editor was that the developer effort typically added and extra 50% effort onto any task and like anything with Sitecore you ended up having to dig through PDFs on their development portal.

A slight aside though. One of the best things about Sitecore was its OOP approach to content. Every piece of content was an instance of a template. If you knew what you were doing with it you could build things very cleanly. I haven't seen anyone else implement anything similar in their CMS.