Laravel or CodeIgniter

Depends on your level I guess. Codeigniter is a good start, Laravel is much better designed (using modern features as IoC) IMO. From what I've learned in C# coding mechanics, Laravel is the better fit.

I would choose Laravel, I actually switched my new projects to that in April. I was going to start a new one and I was thinking to go back to Ruby on Rails, but then I decided to try Laravel and I like it, very much. I've been using CodeIgniter a lot in the last five years, for little to medium projects, it's easy to use and relatively easy to modify. But lately Ellislab dropped CodeIgniter development, they are seeking for a group interested in continuing the project:

• http://ellislab.com/blog/entry/ellislab-seeking-new-owner-for-codeigniter

From this point of view it's not a great news because there is no certainity of the future developments, and if it will ever support last versions of PHP.

My PROS list about Laravel 4:

• good ORM library (Eloquent) which reminds me a lot Ruby on Rails, it's really easy to create relationships between tables, it supports soft deleting and you can use multiple databases concurrently
• good command utility artisan which helps writing CLI scripts or asynchronous jobs, migrations scripts and resources
• it's easy to create APIs, you can use HTTP verbs to interact with resources, it supports Auth Basic and you can also build your own mechanins by creating your filters
• good template system: Blade
• you can group and prefix routes, and also you can create named routes, I find this powerful because it gives you the ability to switch languages really easy
• it's binded to Composer project which gives the ability to easily include third party code in your application: https://packagist.org/
• it's easy to create libraries and indipendent packages to integrate the application

I don't like much their documentation, because it lacks some information, you have to search a lot, especially in the github issues lists to get some good input, or browse directly the API source, to get some undocumented functionalities. But I think it's a matter of time, it's still new and the development was really fast.

Like what Pritaeas and Cereal said, Laravel is well coded from the beginning to end. Laravel is also built upon Symfony Components without the Twig. I have seen questions on the web asking which one is better Symfony or Laravel. This question seems to be valid and yet Ignorant and extremely mal-informed. Laravel will not exist without the Symfony components and foundation. The founder of Laravel even acknowledge this, because of one of the person at the convetion asking him, if he want to close Symfony's door. His response was " We would never existed, if Symfony does not exist". So, what this means is that, the dependency of of Laravel's core to symfony is pretty high.

So, to add answer to your question, I would choose Laravel over CI, because it uses components that are regularly updated.

Here are the framework questions that are pretty confusing, unless you are extremely active in PHP community. I mean active at the core where all of the changes and developments are announce.

CakePHP -- Pretty much on its own, except for some contributed plugins and modules. Composer ok

Zend -- Pretty much on its own, but have enough resources to lead the framework game. No matter what convulated opinions we picked up from the web, Zend is not going away. They are pretty much part of the governing bodies that drives the evolution of PHP. Unless, our 3rd grade teacher who barely read technology news, said it is not true. Can take Twig, Smarty, Rain TPL. composer ok

CI -- on its own + plus contributed libraries and plugins, can take twig and Smarty template engine. Does not support Composer ( only the distro from source).

Kohana -- Built on CI + Symfony + ORM , can take twig smarty as template engine. I believe this is the Fastest of all Framework. Don't believe what I said.. test it and give it a short spin. Composer ok

Laravel -- Please read above,, this is your question

Symfony 2 -- From its early version, version 2 is the most polished and one of the most promising MVC framework next to Zend. Symfony knows the ins and outs of MVC pattern. I can't even compare Symfony against Zend because they are almost the same but they are completely different. It is like comparing two mountains that are equally tall, but miles apart. Symfony is very powerful framework, especially its foundation libraries and modules. Most frameworks uses these libraries including "Laravel". If I have to choose between Laravel and Symfony 2, I will take Symfony 2. Why would I take Symfony 2 over Laravel? The reason is rather personal.. I just love symfony if something is build solely from the foundation of symfony, I will still go for the foundation. Besides, symfony 2 is a lot easier to upgrade. just run composer update, and you are done.

Framework that may take the community by storm, if properly developed and maintained. Watch out for these guys.

PPI -- The PHP meta framework. The creator of this framework took the best of Symfony2, ZendFramework2 & Doctrine2 and combined them together to create a solid and very easy web application framework. This framework support Twig, Smarty, Mustache, swiftmailer and they are all built-in. If they can sustain the development of this framework, I will take this framework over Kohana. Of course, they still need to work a little on polishing and letting the world know about this wonderful piece of work. If you want to jump into something NEW and Yet promising away from the spotlights and hypes?, take PPI and grow with them. Composer ok..

PPI supports Smarty and Twig..

Regardless of whatever framework you choose, all of them requires an advance understanding of object oriented programming, MVC software architetural design pattern, and design patterns. Without these knowledge, I don't think anyone can thrive in an environment built by someone or group of people who are driven by such strict doctrines and methodologies.

thanks for reading my blobberrrr...................

Laravel 4 is a shiny new speedboat while CI is a putt-putt. What this means is that you can get your hands dirty really quickly with CI and get fast results as the learning curve is pretty shallow for a framework. The coarse controls are easy to master. However, delve deeper into the engine and try to make it dance to your tune and you find that it's been cobbled together with some sticky tape and some borrowed axle grease. You don't want to push this engine to hard at 'ramming speed' for too long.

L4 on the other hand is the exact opposite IMO. If you're not familiar with frameworks, then you may find it challenging. The learning curve is a lot steeper - imagine your familiar putt-putt's tiller being replaced by a steering wheel and a bank of LED gauges. Oh dear - need to consult the manual - a lot. But then as you master the basics, pushing L4 further is easier - it has that beautiful engine that just purrs as you start to give it some gas.

L4 fan (following some lost years in Yii land).

So what are your own thoughts @iamthwee? Are you in the process of choosing, or just throwing a ball for us to play with?

BTW, every framework had its pros and cons. There are aspects L4 that drive me to distraction though. The built-in localization class (like many frameworks, though). Why the hell can't they just use simple gettext? But no, they have to fanny around with it. Small rant.

Guys...

This is my situation. I've just recently acquired a fairly big build job. In my head I can roughly see where and what I need to do. As usual, time is of the essence so I don't wany to mess around too much learning a framework with a steep learning curve.

I wish to use correct practices so using a framework and MVC pattern is appealing to me. I already know Code Igniter has brilliant documentation and has a fairly small learning curve.

Bear in mind, I've never used MVC so in effect I am dipping my toes.

The other appeal is that there are already a load of youtube videos which I can easily run through. I'm sure this is the same for laravel but there doesn't seem to be as many and the documentation isn't that great.

I realise Laravel has things that CI doesn't but I'm looking at it and it seems too abstract for me, in other words, I don't find them useful.

I build my db queries using a query builder. This is fine for my needs. SQLeo is what it is called.

I'm not quite sure about templates, or using a templating engine like smarty. Again I think it is too abstract for me to begin with.

There will be a lot of custom jquery, and custom css... If the framework gets in the way then I don't think the framework is working for me.

So all in all, I'm happy that CI covers the basics that I need. Sessions, passwords, login systems and file uploads.

The rest I can build in as it will be highly customized, so I'm not even sure how good Laravel will be as it will not afford be any extra productivity.

I totally understand your situation and I have no disagreement whatsoever, but I have a few concerns about CI. It is no longer maintained by its creator. In fact, Ellis Lab don't want it anymore and it is up for adoption.

Pretty soon, it will show its age. PHP is now in version 5.5.3 two weeks ago it was version 5.5.1. The last update on CI was not even disclosed. CI don't even support Dependency manager for PHP, while the rest of the framework already did (big and small). Even, the smallest template engine called RAIN TPL is Dependency manager supported.

If it is a big job, I am happy for you. However, how are you going to control the PHP version on the server side. Unless, you have control over the server where the application will be hosted, I could see the possibility of controlling which PHP version installed on the host.

If you need to get it done yesterday, then of course, just get it done. Just a note on MVC. CI is very relaxeed about MVC - in fact - it isn't very bothered about models at all. L4 is far more rigid and expects high standards.

SO in your shoes, I'd just get on with it and use CI for this project - no time to phaff around. Support material (videos, forums...) for CI is extensive, so you won't go far wrong. :)

Just to say, thanks for all the advice guys...

I'm opting for a CI workflow and seems to be working just nicely. I guess when I get properly into MVC I'll switch to laravel.

But CI with my own jquery and an 'agile scrum' workflow seems to be working for me. No doubt I'll have more questions down the line.

I only have experience with one project (DaniWeb), and only experience with the one framework (CodeIgniter) that powers said project. I went with CI because I didn't have any previous experience with MVC and it seemed like a good introductory framework that is both lightweight and has a lot of built-in functionality that I use. However, when I was deciding, I was hearing a lot of great things about Yii. I don't have any experience with it myself, but how does Yii compare against Laravel?

Update: The fact that CI is abandoned does worry me significantly, I'm not going to lie. However, I think there's a big enough community behind it that someone will ultimately take it over.

That aside, if you are in the same boat I was, which means you wanted to get up and going fast, have no previous experience with MVC, and feel it has a good sampling of built-in libraries and functions, then I would recommend CodeIgniter for a build-to-hire project because, odds are, you're going to build it, make some money, and move onto the next thing. You're not like me where whatever you decide on, you're permanently tied to for the next decade (as I was with vBulletin).

Thanks Dani, very helpful.

It seems CI is the way to go for my personal situation.

You're welcome. In case you couldn't see where I was going with that, I meant that the fact that CodeIgniter is semi-abandoned or has a bleak future shouldn't influence your decision with a one-off build-to-hire project, the way it would have influenced my decision had it been known when choosing what to use for DaniWeb.

Guys another quick question. Although CI is no longer maintained does that necessarily make it unsafe?

I tend not to jump on the bandwagon. For example, I've been using Dev-cpp for years and despite the fact the IDE is no longer maintained you can still produce robust and safe c++/c code.

So really, (apart from all the cutting edge crapola) ORM, artisan and composer, which to me just seems like hyped acroynms why is this even important.

Sorry, to be naive... but I really don't see why there is a hurry to switch over?

The IDE you use is ultimately just a feature-rich editor. Your C++ code ultimately behaves and functions pretty much the same regardless of which editor or IDE you used. A buggy IDE can make it a bitch to code with, but only you, the coder, would ever be affected.

Frameworks are an integral part of the finished product. When it comes to a framework, any of your own code is called from within the constraints of the framework (in fact, your code can't stand alone), and essentially is only ever as secure and stable as the framework itself. Any bugs, issues, potential exploits or security breaches in the framework would always carry over to your finished product.

The only thing I'd be a little concerned about (not very much maybe), is whether code completion and hinting, for example, are maintainable with successive releases of the language. e.g. PHP, is the functionality working with v4?!
Some IDEs have framework plugins, so it may be worth your while looking at these - it could save you a considerable amount of time - especially with code hinting - so you don't have to constantly resort to the manual - or that horrible dropdown menu tab on the CI site.

For example...

http://www.codelobster.com/codeigniter.html

Not a plug, haven't tried it.

I honestly believe that they are important as follows:;

Composer, ORM,http-foundation (from symfony), class-loader from symfony, and native autoloader from composer are probably the most needed if you want to built an application on top of symfony or anything from the packagist.org. In fact, composer allows us to use Zend libraries if we want it to be a part of our application.

It is also important if you want to follow the proposed standardization mainly PSR 0 - 3 standards. Although no developers have had their arms twisted to submission, I finally understanding the reasons behind these proposed standards.

In a classic OOPHP/MVC application design pattern, we normally do things like this

autoloader.php
bootstrap.php
index.php // this routes to view via .htaccess
.htaccess

applicationDirectory
    +Controller
    +Model
    +View

classDirectory
    +classOne.php
    +classTwo.php

includesDirectory
    +SettingsDirectory
        +DBSettings.php
        +SiteSettings.php
 modules
     +modulesOne
         +mouduleOne.php
     +modulesTwo
         +mouduleTwo.php

The above design is pretty congested. Looking at it, can give anyone a serious headache.

In the event that a file/directory or files/directories are deleted because the application does not need them anymore, how are going to update our application file system mainly-> the bootstrap, and autoloaders to reflect the changes made in the application? That would be excruciating right? Imagine, if we have 10 php file requiring or depending to file/s that already been deleted.

The solution to this problem is to use composer (Dependency Manager for PHP).

By utilizing composer we can build our application as dependency aware.. We can delete any files or directories within the vendor directory and then just run

composer update

the autoloader will be updated including the applications dependency. This is made possible by one autoloader only concept.

In composer assisted application, directory structures follows the PSR standards. So, the above not so organized file structures can be build with composer in a much much cleaner structure.. The vendor theory.

application
    +controller
        controller.php
    +model
        model.php
    +view
        view.php

vendor
    +bin
    +symfony
        autoloader.php
        classloader.php
    +smarty
        smartyClass.php
        bin
        plugins
    +doctrine
        +orm
    +yourOwnClasses
        classOne.php
        classTwo.php
    +modules
        mouduleOne.php
        mouduleTwo.php
    +managers
        dbmanager.php
        dbSettings.php

   autoload.php  

index.php
composer.json  

Say, after the development the team voted down the need of the modules directory and everyone agreed to just completely eliminate it from the application, we can literally delete the modules directory, and then run this composer command

 composer update

the autoloader.php in the vendor directory is updated. If we want the classes in the YourOwnClasses directory to be included in the application we just update our composer.json like this to reflect the new dependency of our project

"autoload":{
    "classmap":[
    "vendor/YourOwnClasses"
    ]


},

we can also set the minimum stability of our application to development or stable release..you decide which one.

WARNING! the minimum should be set to dev..

"minimum-stability": "dev"

or

"minimum-stability": "stable"

We can add and subtract modules and plugins as our application shrink or expand. For example, if we don't want the the doctrine/orm , because we found out that kohana ORM is more flexible, we can delete the doctrine directory and then add this to our composer.json

"require": {
"kohana/orm": "3.3.*@dev"
},

Just delete the require entry for the doctrine, and then execute the update

composer upadate

We can continue to shuffle things until we found what configuration is more suitable for our application.

I honestly believe that Composer is not bad after all. I mean this is pretty darn excellent concept.

What is the catch for all of these convinience? As we keep adding modules and plugins in our vendor directory, the vendor/autload.php will have to carry all these files on its back ( carrying as in include_once or require_once). I have ways of minimizing these draw-backs, but my attention span is gone now... maybe later I will expand more on this..

Laravel is simple and elegant , then easy language as like as codeigniter It is simple, and also quick to set up CodeIgniter. Just download the preferred version from CodeIgniter homepage. Otherwise, from GitHub. Thereafter, unzip the contents.
Here, let us make a brief analysis and know the differences between Laravel and CodeIgniter. You can read here to know about pros and cons of laravel vs codeigniter.
http://laraveldevelopment.blogspot.in/2015/10/laravel-vs-codeigniter-which-is-better.html

Hmm. Okay, if you are going to link to your own site with regard to issues on this forum, please include some original material, otherwise it just seems like blatant advertising.