[eluser]Alucemet[/eluser]
Jonez, I just want to comment:
I still maintain and actively develop CI applications. It's not so bad, but without all of my "hacks" (which would take countless hours to code from scratch), CI is a little weak. Maybe the same could be said for any framework.
Maybe you're right about the Auth. I really don't like some of the popular CI auth libraries, and if one of them were the official auth of CI, I may have chosen another framework. I do like my own auth library, so maybe it's just my desire for that to be built in to the framework, or something else that is usable, that makes me consider it a requirement. I can't remember the last project I did that didn't have some sort of need for Auth. Yes, the auth requirements change from project to project, but there ought to be at least some driver based auth solution. CI would be better if it had "standard auth", "facebook auth", "etc", "etc" auth drivers. This is a huge thing. Maybe me and you are smart enough to pull off a good auth library, but the majority of devs simply have no idea where to get started with this. They find 10+ auth solutions as they search the internet for one, and then they choose the wrong one because of X, Y, or Z.
The SSL issue is primarily a need for the URL helper and FTP library to do some of the following things:
1) Create secure links even when the current page is not secure.
2) Create standard links when the current page is secure.
3) Create links that are secure if the server has SSL enabled, but not secure if it doesn't.
4) All of the above applies to anchors too, and site links.
5) FTP library currently offers no secure connection, and there are no other options. I end up using phpseclib.
Autoloading; I just want to type as little as possible. For the fraction of a fraction of a second that autoloading might cost me, I willing to make that sacrifice so that my fingers still work in 10 years. Also, being able to use the PSR-0 or PSR-4 autoloading is pretty cool. No more $this->load->library('X'); This doesn't seem like a big deal, but as applications reach the point of being considered huge, it's easy to forget about loading. I want to forget about loading!
Yes, overloading in CI is very simple, unless you want to make a change to the DB classes, then you're kinda screwed. I've done it, and done it the right way, but man what a waste of time.
Flexibility... I mentioned it because in my own framework I've managed to use dependency injection for everything, yet at the same time can access everything using static classes. It's like 2 for the price of one, and everything is autoloaded. I don't know what other people are talking about when they mention flexibility, but that's my flexibility. I've also set up my config class to use "dot" style syntax like Laravel. This is really nice compared to CI's flat config array. Yes, you can nest arrays, but retrieving is more complex. I don't know if there is anything big in the way of flexibility, but all the little things add up.
So, in conclusion, I think I'd rather not use anybody else's framework again. Having my own and being able to do whatever I want with it is priceless. I still use CI daily, but my "employer" has already said that we are never upgrading to 3.0 because of the license. To me the license is a bigger issue than anything else, and it's one of the things that makes 3.0 useless to me. I can never count on benefiting from CI 3.X+, unless I want to break the rules of the license. I feel ripped off. I spent years getting into CI, making it work for me, and then hit in the face with a license that sucks. Now they just want to give it away? Heck, if they'd just change the license to MIT or BSD, then they'd really be giving it away. I could only expect that greed has some bearing on their decision not to do so. Do they just want to have their name attached to CI and all derivative works for eternity?