Real Question Time: Assuming that CMSs are really Content Management Systems, intended largely to serve relatively static content, and not be an app development platform do we need another?
I'd say for 90% of people Wordpress for all its problems is fine, if someone is technical and wants more control and customization well really at that point Jekyll is pretty powerful, and if you want fancier you've got Gatsby or whatever the JS flavor of the month CMS is.
Is there a shortage of tools to allow me to publish a webpage? Is the problem of creating and publishing a website so hard that we need a new entrant to solve the problem? How much more complicated can it get then "Here is HTML, CSS and JS put it on a webserver."?
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.
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.
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".
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.
> 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.
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'm sorry for the somewhat unproductive comment, but for anyone else wondering: Their homepage actually has an explainer below the title and the community reviews aren't empty gray blocks. They've just used a font weight of 100, making the text effectively invisible.
1. Our frontend editor, where you edit content, is open-source. You can add new field types with react components easily.
2. The editor is also mounted on your site and lives there wherever you want. So, yousite.com/cms. We handle auth as well.
3. You define your schema in your code, like a DB schema, instead of in a GUI. Your schema lives in git with your app.
4. You can get started completely from the CLI, never touching a web app.
5. You can extend your schemas with plugins from the community.
6. We give your features like content previews right out the box with no code setup.
I can't find anything that explains what Tipe actually is. It's a plugin-based, customizable SaaS?
Their GitHub page is some confusing bullshit where they seem to have taken the repo of a completely unrelated Angular animation library that has been inactive for 6 years and converted it to be Tipe, presumably to make it seem as if Tipe has earned 2.1k stars when it was actually the Angular project that earned those stars.
They claim to be open-source but I see zero source code. Maybe the source is in one of the two different CLIs that seem to exist? But the one that actually seems documented and usable hasn't had a commit in 10 months.
yea, you're absolutely right! I am the author of that said animation lib, ngFx, from years ago. Was actually my first open source project. When we started tipe years ago, we sunsetted that project and used the stars to generate hype for tipe. We were way ahead of ourselves :). Because we're in private release, all of our open source is private on github right now. Once we're not longer in private release, it will be public.
GitHub should tie stars to commit hashes to avoid this sort of crap. Your repos stars is calculated from the started commits that are in this repo but not any it's forked from, on the default branch.
Still prone to abuse from transferring repo to credit somebody else, but the original repo owner would have to sign off on the transfer at least.
I'm Scott Moss, CEO of Tipe (YC W18). We actually just saw that someone posted us on HN. So here to just drop a little bit about Tipe. Tipe is a headless, open-source CMS with a focus on Jamstack apps. Our goal is to have the quickest setup to allow your team to edit, preview, and publish content. We also want to enable you to customize and extend your CMS to fit your team's needs. You can even reuse components you already created in your app to customize tipe. The sky is the limit. We handle the API and infrastructure. We're currently in a Private release and are looking for teams who are using Next.js. If that's you, please sign up!
I'm not in this industry anymore but used to work for a company that provides CMS to fortune 500s. A significant portion of our customers used angular (not angularjs). Are you planning on supporting that as well or remaining react focused?
Absolutely, my career started with Angular and my co-founder created Angular Universal. We have big plans with Angular. You can actually use Tipe with any framework or platform, we're just focusing on our deep integrations one framework at a time for now it get it magical.
i used to work in enterprise cms implementations. a couple of thoughts:
- in my experience most cms implementations are handled by a partner or vendor with some expertise. few businesses have the direction/leadership in place to hire a few devs of the intended cms and start hacking away.
- if you are targeting enterprise you need to market to C-level (or slightly below) marketing people, not devs. marketing holds the keys here and any technical people are usually just along for the ride.
- non-cms content (coming from business systems/integrations) will come into play quickly, figure out a simple blueprint to extend the cms object model to account for this.
- though these were enterprise setups they were usually way off the mark by the time we talked to actual system users. think multiserver architecture, requirements to edit the most obscure content that will never be touched after launch, integrations that dont make sense, access to inaccessible data, etc. probably 30% of the time it should've been something simpler like wordpress, netlifyCMS, etc., 30% should have been static content, 20% should have been completely custom and 20% were actually a good fit for the cms.
- set up examples of common site layouts/components and a WYSIWYG implementation for each. non technical users will expect to be able to change EVERYTHING and page templates quickly turn into a mess trying to keep it all together. episerver has a pretty good system for this IMO.
Can anyone in plain English explain the advantage of JAMstack over the typical nodejs or LAMP stack? All I seem to get is jargon filled press releases from companies with millions of dollars of venture capital.
One offloads a large portion of rendering to the browser where as the other does it mostly on the server. Less processing on the server means less server costs. The former results in an API that can usually be repurposed more easily by other types of clients, such as Android and iOS apps. Also the API can usually be anything that responds to a HTTP request, such as Firebase, PostgREST, or even Airtable's API. Since the rendering is handled in the browser, the frontend can be placed any server that serves up static HTML, CSS, JS and images. Usually this is a CDN.
Of course all these things are really trade-offs. It's arguably much easier just to throw together some PHP and stick it on some LAMP shared hosting if that meets your needs. Or if you're more comfortable with server side languages, you'll be a fish out of water. If you don't know why you would need it, you probably don't.
> That makes sense. But isn't that punishing to lower end hardware users?
Yes, and the punishments will continue until hardware improves. More seriously, this is definitely a big trade-off. That's why page weight has been growing over time and client side metrics haven't been getting much better despite improved hardware and connection speeds. There's no free lunch. As I've mentioned in past comments, now's a great time to be a web performance consultant.
> Also aren't you moving much more data back and forth to do that?
Considering that usually the bulk of the frontend arrives once and then gets cached/runs continuously, I would say generally no. Server side rendering requires the page to be sent in whole on each request, unless you're doing some funky hybrid stuff with partial server rendering.
The other problem with this approach is that is moves a lot of complexity to the edge of your environment.
All the transformation & orchestration of your content has to happen in your app.
If you have one backend and one app, that's not necessarily a bad thing, because you have to do that work somewhere, but if you have multiple apps (perhaps by multiple teams) that all consume the same backend, you start to duplicate a lot of that complexity all along the edge of your system.
49 comments
[ 2.5 ms ] story [ 30.6 ms ] threadI'd say for 90% of people Wordpress for all its problems is fine, if someone is technical and wants more control and customization well really at that point Jekyll is pretty powerful, and if you want fancier you've got Gatsby or whatever the JS flavor of the month CMS is.
Is there a shortage of tools to allow me to publish a webpage? Is the problem of creating and publishing a website so hard that we need a new entrant to solve the problem? How much more complicated can it get then "Here is HTML, CSS and JS put it on a webserver."?
The key is allowing non-technical folks to work without much training. I don't think anyone has found the right balance yet.
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?
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.
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.
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".
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.
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?"
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-...
1. Our frontend editor, where you edit content, is open-source. You can add new field types with react components easily. 2. The editor is also mounted on your site and lives there wherever you want. So, yousite.com/cms. We handle auth as well. 3. You define your schema in your code, like a DB schema, instead of in a GUI. Your schema lives in git with your app. 4. You can get started completely from the CLI, never touching a web app. 5. You can extend your schemas with plugins from the community. 6. We give your features like content previews right out the box with no code setup.
Their GitHub page is some confusing bullshit where they seem to have taken the repo of a completely unrelated Angular animation library that has been inactive for 6 years and converted it to be Tipe, presumably to make it seem as if Tipe has earned 2.1k stars when it was actually the Angular project that earned those stars.
They claim to be open-source but I see zero source code. Maybe the source is in one of the two different CLIs that seem to exist? But the one that actually seems documented and usable hasn't had a commit in 10 months.
Seems questionable to repurpose the repo to leverage the stars regardless of whether you posted it here or someone else did.
Still prone to abuse from transferring repo to credit somebody else, but the original repo owner would have to sign off on the transfer at least.
How common is this?
Seems like fraud to intentionally swap out a project within a repo for something very different to repurpose a reputation metric.
I'm Scott Moss, CEO of Tipe (YC W18). We actually just saw that someone posted us on HN. So here to just drop a little bit about Tipe. Tipe is a headless, open-source CMS with a focus on Jamstack apps. Our goal is to have the quickest setup to allow your team to edit, preview, and publish content. We also want to enable you to customize and extend your CMS to fit your team's needs. You can even reuse components you already created in your app to customize tipe. The sky is the limit. We handle the API and infrastructure. We're currently in a Private release and are looking for teams who are using Next.js. If that's you, please sign up!
I'm not in this industry anymore but used to work for a company that provides CMS to fortune 500s. A significant portion of our customers used angular (not angularjs). Are you planning on supporting that as well or remaining react focused?
Is this a typo?
- in my experience most cms implementations are handled by a partner or vendor with some expertise. few businesses have the direction/leadership in place to hire a few devs of the intended cms and start hacking away.
- if you are targeting enterprise you need to market to C-level (or slightly below) marketing people, not devs. marketing holds the keys here and any technical people are usually just along for the ride.
- non-cms content (coming from business systems/integrations) will come into play quickly, figure out a simple blueprint to extend the cms object model to account for this.
- though these were enterprise setups they were usually way off the mark by the time we talked to actual system users. think multiserver architecture, requirements to edit the most obscure content that will never be touched after launch, integrations that dont make sense, access to inaccessible data, etc. probably 30% of the time it should've been something simpler like wordpress, netlifyCMS, etc., 30% should have been static content, 20% should have been completely custom and 20% were actually a good fit for the cms.
- set up examples of common site layouts/components and a WYSIWYG implementation for each. non technical users will expect to be able to change EVERYTHING and page templates quickly turn into a mess trying to keep it all together. episerver has a pretty good system for this IMO.
Of course all these things are really trade-offs. It's arguably much easier just to throw together some PHP and stick it on some LAMP shared hosting if that meets your needs. Or if you're more comfortable with server side languages, you'll be a fish out of water. If you don't know why you would need it, you probably don't.
Yes, and the punishments will continue until hardware improves. More seriously, this is definitely a big trade-off. That's why page weight has been growing over time and client side metrics haven't been getting much better despite improved hardware and connection speeds. There's no free lunch. As I've mentioned in past comments, now's a great time to be a web performance consultant.
> Also aren't you moving much more data back and forth to do that?
Considering that usually the bulk of the frontend arrives once and then gets cached/runs continuously, I would say generally no. Server side rendering requires the page to be sent in whole on each request, unless you're doing some funky hybrid stuff with partial server rendering.
All the transformation & orchestration of your content has to happen in your app.
If you have one backend and one app, that's not necessarily a bad thing, because you have to do that work somewhere, but if you have multiple apps (perhaps by multiple teams) that all consume the same backend, you start to duplicate a lot of that complexity all along the edge of your system.