IMO, you're giving way too much control to the end user with regard to configuring the layout and minute details of their page. Giving a content author control over the padding, background, font choices, etc, is a recipe for them creating super specific pages that look bad and have no consistency.
Typically, I'll limit clients to specific widgets and layouts and train them on how and when to use these elements for maximum effect. That's the only way to maintain design integrity. I don't let them pick fonts, font sizes, colors, etc. Authors are given a list of choices for the fonts, and these choices correspond to the font hierarchy specified early on, and they have to build pages within those bounds.
The idea is you want to give them just enough control to author the content they need (without weird hacks) and nothing more.
This is also true of rich text editors (at least in their usual default configurations. First thing to do is hide most of the options)
The reason we've developed our own CMS framework (on top of Django) is because everything else I looked at had a complex, powerful and dangerously flexible interface. I lock down almost everything apart from content fields and a choice of page types (about us, contact, product lister etc).
A CMS isn't a design tool or a page layout package. Unless you're building something that's meant to be reusable and configurable by end-users (a mammoth and complex task which you probably want to avoid) then lock down as much as possible. I've had more problems from allowing too much flexibility than i ever get from allowing too little.
Hey! Relax creator here. You're absolutely right, although Relax stays in between that problem. Each component can have styles, and these styles will come alongside a theme. Which means if the end user is using a theme, he'll just have to drag and drop components, and select the style from the ones the theme has. Makes sense?
We'll also have a templates feature which users can use to not start a page from scratch :-)
One thing that's really missing from the OSS world is a CMS that builds static content. We've got Jekyll, Hugo, Middleman and others that are really only targeted at developers.
I'll admit, it's not easy. This is why CQ, Teamsite, et. al. cost a lot of money (insane amounts of money, oh and they're both terrible. CQ is good for end users, terrible for devs. Teamsite is just terrible, and cost $11k per website).
No, this is a terrible idea that is being spread like a cancer by people who don't know their history.
First of all, static rendering CMS-es are IN NO WAY missing as you say; in fact, as your own comment hints, such systems are incredibly abundant. There are MANY other static-render-HTML products that could be added to that list, and they stretch back into the 1990s.
The basic problem with this approach is well understood: As the corpus of content on a given site grows, render time quickly approaches time between updates. In other words, you start waiting for renders to complete before you can change something else on the site.
This happens in part because changes to a single particular piece of content often cause changes to multiple pages — think blog views, archive pages, index pages, tag pages, RSS feeds. Meanwhile, as a site grows, the number of contributors tends to grow, including authors, editors, illustrators, photographers. So not only are the static renders taking longer as the site grows, there is also a growing likelihood that someone will want to touch a piece of content in a given time period, thus triggering a new render.
Probably the most high-profile example of how this could fail was when there were a lot of people using Movable Type for their blogs in the early 2000s; MT did static renders and many bigger blogs had switch to other blog engines or carefully operate around massive render times for MT sites.
If you have a small personal site, static renders are fine. But SO IS BASICALLY EVERYTHING ELSE. You can build a personal site using any number of primitive-but-effective technologies, like server side includes, emacs macros — hell you could literally make a Microsoft Word template and publish everything from there via SFTP. On the flipside, you could install the most inefficient, computationally intensive, database driven crapfest of a web app and it won't matter because you don't need to scale.
In other words, static CMSes are fine if you don't actually really need a CMS. By all means, for yourself, or a tiny project, use whatever you want. But we don't need MORE of those tools.
I don't think anyone is claiming that a static CMS would be a "good idea" for people who have a multitude of pages that are constantly changing, that is of course, madness.
There are a huge number of websites (ie: like every small business website I have ever been to) that have like 5-10 pages tops and they almost never change. For all intents and purposes, they are static. Throwing such sites up on github or s3 is a no brainer. I disagree with your statement that we don't need MORE of those tools. We absolutely need more of those tools, but not for developers (there are literally a million to choose from if you are a developer), what we need are nice clean user-friendly front ends. Every time I have to enable javascript just to visit some Wix website I cringe a little.
There are plugins for Wordpress that will bake the front end of the site in to static HTML and push it up to an S3 bucket for hosting. Seems like a decent solution to me.
On HN you are generally expected to 'get started', rather than insulting projects like that without expanding.
I would actually say, though I vastly prefer say Jekyll over WordPress, that generating a static site from a WordPress site probably works pretty well and gets you a very mature CMS UI for your users.
Doing it that way round is probably preferable and better understood at this point than the newer solutions that are trying to bolt CMS backends onto Jekyll sites (CodeCannon, Prose.io etc).
Fair enough, I half expected to get called out. My original comment suggested that what was needed (particularly for non-developers) was a "nice clean user-friendly front end". Wordpress, although incredibly popular, is IMHO, a usability nightmare and does not fit the bill. It is one of the least intuitive pieces of software I have ever used. I have recently spent some time searching twitter for people having problems with wordpress, and I know i'm not alone.
In any case, for the websites I am talking about (small non-technical businesses in particular), wordpress is overkill and operates at a higher layer of abstraction then necessary. Also, such a solution has almost all the disadvantages of wordpress (Finding wordpress hosting [These guys are not going to have their own on-premise wordpress install], setting up and configuring wordpress, keeping wordpress and plugins up-to-date), for very little advantage (slightly more consistent load times? ). Just putting a CDN in front of it would get you most of the way there.
It's also hard to recommend a good wordpress host [The exception to this is sandstorm, which is amazing and does the wordpress->static thing exactly right]. Managed wordpress is what you want, but it's bloody expensive (again, IMO, but these kinds of customers are generally cheap). Anything more hands-on than fully manged hosting is a lot of work and maintenance for something these people are realistically NOT going to use on a daily basis.
I think Wix and Squarespace serve a very much needed part of the market, and I wish I could point people at an elegant open source solution that would allow "normal" people to have affordable websites backed by S3 or Github pages (like us developers enjoy).
> The basic problem with this approach is well understood: As the corpus of content on a given site grows, render time quickly approaches time between updates. In other words, you start waiting for renders to complete before you can change something else on the site.
Is this limit still likely (honest question)? Hugo seems to benchmark at around 1ms/page.
What sort of scale is common for large sites, what speed would need to be hit for this to become a problem that's simply irrelevant at even the largest scales?
You're assuming that a site's traffic and content change rate grow at the same (or similar) rates. This is almost always true of media properties, but not necessarily of popular single-contributor blogs or brochureware for business, organizations, political campaigns, etc. Many of those are powered by WordPress or Drupal, but they could exist as static sites, as their traffic level is not correlated with their rate of change.
>* The basic problem with this approach is well understood: As the corpus of content on a given site grows, render time quickly approaches time between updates. In other words, you start waiting for renders to complete before you can change something else on the site.*
Only on naive systems -- or if you change the design and layout of the whole site.
Besides, for 99% of websites that are not news or forum sites, the content never grows that much. And for brochure style sites, it's at most a few 10s of pages per year.
>Meanwhile, as a site grows, the number of contributors tends to grow, including authors, editors, illustrators, photographers.
That never happens for 99% of sites -- that could still use static rendering.
So not only are the static renders taking longer as the site grows, there is also a growing likelihood that someone will want to touch a piece of content in a given time period, thus triggering a new render.
>On the flipside, you could install the most inefficient, computationally intensive, database driven crapfest of a web app and it won't matter because you don't need to scale.
Is speed really an issue today though? With multiple cores, multiple machines etc.. Seems like a simple enough engineering problem. How many "pages" does a big site have? How many can be touched by a single update?
Also see Hugo, as someone mentioned..
Not doubting that you're right regardign the history, just that it has to be this way today. OTOH, a dynamic page can also be plenty fast, it does not have to be Wordpress.
The small answer is that rendering touches not just CPU but storage as well. Yes we have SSDs, which help, but writing to "disk" is still relatively slow.
The big answer is: If you can render each of your pages very quickly, there's no real win from pre-rendering everything. You should just render on the fly. The whole point of pre-rendering, historically at least, is to make a site very fast by eating the cost of the render up front.
But from that storage "problem" you get to avoid hosting on a dynamic platform, and literally just need a static web host. As mentioned you can put stuff up on s3 and be done with it.
At large scale of visitors, this kind of approach is a lot easier to handle than the dynamic model.
You could also get a static website generator to output e.g. PHP or HTML files with 99.99% static content and includes/SSI for commonly shared content.
This way few or no pages need to change just because the shard content (e.g. a "latest posts" box) changes when a new post is added.
And you still get the speed of serving, security, AND simplicity and easy hostability of merely serving static files.
How large does a site need to be before render time becomes a significant issue? I can understand it being an issue for, say, Google News or some other highly dynamic site where the input sources are programmatic. But for sites where there are humans providing the content, why in today's computing era would it take more than a minute to update hundreds of pages?
Prose[1] makes editing static sites quite easy. Unfortunately, the last time I tried it, it had lots of bugs and missing features, but seeing that there's been quite a lot of activity recently that might have changed.
Lektor (https://www.getlektor.com/) might be a good candidate for that. It has a graphical user interface which makes editing accessible for non technical folks.
Bricolage in the late noughties was this. Salon ran it for a fair amount of time. The company I work for currently uses it, although I think we're one of the last ones, and since it's not really getting any updates anymore, we'll likely be moving off of it in the near future.
It made some really novel decisions on the Admin UI spectrum, and it's not terrible for content managers as a lot of open source CMS software tends to be, but it never gained traction. My familiarity with Perl isn't what it should be, so it's always painful to try to dig in to debug problems as well.
Speaking with my DevOps hat I cannot "relax" with MongoDB in the backend ;) Have you done ANY heavy loadtesting with this infrastructure (which is cool but does it scale?) and what is your result in comparison to Wordpress and static content?
How likely is it possible to switch to another database like PostgreSQL?
Considering most CMS systems barely reach 100req/s (uncached), I think we can say raw database speed is less of a problem than bad query patterns. Or if you prefer, the use of a SQL db is no guarantee for performance.
Maybe mongodb will perform better, free of joins, than MySQL/Wordpress/whateverCMS... or maybe the data access pattern will suck and make it slow (and maybe it would be slow with a SQL db too, like other CMSs).
Ideally (in terms of performance), a single K/V request would be needed for each page, and the CMS would handle all the denormalization (and tens of thousands of req/s). I don't know how they've designed their data model...
All in all, a CMS is the most cachable web app ever, as it's more or less meant to replace static pages ;-) The poor performance of existing CMSs has always been hidden by caching layers...
100% agree. But there is not a single word about caching or how to integrate it with Relax either. I understand it is a young project but if I need a CMS I want it to have it a little tested and scaling questions not open. Caching is totally NOT trivial with React,Redux,GraphQL (at least I totally don't know how to do it but maybe I'm not smart enough) ... maybe it is even harder with such an architecture. I'm just saying I doubt a littlebit the cool and shiny architecture justifies the purpose (many questions open).
Despite that, can't say for a fact that's the case for Relax since I haven't test both on it. Mongo is behaving really well though, our demo instance has been getting a pound lately (dozens of users at a time) and it's running smoothly even though our machine is not really powerful.
Having this said, not entirely against having different database layers supported in Relax. Since we're using GraphQL would be a matter of creating an abstraction when accessing the data on the queries and mutations resolves. Not on our priorities for now but we're always open for contributions :)
I don't have one specific piece of advice, but after playing with the demo, the front-end of this CMS is very hard to use. I don't seem to know what the heck is going on when I create new items or drag little boxes around. I literally have no idea what I am doing.
Hey! Relax creator here. Sorry to ear that. Since it's a demo people add a lot of noise to it (a lot of styles and colors etc), with a private account and with some theme imported you'd see that making a theme is a bliss with it :-)
I wish, someone would build an OSS CMS on top of Apache Sling. The concepts of JCR and Sling are perfect up to a point, where I don't want to deal with anything else. If my company had the money, we would instantly buy Adobe AEM licenses. Unfortunately its soooo expensive and they are the only ones who have a CMS frontend for Sling.
I've just started working with Joomla in the last few days. The only redeeming factor with it is that you can install it anywhere (since PHP is so prevalent). I wanted to install Django-CMS, but guess what: the host I have to work with does not support Python... So I'm stuck in CMS Land with choices that don't really help me much. Hopefully I'll get over the initial 'ugliness' in using Joomla. Relax CMS requires Node.js, which unfortunately is also not supported as much as PHP ... sigh
If Joomla today is similar to Joomla ca. 2010, I'd rather call each potential visitor and read them the html than use that CMS.
I'm really quite fond of the static generators now. I'm not even sure why – the principle isn't much different from a dynamic CMS with caching. And data probably belongs in a DB rather than a bunch of files. But the architecture of Hugo etc. make them really easy to understand, I can host it on google cloud storage (and probably serve thousands simultaneously without breaking a sweat), it's as fast & save as possible and I don't have to worry about passenger/postgress/memcached/etc. making any trouble.
I'm sure the next step will be web-based authoring tools for Hugo/Jekyll/etc., which will seem a little strange but actually get us close to the best of both worlds.
There's always some dependencies. Most hosting companies nowadays have servers setups that already brings you Node.js installed the same way you have servers with PHP configured. You just have to think PHP is declining and JavaScript rocket flying so things will turn on this. Also with docker setup on the way for relax, it'll be a breeze
Is there an easily accessible API for this?
The ability to add schemas, and manage media is nicely done, but for a game app I'm building we have our own client app.
I'd like to mix the occasional embedded webview, but mostly just access content as JSON.
There maybe other CMS tools that are more suited to being used just for their backend, any reco's appreciated ^_^
Hey! Relax creator here. Schemas you create in Relax will be able to mark as publicly accessible, so you'll be able to use it as an API, it's a GraphQL API though :)
Throwing "Uncaught TypeError: Cannot read property '_currentElement' of null" on the page edit view. UA: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36. Just saying ...
Hey! Relax creator here. Yes it will. You'll be able to create any component to use on the page builder where you can make your own settings and styles options.
"We've now switched away the human interface used to manage the control rods in the nuclear reactor from antiquated buttons and levers to a touchscreen running an application powered by node.js+React+Redux"
Hey! Relax creator here. Actually the demo version goes back quite a while. We're redesigning a refactoring pretty much of it. Should be completed soon and we'll update the demo when it's more stable :-)
Typically, I'll limit clients to specific widgets and layouts and train them on how and when to use these elements for maximum effect. That's the only way to maintain design integrity. I don't let them pick fonts, font sizes, colors, etc. Authors are given a list of choices for the fonts, and these choices correspond to the font hierarchy specified early on, and they have to build pages within those bounds.
The idea is you want to give them just enough control to author the content they need (without weird hacks) and nothing more.