So, after you read my first blog post, you can see, that I'm a strong believer in the use of frameworks. But there are so many frameworks out there! So why did I choose Laravel out of all of the possibilities?
At the time that I was choosing a framework, there were several main players:
Don't get me wrong, all of these frameworks are good and have their benefits but these were some of the leading factors that pushed me away from the other ones.
The fate of CodeIgniter was somewhat questionable. Around the time I started developing some of my projects, the main company that was supporting it was abandoning ship so I wasn't too sure about the status / livelihood of it at that point because of that, and it was built for an older version of PHP and from what I had read, the code wasn't updated to make use of the newer features which made it so that this framework was not the one for me.
I had tried both Symfony and Yii before, but I got confused in them. There was stuff that magically worked (which is awesome) and stuff that you had to do. I ended up scrapping those because I never really got into the flow of working with those.
I had a friend who was friends with the creator of CakePHP he got some decent say into what was going on. However, he also said that it felt and was very bloated which immediately deterred me from using it.
Which brings me to Laravel. I started playing with it back in the day of Laravel 3. After a little ramping up, it just clicked with me. At the time I was just starting up a freelance project and decided it was the best approach because it does follow the "Model View Controller" approach, and it was starting to gain a little bit of steam in the PHP development community. The thing that really struck me was how flexible it was. I could literally just "plug stuff in" and it works. Or, if I don't like how one thing is configured in the main framework, no problem, I can tweak it in my own area to better suit my needs!
The best part about it is that they supported closures! For those of you who do not know what closures are, they are essentially ways of scoping things into a function call. With Laravel, if there is a value at that point in time, it will just use the value otherwise it will call the function (even an anonymous function) in order to derive the required value(s). This was a huge plus for me! It means I can easily inject more logic as I need to.
After that Laravel 4 came out. I was hesitant! I started using it (and composer) for the first time and for me, it was a nightmare! Sure, part of it was me being new to using composer and how the library dependencies worked. But, after a few days of struggling, and several bug fixes later, I started working and enjoying Laravel 4 as much as I did Laravel 3.
After the initial ramp up on Laravel 4, I found myself excited to code! And, now that I knew how composer worked, I could make my own packages to help other developers using Laravel! I was on cloud nine! That was when I built 4 different packages for Laravel:
Then they came out with Laravel 4.1 which required lots of changes to your existing code but it did feel like it was working better. I took that as an opportunity to build up Virtual Pet Directory. And did it ever feel good to be coding.
Now here I stand mid-November and Laravel 5.1 is out and guess what? Long Term Support! Taylor Otwell from Laravel has now said "this is our best incarnation of the framework, we will now be supporting it for the future". For a developer, and an owner of a site, this is a huge win. It means I can now code with confidence that if there are bugs, they will be resolved and pushed forward in new releases.
Over the last 3 years, Laravel's core community has jumped in between a few sites. They started directly on the main Laravel domain, and now finally reside over on Laracasts. What is Laracasts you may ask? Well, Laracasts is an incredible resource made by Jeffery Way, who is a Laravel enthusiast and an amazing teacher. Through this site, he teaches things such as best practices, cool new features of both Laravel and PHP. He has several in depth breakdowns of what is actually going on in the Laravel framework and it is just an invaluable resource for anyone starting out. And, if you still have questions about how to do stuff in the framework, then all you need to do is write on the discussion forums and a lot of people are willing to help you out.
Laravel is still actively being developed and has a large number of contributors who all do their best to improve it with commits going in each day!
So, to conclude I have a few reasons why I chose Laravel for my primary framework and they are:
Thanks for reading :)
Posted in laravel
I've heard and seen the following so many times. "Why should I use a framework when I can just code my own framework?". Or, "using a framework slows down the application, and I need it to be speedy. So I need to use raw PHP". Yes, those two statements are 100% accurate. You can build your own framework, and technically yes your code would hypothetically speaking be faster if you wrote barebones PHP.
However, script speed isn't the only thing you should be worried about!
There are several PHP frameworks out there that are being fairly actively worked on. Let me ask you a question. What do you think would work better? An application/framework that is being developed by one individual who has a certain set of skills? Or, would you rather use a framework that is being actively worked on by a bunch of software developers around the world who are actively talking about ways to improve?
To me, the answer is simple. Use the framework. I have been developing software for over 10 years now, and I still find myself learning from those around me. Be it through code reviews from co-workers, or from merge requests and issues logged from other people on GitHub. Yes, I have a fair bit of knowledge but everyone picks up things differently. Could I make a decent framework? Possibly, would it benefit from other people's input? Probably.
The fact that something is "open source" doesn't mean that there is nobody monitoring check ins and updates for it. Take Laravel for example. When I wrote this post, there is a total of 294 people who have contributed fixes to the framework. However, they have core maintainers. It is these people (who are normally core to the project and have proven themselves already), that are reviewing every check in that someone does and making sure it meets the standards that they wish to enforce.
"I like to know everything about what is going on in the application". My answer to that is who cares? Do you know how the operating system that your application is running on works? Do you know the inner workings of PHP converts the code you write to code that the computer can understand? Likely your answer to both of these is "no", so why do you need to know each and every inner working of the application too? Yes, it helps when you are trying to design and write the code (to some degree), but it shouldn't change your mind. Treat the code that they give you like an extension on the PHP language. But more than that, let it help guide you on what some best practices are / may be when you actually start building your application.
"It is all written by other people, so there could be bugs." Yes, this is true. Just like PHP can have bugs. Code has bugs no matter where you get it from so don't let that be a deterrent. Is your code 100% bug-free? Probably not. So why not let others handle the core of the framework while you reap the benefits when they have bug fixes available? Lots of frameworks use unit tests in order to test and validate each "unit of work", so they work on proving their code works. And if a bug is found, more unit tests can be added to ensure that they don't crop up again.
If you write your own framework, are you able to search Google for your specific issues that you have? Likely not because it is fairly hard to give enough information if you built a framework because you need flatten it out as much as possible. With a framework, you are able to Google the framework name you are using and your particular question. Or, post on the framework's forums. Both places will likely get you a much better answer and, depending on how active the community is you could have a response in a matter of minutes. Sure there are moving parts, but there are also more people willing to help to lubricate them. So why not?
"But there is so much to learn if I use a framework". Yes, yes there is. Learning curves aren't necessarily a bad thing. They are a way that you become a much better and much more rounded developer. They help you to flex to expand what you know which in turn allows you to make better decisions going forward.
"What do frameworks buy me?" Most frameworks come with at minimum an easy way to interact with your database. By profession, I am a database developer. So I don't mind writing SQL queries. But if I'm given the option to have them auto-generated based on a object, why wouldn't I take it? It's 1 less thing that I have to manually do. It's these small efficiencies you gain through the development of an application that allow you to:
Not writing SQL queries isn't enough for you? Then how about the fact that for the most part, the use of a framework will not necessarily force best practices on you. But, they do their best to help push you in the right direction! I've seen so many sites which have code that is a nightmare because essentially every layer is tangled together. You have the database being directly summoned by the front end and huge "if-then-else" statements that start forcing more and more levels of indentation which can get confusing. I'm not saying you can't do this in a framework. But, after using it a bit, you will quickly realize that it is not the right thing to do. The "Model View Controller" architecture has been around since the late 1970s and is still a prominent setup. Because it pushes you to ensure that every section does it's own work and that is all.
Sure frameworks can cause an extra little bit of processing time in your application, but that is nothing a little extra RAM, a better CPU or even, an SSD cannot solve. If you are able to determine that those are your bottlenecks that is. For the most part we are talking milliseconds which isn't much time at all. Your system could be processing someone else's request at that time. However, you will make up for it in the amount of code throughput you can have as you work on your application.
If you ask me why do I use a pre-existing framework, the answer is simple:
Hopefully this helps to guide you in your decision of whether or not to use a pre-existing framework or to make your own a little bit easier!
Posted in programming