…about two years in fact since the last major version was released. I am looking forward to converting my old apps especially since PHP 7.1 is mandatory.
It’s been a long time coming, but we have frozen the CI4 initial release features, and are getting ready to launch 4.0.0-a1
We are reviewing the code, documentation, and release process, and look foward to launching by Sept 30th.
We will be asking the community to test the framework then, and report anything we missed. If needed, successive alphas will be launched every 2 weeks until “complete enough”. At that point, we will launch the beta, with requests to test the heck out of it and find any bugs.
This repository holds the pre-alpha code for CodeIgniter 4 only. Version 4 is a complete rewrite to bring the quality and the code into a more modern version, while still keeping as many of the things intact that has made people love the framework over the years.
Because of performance scalability and features. also laravel is one of the highly-used open source modern web application framework…of course many contributors to make laravel more.also lots of dependencies that you can plug to laravel…example yajra datatables…like creating pdf …barcode generator and more…
I’m sure you can do all that with CodeIgniter too, so that’s not really a reason.
I’m not saying Laravel is bad here. There are loads of people using it, so they must be doing something right, but this thread was about CodeIgniter. Let’s stick to that unless there are hard arguments to be made as to why people should not be using it cq. should be using Laravel instead.
Okay so I looked at CodeIgniter and I don’t like it.
it doesn’t have namespaces, so it’s probably relying on some sort of custom autoloader. PSR-0 and PSR-4 have been here for a long time now and I can’t think of single reason why you wouldn’t want to use those
the database uses some sort of escaping instead of prepared statements. The concensus is nowadays that prepared statements are more secure. I don’t know why they wouldn’t go with that.
the database function has a hardcoded path to the settings which is a clear violation of inversion of control. A database class should get settings passed to it and not worry about where they come from, that’s not its job.
the database connection is also the query builder instead of using a separate class for a query builder, which is a violation of both single responsibility principe and encapsulation, and is a disaster waiting to happen due to shared state.
There is probably more, but the above is already more than enough for me not to use it, so I stopped looking.
You looked at the 4.0 alpha version? Just curious. Everything you listed was true of the older versions. Bit surprised that the completely re-written latest and greatest would still have these issues.
I was assuming I was, as I was looking at the develop branch, but it turns out they’ve created a new git repository for version 4. I’ve taken a look at that and it doesn’t seem to suffer from any of the problems above anymore, which is good
The Github Repository link in my first post has the normal clone and zip download links. Latter including Documentation is about 1.5 meg. I am pleased they have kept the source “lean and mean”
