HN Explorer

Tell HN: the tool we need, a modern CMS with no server runtime

9 points by kls ↗ HN
I have been thinking about this one for a long time, but I just have to many irons in the fire to pursue building it.

There are a lot of new client side templating frameworks coming out like dust.js, but I think it would be nice to have a modern CMS that does all of the templateing and then exports the site as flat HTML files for the non dynamic stuff and snippet files for the dynamic stuff. This way designers and copy editors could work in a CMS like they do with the old CMS solutions, but instead of it running server side, it would export all of the content to flattened HTML files. For the dynamic stuff it could be plugable so that the content is published to content files that can be picked up by ones favorite client side templating framework.

Further, it could be enhanced to support WYSIWYG editing for different widget toolkits, say Dojo's Dijit or jQuery UI, where front end developers could write a widget, add it to the CMS and then site editors could add it to a page, Think of Drupal but for pure JavaScript, HTML, CSS based apps. The more I think about it, the more I really want this tool, the new JavaScript app stack is so much cleaner than the old stack and I would love to see a CMS tool that makes a clean break from the old cruft and provides a tool specifically for this market. If anyone is looking for an idea and decides they would want to pursue building a CMS like this, feel free to contact me (in my profile). I would love to discuss my ideas for a CMS like this, as I said, I just have too many irons in the fire to even embark on such a project, but would love to see it come to life. Not to mention I would purchase a copy for every project I work on, if one existed.

11 comments

[ 3.3 ms ] story [ 29.4 ms ] thread
papaf
I wrote a static page publishing system in the mid-nighties. They're harder to do than dynamic based systems -- calculating which pages link to a given page and need to be updated, say when a title changes, is a pain.

I think static page based systems are needed less now due better hardware performance and the introduction of memcache.

That said, static page systems are very reliable. Even when the CMS goes down people still get content.

If your site is small enough to export the whole thing on every update there are systems such as Jekyll and Hyde.

arb99
loads of v high traffic sites run just wordpress (although, most will have a cache plugin). its not really a problem in 2011. having a static version of a site would cause lots of problems. typically have to really refresh every single file on the whole site whenever an edit is made (to make sure everything is up to date. you could work out what pages need to be updated really, but depending on complexity of the cms it could be a daunting task)

just use whatever cms you want to (or write your own) and write even a simple cache script for it, or run something like memcache

kls
The point of a CMS like this, is that it would be built specifically for people that write client side UI's. So there really is not a need for a server run-time component, because the client app, request data and assembles the view. But there is still a portion of these web apps that are static, like the header, footer, etc. Say I want the same header on index.html and page2.html, I have to accomplish in one of two ways, I either use something like tiles for Java or I used something like dust.js on the client (for this style app, tiles is out, so it would be dust). What I would like to see is a CMS that composites that header into both pages and removes it from a run-time concern on either side. Now that's just one really simple example and I know current CMS's can do that, but I think their is a value in a CMS that only caters to this style app development. Further, the reason, that I would like to see it not have a server component is by eliminating it, and putting all of the dynamic CMS logic in a JavaScript files that get's delivered to the client, would be because CDN's could then be exploited for scalability. I could see, a pattern where companies use a CDN for all of the content, and an AWS instance to set up REST services and have virtually no infrastructure.
swah
What about static templating like mustache?
kls
Sure and that is what a lot of people use, but I would like to see something that allows copy editors and designers the ability to publish without the aid of a developer, after the core application has been built. I would like to see the traditional CMS workflow adapted to modern client side browser apps. But I think there is value, in a clean code base that is developed for this market and not a CMS that has been adapted. It's a completely different way of developing apps and I think we need a new CMS that is designed specifically for it.
eof
not exactly what you need; but the boost module for drupal essentially outputs a drupal site as static HTML files
mleonhard
Do you want to separate the CMS hosting from your web hosting?
kls
Yes, most of the apps I so now, the UI is completely client side, with the app getting data via REST services, one of the last areas that can be a pain, is in content templating, what tiles and velocity do in the JSP world. What I would like to see is a CMS that provides that kind of templating for people who do not use server side frameworks anymore. I would like to see it publish to flat files because I think CDN's could then be used to bring in scalability on demand at inexpensive costs.
swah
I believe you said you were using Alfresco one of those days. How is this different?