 Towards a frameworkless world. A frameworkless world. How many people over the past two days, which have been a great two days, I'm sure you'll agree, have been to a talk that was about a framework? Stick your hands up. I'm not going to make you stand up because you're all tired after two days. Keep your hands up. Also stick your hand up if you've worked on a project that used a framework this week. And join your hands so that any of those, if you have a project in your company that uses a framework. So, I mean, I can't quite see everyone, but I'm pretty sure most of the hands in the room are up. So I'm here talking about a frameworkless world in a world that quite obviously has quite a few frameworks that are obviously quite well used. So quickly, who am I? My name is Michael Cullen, and that photo looks even more ugly than it normally does when it's that large. That's my Twitter handle. If you want to tweet abuse at me, if you want to tweet constructive criticisms, anything else during the talk, that's where you can find me. I can't respond. I'm completely defenseless for the next 30 minutes. So there you go. I work for a company called Samnose. We're hiring. We do cool stuff with data and APIs. Come have a chat with me if you want to talk about that. I work on a project called PHP BB, which is a foreign software, which you probably used about 150 years ago. You probably found security issues with it and stuff. It's a bit better now. Still a way to go. And I also am a secretary of the PHP Fig, which is a PHP Framework and Tropicality Group. I'll mention it a bit briefly later. But realistically, you don't care about any of that. You don't care about me. I'm just a guy on a stage. We're going to talk about frameworks. And because it's a keynote, everything has to be big and important, so we're going to talk about the PHP world. But it's a framework as well, so we'll make it dark. I like history. Who likes history? Who likes history but hated history when they were at school? Yeah. This will be fun history, I promise. But we're going to start off with a date just like school. So 1994. What happened in 1994? Nelson Mandela was inaugurated as president of South Africa. China got the internet. That's cool. That affects all of us, especially those of us that have websites that are currently used in China. This other kind of important thing happened. It was kind of this guy's fault. I mean this guy's success. Does anyone know who this guy is? Shout out. Rasmus, yes. He created PHP for anyone who doesn't know about it. Eli was talking yesterday about old schoolers and stuff, and in 1994, I can confess, I was one of those that he mentioned that wasn't actually born. So he created PHP as a tool so he could track visitors to his resume. I don't think he realized the effect it was going to have on his resume in the long run, but that happened. And we're all here today because of that. And we've come quite a long way. This goes to 2018 because we're always forward-thinking, right? As developers, we're always thinking about what we're doing next, except half the time. So we're over here, 2017. PHP 3 over there in 1998. 1998 was when we had the Zend engine. Yeah, big route, go on. Okay, that was pathetic. We can have a bigger route for this one though. PHP 7 in 2015. There we go. That's much better. So we've come a long way. Who remembers PHP Lib in 1998? Like, I see like four hands, five hands, and I don't think that's just because I can't see any of you. PHP Lib was kind of like the first framework. I recently tweeted out when I was working on this talk, I was like, who has a release date for PHP Lib? I don't know what year it was. And the response I got was from one of the initial guys who worked on it. And he sent me an email to the mailing list where it was kind of being announced. And basically it was sessions handling. Yeah, I mean, not a huge amount, but realistically, in that day that was a framework, right? It provided a couple of features that you use in a lot of applications. And we call that a framework, right? 2005, Symphony 1. Who used Symphony 1? Okay, yeah. Okay, that's a fair enough reaction in Symphony 1. That was kind of like the first proper framework. You took this big thing called Symphony and you built a project around it and you had this big application that was called a Symphony application and it did some horrible things. But it kind of gave you a structure to your application and it meant that we could stop using all of those homegrown frameworks that we all started building ourselves. 2006, who remembers CakePHP? Who still uses CakePHP? A few people. CodingNighter? I see my company has raised their hands. We don't use it anymore. And Zen Framework. Who's used Zen Framework? Okay, but this was Zen Framework 1. Zen Framework 1 is very different to Zen Framework 2. Yeah, just like Symphony, Symphony 1, Symphony 2. And then there was kind of like a little lull for a couple of years and then there was this framework that I can never remember actually how to pronounce, although David, I think, is here. Do you want to shout it out? David? Okay, no he's gone home, never mind. Long weekend. And then we get to 2011. And this happens. This is ridiculous, just saying. So we have FuelPHP, we have Aura, we have Lithium, we have Symphony 2, we have Laravel, all of these kind of pop up. And we have Composer Pop-Up. Now Composer was initially created by Jordan Niels. Niels used to be the lead developer of PHPV. And he initially created Composer because he was like PHPV, we need a way to do package management. We need a way that we can have all of these extensions and styles and they can all work together and depend on each other. So he started working on Composer and then he had a chat with Fabien Potentier, the lead developer of Symphony at Symphony Live. And Jordy was there and Jordy was like, hey, I can help out with this because Symphony is having a similar problem. Does anyone remember you used to have the depths file in Symphony? Yeah, that was kind of ugly, right? So we solved that problem and PHPV implemented Composer this year. So we took kind of a long time after we then invented it. But yeah, so huge advent of frameworks in 2011. And then in 2012, two things happened. We had one extra framework, Falcon, and we had the PHP Frig. It was initially created the first ever meeting of the PHP Frig. I'll talk a bit more about what that is in a minute. But then there's nothing. There is nothing between 2012, and I'm going to say 2018 because I'm hoping none of you are going to invent a framework in the next 10 minutes, although if someone goes and writes one now and proves me wrong, then obviously you didn't pay attention to the whole framework this bit. But so we have this big lull here, and my thing is not working, so that's not helpful. Between 1994 and 2005, we had no frameworks. We lived in a frameworkless world. Well, we had pitch free, whatever. Then we had a lull because we had some stuff in 2005, 2006. Then we had all of this in 2011. It was like, yay, we have Composer, we have libraries, we have all of this stuff we can include. It's great. And then nothing again. So did every PHP developer just stop developing PHP at that point? Obviously not, because we're all still here. Packagist. So if we look back to kind of 2012 when packages started, this is an exponential graph, essentially. It's not very smooth. Everyone likes a smooth graph, but they never really are, are they? A ridiculous number of installs. You can't read these numbers down here, but it says basically four million packages installed. And if we look at the number of symphony downloads, that's now almost 700 million downloads. If we look at Zen Framework, that's about 150 million downloads. If we look at Laravel, that's 30 million downloads. So that means that 18% of all downloads from Packagist are symphony. 18%. That's ridiculous. If we include Zen Framework and Laravel in that number, that number is 24%. That's a quarter of all downloads of packages are frameworks. So frameworks are a big deal, which puts me in a problem because I submitted an abstract to this conference and the talk title was Towards a Frameworkless World. So where does this leave us? What if I told you that frameworks weren't actually frameworks? I found a fix for this. I worked out how we were in a frameworkless world. Because frameworks are frameworks. If you look at the symphony top downloaded packages, this comes from their website. And they pull that from Composer, from Packager's API rather. So I trust these numbers as much as I can. Although realistically, those numbers will be slightly off because they did zip downloads at the beginning of their time. But we can roll with this. So we've got event dispatcher, we've got console, we've got YAML, finder, process, blah, blah, blah, blah. All of these different components. Symphony itself, the actual symphony framework is 15th. It's kind of low, right? Framework bundle is not even on the top view. If I look at Zend, it's kind of the same. They're seventh. But it's still not the top. The framework is not the most downloaded part of the framework. And if we look at Aura and Laravel, then it's kind of a similar kind of solution. Laravel is a lot less componentized in the way that kind of operates as a layer. But even that is the same. If you look at all the downloads of all the different Laravel components, they're actually more than Laravel itself. And if you look at Aura, that's very componentized. So if we actually look at the number of downloads of those actual frameworks, of the symphony framework, of Zend framework, of Laravel, we're not with 35 million. Now considering I was talking about 900 million just a few moments ago, we're in downloads of frameworks. And now we're talking about 35 million. That's tiny. We all feel like we're using frameworks, but actually it turns out we're really not. This bar chart on the left, this bit just... that bit down there, that's frameworks out of all downloads on Packagist. And on the right-hand side, we have all of these other libraries, these components of frameworks. Because we libraryed all the things. Because everyone loves a library, right? Who likes a library with books? How at a tech conference does that get a bigger whoop? Anyway, I love books too. Sorry, I get it. We libraryed all the things. We like libraries. And the reason for that is that frameworks aren't frameworks. Yay, I found my solution. Your application should have three things in it. It should have your business logic. Libraries and glue. Nothing else. Nothing. Who thinks that they have something else in one of their applications? It's not one of these three things. You're wrong, and I can say that because I'm on stage and you're not. However, feel free to come and dispute that with me later. I'm just going to say that for the sake of it. I'm actually curious as to what your extra thing is. So business logic. What the hell is business logic? Your business logic is the stuff that actually matters to your application. That's saying that if we want this specific endpoint, at this specific URL, we can do this thing. And output this kind of data. And we can send this thing to cache. But the thing is that we don't actually put it in the cache. We tell monologue to put it in a login library or we tell symphony cache to cache it. That's done by libraries. So libraries is all of your technical stuff. That's stuff that does stuff. That's things like monologue. But also it's things like internal tools. So quite often you'll end up accidentally integrating into your business logic because you're only ever going to need it in that one place. If you're persisting stuff to a cache, if you're persisting stuff to a file system, if you're retrieving stuff from a file system, if you're doing your processing a request, symphony request, symphony response in HTTP kernel foundation, that's a library. It's not a framework. And then finally we have our glue. And this is basically what a framework is. A framework is glue. It's a glue between all of these different components. It's a glue between your event dispatcher, your container, your caching library. And not all of that is part of your framework bundle in your vendor directory. Sometimes that's your configuration in your YAML files or if you're slightly insane or your XML files and annotations if you're slightly less insane. That's a bit opinionated. And it's also about your structure. Your structure of your application. You have an app directory. That's all kind of glue. This is a word I made up, by the way. This is not typo. If you're being library agnostic, I reckon that we should say that this is library agnatism. So I'm inventing this word because I feel like it. Library agnatism, what does that mean? It means that you can swap out a library during development. That's solid principles, right? Everyone follows solid principles. Everyone likes solid. Dependency inversion principle says that you should depend on abstractions and not concretions. So you should be able to swap out libraries. You shouldn't be depending on a specific library. You can use tools that work for the job. Instead of saying, hey, I'm just going to use symphony or hey, I'm just going to use n-framework, you can do what Drupal do because Drupal are doing good things right now. And you can use a bit of zemframework and you can use a little bit of symphony. That's perfectly fine if that's what does the job. And you can drop in replacements. So Gary, who did a keynote yesterday in the afternoon, he told me a story a little while back. I think it was a PHP world. And he said that he disliked symphonies container or dislike pimpleware rather. That's perfectly fine. That's an opinion. He didn't even necessarily dislike it. He just prefers zends, which is cool because he is the lead maintainer of zends service containers that kind of make sense, slightly biased. But it means that when he goes and uses a micro-framework or whatever, if it's implementing certain interfaces, he can just drop in whatever he feels like. But then you kind of get this thing called dependency hell. Who has dependency hell? Quite a few of you. If you don't have dependency hell, you probably do and Composer just solves it for you. You can have library one and it can say, hey, I require monologue symphony cache and pimple. And you can have library two and it can say, hey, we require klogestations n-framework. Library three says, hey, I want analog PHP cache and PHP lead container. And then your business logic has a completely different set of requirements. And that's hard. So we develop interfaces and we say that all of these different libraries, if they implement these interfaces, then you're not depending on monologue anymore. You're just depending on three things, three interfaces. And those different libraries can implement them however they need to and provide that additional functionality that might be appropriate for your use case because you should be using what is relevant to you and not just whatever a certain library forces you to use. I don't want my caching library to dictate my logging library. I want to dictate my logging library. So we go from ten dependencies to just three, which I chose. I call myself a symphony developer. So I went for symphony cache and symphony dependence and injection container. You can do whatever you like. So I said I'd mention a fig very briefly. What is the fig? It's kind of a bit like PHP Congress. This is a photo of Obama speaking at the PHP Congress. This totally happened about three years ago. Yeah, it says in PHP we trust at top. So yeah, PHP Congress. What do I mean by that? What do I mean by that? So PHP Congress, it's a bunch of people that come together representing different parts of the PHP ecosystem and whether that's from different projects. You can call them states if you want. And also from the community with the new fig three and you can elect community representatives. It's also a bit like the UN because we argue a lot. We don't disagree on things. We don't always agree on things. But the idea is it's designed to represent this huge diverse group of people. A huge diverse group of different projects. It's called the PHP Framework Interoperability Group, which of course is a problem because I just said we're in a frameworkless world. So just pretend it's like a standards group or an interoperability group. So I was talking about those different PSRs or interfaces that we could be moving over to. And that sounds like PHP standards recommendation. And a lot of them are interfaces. Some of them do other things. But I don't really care about them in this talk. So these interfaces, they're great, right? They allow for framework agnosticism. And this is really important because we're no longer a symphony application or a Zen framework application or a Laravel application with PHP applications. And we're just having, you know, might be the choice that you, a bunch of symphony components work for you. I said earlier that symphony cache and symphony dependency injection worked for me. So I pulled in those two different things. That doesn't mean that I've got a symphony application. I have a PHP application that uses symphony. If I decided to then pull in the Zen service container, I'm not suddenly using a Zen framework application. I just happened to be doing that. This applies to people too. Who in the room describes themselves as a symphony developer, a Zen framework developer, a Laravel developer? Yeah, I'm perfectly happy to say that I, if you look at my Twitter bio, it probably says I'm a back-end symphony developer. I work a lot with symphony. But after this talk, I should definitely go change that because I, as a developer, should become framework agnostic as well as my applications. Ultimately, the framework, all that is, is your glue. And your glue should be up to you. Focus on the libraries that you're using. Focus on your business logic because that's really what you care about. Your applications, if you make these completely framework agnostic, that's not really a thing because you still have your glue in your applications, right? Your glue is still really important. Your glue is what brings your application together. But it shouldn't really matter what your glue actually really is. Your libraries. If you're developing a library, then why develop a library for symphony when you could develop a library for every single framework? And then just have glue packages, a bundle for symphony have a service provider for Laravel. Someone can just drop into their project. Immediately, you've just stopped having 30 million people from being able to use your project and had a few hundred million. And finally yourselves. If you can make yourselves more framework agnostic, then it means you're a lot more versatile. If you go into a new job and you suddenly have start using a new framework, that's great. But I think we should actually bear in mind the fact that we're just not symphony developers. We're not symphony developers. We're just PHP developers. Matthew Werofini, great guy. Gary also spoke his phrases yesterday. He created a blog post, which you can go and find actually down here. And he made this quote. He was talking about Composer and having lots of different packages. And he said, the logical implication of Composer is the ability to package reusable web-focused widgets that can be composed into applications. Now it's a very long-winded sway of saying that why do we have to have a symphony bundle? Why do we have to have a Laravel bundle? Why can't we just have a whole bunch of libraries and build our applications? Because as developers, that's what we do. We build applications. We don't build symphony applications. We don't build our framework applications. We don't care about that. We don't need to. Thank you very much.