Differences to Grav

The CMS Questions
1

Don’t worry, I have no plans to leave Kirby.

I asked in the Grav forum if anyone used Kirby before and why they switched to Grav. I think it’s a good way to find out possible weaknesses with Kirby, where Kirby can improve.

What Grav has that Kirby don’t (not my words):

  • Admin engine is closer to PHP best practices.
  • Admin is more customizable.
  • Uses Twig, Composer and Symfony Framework.
  • Excellent conceptual/design model.
  • Self-contained Skeleton format.
  • Powerful modular content support.
  • Custom content type definitions.
  • Documentation quality.

What Kirby did better was (not my words):

  • Edit media files in the panel.

I don’t agree or disagree with anything above, I just copy what they said. However, I did remove some stuff that I know that Kirby already have.

It may look like Grav is the winner here, but this is from the Grav perspective. We could probably come up with tons of stuff that Kirby does better. I think that the feature that Kirby supports PHP templating alone does Kirby to a winner. I never get why it’s beneficial to add another layer of abstraction like Twig.

Have you tried Grav? What are the differences?

I also think it’s good for the crew to look how other cmses does things, but it’s probably done already. Both Kirby and Grav uses get in their domain and both have blueprints.

2 Likes
2

I’ve worked with Kirby and started a project with Grav. Early impressions:

  1. Kirby’s admin has better UX.
  2. I wouldn’t say Grav’s documentation is better. Some parts are well written with a conversational tone, but I’d say both documentations are rather good, with some particular strengths and weaknesses.
  3. I rather like Twig, which we’re using extensively at work (with Symfony mostly). I’ve also been working with Django and Jinja in the past so it’s familiar for me. We also have some front-end components which use Twig templates. So I’m looking forward to using Twig in Kirby 2.3, though it comes with trade-offs (refactoring your templates to put half of them in a controller).

Feature-wise I haven’t seen something that Grav has and Kirby might lack, and I don’t find Grav easier to develop with for now, but it’s early days (just starting the project).

3 Likes
3

I opened an account just to reply to this. I tried a lot of CMSs and must say that Kirby got me :heart_eyes:

  • Kirby is light, fast, flexible, easily extensible
  • Fits to my mental model (documentation, code, structure)
  • Users love it so much (panel, kirbytags)
  • The way the project is managed
  • And no Symfony, Twig…
7 Likes
4

To me the fact that you don’t need Twig, Composer and Symfony Framework is an advantage. There’s much less dependancies and overhead in developing for Kirby.

I think Kirby’s PHP object and methods model make for pretty clean template tags, so I think adding Twig into the core would be overkill. As a plugin? Sure!

8 Likes
5

I also like that Kirby doesn’t force me to use any template language. It would be fine as an option though, so everyone can be happy.
Twig and Symphony are all the rage now, but in a year or two that may change, and then having only Twig in core or being based on Symphony would become a disadvantage again.
Having used Twig on client projects, I can’t say I’m in love: I don’t find it very legible (or maybe I just don’t have a great syntax coloring for it?).
I’ll try Kirby Patterns on my next site.

Regarding the admin interface, right now Grav has the same issue as Wordpress: the client is given a mish-mash of content edition, settings, site-building options. It’s “show everything by default”. That may change with their upcoming “pro” admin though.
With Kirby I can give them just what they need.

6 Likes
6

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

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
9

Template engines are indeed and luckily optional.

4 Likes
11

Phew!
This is good to know! :smile:

12

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.

2 Likes
13

Kirby 2.3.0 Beta:

The template engine is now a component.

2 Likes
14

Thanks.
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:

2 Likes
15

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:

2 Likes
16

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.

24 Likes
17

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.

Website

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

Headers

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.

Docs

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?

Structure

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.

2 Likes
18

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

this!

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.

4 Likes
19

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