Differences to Grav

Kirby 2 Solved ✅
20

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:

Mike

4 Likes
21

###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.

3 Likes
22

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:

4 Likes
23

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
24

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:

2 Likes
25

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…).

4 Likes
26

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!

5 Likes
27

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.

3 Likes
28

By the way about discussion that Grav looks like Designer made it and Kirby looks like the engineer made it - that its funcional. Well i have degree in graphic design and i disagree. On contrary Grav looks exactly like something that wasnt touched by a designer. Its horrible boilerplate startup bootstrapy thing.

In Kirby its imidiately clear that every single decision there was made by someone with critical design thinking. Actualy this is Kirbys biggest power. Where in Grav lot of the functionality gets added because part of the community wants it - nobody is able to keep the big picture like with Kirby.

And even in code - most of the kirby API is so well designed. And its sometimes very unconventional for example - no themes, just site folder - its great for custom sites. Every other markdown based cms uses frontmatter and content area - kirby just throws the content area away and uses basicaly just frontmatter - it makes things so much more clear. There is lot of stuff like that.

Love.

5 Likes
29

Maybe I put that wrong. I only made a first impression of the Grav site and some screenshots from the Grav admin. I did not refer to the design of the code.

Anyway…

I look at the Grav site and I see:

  • Modern colors like, purple, green and blue.
  • Modern thin uppercase fonts.
  • Animation bubbles.
  • Animation effects when scroll, hover and click stuff.
  • Everything is big.

All these things I often see when a designer have built a site. Much time has been spent on the “wow” experience. Often that also mean that not that much time has been spent on the important stuff like functions, structure, speed and even usability.

I personally think that the Grav site is “over”-designed. It feels like a show-off for me. The Kirby site is much more “cut to the case”. No need to show-off. That’s confidence! :slight_smile:

1 Like
30

Pish Posh - this was well said. The reasons you stated are exactly why I favor Kirby as well.

31

Thought I’d bring a different perspective here. I’m not massively familiar with Grav, but I know some other systems very well that follow a similar approach to Grav.

I can’t talk about system differences (I’m new to both). But from the instant attraction to newcomers, Grav wins there. Not because it’s better (Kirby feels better when you spend time with both)., but because it sells itself better.

Grav is open source, free and community driven (though it is from a commercial theme provider). Kirby is open source, low cost but lacking community drive (I’ll explain below).

Grav has very accessible plugins, viewable and installable through the admin, Kirby depends on github and a third party site.

Grav has a very clear and accessible list of themes. Kirby relies on a commercial third party site.

Grav has a very cool looking admin panel that could impress a client. Kirby has a nice simple admin panel that is clear to use.

To be clear, for me if it was a choice between these two, Kirby would be my choice. But I bet that most visitors to both projects will initially choose Grav for the reasons above.

The downside to Kirby for me is the lack of encompassing community - the forum community is strong but the plugins are 3rd party controlled, themes is a commercial project. As someone that is used to be very involved, where will my support end up? For example, there’s less motivation to make free plugins or themes (which projects need nowadays) when they are controlled by commercially invested non-Kirby site.

If there is one thing Kirby needs to change, it is to contain it’s eco-system within the Kirby brand. Nothing wrong with commercial themes and plugins, but they should not be Kirby’s only resource.

If Grav ends up winning this ‘battle’, I bet it’ll be more about the eco-system and encompassing fully Grav controlled community than any of the features.

2 Likes
32

I don’t agree. There are 389 known Kirby plugins right now and it seems to be 172 Grav plugins.

Also people really want to make plugins for Kirby. Just look in the forum for the category called “Plugin”. It appears quite often.

Of all 389 Kirby plugins I’ve only seen less than 10 plugins that are commercial ones. I’ve made about 50 Kirby plugins, all free, MIT license.

Looking at the repositories on Github, people really try to help with issue reports and even pull requests.

2 Likes
33

@mikeuk besides what i wrote here Folder and template organisation confusion - that Grav devs do shady things and Grav admin is clearly worse than kirby panel…

  1. Kirby is not open-source. Its a commercial product with benevolent overlords i would hang out with. It has advantages and disadvantages. The advantage is that there is someone deciding the shots (@bastianallgeier) and he leads the project well. Its also his living so he has motivations there. The disadvantages for me are that i am not so eager to hack on kirby and use it for some more experimental projects i would send to the wild.

  2. Grav has bussiness plan too and it is exactly build around commercial themes. Unlike kirby.

  3. We probably have different clients but Grav admin is very ugly. My clients would hate it compared to kirby.

  4. Grav has Gitter channel, its good for realtime discussions but usualy just full of people that cant understand Gravs confusing documentation. Their forum is much worse platform than this one. You cant reliably search forum or the chat. Here most of the time the solution of your problem is already on the forums. You will see threads that are months old to reemerge with additional questions and solutions. I find this much more functional.

  5. I understand the gripes with plugins site - i just dont think people use it that much. Search the forums or github. People are making plugins to solve their problem and then they share it. There awesome people whos plugins i use in every project. I should actualy pay people like @jenstornell @mzur @lukaskleinschmidt (and many others) - but i guess that is open-source and good community.

  6. Gravs themes are mostly trash. You must understand that people using kirby are mostly looking for best cms to make custom websites. Its exactly the reason why there is no theme folder, kirby is for making sites from ground up, you dont need themes. The quality of websites made with Kirby is highly superior to things people make with Grav, because it attracts different people. You will find super famous designers lurking around here. There is certain philosophy behind kirby that these people like.

I agree on one thing, @bastianallgeier and the team might want to think about the branding a bit more. The kirby homepage is fine it just doesnt explain much. The amount of awesomeness you get with kirby-modular + kirby-sortable + kirby-patterns and things like kirby-fieldtoggle is monumentaly immense. No other cms can so easily pull this off. Kirby is this little gem that not many people know about.

On the other hand i would much rather have kirby team to work on kirby and not on their brand :)). Maybe you should hire some of those famous designers.

5 Likes
34

Totally IMO: The main problem with this whole discussion about CMS and comparisons is that we put everything under one big roof.

I think @krisa is right when says this people using kirby are mostly looking for best cms to make custom websites.

I personally look at Grav as an attempt to replicate the WordPress world with a file based cms. Nothing wrong with that. Kirby on the other hand is doing something quite different. I think at Kirby more like a framework, like Rails or Laravel. It’s clearly a different context and a different type of tool but is not something you install, add a bunch of things (themes and plugins) and you’re good to go. It’s just a collections of tools you can use to build something for yourself or for clients.

You can install wordpress without ever have to touch a single line of code and I think this is what Grav is trying to accomplish on some extent.

Under certain aspects the two (Grav and Kirby) are completely different projects run in completely different ways with a completely different audience in mind. There are overlaps obviously.

I’m personally happy with the Kirby ecosystem, I like that is not open source, I like the community, I like the way @bastianallgeier runs the project. I also like that the other Kirby guys and girls are always very helpful here on the forum.

Anyway, just my 2c

9 Likes
35

I agree. I think it looks like this on a scale:

1 Like
36

@manuelmoreale @jenstornell I think both of you hit the nail. The laravel comparsion is precise. We are small (just two) and we also design so we usualy do projects where laravel or rails would be an overkill.

Kirby - Laravel light with admin iterface and filebased database :)).

37

Maybe Laravel is more “app oriented” while Kirby is more “traditional sites” oriented. You can do both with both tools obviously but for example building a personal portfolio with Laravel seems a bit overkill. Anyway yeah I agree with @jenstornell and his scale.

38

I’ve tried Laravel and I thought it was like a complicated version of Kirby without the Panel. I did never really got it. Kirby is a kind of simplified Laravel in the core and on top of that we have Panel which is kind of the WordPress element, the UI that is missing in Laravel.

In my world: Laravel Light + WordPress Light = Kirby

39

As someone who has tried an awful lot of CMS systems, I can honestly say there is no such thing as the perfect one. There is only the perfect one for the current job. Some CMS systems are suited better to certain types of work. I don’t rate Wordpress. I have no idea why it is so popular, other then it was in the right place at the right time - there wasn’t much competition when it launched.

I came at Kirby from Textpattern which imho is the just about the best CMS out there, albeit the underdog. I moved to Kirby because the TXP development progress stalled to security patches only for a couple of years, but I think thats picked up now. I got frustrated waiting for them to re-develop the core of the CMS to a point they could get back in track for new feature releases and advancements. For me, Kirby is close to Textpattern. And there lies the problem - Kirby will do well and grow if time is given to it. I still love Textpattern and will go back to it. Right now though, Kirby is the right tool for me because there is an active dev community and constant plugin production and decent documentation.

I have three go to tools for sites. For small ones (less then 10 pages) or one page wonders, I use a custom static generator I built with Gulp and Metalsmith. For medium sites up to 50 pages, Kirby is a good fit. For larger sites, I’lll go with Textpattern.

To many developers waste so much time agonising about wether they are using the right CMS. The fact is, it is the right tool if its a fit for the project. If you spend more time managing the tool than building the site, its the wrong tool.

I installed Grav aw while back, poked around… then I deleted it and went back to Kirby. It didn’t grab me.

Just remember the Kiss principal - Keep it simple, stupid :slight_smile:

3 Likes