Differences between Kirby and Grav?

Archive
1

It’s the first time I’m here.

I’m using Kirby (https://getkirby.com/) right now but are curious about what the differences is to Grav. I know I could go through all the docs to find out, but maybe someone can just give me some hints?

3 questions…

  • Have you used Kirby before? Why did you leave?
  • Why would you choose Grav before Kirby?
  • What would you want from Kirby into Grav? What are you missing?

I already know that Kirby costs money, but that’s about it.

Thanks in advance!

2

I asked on our chat to ping people that used it in the past to reply here :slight_smile:

3

Hi Jens,

I use(d) Kirby 2 on some smaller client projects over the last year and was/am satisfied with it. I had a look at Grav out of curiosity only, not because I was really missing a feature in Kirby at this point in time.

I then migrated a site from Kirby 2.x to Grav 1.0 over a weekend and liked the process and results. What I like about Grav is the backend, the “engine” that is closer to the PHP I deal with in other bigger projects. So I felt more home from the start. I could say it’s closer to current PHP programming best practices, but that’s somewhat subjective I know.

So, one reason to choose Grav over Kirby is that I’m using tools I already use in other PHP projects (TWIG, Composer, CLI, Symfony Framework goodies).
I also like the idea to extend the Dashboard in Grav Admin with plugins, something that is not easy or impossible to do in Kirby without hacking Kirby Panel.
What got me confused at the beginning was the way Grav uses it’s YAML Blueprints to create custom content types, configuration and define themes or plugins. After reading the docs and chec king sample code it clicked and felt really nice and rewarding. As a side note, Blueprints will be getting even better with the Grav 1.1 release later in April 2016.

What I’m missing in Grav so far is the media management of Kirby. I loved that I was able to edit media files in Kirby Panel, something not possible in Grav Admin 1.0. This problem seams to be dealt with in Grav Admin 1.1 (Pro) though. So with this problem out of the way, and the upcoming improvements, I think I will stick with Grav from now on.

I also checked Statamic 2 based on Laravel 5.1 and with Vue.js for their Control Panel, but was not impressed about the speed, something I really like about Grav too. It’s really fast out of the box!

If you have any more questions, feel free to ask and we’ll do our best to answer them for you. :slight_smile:

Mike

4

Hi Jens,

You might also find some info re: Grav vs. Kirby in this blog post helpful: http://hibbittsdesign.org/blog/posts/2016-02-03-why-I-chose-Grav

Cheers,
Paul

5

Good answers! Thanks!

6

I just want to add that there is widget support in Kirby as well https://getkirby.com/docs/panel/developers/widgets and a CLI https://github.com/getkirby/cli

7

Grav feels much more thorough, too. In Kirby, the core features are basically built by a couple people; in Grav, they’re built by many times that. As a consequence, Grav natively covers more usecases than Kirby (also, bugs and issues seem to be better accounted for).

One notable bug that keeps on annoying me with Kirby: thumbnail handling in Kirby is really prone to fucking up and plainright not working (in spite of good syntax of course). This is pretty bad for production. I recently 90% built a site for a client in Kirby and frankly I’m thinking of just switching to Grav and delivering a Grav installation simply because of this one issue.

I’m currently going through Grav’s documentation and there have been many times where I went “oh, neat, this is a feature I would have loved to see (in such a simple implementation) in Kirby”. For instance: taxonomy collections and page types are two things that are annoying as heck to code in Kirby, and trivial in Grav.

Also, Kirby handles each field equally in its content files (text: and title: are at the same importance level). Grav imposes a separation between the headers and the content, and offers a huge amount of predetermined headers you can use as standards (instead of reinventing the wheel every time you want tags).

Honestly I’m not sure there are many good reasons to stay with Kirby at this point (beyond gratitude for Kirby or whatever) and this situation will only get more black-and-white as Grav’s open-source development quickly stomps Kirby’s slower commercial development.

8

I’m not here to start a war, but I can inform you that I started the same topic in the Kirby forum as well: