Differences to Grav

I just got some answers to some of the things I did not fully understood:

  • Excellent conceptual/design model.
  • Self-contained Skeleton format.
  • Powerful modular content support.
  • Custom content type definitions.

This thread has me a little concerned. :wink:

I’m probably not keeping up with current events, but I take it if Twig templating is offered as an option, it will take the form of a plugin/extension as opposed to being baked into Kirby’s core?

One of the reasons I like Kirby so much is that there is no template engine. :slight_smile:

1 Like

Template engines are indeed and luckily optional.


This is good to know! :smile:

Just to clarify my previous post, not having Twig or Symfony as dependencies is a big selling point. And regarding the panel, Kirby appears to me as a great relief for users.


Kirby 2.3.0 Beta:

The template engine is now a component.


Just read about the new component architecture in the 2.3.0 changelog and this looks like an excellent solution.

Users can now stick with Kirby’s default PHP templating or integrate the template engine of their choice.

I think this is going to keep everyone happy. :smile:


IMHO, Kirby’s simplicity - both for the developer and the end-user - is its biggest selling point. On the development side, the simplicity is seen when a new developer joins our team: they can get up-and-running with Kirby very quickly, and there are no separate frameworks and libraries (Twig, Symfony, etc.) to learn - just Kirby.

On the end-user side, we see it whenever we teach a reluctant client how to use the panel on their new site: they are always pleasantly surprised at how simple and intuitive it is to edit the content on their site, and we have won contracts on that basis alone.

The single point where Grav is - in my view - superior to Kirby, is in its implementation of PAGE SECTIONS - something Kirby doesn’t really have. I just checked the 2.3 beta, and Page Sections are not mentioned anywhere…

It seems to me, however, that Grav has gained much momentum due to its Open Source - i.e., free - status. This has helped it quickly grow a community, and gather interest from developers who have already created many plugins and templates for it - in a very short time. Whether this growth and enthusiasm continues, remains to be seen. Launching a ‘paid’ version of the admin backend for Grav is a big, risky gamble by the Grav team. In the past, many good Open Source projects lost their strength once the financial side of the enterprise comes out…

But as a Kirby fan, that doesn’t bother me one way or the other. If Grav fails and dies, it will be a shame - it has already instilled some innovation in a corner of the CMS world that was starting to get stale, and it deserves its place. If it survives and thrives, it will be a good thing for all: it raises the bar for future projects, and perhaps it will even prompt @bastianallgeier to implement some new features - such as Page Sections - that we hope to have! :wink:


I don’t want to comment on the details here. I think you can all test this on your own and see what you prefer.

But I wanted to leave a few thoughts anyway.

Competition can be sometimes really tough and nerver-wrecking as well es motivating. Personally I started trying to think as little as possible about competitors a couple years ago. I feel that it takes away too much energy and focus from your own stuff. That’s why I hardly ever check out new content management sytems nowadays. I prefer to skip roughly through their set of features and that’s it.

Instead I try to get inspiration and ideas from two major perspectives:

1. Clients

I still work on around 15-20 client projects per year. Most of the time I have direct contact with clients and don’t work for agencies. 90% of those client projects are based on Kirby and I consider this a very elemental part of the work for Kirby. I want to know what they need and what their difficulties are in maintaining their sites. Kirby features are massively influenced by their feedback and watching them use it on a daily basis. Even after 15 years of working with clients, I still get to learn so much through the various projects and processes and it always ends up in new ideas and improvements.

2. The web

The web has become extremely important in my life. Not only because of relying on it financially, but also through the possibilities it has given me and the ways it connects me with so many people. I care deeply about it.

I feel like we are just getting started with really understanding the web and becoming professionals in our craft (I hate this word, but couldn’t find a better alternative) I love how it is so multi-disciplineray. To succeed building stuff for the web, you have to be interested in technology, design, communications, culture, marketing, business and so much more. I love to see how independent designers and developers as well as companies and agencies start to use this medium more creatively in the last years and how people produce really high-quality content for it. But I’m also shocked how much there’s still going wrong, because too many people have no idea what the web really is, what it means for us and what it needs.

There are people in our industry, I really look up to. People like Jeremy Keith, Jeffrey Zeldman, Stephen Hay, Dan Mall, Chris Coyier or Sara Soueidan. But also Designers like Erik Spiekermann, Brendan Dawes, Oliver Reichenstein or Stefan Sagmeister and so many more. I’m inspired by thoughtful work and by creating high-quality projects year after year. I’m inspired by those who seem to understand what the web is and are interested in the future of it and not just how to reap it most efficiently.

Working for the web myself and watching all those people talk and write about their experiences, one point always stuck out. You can only come up with high quality work, if you consider all the parts involved. Design is not just the visual part as well as development is not just the code below it. Everything is intertwined in a project and every aspect is important. If you are serious about what you do, you are not just a frontend developer, or not just a designer or a backend dev or sys admin. It’s about being interested in all those aspects and being able to focus on the outcome for our users — the product.

For Kirby, my biggest wish has always been, to build a tool that brings designers, developers and clients/editors together and help them focus on the final product — a great, individual website with high-quality standards.

People sometimes ask me about Kirby’s roadmap and I think this is closest to a real roadmap: become better in achieving this for all parties involved. I wish that the team as well as Kirby’s community is moving forward by getting inspired and learning from all sorts of disciplines in order to build better stuff for the web.


I still work on around 15-20 client projects per year.

That’s a big strength I think. That means that you get the same perspective as us who build things in Kirby as well as your clients. Then you probably take better decisions. They are based on what is needed and probably not of what is the most fun to build.


I’ve looked a little more into Grav vs Kirby. When comparing websites they are really different.

Grav has animations, colors, fancy fonts etc. It looks a bit like a commercial WordPress theme. It feels like a designer made it.
Conclusion: Made to be beautiful

When looking at Kirby I feel it has a touch of industrial design. With that I mean that the font is not made to be beautiful, it’s made to be readable. The slideshow on the first page is lightning fast. No animation.
Conclusion: Made to be functional


One interesting feature that I found reading somewhere is that Grav saves important stuff in headers. When using a function to get all pages with a special category it will only read the header. The content is in the body and will only be readed when needed.

I don’t know if it would be good for Kirby, but an interesting idea for speeding up.


What I like about Kirby docs is that it’s often easy to understand. Lots of examples and texts.

Grav has a kind of documentation tool that I like at first site:

It would never replace great examples and texts, but is good to fast find a function to see what it takes for arguments.

Both is good to have. Maybe generate a tool like that from inline documentation in the code?


Grav seems very structured. It feels like they are using yaml for almost everything. I would probably love that… at first… then I would lack the possibility to add logic.

Kirby uses php more.

Half way to WordPress

Grav has alot of features it seems. It has themes and you can activate the plugins right from the admin.

I feel like Grav is half way to WordPress. It has more of WordPress than Kirby. More bloat, more dependencies, more features.

Kirby has just what I need, often just when I need it. Not more than that.


[quote=“fvsch, post:2, topic:3795”]
and I don’t find Grav easier to develop with for now[/quote]


I’ve been working with Kirby for years.

I gave Grav a try with two client projects after it reached 1.0, and I just went back to Kirby, for the next 5…

Time is golden, setting up Kirby (thank you for the CLI tool), models, controllers, etc. is blazing fast so I can spend most of the time on the actual website development, and still give clients a very nice and customized tool to work with.

I’ve used almost every single feature in Kirby and I don’t think it’s missing anything compared to Grav.

I love Symfony and modularization of things (I work with node.js a lot), still I don’t think that’s a weak point in Kirby. The toolkit is solid, and also @bastianallgeier has shown no fear in going this way… (third-party components in the CLI tool, now using namespaces in 2.3) but, IMHO, in a very calm and thoughful way, which gives you confidence… like the team knows what they’re doing.


Still building a first site using Grav. For now I’m finding it a bit over-engineered, as if the project’s goal was to build a WordPress replacement and an ecosystem of plug-and-play plugins and themes, with all the related cost in complexity (extended configuration, conventions to follow). The Grav developers are from a company that does a theme framework for Joomla and WordPress, and it shows (a little).

So there’s a bit of a learning curve, and it doesn’t help that the documentation is not so great. I mean it’s decent, close to good, but still lacking on a few points. Some documentation pages are very long and don’t have a Table of contents, and the search can result a page as a result but it can be because of one mention at paragraph 45 and you have no way to know that. Also it’s lacking a proper “Reference” index (like Kirby’s Cheat Sheet), only having an automatically generated API index (better than nothing but useless if you’re not a dev).

Also sometimes it’s just plain bad writing. For instance if you want to do templates you must first understand that the doc for that is in the “Themes” section. Okay, that’s a bit of jargon but not a big deal. Then you read the page about “Theme Basics” and it explains how to create twelve folders and ten files, with extensive YAML configurations and a big code example for a theme’s PHP class… which is totally optional they say, but it’s right there in the middle of the “Theme Basics” page, before the smaller section on templates. Now I’m sorry but I’ve done some technical writing before and that’s just bad information architecture. -___-

Right now I’m trying to build a simple, one-level navigation (it should list three pages). I had no idea how to do that after reading the Theme docs. Trying to adapt one code example I tried {{ page.find('/').children }}, but as it turns out it gives me the children of the home page. Then I read some more documentation pages but the relevant info was not there or I missed it (their documentation for Twig templating is messy). Then I clicked “API”, hoping for a reference index, but it’s the generated documentation for their PHP classes (since I’m a developer I will probably be able to find what I want there, if it’s complete, but even that is not a pleasant experience).

That’s on the templating side. Haven’t really worked on connecting the admin plugin yet.

Grav looks like a good tool, really. They’re also trying to do more, which is commendable but comes with an even stronger need for great documentation, and on that front they’re not there yet.

PS: for the people who were interested in Twig templating in Kirby, I built a plugin for that. And for those who don’t want Twig or any templating system, don’t worry, nothing is changing in Kirby on that front.

1 Like

I already answered over on the Grav Forum and tried to shed some light on things I like about Grav.

In general I want to say that both systems are really nice to work with. That’s my subjective opinion based on having built several sites in both systems, Kirby 2.x and Grav 1.x, even migrating/porting on from Kirby to Grav. ;). I never made it into the guts of both systems, but used lots of the functionality. I tweaked the systems to my liking with blueprints/skeletons, custom themes, fields, plugins and more, to cater for my client needs.

At the end of the day, I’m happy to have both systems as options in my toolbelt. I used them as the tools they are, not because of marketing or fellow developers/desingers or herds say so. One project or client feels better with Kirby, while another has a need that I can better combine with Grav. Both systems are actively developed.

I must confess that Kirby looks more polished and clean, compared with Grav Admin 1.0, but it’s something that will change with Grav Admin 1.1 and even more with Pro.
Also, the Grav website and documentation need improvement, but that’s something each project needs to tackle and the Grav team is aware of that too. As far as I can judge, both teams are really responsive when it comes to issue handling and improvements.
Both have a solid vision and concept for their systems. Grav being the “youngster” gets a ton of “please implement this and that” to make Grav look and behave like ABC or XYZ. While Kirby has already established itself and speaks towards a certain kind of developer, designer and client. Grav has to find this niche/position.
It’s true that the Grav team wants to “sell” their Gantry Theme Framework. Yes, there is already a Plugin for Grav, but hey, you don’t have to use it and the same is true for the paid Admin Pro plugin, once it’s released.

And don’t forget systems like Statamic 2 that in the end of March 2016 or a Pagekit 1.0 in April. All available to help us bring the internet to life and help our clients and us to spread their message and visions. As long as there is fair competition I’m pretty sure, no matter what system you use, you will see improvements over time, and if you don’t see them, just migrate to another tool. It’s not rocket science isn’t it? We are not talking Typo3 or Magento here right?! :slight_smile:



###Played with Grav for the first time, this weekend.

I did know it’s existence, but did not consider it as an “alternative” for Kirby.

Most of my clients want WordPress as the CMS “to be” (don’t care if they’re right or wrong on this; it’s their decision).

But when someone doesn’t want WordPress, Kirby is the CMS of my choise.

I have about 100 project per year and I’m pushing Kirby as hard as I can.

But it’s always good to enlarge your horizon, so I decided to give Grav a try.

In short;

  1. I don’t care Kirby cost money and Grav is free; my clients always buy a license and the amount of money is peanuts, when you see the costs of the whole project.
  2. Grav looks professional, but Kirby also does. I like the minimalist approach of Kirby, but also like the (colorful) GUI of Grav.
  3. I like the idea that Grav is powered by a community, not a single person; don’t get me wrong - I do not mean this personal.
    But when a client chooses for Kirby, it’s whole online strategy depends on the hart and soul of one man; Bastian… This can be tricky when creating real large projects.
    As we speak, I am building an online survey - powered by Kirby, for a company that wants to use that survey for at least two years (and offering it to about 25.000 clients).
    They asked me several times about the update-sequence / reliability of Kirby; is is safe, will it be there in two years, who is giving us support, etc… This is much easier to answer when a team is developing a product, not a single (brilliant!) brain
  4. Grav is too loaded; like I said - I mainly use WordPress, but when I do not use it, I want a real alternative;
    Grav is like WordPress for me… themes, plug-ins, etc… it’s too much out of the box (for me personal).
    So that’s why I stick with Kirby; it’s fast, clear, not bloated… it doesn’t do much out of the box, and I like that. I build every function I am missing myself, keeping code and performance clean

This is just my thought, my English isn’t perfect - so sorry for any mis-understanding.


Well, Kirby is not developed by a single person but by 5 people. And then there are lots of contributions from the community, so I think that counts as “team”. :wink:


I didn’t know that about 5 people were developing it.

“Of course” I do “know” your name and Sonja’s but I always thought Bastian was write the code all by himself.

Anyhow - good to hear Kirby is team- and community powered.

Grav has it’s strong point - like Kirby does, but I really, really appreciate the fact that Kirby is “naked” when you first install it.

Out of the box, it does it’s job… when you create some cloths yourself… it’s the best model ever.

1 Like

I agree. One of the main reasons I now refuse to work with Wordpress, is because if you give clients the ability to instal plugins and themes, they will. And they will break your site, and make your site insecure. To be fair, both in Wordpress and Grav there are ways to disable these features, so that clients will only have access to a more simplified panel, but in both cases, it’s a chore - and one that we don’t have to do with Kirby.

I found that clients love the simplicity of Kirby, and I have won jobs because of it. When clients tell me that they’ve been quoted by a competitor on a Wordpress site, I smile and tell them they’re certainly NOT getting a Wordpress site from me: they’re getting something truly professional, stable and easier to use. Kirby now actually helps me win the sale. :wink:


So I finished my project with Grav.

All in all it’s a pretty good tool. The admin plugin is limited now, so Kirby’s admin would be an easier sell to clients I think. The static content, page metadata (fields), traversing and routing capabilities are good (though a bit under-documented). The modular pages (non-routable pages which are generally used as sections of a parent page) are a nice feature — the actual feature is that each “module” can have its own template (I think the same thing would be doable in Kirby with a plugin, by the way).

My main issue was the documentation, which made the learning curve not so bad, but still slow… lots of trial and error, and difficulties to find the right information (when it was even there).

Compared to Kirby, Grav might also feel a bit over-engineered (when you tout “we use Symfony components!” as a selling point, that’s kind of expected ^^), and the focus on distributing themes and plugins adds one layer of complexity (which Kirby basically skips). In Grav a lot of config can end up in your page’s metadata, because that metadata will then be used by themes and plugins; in Kirby you would do more things in your templates and/or controllers, not relying on third-party “themes” that you can switch in-and-out (ala WordPress/Drupal/etc.).

A few things I liked:

  • The built-in image processing and caching is nice.
  • I did like working with Twig templates (but I’m used to Twig, Django/Jinja, etc.).
  • Page collections with built-in filtering on dates + the pagination plugin. Not perfect but really helpful to have easy pagination support almost out of the box.
  • The admin plugin views for editing the main config files. I thought this was awful at first, but you can create a user which has not access to those files, and it turns out the web view is a nice way to discover settings that you can use to tweak or optimize your project. Live documentation. :slight_smile:

Some things I have more mixed feelings about:

  • When you want to do something not self-evident, you have first to check if there is built-in support or a plugin for that, then try to use the right YAML settings in your global config or in your page’s “header” (“fields” in Kirby parlance), stumble through documentation that is often limited or too complex. If that doesn’t work, maybe try to do it in your Twig templates, using the page object and collections and some underdocumented methods. And if you’re stuck after that, can you just write some PHP? Well, after finishing the project I discovered that the Grav way to do that is to write a plugin. While in Kirby you can use PHP in your template (not recommended for logic but if you want something quick and dirty, you can do it), in a controller or in a plugin, in Grav apparently you have to write a plugin which must be a verbose PHP class (very much like Symfony stuff). The main plugin tutorial from the docs actually describes what I would call a controller, so that’s not very intuitive for me.

  • The documentation for Grav is rich but it can be hard to find what you want. Since Grav is young, a few details are outdated. It lacks a proper reference (especially for things like traversing content and filtering, I had to look at the PHPDoc-generated docs, aka not really docs; when you have to read the comments of class methods, you’re not in friendly doc territory anymore). I also find the regular doc a bit hard to use (long pages without table of contents or sub-headings showing up in the search).

  • The user community seems to have less programmer types, judging by the average questions in the forum. A bit more like your usual open-source CMS, WordPress etc. It’s great that it helps more people build websites, but that means forum answers can have a lot of noise when you’re looking for solid technical answers. On the flip side, the developers of Grav seem to be really reactive in the issue trackers, and often answer questions in the forum.

  • Customizing the form views for the admin plugin was alright, I managed to do what I wanted mostly, but the YAML conventions used for that were very verbose and had so much nesting… it was hard to get started.

  • There’s a built-in asset pipeline, which I didn’t use because I didn’t need it but if you use plugins that output CSS or JS code to work you will need to use it. It seems well done and useful, but asset pipelines can be a mixed blessing (losing some control over what you output, introducing a bit of complexity…).


I have just given Grav a short spin on a Windows Xampp test install. Not a pleasant experience. For starters, I had to google 30 minutes until I found I had to make a setting in OpenSSL just to open the config panel.
The admin panel seemed overloaded with options, and for some reason, following the trends of making fonts and inputs bigger and bigger. For crists sake, my 8bit Amstrad had more lines on the screen at once than this CMS… Yes, I am able to manage 1200 pixel or more, thank you.

The template and CSS in default install is a huge labyrinth in first install. For a novice, it’s next to impossible to figure out how to do simple things, even add a sub menu.

So in short: the learning curve is too high. In that case, it’s simpler to stay with Wordpress or something similar.

Kirby does things just right, in my book. It’s flexible, yet light weight. And possible to get an overview of.

Keep up the good work!


My two cents here. We tried to use Grav on one nonprofit project where there is lot of technical people and they wanted everything to be open-source. We made the site in Grav but after some time we hit big wall and that was the admin interface.

Grav is completely fine when you use it just as rendering engine of your markdown. It has even some nice advanced features compared to kirby - defining colections of pages in content pages and especialy creating custom taxonomies.

The admin is unfortunately lacking. I mean you get all the similar fields and stuff but there is major problem when you want to limit if some template can have children pages or what kind of children templates it can use. Its because in grav admin you are putting pages into their place -> you are setting the parent of the page all the time. There is no way to go to deeper levels of the hiearchy to just see your blog folder. It also means when you have 50 blogposts and you want to create child of page alphabeticaly after your blog folder, you have to scroll through 50 blogposts because when you create page there is flat hiearchy.

I think its unusable on even basic blog sites. And imagine your client that will want to do blogpost and he will have to remember not only where to put it but which template to use because yes when picking templates you see all of them.

The funny thing is i tried to push this in the community and i think the lead devs are deliberately silent about it. The reason for it is that there is very soon going to be “Admin Pro” which is i asume gonna fix those issues. Of course admin pro is not going to be free and frankly thats fine… but then why would i use Grav over Kirby when they are basicaly same but Kirby is just much much more mature?

And you guessed it. We rewrote the Grav site in two days in Kirby and came home.