I’ve read a lot about frameworks over the last few days, but there are a few things that makes me uncomfortable about frameworks. I decided to ask you to make a good decision.
I’ve never used a PHP framework.
1-) It seems that every PHP framework is updated and changed over time, so we’ll have to keep changing our codebase regularly (whenever they decide to release a new version), is that correct? For instance, laravel5 has no backwards compatibility, so every codebase that has been written in laravel4 will need to be converted into laravel5, right? I think it’s a bummer.
2-) I already implemented a logic (I don’t mix HTML with PHP, created different folders for core functions, use OOP, etc) and I use a mysqli wrapper class to make my queries secure and short. Should I use a framework anyway?
3-) Can I still use native PHP code in my script without any conflicts when I use a framework or do I have to do everything with the framework’s way? Currently I have a large codebase, so there is no way I could convert it into Laravel in a short amount of time.
I think it’ll be better for us to create our own framework when the time is right (it’s not now), so we’ll have full control over documentation and codebase.
I haven’t used a PHP framework either, but I use Django (a Python framework). So my advice is based on that, not sure how well it translates to PHP frameworks.
So really Django facilitates a number or really useful concepts:
Dont repeat yourself: The idea here is to create your project in a way that minimises writing the same logic more than once. This includes removing verbosity suck as querying the database and extracting the data into data structures which you use in your middleware.
The stucture of the system you build is relatively standard, so a django developer can pick up a project and understand it much quicker than if you don’t use a framework.
Re-Usable logic: You are encourages to write components/apps which can plug into any other django project and used straight away. This includes the component creating it’s own database tables it needs automatically, even if the other project uses a different type of database!
Standardised testing: You write unit tests as you go, and can at any time run a project wide test that makes sure that what ever you have written passes those unit tests. This saves LOTS of time in debugging.
scalability: Frameworks generally encourage you to build your projects in a way that can be easily scaled up if they need to be.
Fast re-factoring: Because your data is based in a model, to change it, you just change the model and those changes are rolled through to the database automatically. The model api is also automatically updated, so all that is left is to amend the finer parts of the logic you have implemented, and test it!
Security: Frameworks generally make it harder to introduce big security vulnerabilities, and easier to prevent them.
Why not try CodeIgniter? It is less than 4 megs including comprehensive documentation.
Try uploading to a sub-domain, connect your database and gradually convert existing pages.
Usually important patches can be updated by including the updates in a single line in the common index.php file. I think you will like it just for that reason alone!
It’s true that Laravel has been a bit too ‘relaxed’ about breaking backwards compatibility in the past, although the extent of the changes are often exaggerated. Many people claim that the switch from v4 to v5 takes a couple hours at most. I believe the latest version of Laravel is a LTS (long term support) release, meaning that it’ll continue to receive bug fixes for several years. At the end of the day though, if you’re following good programming practices, your model layer should only be loosely coupled to the framework you use, which should reduce the time and effort it takes to upgrade the framework.
If you have an existing codebase, it may not be worth the effort to rewrite it using a particular framework. It might be a better option to gradually replace sections of functionality with 3rd party components (take a look at Composer, if you’re not using it already). This would give you more flexibility to choose components/libraries that do what you want in the way that you want, while having the benefits of well maintained and tested code. It’s also easier to take this approach than trying to rewrite your app using a framework.
It depends. If your business logic isn’t tightly coupled to your ‘controller’ code, then you should be able to reuse it with minimal effort. However, anything that deals with requests and user input would probably need to be rewritten to use the framework’s infrastructure.
In my opinion, there are very few circumstances where writing a custom framework is the right way to go. For prototyping and smaller apps, a framework will make you more productive and remove the need to write a lot of the tedious, boiler-plate code that you need for every application.
If a full framework contains a lot of functionality that you don’t need for a project, or you have some specific needs, then using Composer/Packagist to assemble just the components that you need can be a good option. As I mentioned above, using 3rd-party components still gives you an advantage of using tried and tested code, where many pairs of eyes are involved in spotting bugs and providing fixes - this is a huge advantage over relying on code you’ve written yourself.
If your asking the question ‘should I use a Framework?’ then the answer is nearly always ‘yes’ if anything to make yourself a better programmer and educate yourself about how others are doing it.
Once you get your head round a couple you will doubt have a few reservations about the framework of choosing and may want to switch down to a microframework or just start bootstrapping everything via composer.
I really want to take a step and want to write better, faster and more secure code, but since there is a learning curve while learning frameworks and they keep changing themselves, I was hesitant to do it.
This is a fact of programming life. It isn’t just about frameworks, it’s about technology. Technology changes and either you change with it or you don’t. If you don’t, you run with possible additional risks, one of them being reduced security. So frameworks don’t change for the whim of changing, but because technology changes. The language changes. The supporting software changes (i.e. database, web server, etc.) Concepts change. Coding methods change. And, in most cases, these changes are for the better. In other words, your code base should be changing and evolving too. If it isn’t, you are running with those additional risks.
Popular frameworks have a larger user base. Because of this, they can find bugs faster and fix them. The other side of this coin is, bugs are more public and if someone knows you use framework X with security bug Y, if it isn’t fixed very quickly, you are open for possible attack. A good framework’s development team fixes security bugs very quickly btw.
This is a development decision that is often inevitable. What was one way of doing things in the past no longer holds true today and you shouldn’t stay stuck with old legacy code for the reasons I mentioned above. If you programmed with OOP correctly and the framework did too (less coupling and proper cohesion), then it shouldn’t be too hard to upgrade gradually. You might want to think about Symfony, because they have a very good sense of both staying modern, being very modular and also giving support for older versions for longer periods of time (LTS). This long term support btw, isn’t done so you can sit back and not have to update your code, but to spread the cost of updating over more time. To do it slower and more methodical. Refactoring should be a constant practice. Fix bugs, refactor old to new, do newer stuff aka, add features. Wash, rinse, repeat. That should be your software development cycle.
If you are eyeing Laravel (or any other framework), think about how modular it is. For instance, I was just looking at Blade and noticed it has a dependency on Laravel’s View and Events components. That, to me, ties their templating system very much to the framework. This is not a good thing really, because then you can only use Blade with Laravel. This kind of hand tying of components to the framework is something Symfony is trying to break (and doing a good job at it). For instance, you can use Twig without needing Symfony.
The next step in my mind is getting client code to be more “framework agnostic”. This is a really hard goal and I am doubting it can be reached, simply because every API is it’s own API with its own specifications.
That is why I feel the next best thing is a framework of uncoupled components and you can mix and match to make your own framework. This way, you can create your own opinionation.
This is a good step. I am at this point too and I am writing my own mini-framework as a learning experience. When I get to a point, where I am not certain what to do, I go look at Symfony or Laravel or some other framework to see how they are doing it (or I ask questions here! ). Sometimes I like what I see in a framework. Sometimes, once in a while, I don’t. I am too much of a noob to know any better too.
One thing I’ve learned, frameworks do have those built in “opinions”. Things like Symfony’s “actions” or Laravel’s slight deviations from the PSR coding standards. You either like them or lump them. But, yes. They usually are chock full of knowledge to learn from to code better. Not all are perfect and follow best practices to the tee. For the most part, they will help you with your goal to learn to code better, both from a framework and client coder perspective.
