|
|
本帖最后由 phoenixg 于 2012-7-9 16:03 编辑
转载自：http://heybigname.com/2012/05/06/why-codeigniter-is-dead/
Hex大哥不好意思，纯粹是技术讨论发这么耸人听闻的文章，欢迎拍砖，不过不要打头哦~
有兴趣的高人请帮忙翻译下！
I've written many CodeIgniter tutorials, recorded a dozen screencasts, and participated in the #codeigniter IRC support channel for years. Consequently, many people ask me why I no longer use it. I realize that this article is not particularly flattering. But, I've answered this question enough times to warrant a post, so here it is.
CodeIgniter has been the go-to framework for programmers new to PHP frameworks. It is relatively easy to use, the documentation is widely considered to be good, and there is a large support community (there are currently 140 people in the CodeIgniter IRC channel). It has stood as the most popular PHP web-development framework for years. Consequently, there are many screencasts, written tutorials, and third-party libraries available. CodeIgniter is built around the concept of legacy support. So, its design is structured around the capabilities of PHP4.
However, CI has aged poorly due to a combination of legacy support between major versions and a virtually complete lack of leadership. Despite the emphasis on legacy support, recent versions of CI require PHP 5.2. PHP 5.4 is the most modern stable release and 5.3 is now available on any reasonable host. (If your host doesn't support PHP 5.3 then jump ship as soon as possible.) By providing legacy support (changes to the framework rarely require any changes to your code-base) CodeIgniter has been unable to implement any of the features available in 5.3 that give developers more flexibility to create elegant solutions to problems.
Since CI doesn't use any of the new features, best-practices suggest that its users should avoid them in order to provide standardized code. It should be easy to find and hire a PHP developer who is versed in CodeIgniter and mismatching a bunch of code-styles is a bad way to approach that goal.
When it comes to code modularity CodeIgniter is one of the worst performers in the industry. CodeIgniter is not built using any modular design pattern so all solutions are after-thoughts that were developed by members of the community. Out-of-the-box CI supports libraries (basic classes), helpers (global function declaration), and plugins (the same as helpers, these are not used). These are all different versions of the same concept separated by intent.
There are some third-party modularity solutions available. The oldest and most powerful of these is Modular Extensions by wiredesignz. It allows the implementation of HMVC modules. Unfortunately, in order to implement this he was forced to permanently alter core system files and this makes the code brittle. Issues can easily arise from upgrading CodeIgniter. As a long-time member of the #codeigniter IRC support team I can attest to the amount of issues that users end up running into as a result of this implementation. The fault is not so much on the code that drives Modular Extensions. But, on the fact that it's essentially a hack designed to expand a system that fundamentally rejects modular code.
Another third-party system released for CodeIgniter is Sparks (getsparks.org). I was a big proponent of Sparks at first and made a number of screencasts that encouraged its use. But, it quickly became apparent that Sparks is the worst form of code modularity currently available for popular PHP frameworks. The core concept seems reasonable enough. It's a command-line tool for installing packages that pulls from git repositories, supports server caching (removal of the original repo doesn't kill the spark), and versioning. These are all good things. However, it falls flat on its face due to the fact that it can't offer more than CodeIgniter itself does. Sparks can only provide libraries, helpers and config files. This limits its function to a central repository for CodeIgniter libraries. Unfortunately, it fails at that as well due to the fact that CI developers cannot rely on the libraries that they need being available within the Sparks system. A Google search ends up being the go-to method in the end, rendering Sparks useless. It is now apparent that modular code solutions have no place in the world of CodeIgniter. These are symptoms of a greater problem.
CodeIgniter was conceived by Rick Ellis of EllisLab. It is now community supported to some extent, but still seems to wilt under its creator's needs. CodeIgniter is the platform on which EllisLab's flagship product (ExpressionEngine) is built. In part due to the preoccupation of EllisLab with ExpressionEngine change to the CodeIgniter framework has come infrequently and the magnitude of the changes have been insignificant.
CodeIgniter Reactor was released so that the community could make changes and improve the framework. Unfortunately, due to the fact that there is no strong or dedicated leader, improvement to the framework has not occurred. One could easily argue that CodeIgniter 2.0 brought only minor usability improvements at the cost of dropping PHP4 support entirely. The CodeIgniter development team is either too busy with their other projects or just not sure what CI should become. It's no longer the framework for legacy support and it begs the question, "what was the purpose of dropping that support?" as users have seemed to have gained little in exchange.
When it comes to community participation only the most daring need apply. CodeIgniter is not well unit tested. This means that there is no way to responsibly make pull-requests as you're unable to test whether or not your changes have unexpectedly broken something. There was a time when this was the standard in PHP but as a community and as an industry we're past the point where that is acceptable. The community has been trying to catch up and to create tests for CI but in the last few years very little real progress has been made as the task of retrofitting CodeIgniter with unit tests is Herculean.
In summary: CodeIgniter has proven its inability to change and it can no longer compete with the feature-set or practices found in any other modern PHP framework. When I say that CodeIgniter has died. I don't mean that nobody is using it. I'm saying that CodeIgniter has nowhere to go and can become nothing more than it is.
Solution: Don't be content exploring only a single framework. CodeIgniter is lauded to be easy to learn. It is that. But, so are other frameworks. Do your due diligence and find what best serves you and your organization. Without experimenting we can't truly understand what we prefer. It's far easier to identify strengths and weaknesses when you have something with which to compare.
I use Laravel.
UPDATED 5/21:
There has been a lot of response to this post, some of it negative. I'm going to take some liberty to clarify my position.
I made a few key mistakes while constructing this post. The first is that the title distracts from the actual information in the post. The second mistake was to advocate Laravel in this post as some have assumed political motives, which is simply not true. These mistakes have distracted and confused the issues.
The assumption that I simply became bored with CodeIgniter isn't the case, and it ignores the issues that I discuss in the post.
I acknowledge that there is responsibility inherent when one provides and promotes educational resources. However, I disagree that responsibility should embargo unpopular ideas.
I'm not interested in intellectually or emotionally strong-arming anyone. I express my ideas because I believe that there is value in that. I believe that the otherwise warm response to this post is due to many users having similar experiences and perspectives on the subject.
I value the perspectives of others and you should feel free to contribute to the lively discussion in the comments.
|
|
IP卡
狗仔卡
发表于 2012-7-9 15:55:31
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡