A CMS with no server and 18 lines of configuration
netlify.com
netlify.com
The only problem is it typically locks out less-technical contributors, so it's often with a bit of sad resolve that I've then brought Wordpress into the equation—just to empower other editors.
This is an alternative. The Netlify CMS cleverly provides CMS UI that then commits editors' changes via git (with no git knowledge needed), so they look to me just like another contributor. Since content is managed in static files, any participant can use any tool to to participate.
Some developers love Wordpress with it's ecosystem of plugins and capabilities. This is not for them. Other developers would rather not run Wordpress, yet are just looking for a way to bring in other contributors to a web project, working in a compatible workflow. Those devs, I think, will relate to the ideas of this CMS.
I see the appeal against Wordpress. Wordpress is hell to integrate, slow and a security nightmare. But I don't see the advantage compared to, say Kirby.
There's a post somewhere down below saying smashingmagazine moved to netlify from a Rails, Shopify, Kirby mix[1]. "move would need to include solutions for a decoupled CMS, comments engine, eCommerce platform, and member login."
What Netlify provides, reminds me of what parse used to provide. Except that it adds a CMS and targets Web applications with identity[2] etc. They sell a client facing website platform. Good for them. But that's not what the post is about. So yeah, I do find it misleading.
[1]: https://www.netlify.com/blog/2017/11/21/smashing-magazine-is...
However, the CMS itself is not tied to our deployment and automation platform. It can also be setup to work for GitHub pages or self-hosted setups.
The basic idea is that's its an editor friendly content management UI for persisted data stored in a GitHub repository. What you do with that data is up to you.
Since it was discussed in a different subthread: If you would describe it like that, why isn't something straightforward like that the blog post title?
In a broad sense there's nothing that can't work with the CMS - you can integrate a Mailchimp sign up form in your template and never have the CMS touch it. Beyond that, reach out in the spectrum community for help with a specific use case: https://spectrum.chat/netlify-cms
The demos is cute and all, but not really different from the many other existing CMSs for static site generators.
That said, I do think it's good we're finally having some options for this model besides Movable Type, which has been around for 18 years, but which is too expensive for the needs of many.
1. Git based, which is how devs are working increasingly
2. Highly extensible, from backends to editor plugins
3. It's open source
As a bonus, it's very easy to hack on - just a single page app written in React.
Having been involved in a few single page apps, I'd like to point out that JavaScript is a Turing complete programming language. There is no "just" about it. It may or may not be easy to work with, but the fact that it is a single page app or that it is React, had nothing to do with the matter.
After all, php is "just a web page with some templating commands" (and look at where that gets you).
Also, when you are enjoying that warm feeling from being "serverless", bear in mind that building something you value around someone else's service, especially if you aren't paying them for the privilege, may not be a spectacular idea.
This message brought to you by the American Society of Cynics. Pointing out that your glass is half empty is our calling.
And you don't have to use Netlify's service with their Netlify-CMS. Their step-by-step guide uses it, but that's only because they obviously want to promote their service[2] and it's the easiest way to get it all set up. You'd otherwise just host the CMS page at /admin of your site and configure a webhook to deploy your site on a push event.
[1] Unless your point is just that programming is hard. Which is obviously true.
[2] Though their service is pretty shweet as they put your assets on cloudflare and handle the webhooks for you.
Minor correction to your 2nd footnote: We put your assets on our CDN - some of which is served by amazon's Cloudfront. We don't use Cloudflare's services to run our CDN :)
The project is great, it’s really nice contribution, and I’ve had good experiences with netlify as well. No reason to leak brand faith over stuff like this.
>>A Complete CMS with No Server and 18 Lines of Code
You can literally tack this CMS onto your existing site with a trivial amount of (configuration) code. You cannot in any sense do that with a traditional CMS. I'd call it tongue in cheek for sure, but I don't agree that it's a lie. Just a matter of perspective. Glad you like the project!
So apparently the title failed to communicate this correctly. (IMHO, you should present it as a editing frontend or a backend UI or ... that's used in combination with other tools and services to form a CMS)
It’s not a matter of perspective given the target audience. Developers don’t think that doing something in “x lines of code” means configuration files.
It’s intentionally misleading, and that fact that you double down on it after it’s mentioned reflects on the company.
I’m not saying it an easy distinction to draw, in fact often it’s incredibly difficult and that’s why marketing claims have such wide legal latitude.
It’s just that in this case, given the foreseeable audience interpretation, and given the audience is known to have a penchant for unvarnished, straight talk about technology, it’s not a good decision for your company.
Startups come out of the gate attempting climbing mount everest. Given the difficultly, unforced tactical errors really need to be avoided, and corrected when pointed out.
Or, you could build a CMS around https://stackedit.io. It can apparently sync with CouchDB.
So, what number do we actually care about? You chose to be pedantic and you didn't go far enough. How about, instead, we care more about how much I have to write to achieve what they say I can; 18 lines.
In fact, if it was clear that it was configuration lines, it wouldn't be a good title, because it's not particularly impressive: for example in Wordpress you just need to change 4 lines of wp-config.php to start using it.
That said, my comment was ultimately pointless and I regret making it, agreed.
I'm creating a website for my parent's farm. Right now I'm using netlify for hosting(free), metal smith as generation, and netlifycms so my parents can edit the content.
For example we raise registered goats so we need to add info for each goat to the web site. I added a new collection for goats, configured it to have the right fields, and added the needed layouts to metalsmith. The information is then used in creating both a summary page that lists all the goats and individual pages for each goat. Only thing I have to pay for is the domain.
I'm really liking it so far. It seems to be very flexible with the ability to extend the code and write your own widgets.
My only complaint about the CMS is the documentation is lacking so you have to dig through code to fix some issues.
Thanks for making this netlifycms devs. :)
That said, it would probably not be that hard to create that electron app. You just need to include 3 files to get netlifycms to work.
(Compared to say, old school shared hosting plan or a static site on AWS where I need to mess with 3 separate services + config if I want to make any changes after running the wizard.)
/unpaid schill
These all turned out to be lousy approaches when it came to UGC, personalisation, migration and URL paths, authenticated content, non-technical business users, team authoring and non-trivial workflows (e.g. picture desks), content reuse and contextualisation, evolving functionality (a split front and back system can require 2 dev streams kept in sync like trying to ride 2 horses).
Integrated back and front end systems was the start of solving these issues and has evolved to SaaS for non-complex use cases. If you look at Wordpress and Drupal, they have been adapting over many years answering these kind of questions and you'll see that they are now starting to address multiple front end channels, PWA and so on.
Old versions of Drupal for example used to allow pages to be rendered to file for faster delivery. However, it turned out that the number of pages grew towards infinity due to dynamic variants of pages (making server and file system into the bottleneck), and that CDN's just became a much better way to do this. Likewise, work was started on a materialised views layer to optimise DB calls until it was discovered that PHP object caching had become very effective and made this redundant.
A static generator could be a good app for a developer to blog but this is niche and it is about the worst choice possible for almost all organisation-based CMS users.
For example, I consulted to a large national broadcaster about 6 or 7 years ago who had created a legacy CMS which rendered XML/XSLT to reduce bandwidth, and the user's browser compiled to HTML in much the same way you describe. It would have been interesting as a tech demo when it was first created about 10 years ago and would have made a good HN blog post. But as a production CMS it was completely unmanageable, prevented them doing the things they wanted to do at a business level, and grew into a tentacled legacy blob which was extremely expensive to migrate off. It was an embarrassment to the tech management and they were open to switching tech even if that meant recycling their large in-house dev team. In the end the cost of their tech experiment which had gone out of control ended up in many millions.
Developers building CMS's is an established anti-pattern with a problem space that is quite hard to understand unless you have been working with users at large orgs for a while. Go and look at how many modules are on WP or Drupal - 10's of thousands, each one which will have had months to years of dev time. Each one represents real use cases that organisations had which was not solved by what developers imagined managing and publishing content to entail.
As for IA/schema, one of the major reasons to use a dynamic CMS is that you configure your own because there is no such thing as a generic 'good IA' for any non-trivial content (recipes are probably the closest but even there most schemas are too limited for professional use). If you are working off a fixed IA, you may as well just use a low end SaaS. Drupal is particularly strong in IA, offering nested object modelling, workflow authoring, content versioning (now including staged sets of content so you can version sections or hub landing pages).
You then need to start adding considerations like BigPipe, or offline first access with eventual consistency for edits, and how all these play with access levels for granular pieces of content which may sit within pages depending on who's viewing, ditto contextual content. These are just a few things off the top of my head which CMS's start needing to provide.
If I was creating something in this space, I might look at small serverless modular apps performing simple use cases in a very polished way which could be used alone, or very easily integrated with major CMS's (including building, maintaining, and promoting those integrations). But possibly better to look at SaaS layers which sit on top and address digital experience and orchestrate content from multiple backends across multiple front end channels e.g. gamification, recommendations etc. A lot of money there and few open source solutions. (Even something as simple as buffer which just publishes from its backend to major social media channels has very little competition and is quite expensive. I'd imagine something which could simply manage a flow of content to and from social media, sites, apps could do well, even before you started adding in any intelligence around that content and your users.)
My personal website is written in Markdown and loaded & converted to HTML on load using JavaScript. I hard-coded the whole thing a few years ago, and I dread maintaining it so I rarely post.
Now there's a decent CMS that's targeted to Github, I'll experiment with it and seriously consider migrating my website over to Netlify.
I like being able to give my personal website as http://peterburk.github.com because the .com subdomain makes it sound more professional somehow. Non-English speakers will recognise a .com when they might not recognise .io as a URL.
The main problem I've had with regular CMSs (DjangoCMS, Wagtail, ...), is the sometimes steep learning curve associated with them and the less than ideal deployment options (especially if you've been spoilt by Heroku, Dokku et al.).
I like the idea of headless CMSs but currently the only available open source ones that i know of are written in PHP or Javascript (Node.js). Also when you're done building your data models and adding your content, you still have to build/deploy another app to access the data.
Flat file and static CMSs (Lektor for example) are great until you need some server side processing and then you're forced to make use of a 3rd party provider (for form processing and so on).
For me, the sweet spot would be a headless CMS that behaves like a static site generator and can be embedded in my Flask app as an extension.
Python frameworks, owing to the Django CDN-focused approach, tend to make static assets harder than they have to be, so the answer to a better approach for Python in specific is often to setup the static asset hosting more directly in your web server than in your framework. But that too is "just" a configuration/CI/CD issue.
Finally, an approach that is increasingly common is simply to treat your own dynamic server-side assets like a "3rd-party" API: host it on something like api.example.com and let your main website just be the static app served from a static file server/CDN.
I am really curious to see how it can scale with a loooot of content.
I like the way it uses pull requests to handle drafts. A couple of clever build scripts in the repo would make for a pretty sweet deployment workflow.
I'm not super keen on the way it stores uploaded assets though. I understand the benefit of simplicity in only targeting a single API, but it would be nice to target a cloud hosting service (like GCE/AWS storage) for asset uploads.
Alas, for massive sites with lots of content, Netlify's other services plays nicely with other tools. E.g. his AT&T dev proposes GatsbyJS, Contentful, and Netlify in combination [0].
[0]: https://hackernoon.com/contentful-and-netlify-the-dynamic-du...
Unix geeks being Unix geeks would bake their own concoctions, with Emacs, Perl and whatnot. I had one lying around for years, dragged kicking and screaming out of the foggy Interwebs of 1998.
This sort of tools were needed because back then, a static website with hundreds, maybe thousands of pages was not at all unheard of. My first paying gig was for a computer magazine which had, in 2002, just upgraded its website to a fancy dynamic thing (it was a CMS, but the system it ran predated the term, I believe). Prior to that, they had a static website, containing a lot of the articles that had been published, mailing list archives (statically generated -- the mail server that was running it was sitting in the corner of an office and it had a cron job doing the archiving) and a bunch of other things. It definitely had thousands of pages, and a lot of them were hand-written.
If you are willing to forgo a couple of things, like managing relative paths, it is remarkably easy to get somewhat primitive (but sufficient) templating support and management out of nothing but your favourite shell which also produces remarkably clean output. At the end of the day, generating a static HTML page largely consists of concatenating a header, body and footer section, then replacing a number of variables.
The script I use today barely has 150 lines, about a third of which are comments. The only thing I need which it does not do is automatically generate RSS entries, which I think would take maybe another 50 lines or so, but I am just too lazy.
For a while, I also used a GUI script I wrote in an afternoon or so, which would help me with things like creating new pages automatically (i.e. writing the initial boilerplate in the right directory), but I found myself using it very rarely or not at all. I thought I would write an emacs mode for it, but it also turned out I just do not really need one.
If you run a blog with a high posting rate, you definitely need a real thing, but if you post maybe one or two things a week... meh. I have been using this contraption for almost two years now, and while some things require manual intervention, I think I have definitely spent less time working around its shortcoming than fiddling with WordPress and managing the whole LAMP (well OpenBSD-Nginx-MP) thing behind it and whatnot.
There are also things like Pelikan, which I am quite certain HN knows about, which are even more flexible than anything one writes by themselves.
No affiliation with the developer. Just sharing based on relevance.
Also, isn't this against the TOS of GitHub?
Okay, but I was also thinking how easy it would be, for non-programmers. I.e., what would be the easiest way to host it without cost?
> I'm curious why you think this is against GitHub's TOS? We're creating commits and pull requests via their API, which is exactly why the API exists, programmatic interaction with the service.
Yes, but you would be committing data, not code.
Also, I suppose the data would not be not human-friendly to read, so that's another step away from typical github use.
Regarding what we're committing, it's definitely human friendly, mostly markdown, or else json/yaml/toml/etc, nothing crazy. It's a completely legitimate use, same kind of data that GitHub's own Pages product uses.
I wonder though, if a developer needs to find/provide hosting, then why not use a local db (or even a local git-repo) instead of github? With current data storage solutions, installing could be as simple as one line of code.
Oh yes, it's based on NodeJS, so it's hype!
Traditional CMS's are opinionated server side applications that live outside of the site developer's workflow, and are subject to maintenance and a high potential for getting hacked. The advantage is eschewing all of that for a hackable React app that literally lives on a page on your site, and gaining the speed and security benefits of static development.
To better understand the methodology, check out https://JAMstack.org.
The advantage of these tools is that you can get a statically generated site without having to use terminal commands or git. It's perfect if you're setting up a simple site for non-technical clients, then they can manage their own content and you don't have to babysit Wordpress or worry about scaling.
https://www.smashingmagazine.com
https://www.netlify.com/blog/2017/11/21/smashing-magazine-is...
> Here’s a quick way to run a server:
you could just as easily run `python -m SimpleHTTPServer 80` and skip installing anything.
I was excited but you use github and where will that local http-server be deployed?
and where do you put the status site code?
Is that right?
That said, you don’t need a direct integration to work with a service - you could upload files to a service and enter the url into the cms as a stopgap.
Thanks!
We have a lively community on Spectrum if you have questions: https://spectrum.chat/netlify-cms