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.
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.
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
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.
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. :)
(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
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.
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!
