Linxphp and why I wrote another PHP framework
Recently I’ve been asked to explain in a forum how can it help anybody in their projects, what are its advantages or, basically, why should someone use it. And I thought it was a good opportunity to finally talk about it in a most formal way.
Being out there already a lot of other PHP frameworks, some of them very well known and having large communities of users, I think the answer to why someone would use linxphp is basically the same as the answer of why I’ve programmed another PHP framework instead of using an already existing one. The reason I’ve done this is, mainly, because how complex and restrictive most PHP frameworks are. I think that most popular frameworks (CakePHP, Sinfony, Codeigniter, Zend, etc) became too complex with the time. The feel I have about them is that, at some point, their developers lost the way, forgot that they were doing a tool for helping programmers; and instead of that, they started to make their usage more and more difficult by adding a lot to learn, restrictions and requirements. In some cases I can’t even understand how come so many bad practices got so popular and accepted between their users, like the poorly DB and OOP design in Drupal, or the HTML helpers of CakePHP (a function for printing only ‘</form>’, really?). The most common issues I see on PHP frameworks that I try to avoid with linxphp are:
- Installation Scripts: After downloading a framework, the next thing to do , usually, is to install it. In most of the cases it’s done through a nice web based wizard, but sometimes we see it done via a console based list of command, which is the case of Sinfony (WTF were they thinking!!). When it comes to CMS, like WordPress, or Drupal, it makes perfect sense, because it needs, at least, to create the database schema it will use, but I believe this is the only case when an installation is justified. The point is that you are installing a programming language script, it should be (and it’s) perfectly able to set up all the variables, such as the path to the application or the base URL, at runtime. The problem to set these values at the installation and save them forever, is that it makes your application difficult to move. When you need to deploy it, or migrate it to another server, you are forced to spend time searching where to rewrite the many settings that could be easily managed by the framework. In linxphp there are no installations. The application path on the hard disk and the URL of the application are detected an set up on runtime, which means the you can move your site as simple as a copy and paste. Even the SQL tables that you design using the ORM models are created if they are not found.
- Changing the way PHP works: A PHP developer knows, for instance, that he can find the parameters passed via url in the $_GET superglobal variable, or that the session is stored in the variable $_SESSION. For some reason, many php frameworks think this is not correct, and make available confusing alternative ways of gathering that information (like Sessions in Cakephp), or what is worst, they doesn’t allow you to access them! (the case of CodeIgniter). One of the goals I’ve set for lixphp is not to be obtrusive, you need to be able to use PHP the way you’ve learned it. No strange behaviors, no need to learn something new.
- Useless tons of libraries and modules: When you’re starting a project, depending of your framework of choice, it could take up to 300kb or 7MB. Why is the size of the framework so important? Because it gets loaded into RAM, and it will determinate how many visitors your webpage can have before your server runs out of memory. In most of the cases, you won’t need to use all the features the framewors are providing. What they do wrong is to develop libraries that offers features that PHP already have, like template engines (special mention to Smarty, the dumbest project I’ve ever seen). Or features that you can find in third party libraries, which are focused in the solution to one problem and will surely do a better job resolving it. One of the priorities of linxphp is to be small and provide solutions only for the things that you are more likely to need, I’m sure that out there are stand alone libraries to use for the rest of the problems.
- Restrictiveness: Most frameworks, when defining their patterns, tends to be restrictive to the user. Something very awful about CakePHP is that the view you’ll show by default needs to be named as the controller. You need to write extra code if you want to avoid that behavior, and you’ll need to do that at some point. That, more than a feature, looks like a bug. A framework should be designed to help the users, not to put obstacles in their path. What I want to achieve with linxphp is to define a guideline of work, not a rule.
At this point you may think we are a bit conceited about our framework. But we don not want to make the best php framework ever, we’re just trying to avoid these common issues. With some luck, we may not make the same mistakes, but we know we’ll certainly make others because nobody’s perfect. I don’t consider ourselves specially brillant, but our experience of more than 10 years in PHP development teached us what we don’t like about it. So, basically, we’re doing this for us first, because we work at web development and we need a framework to feel confortable with. But if someone else can be benefited from our work, much better!