Transcript

[Banjo music]

MANTRA:Just Build Websites!

Dave Rupert:Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a show about websites. That's the new intro.

[Laughter]

Dave:We're still working on it.

Chris Coyier:I like it.

Dave:I'm Dave -- $20 billion -- Rupert, and with me is Chris -- probably $22 billion -- Coyier. Hey, Chris. How are you?

Chris:[Laughter] I wish. That's good stuff. Yeah, we have a special guest today. I think we're going to end up talking about probably CMS a bunch, but it'll be hard not to talk about this crazy Adobe news.

We have with us Bastian. Oh, damn it. I forgot to--

Hey, Bastian. How are you?

Bastian Allgeier:Don't try. [Laughter] Hey! Hi!

Chris:Tell us your name and your basics.

00:01:03

Bastian:Yeah. If I pronounce in German, it's just AHL-gy-ur.

Chris:Mm-hmm.

Bastian:You don't have to repeat it. It's a weird name in Germany there, so don't worry. [Laughter]

Chris:Wonderful. But we've had you on before. You're a long-time guest of the show, but it was in the year 2014, so a little while ago. This show has some long legs. As a matter of fact, this show came about -- as so many have lately -- from a Twitter conversation. I think even you were like, "Yeah, it's been a little while," since you've been on the show.

Bastian:Mm-hmm.

Chris:We were like, "Ooh, that would be awesome to catch up," because I love to see that Kirby seems to be evolving and doing well and doing the small business thing, just as I am and Dave is starting to do. That's always fun to talk business with like-minded folks. Not to mention just talking about CMS is just kind of fun and right on target for this show.

Yeah, huge news for Kirby, though. It got picked up by Automattic, right? $19 billion.

Bastian:[Laughter] Yeah. Only $18 billion, though.

Chris:Oh...

Dave:Oh, well...

Bastian:A shame.

Dave:Just add on a yacht or two there.

Bastian:Yeah. It's okay. I think we'll get by. [Laughter]

Dave:Yeah.

Chris:WordPress is dropping MySQL for flat files. It's the new way to go.

But can I start with that because I think that's so interesting? Kirby is a CMS. Kirby is a PHP-based CMS, so it feels like it's in the category of the great CMSs of your that are all PHP. For the strong reason that, for a long time on the internet, it was a commodity to buy hosting that had PHP on it, like so much hosting.

Why not? Software engineers were incentivized to build software that ran on this hosting that you could buy for $5 a month that was pretty much fine and still is fine. Pretty cool. But Kirby also has lots of modern, interesting things to it, and shares some DNA with the CMSs of today that are so hot like the static site generators. Kirby is not a static site generator, right?

00:03:16

Bastian:Yeah, true. It sometimes gets confused with it. I think the flat file definition is a bit weak sometimes. It comes from those CMSs that load files dynamically and then put them into a template and then render stuff. But then it turned more into the static site generator buzzword thing later, and I think this is kind of what we still see and that people confuse it with it.

It can be a static site generator, but it's not a static site generator out of the box, as you already described. It's basically loading content from files and folders, and then it's dynamically generating pages.

Of course, you can cache them. Of course, you could generate static sites out of them if you want to. But first and foremost, it's a pretty regular, dynamic CMS.

Chris:Yeah, just let PHP create the response on the fly.

Bastian:Yeah.

Chris:Cache it, maybe.

Dave:When we say CMS, there's a UI, like an admin UI that comes with it, right? It's not just 11ty style files and folders and, boom, a website.

Chris:Yeah, front matter.

[Laughter]

Dave:There's a whole GUI that happens, right?

00:04:32

Bastian:Yeah, exactly. Yeah. We have a full admin interface or a panel, as we call it. You can do all kinds of stuff there via desktop or on mobile or wherever you want to go, and then just administrate your content there, post new stuff. Yeah, it has an interface. Yeah. It's not just a command line tool or whatever.

Dave:Mm-hmm.

Chris:Right. That's a distinguishing feature, too.

Dave:Yeah. I was going to say, I feel like that's a very important distinction compared to a lot of the current gen tooling that's just kind of like, "Hope you know computers." [Laughter]

Bastian:I mean it started that way, actually, so it started as a pure command line tool. It wasn't really command line, so you just put it on a local installation of MAMP or whatever, and then you could add folders and files. But you would have to do that manually, and then you upload the files and folders via FTP and, the good ol' days or later, via deployment scripts. But there wasn't an interface first for, I think, a couple of months. Then lots of people asked for it, so we added it in 2012 (back in the days).

Dave:Yeah. Wow.

Chris:It puts it in a different category. I think that's -- I don't know. If I'm serious about managing the content on a site, I want an interface - gosh-dang-it. I know Dave might disagree. You've been rockin' the Jekyll thing for a long time on your own site. But I don't know. There's something in it for me that I like.

Dave:What Dave Rupert wants and what--

Chris:The world.

Dave:--former past clients want is very, very different. You know?

Chris:Very different. [Laughter]

00:06:13

Bastian:[Laughter] Yeah, we still see that a lot. I mean we always try to keep it that way so we can use it both ways. You don't have to use the interface. It can work just as it did before with files and folders.

Chris:Oh, interesting. You absolutely don't have to.

Bastian:Yeah, you don't have to. You can switch it off, and that's kind of a nice thing to have. We do that for our own website, actually. We don't use the interface for our own interface, which is maybe a bit weird.

Chris:Oh, wow.

Bastian:But we use it in other places, so I think we are fine.

Chris:Yeah.

Bastian:But, yeah, we--

Chris:It helps to use your product.

Bastian:It helps to use your product. Absolutely. But we see that a lot, so there is a good split between people who use it completely without the interface. And people, of course, use it with the interface. Yeah, it's important to us.

Chris:What stuck with me is let's say you want a button on your website that goes to your archives. Then when you're in the archives, you're like, "Do I want to look at these from newest to oldest, or do I want to resort them from oldest to newest?" If you're on a static site generator, that's going to be tough, I think. How are you going to possibly pull that off? Are you going to generate your archives twice? How are you going to handle the URL situation? It's going to get weird.

In PHP, you're like, "Yeah, you make ASC into DECS, and it's fine." You know?

There are all these things that servers can do that just open up some doors that a static site generator will never be able to open. That stuck with me. Is that a primary motivator here?

Bastian:Hmm... Well, when we started in 2012--

Chris:Why flat files is the question. You know what I mean?

00:08:07

Bastian:Yeah, why. Well, why? Okay. Then I have to go back a bit earlier, actually. I started as a freelancer. I built websites for my clients and tried dozens of systems, actually, over the years, and built also quite a lot of systems myself.

Chris:Right.

Bastian:To various degrees of quality, I would say. Then there came this weird idea. A client wanted a super cheap newsletter tool where they could just write a text file and then it would generate a newsletter template for them. This kind of was a shitty job at first, but it turned out into this thing that felt so easy, so this idea that PHP just reads a text file and then creates an HTML template out of it. That felt pretty cool, actually, after all those years of complex systems.

From there on, I turned it into a full CMS for the next project. It stuck, and it kind of still felt right. Then the next project came along, and it still worked for that. It just turned out to be a super-flexible system for myself, and that's how it started.

At that time, to be honest, static file generators weren't a thing. So, in 2010, 2011, I never heard about static site generators before. There were CMSs that created static sites or created static files for all their pages or some pages. Yeah.

Chris:Yeah, whatever. Text pattern or whatever the stuff the olds talk about. [Laughter]

Bastian:Exactly, but not in the form that we know them today. It wasn't really an idea that it could become a static site generator. This flat file approach, instead of a database, was the enticing part, which it felt so easy. You could sync it so easily. You could put it into GitHub so easily or in a Git repository. Everything just instantly felt easy after years of working with databases. That was the first idea.

Then we still got all those kind of nice features that you mentioned. You still can do all kinds of dynamic stuff in PHP and sort and shuffle and have random stuff somewhere or whatever.

Chris:Your footer can output the year dynamically for your copyright, which we all know we need.

Bastian:Crazy stuff.

Dave:Nah, I mean I think we all prefer regenerating 10,000 pages just to update the footer every year.

Chris:I like that our expectation now is you have a 2,000-page site and you're like, "Fourteen seconds, I don't have time for that garbage."

Dave:Yeah.

Chris:Another one I think about, though, everybody makes fun of NPM install. People make plain jokes. They write blog posts about how much hard drive space it's taking up, NPM install is just the butt of the industry jokes for security reasons, for every reason. You know?

You have to do -- when you run an SSG, the expectation is that not only are you running it locally but you're running it when you deploy your website and you're probably running it on every push you ever pushed for anything. You change a period on a blog post, the default is first NPM install the universe. Then build my entire every page of my entire website so that Netlify can put these static files in a bucket for the rest of all time because they have immutable deploys - or whatever.

It's not shade on Netlify, but it's funny to think that that's the expectation. You know? You're asking a lot of the cloud to do that for you, whereas deploying one file is like, moop. That's what deploying a blog post surely on Kirby is like, right? You just push one more file to a server and you're done.

00:11:56

Bastian:This can be that. Yeah, exactly. I mean I really like the idea of static site generators. They have advantages that are hard to get with a dynamic system (on the other hand) and you get all the security benefits. You get lots of other stuff - performance benefits and whatever.

I think what we are seeing for us, more and more, is that we can easily go the hybrid way where some pages are dynamic and some pages are static. That is kind of mixing both worlds together in a very positive way for us where we feel like this is the best of both in many cases because, honestly, you just mentioned a couple of really crappy things about static site generators. But of course, there are so many crappy things about dynamic CMSs as well.

I think it's always interesting to see what the trends bring along that can be then retrofitted into systems or maybe even rethought and then just added in a new way that improves it. That's kind of what I like about it.

Dave:We have no sense of balance in our industry. It's always a swing. It's like we're all, like, "Dreamweaver websites are dead! We're all going to blogger."

Bastian:[Laughter]

Dave:Then it's like, "Blogger is dead. We're all going to moveable type. Ah, moveable type is dead! We're all going to WordPress."

Chris:[Laughter]

Bastian:Yeah.

Dave:Then it's like, "WordPress is dead. We're all going to static sites." You know? We have no balance. We're never like, "Man, what was good about the last system, and what could we subtly improve?" It's always this full rejection of the previous religion, and so I like your balanced approach of, like, "Hey, flat file," which is unique, "dynamic," which is unique now, but we can also maybe pull in some of these static kind of bonuses. I think that's a cool, balanced approach.

00:14:07

Bastian:Yeah, absolutely. What you just mentioned, it gets more and more stressful because those shifts happen more often nowadays, right? At least with those shifts from movable type to WordPress - or whatever - it was like every two years something new happened, and then you have to move over. Now it feels like every two weeks you have to move to something different.

Dave:For sure.

Bastian:Framework or new CMS or a new whatever.

Dave:Yeah, well, now we all have to switch our design tooling.

Bastian:Oh, yeah. [Laughter]

Dave:Instant. One day.

Bastian:That hurts.

Dave:One announcement, one tweet later, we're all switching.

Chris:Just immediately, people are like, "I have to pay my creative crowd subscription or I'll never be able to open a file again." Yeah, a lot of assumptions get thrown around real quick. It could happen.

Dave:Well, everyone knows there's a bunch of evil businessmen, all men, sitting in a room just like, "How can we just ruin this big pile of money we just spent?"

[Laughter]

Dave:"How can we just set it on fire?"

Bastian:Yeah.

Dave:Yeah.

Bastian:I think ... Twitter just had too much of a good time in the last two weeks or something and then, yeah, there needs to be some evil coming up.

Dave:A new villain, right?

Chris:Ah, that's true. We've had it too good.

Bastian:Yeah, absolutely.

Chris:Yeah. We need something to yell about. Ah... It's too big of one. My brain turns off. I read five tweets about it, and I'm like, "Okay, I'm bored of this news."

Bastian:Yeah, yeah.

Chris:I need something else to be mad about.

Dave:There are some genuine concerns about management or historic experiences and stuff like that. I don't want to discount those. Those are very personal. I think we've all--

I think it comes down to products you love, right? I love this product, and now somebody owns the product I love. Somebody else owns it. Under new management.

Chris:Yeah, that's it.

00:16:07

Dave:It could just be -- I don't know. We've had it like Shiner Bock in Texas is a beer.

Chris:Mm-hmm.

Bastian:Mm-hmm.

Dave:It's a double bock. It's very sweet. But it got bought by Corona, I think. You think Corona is this cheap Mexican beer, but it's a global beer brand - or whatever.

It tastes different to me. It does not -- it's not the same experience I had when I was drinking a Shiner in my 20s. But is that because Shiner Bock changed the formula, so some ingredient was switched, or is it because maybe I drank too much of it and now it just doesn't taste as good? [Laughter] I don't know.

Chris:But you only have an opinion because you care, right? You wouldn't even be saying anything if you didn't care.

Dave:You care.

Bastian:Hmm.

Dave:Yeah. If you didn't care and if you didn't use it a lot, you wouldn't care. But I think the more you use it, the more you're invested.

Bastian:That is true. I think another problem, especially with the Figma move is lots of people use it for free. It was this really good tool that you could just use, basically. Now the future is uncertain.

Chris:Unknown.

Bastian:Will it end up in the subscription plan of the Adobe cloud or whatever? I think it's a problem that people get so mad about free products being bought and then change their business plan or whatever. I think if it's a free tool, you always have to be prepared that it might either be shut down or that it gets bought someday.

For those who actually paid for it, it's a different thing. But for those, I mean--

Chris:Yeah.

Bastian:A lot of people cry about it.

Chris:This was VC back to the nines. You know?

Bastian:Yeah.

Dave:Yeah, $330 million Series-E.

Chris:Yeah, the dump trucks of bucks came pouring down on this thing.

Dave:Yeah.

Chris:It's going to have some kind of ending. It's not like they're like, "We're going to go family run with this. We're going to go lifestyle with Figma."

Dave:[Laughter]

Chris:Sure.

Dave:It can just operate.

00:18:16

Chris:Here's a curveball for you, Bastian. In the industry, I'd say, there's a bit of a push towards these edge, you know, running code at the edge kind of thing and all these JavaScript runtimes like Deno and Bun shaking stuff up a little bit, but they're kind of JavaScript focused, but more and more cloud functions. You can already run PHP as a Lambda. Then you can run Lambda at the edge.

All of a sudden, now you have worldwide PHP that's not running on an individual server. It's running on whatever the closest node is. Do you watch that stuff? Do you get excited about that? Do you think Kirby could run at the edge one day? Have you played with it?

Bastian:I watched it, but I'm not yet sure where this leads - for us, at least -- because that's kind of--

I mentioned the advantages of flat files. They are on your server. Especially with SSD servers nowadays, it's super-fast and it's super convenient. It can be in a repo or whatever. But with those, I'm not entirely sure yet what happens with the stuff when it's in the edge because it has to have access to the content somehow, and so you couldn't just throw the entire Kirby installation into one edge function.

I have to say I'm not super experienced with that stuff yet. I don't fully understand how it could work for us as a CMS. I think it's interesting. It's super interesting, especially interesting in this case when you use Kirby as a static site generator and then you throw it out there somehow. But I think I can't say too much about it that would be useful.

Chris:Yeah, I understand. Okay, but then here's another one. I've got kind of two follow-up ones. One is related to caching.

If the expectation is I hit some URL on the website, PHP takes over, it knows what it needs: some template stuff. It needs some content, so it's going to ask the disk for a file that has some content in it. It's going to create a ball of HTML and return it to the browser. But that's a little bit expensive, that disk hit, right? You cache it, right? That's the kind of caching you mean.

That caching could be anywhere, right? Your server could be in charge of that, or it could just be Cloudflare sitting in front of it that just caches the response or something.

Bastian:Yeah, absolutely. There are multiple layers that can work.

Chris:Ooh, multiple caches. [Laughter] Dangerous.

Dave:Yeah.

Bastian:No, no, no, I mean multiple--

Dave:Now I'm scared.

Bastian:Yeah, that's super scary. I mean multiple layers that you could choose. It could be ... cache it could be Cloudflare or it could be just the cache on your server that is a simple file cache or Redis cache or whatever.

Chris:Reverse proxy. [Laughter]

Bastian:There are multiple.

Dave:Yeah, like an OS-level cache kind of thing.

Bastian:Yeah.

Dave:That's a file kind of thing.

Bastian:Yeah.

00:21:21

Dave:I guess Kirby will try to read the file every single time it gets hit, and then is that any slower or faster, or do you kind of keep track of that? Like hitting a JSON API for my content or something like that, you know?

Bastian:It depends on the disk speed.

Dave:Mm-hmm.

Bastian:But we see that with ... service, it's a no-brainer, actually. It adds a couple milliseconds, but not a significant amount of milliseconds. It depends on--

Dave:Like 200 would be my ... or something.

Bastian:No, no. More like -- if you say it's a simple page and you have it in a text form as an HTML file on the server and the server can serve the HTML file, whereas PHP has to build a simple page. It depends totally on the page complexity, but a simple page, and it would add maybe 20 or 30 milliseconds or something.

Dave:Mm-hmm.

Bastian:What we have as a solution for that, we call it Steady Cache. It's not fully there yet. It's in beta. Kirby hits that page once and then it stores the HTML file on the server. Then a mod rewrite rule or an NGINX config rule would go to that file instead if it finds it next time, so it will just hit that once. Then afterwards, it's an actual static file that is being served. It's no longer going through PHP.

The PHP has always a bit of an impact when it has to run through it. But it's not that significant. It gets significant if the page is super complex. It has to load a lot of content, a lot of relationships or whatever. Of course, it will always be complex.

Dave:Mm-hmm. Okay. Yeah, yeah. I guess you're saying that read isn't the bottleneck so much as maybe PHP itself, just like memory. Usually, that stuff -- I don't know.

I guess, do you recommend a hardware spec for Kirby or you're just kind of like, "Ah, it should work everywhere"?

00:23:40

Bastian:It should mostly work everywhere. We see it on super cheap shared hosting as well as on high-spec servers, and it is actually a lot. It depends a lot on the disk. If you have a fast disk, even on a super cheap server, it is still plenty fast. We have lots of our own stuff running on five-euro shared hosting here in Germany. Actually, not the full website, but satellite tools that we use, so demo sites and stuff like that we run in one cheap shared hosting, especially because we want to know how good it performs on that and if it's actually usable.

What it depends on -- because you asked about that -- is if it has to go through a lot of folders and files and read those first in order to find something. For example, you mentioned the archive before, the archive example. That can be super-fast if it's a couple of hundred pages. But if you need to search between multiple fields within all those text files and go through all those folders and filter them and do all kinds of stuff with them--

Chris:Right.

Bastian:--then it has to scan all those folders. It has to scan all the files within the folders, and that gets slow, of course. Then you have to do some kind of caching first in order to make it snappier.

But it's a bit the same with databases as well. If you throw a crazy query at a database, it is more efficient by itself to optimize that. But it will also be slow if you don't know what you are doing.

Chris:Yeah, that is interesting. Something like search is always going to be -- that's tricky, right?

Bastian:Yeah.

00:25:20

Chris:There's no way searching a bunch of flat files is faster than SQL.

Bastian:No, absolutely not. I mean you can do that with a simple site with a couple sub-pages and a simple blog or something. It's still doable there, but it easily gets into a place where you say, "Okay, I need something like Elasticsearch, Algolia, or whatever. We use Algolia for our site and index the stuff on push. Yeah, of course.

It's not just a performance issue. It's also the quality of the search. If you want to rebuild a high-quality search, it's a nightmare.

Chris:Mm-hmm. Put it in a -- what's the--? Just have an Algolia integration. You know. Come on, people. Search is a solved problem.

Dave:[Laughter] Speaking of $20 billion.

Chris:Yeah.

Bastian:Yeah. Yeah, that's--

Chris:Elastigolia.

Bastian:[Laughter]

00:26:16

[Banjo music starts]

Chris:This episode of ShopTalk Show is brought to you in part by Split. That's split.io. Split.io/shoptalk, actually.

A very clever name for a product because it has to do with splitting, actually, like the users that use your website. Imagine a basic use case of that being something like A/B testing, like I want to show some percentage of people this version of the website because I want to test the effectiveness of it without necessarily rolling it out to everybody.

Test the effectiveness meaning literally measure the impact that it has and see if it's kind of good or bad. But that same kind of technology then can be used for feature flags. That's essentially what you're doing. You use their product to set up these feature flags, like these 100 people or these 25% of the user base have this feature flag, which you use their dashboard to do. Then it allows you to write if-else statements, essentially, right in your own code base that says, you know, "If this flag is turned on, deliver this piece of JavaScript," or backend code or whatever it is. "Otherwise, do this."

It gives you that ability in your code, but it separates the ability. You don't have to deploy in order to change the 100 people or the 25% or something. You manage that elsewhere, which ends up being a pretty nice experience.

Then again, it helps. It's for rolling things out. You have a brand new feature. You don't want to roll it out to everybody. You want to roll it out to a subset and get feedback from them. That's the whole point of feature flags. Split helps you do that.

Split is the feature delivery platform you need to help execute these modern expectations and continuous and progressive delivery because if you're not delivering, you're falling behind. You and a team of ten can create your first feature flags at split.io/shoptalk. Create your first feature flags with a team of ten. Thanks for the support.

[Banjo music stops]

00:28:29

Dave:It's been a while since we've talked to you. What have you seen people using Kirby? How are they using Kirby? Do you feel like Kirby has a sweet spot?

Bastian:The sweet spot in terms of how it's being used?

Dave:Yeah, or who is your ideal customer or who is gravitating towards picking up Kirby as opposed to the hundreds of other CMSs?

Chris:Kraft is an interesting comparison because you both -- you know, you sell copies of Kraft. They sell copies of Kirby. It's similar in spirit in that way.

Bastian:Yeah, that's true. We see that a lot. We see that in agencies a lot that they often use them side-by-side. That's interesting. Yeah.

The sweet spot for us, well, the ideal clients are freelancers, agencies. We see a lot of them that just keep on building sites for their clients over and over again, a couple dozen per year oftentimes.

Chris:Mm-hmm.

Bastian:Of course, those are really cool customers for us. They build great sites, often high-quality sites. They come back.

If we do our job right, they are loyal and stay with us for years. I would say that's the sweet spot for us in terms of what we really love to see. We have a lot of them, fortunately.

The sweet spot in terms of projects would be the really nerdy ones. I mean there are projects that totally blow my mind in terms of what people build with it, like custom-made organizational tools for - I don't know - a theater or for a company. They often build things like invoicing or something into Kirby. I really love to see those projects. They are the sweet spot for me personally in terms of -- it's really blowing my mind what people come up with and the ideas that they have.

It's not necessarily visible on the outside. It's oftentimes behind the scenes. It's really cool.

Dave:That's cool. I recently saw an app for an agency, like their internal app that they use to schedule vacations or divvy up projects and stuff like that. It was really cool. I think it was built in Rails, but it could have easily been Kirby or something.

I wonder how many of these JavaScript frameworks or CMSs, I wonder what percent of the applications built with them are internal tools. I bet it's shockingly high.

Bastian:Mm-hmm.

Dave:There are five Angular production sites and there are five million Angular backend internal tools or something.

00:31:29

Bastian:I mean another sweet spot that just came to my mind is we see that also more and more is that Kirby has been used as a glue between different systems. I also like that quite a lot. People have -- or companies, organizations have more systems than they would like, often. I don't know. A CRM and then an ERM or a shop system and all kinds of additional systems that they all have to log in separately somehow and then get the data from one and put into another one.

We see that more often because Kirby seems to be quite hackable. This is what we intend with it, but it's lovely to see that it seems to be true that people feel comfortable with it, hacking all kinds of ideas together. And so, they often use it as the glue between different complex systems and then load data into Kirby and combine it there and use it as a single source of truth for their content and for their marketing on the website. This is what I really like, a bit hacky projects that turn out of it.

Dave:I mean that sounds up my alley.

[Laughter]

Dave:I was on a project, and they were like -- we were building out this thing. They were like, "It's five pages." We're like, "Yes, five pages."

Bastian:Mm-hmm.

Dave:We'll scope it. We'll budget it. They were like, "Oh... We've got these testimonials we really like." We were like, "Oh, okay."

It's like 6,000, and they're all in a CSV file, so good luck. You know? We were just like, "Ouch. Okay, we'll do it," but we figured out a system. I think we ended up parsing the CSV into different kind of -- you know hacking it, but it was a hack, if that makes sense. It wasn't a native thing we did. [Laughter] But anyway, it'd just be cool to have a tool that does that.

Bastian:Mm-hmm.

Dave:That has that feature set and isn't made of surprises.

00:33:40

Bastian:Kirby does not necessarily have the features for everything that you've just put it in. We are not a plug-and-play system. We see ourselves more like a Lego brick collection of tools that you can combine and use and customize. It all comes down to the experience that we, as a team, every one of us had in their own client projects, exactly those kind of stories that you just told where you see it in a project.

It starts really easy, and then gets more complex. Then it gets more complex. Then you're suddenly like, "Oh, my God."

Dave:Yeah.

Bastian:The system, we always wanted a system that doesn't get in your way when the project gets more complicated or messy. It's still kind of okay. Even if the project really goes down, you still enjoy the work on it somehow. Well, it depends. It always depends on the details of the project, but we at least try to be as helpful with that as possible.

Chris:Flat files, what's in them? It is an enforced Markdown thing? Is there front matter? Or is the folder structure important? Tell me about what the expectations are of the flat file.

00:34:56

Bastian:Okay, so the basic idea is pretty simple. Every page is a folder. That's kind of how it works. You build a page.

Chris:File system based routing is so hot right now.

Bastian:Yeah, it's so hot. Whoa. Yeah.

[Laughter]

Bastian:Yeah, you have a folder for every page. You have subfolders for subpages, and sub-subpages, and you nest it as deeply as you want until the file system hits the limit. I've never hit that, but I think it's possible.

Then in a folder, the folder name is also responsible for the URL. The URL path is built by the folder names. Routing, you just mentioned it.

Chris:Mm-hmm.

Bastian:Then there is a text file in there. The text file, the name of the text file decides which template is being loaded.

Chris:Oh...

Bastian:If Kirby finds a template which is also named the same way as a text file, it will use that template and, otherwise, fall back to the default template. Then in the text file, we have fields. We have a custom format for those fields.

Front matter wasn't -- at least I didn't know about it back then, so we started with our own format. It's still pretty simple. It's very similar to front matter, actually. You have a field name, a colon, and then the field content. The field content can be pretty much anything, so it could be text or JSON or Markdown or HTML or whatever crazy format you want to throw in there.

Then we separate fields with four dashes. It's dashes, I think. Yeah. I hope...

Then the next field comes, and you can put as many fields into a text file as you want. Every text file can have their own fields. If you say, for example, you build a project directory, not every project has to have the same fields. They can have different fields depending on the project. You can share templates by always using project.txt and they would always load the project.php template file, or you could say five projects use the project.php template and the sixth project is suddenly one of those crazy projects that has a custom layout because the client now needs to go to a trade fair and they need to have a custom microsite for a project or a product or whatever.

Chris:Right.

Bastian:Then you can say, okay, this is a special-project.txt and then you create a new template special-project.php. Then you can build something new for it.

This would be how you use Kirby just by using the file system if you never touch the user interface.

Chris:Right.

Bastian:The user interface does the same thing, so it would create folders for you. It'd create text files for you. It is not living in a parallel universe, so you can use it side-by-side. You can have the interface and you can still work on the folders and the files, which is, in my opinion, still one of my favorite features because you can easily create entire structures for your site very quickly in ... or in your explorer or whatever.

Chris:Mm-hmm.

Bastian:Then switch to the interface later, as soon as the client comes in or when you feel like you want to use it.

Chris:Right.

Bastian:Then we bind.

Chris:There's nothing secret. When that admin UI boots up and you're like, "I'm going to make a new page," and then you start typing a title, and you start typing some content. You say, "Oh, this is a special project. I'm going to save it as a special template." It's not like that piece of metadata goes in a database somewhere because there isn't one. It just affects how and where that file is saved and named.

Bastian:Mm-hmm.

Chris:Right?

Bastian:Yeah, 100%.

Chris:Yeah, nice.

00:38:39

Bastian:Then we bind it, so we kind of need a layer between the quite loosely typed text files and the interface. We somehow need to tell the interface what kind of fields it should show because--

Chris:Right.

Bastian:--by default, you just have a field in the text file with a colon and the content. There is no format yet. It's not--

Chris:That's not a CMS. A CMS needs to have a date picker and - I don't know - all that stuff.

Bastian:All that stuff. Then this is where we call them blueprints. You have configuration files where you can say, okay, this page type (page type project, for example), page type blog article, I want that kind of interface. It's not just about form fields. You can set up all kinds of form fields for the interface, which you can with pretty much every other CMS. But you can customize the entire interface for that page type. Every page type can have a different kind of interface.

For example, if you go to your blog in the admin interface, you would like to see the sub-pages or the articles. Maybe you would like to spread them into drafts and published articles somehow into columns or whatever.

You could say, "I don't need any fields for the block itself, for the block page type. I just need a really nice way to display my articles." Then as soon as you click on any article and you land in the page type article, for example, then you need form fields. Then you might need a gallery, for example, where you can drop images in. All that is then configurable.

You can also extend the interface with custom components, so it's a Vue-based, Vue.js-based interface.

Chris:Oh, you made the call there, huh? You have Vue available to you in that.

00:40:35

Bastian:Yeah, exactly, in our plugin system. With our plugin system, you can create new fields, and you can also create new interface elements. For example, if you say I have a product, and this is the marketing side for a product, it's just about the content for the product, but I also would love to pull in the data that's coming from our shop system, and the shop system is somewhere completely different. Then you could create a new interface element that is pulling in metadata for the product into a Vue component. You can add it to your Vue for the product page type.

Chris:Mm-hmm.

Bastian:It's really highly customizable for whatever you want to build and, yeah, for whatever you have in mind.

Chris:Nice.

Bastian:It's also easy to extend that. I think that's also an important part. The fields come for fee, basically. If you need a new field, you just add a new field to the text file or you add a new field to the blueprint definition. Then it becomes available in the interface, and you can start adding content.

Chris:Ah, that's so cool. That reminds me. Perch did that, too, right? You didn't have to tell it what fields you want. It'd be like, all of a sudden, there's this new field, and it was the UI would adapt to have it available to you. That's really neat, so hmm.

Let's just do one example so we could see how it would go, like a blog post has an author.

Bastian:Yep.

Chris:I want to choose what author it would be. Where do I express that?

00:42:03

Bastian:We have a user's picker or user's field, and then you can just add that to your--

Chris:Oh, that particular one is kind of like a blessed field by Kirby or something. It's like a--

Bastian:Yeah. Yeah. Well, you mean it's not a -- it's a custom form field. Yeah, it has a little button. You can select users and search through users and then select the user you want. Then it creates a relationship between the blog article and that user.

Chris:Right. I just mean what if I said instead of users I said all blog posts have a temperature gauge and I have to write what temperature it was outside when I published the blog post. You wouldn't tell me, "Oh, we have a temperature widget for that."

Bastian:No, no, no. Of course, not. Yeah. [Laughter] Yeah, then you could create either. You are fine with one of our text fields or the number field or whatever kind of field you want to use. Or you say now, well, I wanted a really crazy, little weather widget thingy in my interface. I pull data in from weather.com or whatever platform I want to use. Then you would create a Vue.js component and a little PHP file. The PHP file could do, for example, the API request for you and then send it to the Vue.js file and the Vue.js file would show it to you in your interface. Yeah, you can put it into columns. You can lay out where it should be. For example, you could say I have my blog article, the main fields, the text field, and the headline field (or whatever they are) in a big column on the left. Then on the right, I have a small metadata column. There I put my nice little weather widget.

Dave:Hmm.

Bastian:A few things. I guess, if you click through the showcase on our website or the first gallery on our website on our homepage, you can already get an idea how different the page types can look like.

We created a couple of examples there. We also have them in our demo kit. If you want to, if you click on "Try," you can boot up a demo, an instant demo for you, a personal demo, and we have created a couple of site types there as well of, like, a restaurant or a microsite or stuff where you can see how different the layouts can be.

Dave:I didn't realize Kali's website is on Kirby, which his new timeline feature is really good.

Bastian:Yeah, it's really nice.

Chris:Jon Hicks, too. Classic. You've got all the grand old designers.

Dave:RISD, never heard of it. [Laughter] Graphic Design.

Chris:Man, you've got some killer names on here.

Bastian:It's a graphic design school in Amsterdam, I think. University...

Dave:Yeah, I was just kidding. It's very popular.

Chris:Rhode Island.

Dave:It's very high-end. [Laughter] Offscreen Magazine, so good.

Chris:Brendan Dawes. Holy cow.

00:45:02

Bastian:I just pushed -- so there is another great site if you want to get more into how people use the admin interface. You can check out kirbysites.com, which is a community project run by one of our plugin developers. The cool thing about that is he totally steals the show of our showcase, actually, on that site.

[Laughter]

Bastian:Because what he does is you have the examples there, then you can click on the example sites. Then you can see how the backend for that site looks like, which is, I think, really, really cool.

Chris:Wow.

Bastian:It's not just a screenshot of the site, but also the screenshot of how the admin interface for that site looks like. Sometimes, it's just pretty standard, and sometimes it's just crazy cool. There are also examples of admin interfaces that have been adjusted, so the CSS has been adjusted. You can load a custom CSS file and then customize it. Yeah, it's super interesting for us to see that.

Talking about sweet spots earlier, this is also kind of where this sweet spot is for me when I see really cool interface screenshots and people create great interfaces for their content.

Dave:Yeah.

Bastian:I really love that.

Chris:This is really cool to explore. I think I've learned that menu in German is just menu where the U has an umlaut, which I like.

Bastian:[Laughter] Yeah.

Chris:I enjoy that fact. God dang. If there are this many nice sites, just think of how many ugly sites there are, you know, 100 times. [Laughter]

How's life on GitHub with this? You just throw it up on GitHub, open issues, open PRs. [Laughter] It looks like it's in pretty good shape. You must take care of that pretty well with your team.

00:46:51

Bastian:Yeah, I mean GitHub is a blessing for us, but it isn't always easy. I mean it especially didn't start very easy. When I started it, I put it on GitHub, and I had this idea that I wanted--

We call it commercial open source, which is kind of, yeah, it's not really a thing. But it's kind of our idea behind it. We put the source code entirely on GitHub. You have to buy a license. You have to register it if you use it. There is a registration warning if you don't do that - in the panel, not on the site.

But the source code is still open, and then I'm 100% honest with this. If you know your way around PHP, you could easily just throw out our validation code out of there. And so, it's kind of this mixture between trust-based model and still a forced kind of idea of you have to buy a license.

Chris:Yeah, that's tricky.

Bastian:Of course, the license is also a proprietary license. When I started, everybody was like -- not everybody, but a couple of voices were like, "This is totally crazy. It's not going to work. Nobody is going to buy it. They're just going to steal it from GitHub."

Chris:Even if you don't put it on GitHub, one person will buy it and put theirs on GitHub.

Bastian:Yeah, 100%. I always said I don't want to care about those who steal it. There will always be people who steal it, even if it is behind a closed download somewhere. It will always be pirated in some way. I always wanted to focus on those who actually like it and want to pay for it.

Yeah, that was difficult in the beginning because it started slowly and I didn't really know if it would work out. Years later, it works out really well. I think we have a nice group of people who values the work that we put into it and then don't mind the license fees. We always try to be super fair with the license fees as well? It's not an expensive tool. It's a one-time purchase, not like a monthly subscription or whatever.

Chris:Right.

Bastian:It works out for us. The benefit for us putting it on GitHub is the honesty behind it. We don't have anything to hide. You can try it for as long as you like and see if it really fits to your project and then go for it, or you find out (after a couple of days) you don't really like it, and that's fine. You don't have to buy a license for it.

It's also a security thing for us. We want that openness because I think there's a lot of -- yeah, it's good to be that open in terms of security. We have security researchers coming in and looking through it and pen-testing it before they use it. That's important to us.

The issues and the community integration is super important for us as well, so we get pull requests. We get issues. We have the typical open-source kind of way to deal with all that stuff, and that's a big plus.

00:49:58

Dave:Do you hide support behind a license or is it just kind of open?

Bastian:Not really. We have a limit. Well, I think we are very open with the support as well. We have our forum where we direct all the support to. Sonya, one of our team members, is there pretty much all day and is very active in her response.

We try to not determine too much how many licenses have been bought yet or if there is a license already, we try to onboard everybody who is having problems (as good as we can). But of course, if it gets too detailed, if it is something about the server configuration or the project just has a huge complexity and lots of plugins installed and we don't really understand it without looking at the source code, there is a limit to what we can offer for that price as support.

Dave:Mm-hmm.

Bastian:Then we either decide to go for one of our community members and get help from there or get us hired to help them out.

Dave:Cool. Yeah.

Chris:Oh, is that part of the business model too is that you're kind of guns for hire?

Bastian:Not really openly, no. We don't push it because--

Chris:Not openly. Yeah.

Bastian:No, I mean not. We don't push it because it's not exactly what we love the most about it.

Chris:Mm-hmm.

Bastian:We love the work on the product. We love to develop, to improve it, to develop it, to work on the issues and on new features and on new ideas. We thought about it a lot, but the business model shifts into a completely new direction if we would do a lot of consulting.

Chris:It does, yeah.

Bastian:Or if we would do a lot of technical support behind the scenes because then it's always a risk that clients would ask for special features that we then have to build for them as a core team. Then that would push the CMS into a certain kind of direction or it would occupy so much of our time.

Chris:Even if it doesn't, it's taking time. Yeah, exactly.

Bastian:Yeah, exactly, and we are not a huge team. We are five people, and we are very careful with the time that we spend on side stuff next to Kirby.

Chris:Yeah, you could always have that special price. Be like, "You need my help? How does a million dollars sound?"

[Laughter]

Bastian:$20 billion.

Chris:Yeah. [Laughter]

Bastian:[Laughter]

Dave:Starting price. What's your budget? You know? Zero or $20 million? You know, a drop-down, Kirby can do that.

I guess, yeah. I've been learning a client service business and a product business are very different in terms of demands, and so you can't just be both.

I think we're kind of running out of time here, but one question I wanted to ask was what's your pitch to a developer who is at a company? They always use the big CMSs because they're told to, or whatever. What's your pitch for somebody who wants to make the cell on a smaller indie CMS or Kirby or any of the other ones? What's your kind of pitch for somebody who wants to introduce that into their company?

00:53:33

Bastian:We always get asked that because there are names that always get thrown around. Then people don't even know what the CMS is. They just heard it once and then they want it. Then this is always the competition kind of, yeah, we have to argue why is ours better.

What I try to say most of the times is, well, we claim that Kirby is super flexible. We claim that it's super-fast. That is just fun to use, in our opinion. We are totally bias there, and I can only say, "Give it a try. And if you feel like it's fitting, then go for it. If it's not fitting, then don't go for it."

I think the flat file approach, even after all those years, and that's kind of after ten years of still working on it, is still totally exciting to me. It still feels right. It is just a great way to build websites, in my opinion. It has all those different things that you need, all the different bells and whistles that you can add, which can also keep it super simple. It has all of that, in my opinion.

Dave:Fun and flexible are not generally in my CMS vocabulary.

Bastian:Yeah, exactly.

Dave:That's exciting.

[Laughter]

Bastian:Yeah. I mean everybody is trying to say that. Of course, we also try to say that. The only way we could prove it is by giving it out and saying try it and maybe it works, maybe it doesn't. For some, instantly clicks and they are hooked for years. For some it don't, and I think that's totally fine.

Chris:Just super quick, I want to mention the page transitions, shared element transitions API. I feel like that's going to be clutch for the CMSs, Kirby and the like. It's one thing you never were able to do is make it that SPA kind of thing where things are sliding around.

I say that because I clicked through one of the sites. I think it was the Berlin by Food or something like that, some really nice site built on Kirby. It looks like it has it, so I'm like, "Oh, gosh. Maybe I'm wrong." I kind of doubt that they're using this super new API already.

Bastian:I don't think so.

Chris:Yeah, they must have figured out some cool JavaScript way to do it.

00:55:55

Bastian:We have a lot of -- I think it's called Baba.js.

Dave:Mm-hmm.

Bastian:Ooh, I don't know if I pronounce it right. There is a tool which is basically a page. What was it called, PageX or Turbo Links?

Dave:Turbo Link. Yeah.

Bastian:And then, on top of that, kind of an integration where you can say it does that and that whenever stuff is reloaded. A lot of people are into those transitions nowadays. I don't really know why. I mean they look fancy. Sometimes I feel like they are getting more in the way than they actually do anything good. But yeah, I mean it seems to be fun. Yeah?

Chris:I get it. It's tricky, right? If you go too crazy with it, you're like, "Why did you--?" [Laughter] I don't think that was necessary.

In fact, I just had a good conversation with Hakim El Hattab, the guy who does slides.com and Reveal.js and stuff. He's like, you know, "As many animations as I've done in my life, none is usually the right answer for a UI." You know?

Bastian:[Laughter] Yeah.

Chris:But I say that and then even something as simple as using the GitHub app on my phone, there are so many. Almost every single thing that you click on has some kind of simple whisk and moved the thing. I think it is going to matter.

The Web can't just have no answer for it, and I'm kind of glad that there is.

Bastian:Yeah, that's true. Absolutely. I think that's why I'm so -- well, I'm skeptical about it that libraries that we currently have, they are always a layer on top that if it's implemented right, it's really cool. But if you make a little mistake, it can get so messy. Then navigation is broken or you can't use the back button properly anymore, and so I think it's really important.

Dave:Or sometimes GitHub's new projects feature will assign you an issue 70 times in a row.

[Laughter]

Dave:Sometimes, which happened to me yesterday.

Chris:Oh, no.

Bastian:Oh, my gosh.

Dave:Thanks, JavaScript. Yeah, well, and that shared elements transition, JavaScript frameworks will get better. Static websites will get better. It's a better for everyone situation, too.

Bastian:Mm-hmm. Absolutely. Yeah.

Dave:That's nice.

Chris:Just pulls one of those reasons away if somebody was like, "I can't use a CMS like this. It doesn’t have that thing. It doesn't make that available." Be like, "Oh, just wait. It sure does."

Anyway, yeah. Sorry to steal the ending away from you there, Dave. Go ahead.

Dave:I think that's actually a really good thing to bring up because it gets into that other, like, "Why would I use this? I want - whatever - my page to be a big zipper. Then I want it to appear suddenly." [Laughter] Marketing people are weird.

Bastian, thank you for coming on the show and telling us about Kirby. But before you go, how can people follow you and give you money?

Bastian:Oh, getkirby.com.

Chris:Yeah.

Bastian:That's the easiest way--

Dave:All right.

Bastian:--to follow me and give me money, give us money. [Laughter]

Dave:That's great.

Bastian:No, you can follow me on Twitter. I won't try to pronounce my name again, Bastian Allgeier. Twitter.com/bastianallgeier. Twitter.com/getkirby is also another way. We are also on LinkedIn and the other stuff where you normally find people and sites and products, GitHub, et cetera.

Dave:Et cetera. Awesome. Well, thank you. And thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for eight tweets a month, six tweets a month.

Bastian:[Laughter]

Dave:Join us in the D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris:[Tongue roll] [Whispering] ShopTalkShow.com.