|
> as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with Sounds to me like you already made a good case for why those products exist. Sure, you could also call HTML structured content, but using HTML for expressing the semantics of the content instead of the presentation has always been a bit of a pain. Plus you wouldn't really want to use HTML as a format to share this kind of data with for example mobile applications. You could use XML, but I'd say that's basically the same as JSON with a fixed schema but with more angle brackets, which is pretty much what those headless CMSs return. Then on top you need the devs to build the server, and to maintain the DB, to add a querying API, to add SDKs and tooling that enable smooth integrations with the new API, the workflows on top of the pure content, a UI that is intuitive to the people maintaining the content, security audits, scalability for when more parts of the company want to use your tooling etc etc. Following your reasoning you could also say "Payment provider" is a marketing term for something that is just a DB that needs to sync with some banking APIs and AWS is just APIs in front of some DBs and VMs and analytics solutions are just a JS SDK on top of some DB. Fundamentally everything we build is just some kind of frontend or abstraction on top of a DB. I don't see how that makes it in any way pointless. |