A bit of context as there seems to be confusion: building a git-based website with content as markdown / yaml / json / etc is a pretty pleasant way to work. Changes are fast and easy, and branching and rolling back works really well. Git is really good at what it does for both code and content.
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 still don't fully grasp it. What's the advantage here? Besides the fact that Netlify provides a CDN when you decide to use them(which granted can be very helpful to some people).
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.
Netlify CMS is a self-standing open-source project. We maintain it and are puring a lot of resources into it, because we think it's really important there's a good open-source solution on the market for projects built with static site generators.
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.
> The basic idea is that's its an editor friendly content management UI for persisted data stored in a GitHub repository.
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?
Preface: Netlify is a platform that enables static development, while Netlify CMS is an open source project created by Netlify.
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
It has 18 lines of configuration. The actual CMS (cms.js/css) has almost 2M characters.
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.
Post author here: There's definitely no shortage of options - the CMS exists to fill a very specific trifecta that we believe are critical for modern static development. It is:
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.
Uhh, what? It being written as a single-page React Javascript app means that if you're a web dev with React under your belt, then it won't be tough for you to jump in and extend the CMS code[1]. And it's licensed under MIT, so you can fork and do what you will with it.
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 :)
Yep, the source of a widely useful CMS will always be non trivial - but you have to build your site inside of a traditional CMS, where it lives on a server. Netlify CMS is a page on your site that creates and edits markdown and data files. The difference is real :)
The title of your your post crosses the boundary from promotion/hype to just being a bald face lie. Would you consider changing it?
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
I definitely weighed that out, and I appreciate you mentioning it. I settled on this title because it's accurate for the implementor, and because folks are having a hard time understanding the benefit compared to a large solution like WordPress, as evidenced in this thread.
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!
> because folks are having a hard time understanding the benefit compared to a large solution like WordPress, as evidenced in this thread.
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.
Yeah, I was also hoping for a CMS in 18 lines of code. You could probably just about build something useful if you get opinionated enough, such as sending requests to https://cdn.rawgit.com, parsing Markdown (if you don't count libraries -- otherwise, cheat by using GitHub's Markdown API :)) and wrapping it in an html file (possibly also from rawgit).
Or, you could build a CMS around https://stackedit.io. It can apparently sync with CouchDB.
And its powered by Node and V8, so we've got another 500,000 lines of code there. Ah, but those are actually written in C++, so we need LLVM, another million lines there. And a rendering engine for the frontend, Chrome, Firefox, etc. Microcode in the processor responsible for executing assembly instructions?
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.
There's nothing pedantic about what I wrote. When people say software X has Y lines of code, they're always talking about the code written specifically for that program.
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.
Please don’t run around seeing conspiracies when a more likely explanation is that there are non-trivial numbers of people who hold opinions different from what you expect.
Shouldn't have said "systematic", didn't mean to insinuate a collaborative effort. Silently down voting is what I'm pointing out, as it tends to be non constructive, I don't think I'll ever get used to that.
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.
Since you have a real world example of this solving your problems, I'd be curious to know if having the CMS funtionality available in an Electron desktop app, using a VPS (e.g. Digital Ocean) to host your metalsmith instance, and fronting it with Cloudflare would be of interest?
I would have to agree with Operyl. I don't have a reason to use the CMS in a desktop app and the site will be pretty low traffic, probably 20-30 unique visits a year or less, and all of it local so I doubt cloudflare would be needed. And I would netlify would have something similar protecting their servers.
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.
Once you’ve made the switch to a static front end (eg. a static react front end where the browser loads one file each of html, JS, and css and after that it just exchanges JSON content packets with the server), Netlify’s static content pattern starts to look really natural and a much more modern cloud architecture than old school Wordpress servers running half a million lines of PHP on SQL backends.
After trying it our from a mention on here, feels almost like heroku but for static sites. Maybe a bit simpler problem domain, but same feeling afterwards where having to go back to the old way just feel archaic.
(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.)
The irony is that this is the model which DB-based front and back end integration replaced, and for very good reasons. If you've been working with CMS's for over 10 years, this approach looks archaic and inflexible.
Static pages with placeholders dates back to Perl and the start of PHP. The original CMS model was to separate back and front end e.g. Vignette (and TOGAF guidelines ftm). DB CMS's used to generate static pages for display.
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.
Thanks for that, very helpful. I do wonder if you may be seeing the new architecture as too rigidly identical to the old architecture, specifically in that the templating/page personalization can now be easily moved to the front end rather than needing to be handled on the backend like in days of old. This front end rendering approach allows the browser to pull down one JSON blob of possibly dynamically extracted user-customizing data (first name, last name, items in their character loadout, whatever happens to be relevant) and one or more JSON files of static template content, fold the JSON blobs together exactly as one would have done on the server, and present a fully customized page to the user in a way that accomplishes the goals you articulated (I think) while keeping the templates static and their delivery serverless, fast, and cheap. Are there things you see that I’m missing in that architecture? (I’m admittedly new to these aspects of the CMS world but trying to understand the issues)
I just don't think it's a new approach at an architectural level and I don't see any gains (unlike say, AWS Lambda).
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.
Admittedly naive analysis here, but it seems like there are two distinct classes of issue you are raising. The first class of issue is plugin module availability, the second is data model/schema/information architecture. I may be wrong, but I’m guessing the flaws you saw in the National broadcaster’s system were more at the schema/information architecture level than the plugin ecosystem level, particularly given their willingness to throw devs at it (a bad schema deeply baked into a system is much harder to patch than a lack of extension modules). Now that we’ve reached an era with at least three CMS backends with heavily battle-tested information architectures (I’m thinking WP, Drupal, and Joomla, and there are probably others) it seems like a venture funded startup like Netlify should be able to propose a viable information architecture (or at least encourage/show customers how to implement one if their system is too flexible to enforce a good IA). Once there’s a good IA in place, my (admittedly naive) assumption is that the library of npm packages becomes the front-end equivalent of the WP store and on the backend you always still have the opportunity to procedurally generate any content or templates you want (potentially using WP or drupal or whatever as your JSON constructor kit). I totally hear your concern that random devs building CMS’s is a bad idea. That said, a well funded competitor going after WP with a “more modern” and “more secure” architecture (and well designed information architecture) doesn’t seem like a dumb idea to me given how much money WP makes and how many objections many people have to its legacy constraints.
The business argument isn't there. Drupal for example has over a decade's lead and a developer community and pace of innovation that no private company of any size can match, let alone a startup. They are now competing with the last man standing in enterprise, Adobe. Even IBM are MS aren't really in the space any more. For business lower end, you cannot compete with Wordpress for price and developer availability. For personal, you would have a very tough job to even catch up with the mindshare of Wix and Squarespace, let alone exceed the products sufficiently to take their market, which is super low value unless you can bag most of it. You mention security a few times - do you think any privately funded CMS has a dedicated security team covering both core and community code as Drupal does? I will bet you a bridge that a private company's development resources get diverted to adding features in favour of security to sell the next upgrade.
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.)
I like it. Wordpress charges extra for plugins, Appspot is blocked in China, Rhcloud closed down, and I registered Github pages while they still gave out .com subdomains.
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.
OpenShift.io is "Currently waitlisting registrants." and I think it will only give .io subdomains, not .com subdomains.
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.
Disclaimer: I'm and python and go(lang) developer.
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.
Why not both? Most frameworks (including Flask) already have static file/page tools/middleware. Just set up the static file hosting part of your framework. At that point it is "merely" a CI/CD issue to compile your static site and deliver it to the static directory your framework expects.
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.
As an alternative, I've found a lot of non-technical people are very comfortable using http://prose.io/ to edit markdown files. Saves are GitHub commits.
This is awesome. I haven't tried it yet but is exactly what I've been looking for. I'd like the ease-of-use aspect of CMS to provide to non-technical users with the flexibility of a custom static site generator. Wordpress is super bloated and hard to use for end-users these days. Maintenance, etc is all a headache. Other simple CMS's are paid services and usually don't give a lot of flexibility. Netlify seems like something I could use to make websites to users and not have to worry about too much maintenance / cost afterwards.
I imagine it would scale about as well as the git* API backing it up, given that the content list etc. are all pulled from the git host's API (Github in this case).
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].
A very long time ago, there used to be these programs that helped you write, maintain and manage static HTML websites (this was back when CGI was more or less a recent invention, and the only way to have access to it was to run your own server, which was not an option for everyone). It was basically a WYSIWYG HTML editor a la FrontPage (oh, the horror!) + an FTP client + some basic version control and project management all in one solution.
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.
Cost isn't the big issue, there are plenty of ways to do it for free. 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.
> Cost isn't the big issue, there are plenty of ways to do it for free.
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.
It's meant to be implemented by a developer, but it doesn't take much skill, and can be hosted for free on a number of services. I was a champion of Netlify well before I became an employee, so I still shamelessly plug them as the way to host static.
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.
The CMS is specifically made to work with Git, because so many developers are already using it for the rest of their site development. That said, it's not impossible to write a non-git backend, but it's heavily bent that way at the moment.
I don't understand the goal. So it's a server CMS, which stores data in Github. What are the advantages of a full-fledged CMS like WordPress? Over a static site generator like Jekyll?
Post author here: As others said, it's a CMS for static site generators.
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.
This doesn't replace Jekyll, it's a CMS for those sites.
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.
It's actually great for highly complex, high traffic setups as well - Smashing Magazine was a conglomerate site using Wordpress, Kirby, Rails, and Shopify, and are now entirely static (10x faster literally) and using Netlify CMS for content management. If you haven't checked out their site lately you should!
Exactly. Something you can setup for someone computer savvy in marketing to make changes without having to go through an engineer, while preserving all the other good aspects of static sites that you mention
Its actually a "client" CMS cause it runs client side. Now say that you keep your content on GitHub and your site is hosted on GH Pages. You can include this CMS as a library on your site, serve it from GH Pages like the rest of your site and have it communicate with GH to manage your content.
GitHub is not managed by you and by hosting a static site on GH Pages, you really have no server. The CMS that the auhor refers to is a frontend client-based library that you include in your static site code and communicates directly with GitHub to manage your content. It's a UI for GitHub.
Exactly and this is the purpose of a static site generator. The content is not related to the actual site representation. In the case of the WP, instead of storing the content in GitHub and generating a site to be hosted on GH Pages, you are storing the content in a WP server and generating a site to be hosted somewhere else.
I guess this is also ok with GitHubs TOS since you eventually use their built-in features for static site generation to serve your content instead of abusing the Repo itself as a CMS.
Yep, we're managing Git content through their API, which is exactly the kind of thing the API exists for. There are working PR's for open for Bitbucket and GitLab backends too, those will be out soon.
Asset storage integrations are supported, but it’s very early. That’s one area where we expect to strengthen after 1.0 drops in December.
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.
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.