Would creating a custom php mvc framework from scratch be completely pointless for a small digital agency?
I have heard recently from a friend that His colleges are infact spending time on such a project within their agency. Their argument against using another such as cake or zend being that they come with so many unused features and therefore lots of unnecessary code.
I would have thought that such an endevour is completely pointless and indeed a waste of time and money. Surely it would make more sense to pick a framework that matches your needs as close as possible and then customise/extend it. On such frameworks as zend the code is surely going to be of a much better/tested level than that of 1 or 2 programmers could create in a few months.
It just doesn't make sense to me - can anyone pursuade me otherwise?
Using your own framework has one big advantage over other solutions. It means you have total i mean TOTAL! controll over it. No matter what happens to other frameworks, because one day you have open source software and another day it could be abbandoned or stopped project. And your framework will still be developed. Even if it means you will need to constantly add some features to it, with time it will pay off. Besides, PHP is like one huge framework after all, and it's evolving. Writing your own framework will keep you up to date with this technology :) Of course keeping with other frameworks or CMSes is also good idea, because maybe your clients will want to use them, and you can also learn from them and move some solutions to your software :D
No, I think you will find most here would agree with you - I certainly feel it is a complete waste of time. Especially given that they are a small agency, their limited resources could be better spent elsewhere.
Since they are concerned about a bloated framework, I suggest that instead they investigate using a lightweight PHP framework such as CodeIgniter and Kohana.
I see it pointless. But it's a curse of PHP programmers who tend to invent wheel again and again. I know what I'm talking about. I tried it too.
The best approach seems to be to learn a framework and if it doesn't suit you ask friends who knows other frameworks to learn how is the particular problem solved in other frameworks and if none of them seems good then MAYBE it's time to start work on a new framework.
The point with lots of unused code is not completely valid. Zend contains classes that can be stripped off as far as I know.
EDIT: Performance of PHP can be enhanced via eAccelerator for example. I find it easier than building a brand new framework.
MVC FW is less than 5% of average project code base, so I strongly recommend building MVC for every project and adapt it to the project specifications.
If someone has enough knowledge about MVC pattern and some experience in using and building MVC frameworks, it can be built in some days.
General arguments are speed and performance given by the custom FW.
Sometimes when people are afraid of changes and learning new things, they come up with all kinds of silly reasons why somethings is bad and should not be used.
I once worked in company that was determined to write their own web framework instead of using Django. One of the developers that was working on "admin" part of framework said i wanted him to lose his job cos Django has auto generated admin.
Unless is it very specific framework and you have very good reasons and enough fundings for project it is never a good idea to reinvent the wheel specially if you can't make it the same or better quality then what is already out there.
It depends on what kind of projects they do, and what are their needs. Never forget that in software, the 'best' always depends on what you are doing. There is no 'one golden solution' for everything. This includes mvcs.
There are various reasons to code your own mvc :
You can tailor it to your exact specific needs
You can keep it closed source, reducing exposure, increasing security due to obscurity
You can continue developing it, and then release it to the world when it is mature and fulfills a major purpose - a lot of current mvcs came to being in that way anyway.
You can continue developing it, keep it closed source code, and build massive SaaS services and applications on it, to which you will retain full rights. Can be done with apache license too though.
You can fulfill a purpose that is not fulfilled by any other mvc. Despite every mvc has its zealots who believe that they have the one and all solution, every mvc has its downsides. And believing that 'everything that can be done, has been done' because there are 15-20 mvcs out, is as stupid as saying 'all that can be discovered has been discovered'. And there were people saying the latter at the start of 20th century.
Not to mention that with an external mvc you are using, you are obliged to that mvc's project team for many things. They may already have or may introduce things that you dont like, or even hamper your specific applications.
Not to mention they may just get abandoned. Can happen to the biggest. Codeigniter was all the rage. What happened ? Ellis is dumping it basically. Development slowed down to a halt. Probably soon totally halting. Being open sourced does not guarantee a project either - there have been many open source projects which went similar ways.
What's going to happen to people who had coded major applications with Codeigniter ? Are they going to undertake the security of the Codeigniter installations they have themselves ? Therefore de facto becoming maintainers of their own mvc ? Or are they going to hire external parties to maintain the mvc for them ?
Not a good future investment.
My preference for coding my own mvc is mainly to have a mvc that fits my own style of coding. My criteria for a mvc :
Fast development
Fast modification
Low maintenance
Speed
Security
Extreme simplicity
Reliability in regard to future development
I have coded a major mvc for myself before. and i am still successfully running it on one of my hobby websites which handles ~600,000-1,200,000 unique visitors per month. At a given moment, 250+ visitors (google analytics - it doesnt include any bots) can be present on the site, hammering page after page. And it does not even blink. I like that. Despite it has various shortcomings that i dont like, it works spectacularly.
In the current mvc im doing, im using the lessons i learned from the previous one, as they apply to my specific purposes.
Not to mention it is a great way to hone and develop new skills.
But one thing is a must: plan it very well, and keep building on it, changing and improving it.
For any framework
Pros
get exact functionality you want
control over small details important to your project
familiarity with code
Cons
everything that breaks you must fix yourself
don't get to learn from the mistakes of the past
won't get as many bugs noticed due to smaller audience
Personally I recommend exploring existing frameworks before even considering writing your own. Just remember that it's okay if you don't understand it all in a day!
It's a waste of time. Unless they are building a site with the traffic of Facebook, the performance hits they will get using something like Yii vs. their own should matter very little
It's not necessarily a waste of time but I agree with you, I tried it myself too. I've been using Zend, Code Igniter and Fuel depending on what project that I'm working on.
The consequence that I had in creating my own framework is the deadline. If you're working on a project with a very tight deadline then creating your own framework would be a bad idea.
Related
I am building an application currently in PHP and I am trying to decide on whether to use a pre-existing framework like codeigniter or build my own framework. The application needs to be really scalable and I want to be completely in control of it which makes me think I should build my own but at the same time I dont want to reinvent the wheel if I dont have to.
Any advice greatly appreciated.
Thanks
Use an existing framework.
First of all creating a framework from scratch represents a massive investment in time and effort. The process involves a lot of trial and error, because you're designing something that needs to be both simple and powerful. For every design decision you'll have to ask yourself how it will affect every single future project that will be built on your framework.
You'd think that you could take each design decision and weigh it against the requirements like you would do for any other software project, but the thing is you don't know your requirements. You can't know them, because a framework is supposed to be able to do almost anything (or have the ability to be extended to do almost anything) within its domain. Future project a will need to be able to do x. Can your framework allow that without turning it into spaghetti code? And what if project b needs to do y? What if project c needs to do z?
Have you predicted everything?
Now the normal response to this is that if something doesn't work, you'll just change it in the future. It's software after all. A framework however isn't like a simple application. It's supposed to have an interface and once you expose that to the software that will be using it, you can't change it. You can extend it, but not change it. So now you have to think about deprecating methods, api versions and version compatibility. It's a whole new set of problems to deal with along with normal framework maintenance and new application writing.
Then there's documentation. You need an API, tutorials, example code. Once you build your own framework you have to deal with this as well. You could ignore it, but I assure you that eventually you yourself will need to find out what that method you wrote 6 months ago does. What does it return? What if special case x happens? Have you written all that down, or do you need to step through the code again? And I wont even mention how easy it will be for a new team member to get started on a custom framework whose documentation lies completely or at least mostly in your head.
You also have to acknowledge that unless you're working with the very best and brightest (and have a budget to match) you'll never have the extensive set of libraries that existing frameworks boast. Can you analyze, design, code, test and debug faster than an open-source community?
Finally you should ask yourself if you are proficient enough to be writing a framework. Have you dived deep into the code of a modern OO PHP5 framework to find out what makes it tick? And most importantly do you know why it does things that particular way? Keep in mind that any mistake you make in your design can blow up in your face months from now and you can end up paying for them over and over again.
To sum things up I'd advice you to go with an existing framework; it doesn't mean however that you have to pick one and like it. Take the time you'd otherwise devote to developing a new framework and devote it to learning an existing one. Then you can extend it to fit your needs. Also remember that there could be things you wont be able to do. But I assure you there would be things you wouldn't be able to do with your own framework either, so it doesn't matter all that much. A framework imposes a few limitations. It's the price you pay for being able to develop applications faster.
Make a list of requirements for your framework (ORM, PHP 5.3, PDO, etc). Then iterate over the existing frameworks and narrow them down to find the ones matching with your requirements. Then look at the codebase, documentation, community, project activity – does it feel something you would like to work with? Also be realistic about the time needed to to implement all your requirements by yourself – do you want to focus to building an application or a framework?
I'm building my own and I'm very glad I did in terms of learning, which is important to me. Also I LOVE to be in total control of my code. It comes with lots of negatives though, the big one being I'm the only one that knows how to use it. Also, a lot of development time is spent on improving my framework rather than delivering products to my clients. But I can't stress enough that I really, really enjoy building and using it.
If you want to learn (A LOT) build your own. If you just want to get work done use an existing one. (Before starting my own I almost went with CodeIgniter)
While I've build my own CMS framework in the past, and used custom (in-house) general php frameworks, I'd find an active framework that fits your development style, and use it.
Unless your main product/application is the framework. But it doesn't seem that way.
Your concerns about control and scalability should be applied to the host of frameworks out there - giving you a short list of options that fit your requirements.
Certainly, it's not a question of 'in-house' vrs 'public', then once you've made that call just pick any old framework.
To answer the question behind the question, for a framework that gives you complete control and should be able to scale reasonable well (I'm not sure how you need the framework to scale), I would suggest the Zend Framework. You can use single parts of it, rewrite what you want, and it's far more than just a MVC implementation.
Update: A quick example of customization with Zend. If you don't want to use their MVC stack, but need something to route requests, you can just use Zend's router library. If you like the MVC stack, but hate the way the router works, you can just implement the interface and write your own router.
This applies outside the MVC stack as well. Zend has a ton of libraries for mail, rss feeds, caching, auth, db, etc. Use what you want, and ignore the rest. Extend what you want, most of the framework is tiered with interfaces/abstract/generalized classes that you can build on if the standard functionality doesn't suite your needs.
The decision is very plain and simple.
If you want to learn and have full control - go for your own
If you want just to make money fast - go for ready made one.
I work in a company that initially wrote its own framework, built by a guy that worked here. It was only used on one project. The reason for this is that we soon realized that although it was clever and very good, there was no documentation for it. So if we employ another developer or a freelance guy, they'd have to learn it.
We run with CakePHP for a while, which is popular, but it does seem a mess. We eventually settled on KohanaPHP. Easy to extend, some good documentation (probably not up there with some others though), nicely formatted code (meaning if you can't find documentation you can quickly work out whats going on). The way the framework is written makes it pretty easy for a developer to pick up and follow what is going on. Whereas we always had trouble doing this with CakePHP.
I think the only argument for rolling your own framework is that you may want some highly customised stuff. But Kohana is so easy to extend, you can just throw it in there. You don't have to use their packed libraries if you really don't want to.
That said, some project I don't bother with a framework at all, just some sort of routing solution, like GluePHP. Since it would be overkill to use a full stack framework.
If you were just trying to practice, I'd suggest writing your own. Otherwise, though, definitely go with using an existing one. Symfony ftw.
The short answer is symfony2 IHMO.
The reasons are:
do not reinvent the wheel
a good wheel is better than yours (others are professional wheel makers,
since a lot of time)
an OSS framework can be expanded or modified, even only inspected
first or later you will not have time to maintain your own wheel
a number of eyes and hands do it better than 2!
Of course the previous points are valid for a very small set of professionally made frameworks! My favorite is symfony2, but there are a number of good alternatives.
I have been developing websites in an n-tier structure and so far my requirements are fulfilled. But as powerful frameworks like Zend Framework, Symfony are getting popular, I wonder how to know if it is time to shift to a framework?
Am I in a kind of dilemma? What is the right option?
If you satisfied with your own way - never.
Frameworks being written not by gods but by people. Some of them may know less than you. Or have different point of view.
Also, it is more a paradigm dictated to you, than toolbox. A religion.
If you have your own way and it suits you, better develop your own framework. Not as universal as famous ones, but not as fat and sluggish as them too.
Yes.
It not only speeds up development time (once you know your way around the framework), it enables other developers to have a better understanding of how the site works.
Using a framework has of course its advantages because you can write your code faster, you have not worry about a lot of functionalities that are always required in a web application so you can think more about your application-specific implementation and you have just to upgrade the other functionalities.
Using a framework gives you of course advantages in terms of collaboration because obviously if you use a well-known framework there are a lot of people that know it without spending time to train them.
But, when you use a framework, you must respect its structure, its coding style and its design. That's usually not a problem because if you choose wisely a framework, you won't feel the need to go off the rails.
The best thing to do is really just have a go! I switched from my own coding style into CakePHP about a year ago and haven't looked back since. Makes it much easier for me to work on other framework-based code by other people, too, and it's overall reduced the wtfs of looking at my own code six months later because now the code follows a much stricter format and is more predictable.
If you're asking that question, then the time to try it is probably now since you've clearly had your interest piqued. If it turns out you don't like working with them then you can always go back to your usual way (or even write your own like Col. Shrapnel says).
The 4 reasons we chose to go with a framework (Zend) at my company:
1 - Common syntax: the framework has it's own syntax that all our coders must work to (to some degree). Makes it easier to use external developers, or handle staff turnover
2 - Scale: the site in question was of a scale that demanded MVC architecture
3 - Tested Components: The framework has most of the components pre-built, leaving you to focus on the Model
4 - Brand credibility: There's a certain value in using a high profile framework brand from a client perspective. It implies a standard solution, and "decouples" the client from your custom framework
Whenever you're not quite sure what the end result of the software is going to be. Ready made libraries are usually made to handle almost anything so you can easily extend your site on them. And if there's going to be new people working on it at some point in the future, they can hop in easily, without having to learn your way of doing things.
But other than that, i think that Col. Shrapnel is spot on.
As long as you can't answer this question yourself, I'd say: Always use a framework.
I know a lot of developers who think that using a framework makes them less off a "real programmer" which is just plain stupid. This wrong kind of pride should not stand in the way of creating well structured and maintainable code.
Using a good Framework saves you a lot of the small annoying problems so you can concentrate on your actual project. Of course there are no things that you can't do without a framework but with one you'll be able to do them much faster and with les headache.
Maybe experience will then show you cases where you don't need a framework or are in fact better of without one but these are quite rare.
Need some guidance and ideally some first-hand experience.
We committed to a php framework which, shortly after we built the first rev of the product, stopped all development on the framework for about a year, forked twice, and doesn't really have a big community to begin with, meaning no plugins, tutorials, etcetera.
For another project we developed on rails and it has been night and day: a robust, continually developed framework and a healthy ecosystem of great plugins and a community that is active, growing, smart and helpful.
But the thought of junking all the sunk time and costs into the framework has been a huge hurdle that I'm not sure we're ready to cross, to go from php to rails. However, trying to work with this framework/s has had various level of frustration and investment.
Are there some ideas on how such a port could be less painful (staying in php but a similar OO framework that is growing/healthy?)
Suggestions on how we can continue to plow ahead with what we have?
Ideally someone who maybe found themselves in a similar situation would be super helpful for us to get our heads wrapped around it. The internal conversations we keep coming back to and I'd like to find a direction and move forward.
Thanks for some suggestions, or even questions, that will help us build a decision-matrix around it.
PS: The two or three people I've met on SO who actually have used this framework have been awesome, so I don't want it to be a neg on that. Size (of community) at least from our perspective does matter, and I think we just are seeing the comparison with Rails (perhaps that's an unfair comparison) So thank you!
No matter how far down the wrong road you've went, turn back. Sunk costs are already sunk.
I'd suggest Zend framework if you're going to stay using PHP. Make sure that you build unit tests as you start to refactor so you can be assured that your new code does the same as the old.
It really depends on the cost of changing vs. the cost of maintaining what you have. I don't think anyone here at stackoverflow can make that judgment call for you. I would suggest though, that it's easy to focus on the bad things and forget the things that work. People have a tendency to underestimate how much work they have to put into a port from one framework/technology to another. So if you plan to go that route, try to make it in as small steps as possible; Eg. take the smaller projects first, to get a feel for what it means to port a project over. This will give you time to pull the brake if it turns out to be unmanageable. It will also give you time to adjust to the new platform (Eg. you say that you aren't quite ready to make the step from php to ruby yet).
I can't answer all of your questions, but I was in a similar situation about 6 months ago. Long story short, I gave up on my own framework and moved to Symfony. I hated the idea of abandoning what I had worked on for so long and was so accustomed to, but I couldn't ignore the community aspect. Aside from plugins, I needed to be able to ask other people things about the framework - something that just wouldn't have been possible had I stuck with my own framework. The learning curve sucked (even though I knew it would be inevitable), but in the end I have no regrets after switching. I feel a lot more confident in my products now that I use a mature framework with a healthy community. I would suggest looking at the big name PHP frameworks, and seeing which fits your development style the best.
I would suggest taking a look at the Akelos framework, it is supposed to be a port of Rails to PHP and could significantly ease your framework transition.
As far as moving forward with your current implementation is concerned I would agree with the thought that it's time to switch if your current framework does not have a healthy user base and solid forward progress, this is a key factor for me in choosing a long-term framework solution. The other key factor I hold just as high is how close the framework's implementation, support features and eventual goals line up with the project I want to apply it to. With so many PHP frameworks available you now have the option of being very selective and should take full advantage of that.
I have been tasked with supporting and maintaining several PHP/MySQL web apps (I use the term 'app' lossely) that seem to defy every known coding standard.
The PHP code contains routines, procedures, business logic, and even queries - it's all in the code. There is no object-orientated programming, not even MVC, and certainly no separation of the presentation layer from the application layer. No framework was used to build these apps either and I am using the Yii Framework for new projects.
Although it's time consuming should I rewrite these applications? At least half my week involves fixing them, doing updates are having to work with these existing apps in my new work.
Anyone have any advice on this?
An age old question that is asked alot.
When do you refactor code?
How do you refactor?
How do you stop yourself from refactoring working but awful code?
Basically, if it's working dont' break it. If you work in it, and can make changes to clean up the code without breaking it then do it. Rewrite code? I'd go with the idea of, What's the return of investment, how much time would it take, can you dodge the bugs of the old version without introducing new ones. Things like that.
Good luck with your project, and hope this helps.
I would caution against an all-out rewrite. If the application is working and has users, the path forward is to modify the existing codebase.
Yes, you can implement a framework into an existing framework-less codebase. It takes a lot of effort, but it is possible (I've done this several times). Starting over will cause you to lose precious time. That's been proven time and time again (remember Netscape?)
You're obviously smart enough to know that there is a problem, and to know that the solution is to improve the applications by implementing frameworks and clean them up. That puts you ahead of the game.
Implement new frameworks in phases. Start with an MVC framework - get it into the codebase, but don't fret about the fact that there is no separation of layers yet. Get a new version out that's built on top of an MVC framework but isn't truly obeying MVC conventions. It's a start. Then take a next step - move the business logic into the model layer. Or maybe leave it as it is, but make it OO.
Remember, your job is to produce a product that users can use. Your job is not to adhere to best practices. Meaning - yes, best practices ARE the correct course of action. But they don't matter squat if users can't use your app or your app can't compete with the competition. Don't lose sight of that. Work to improve the app so that you can turn it into a great product, but don't let perfection be the enemy of good.
In my experiences, this has typically been a business decision. Do your bosses know how much time you spend maintaining these systems? How many users actually use these systems? How critical are they to the business? Can you sell management on a rewrite and can you prove it will be useful and beneficial?
You can start some basic refactoring already in your day-to-day maintenance. Whenever you need to make updates, even if it might take a little extra time, find a way to work an OOP solution of some sort in, or clean up the code that's there to make it easier to handle. All-out rewrites are typically not a good idea and are a hard sell, but if you're already maintaining and adding in new functionality, there's no reason you can't use the new code or fixes to improve what's already there.
Will the products last for a long period of time? Will other users see the code and think that you did it? If yes to these, then you might as well rewrite the code. Try and get some support from your company and let them know the benefits and maybe you'll even get noticed for it.
While having no separation between the presentation layer and bussiness layer is clearly bad, there are some merits with other choices. If it is a pain to maintain code, just refactor the code as you go. Since you are familiar with good design patterns, you should be able do it fairly easily. Moreover, this will also help you reduce the bugs in your code. But remember that while refactoring code, things get worse before they get better. So, don't give up too soon.
I would suggest it depends on how much is the user load on these apps, do they really break apart in live scenarios and how much time are you wasting daily on these fixings and all.
Its always better to rewrite than break head on something which is totally messy.
I've been a PHP developer for many years now, with many tools under my belt; tools that I've either developed myself, or free-to-use solutions that I have learned to trust.
I looked into CodeIgniter recently, and discovered that they have many classes and helper routines to aid with development, yet saw nothing in the examples that I couldn't do just as easily with my own tools. Simple things like DB abstractions, Email helpers, etc. There was some interesting code relating to routes - mapping urls to the right controllers; but even that's not particularly difficult to code yourself if you've ever written an MVC style web app with pretty urls.
Even after looking through some of the other popular frameworks, I still see nothing that would be that much of a time-saver. Even looking at the forums, I see people struggling to get the tools to work for them. I do understand how they would be more useful for junior developers, since full system design skills take a while to understand and appreciate fully.
Yet, I'm often told that I should use an off-the-shelf framework to produce my solutions, but I still remain unconvinced. What's the real benefit to someone like myself? Am I just being elitist, or is this a common opinion?
Edit: Looking at some of the answers here, should I perhaps consider packaging up my toolset as its very own framework, writing some documentation and posting tutorials? If I'm hesitant to take on other's frameworks, would opening it up and getting more eyes on it help to improve my own skills/tools?
Frameworks have several advantages:
You don't have to write everything. In your case, this is less of a help because you have your own framework which you have accumulated over the years.
Frameworks provide standardized and tested ways of doing things. The more users there are of a given framework, the more edge cases that have been encountered and coded for. Your own code may, or may not, be battle hardened in the same way.
Others can be recruited onto a project with a standard framework and have access to the documentation, examples and experience with that framework. Your own snippets may or may not be fully documented or have examples of use... but isn't much chance that others are comfortable with them initially.
EDIT:
With regards to your idea of packaging up your own framework, the benefit of cleaning it up for public consumption can be larger than the benefit of getting others to use it.
The reason is simple: you will have to re-evaluate your assumptions about each component, how they fit together and how clear each piece is to understand. Once you publish your framework, your success will be strongly dependent on how easy it is to get up and running with.
Big wins with little effort are essential for adoption (those wins will encourage people to delve further into the framework). Ruby on Rails in an example of a framework that gives such big wins with little effort, and then has hidden layers of features that would have overwhelmed someone just getting started. (The question of the quality of RoR apps is not the point, the point is about adoption speed).
After people adopt a framework, it is about the ease of continued use. Little details like consistent parameter use patterns make all the difference here. If one class has many parameters on every method, while another has setters that are expected to be called before invoking methods, you will lose users because they can't get a "feel" for what is expected in a given case without resorting to the documents.
If both ease-of-adoption and ease-of-living-with issues are addressed properly, you only have to get lucky for people to adopt your framework. If those issues are not addressed properly, even an initial interest in the framework will wane quickly. The reason is that there are many frameworks: you will need to stand out to gain the advantages of having others using your kit (as they rightfully are as wary of your framework as you are of others).
Here's another reason not to create your own framework. Linus' Law - "Given enough eyeballs, all bugs are shallow". In other words, the more people who use a given framework, the more solid and bug-free it is likely to be.
Have you seen how many web frameworks there are for Java? Back in the day, it was fashionable for any half-decent developer/architect to write their own custom web framework. And at the end of the day, 95% of them looked like a custom implementation of Struts (the most popular Java web framework at the time). So they basically created a Struts clone that was: 1) proprietary; and 2) not as well documented and tested.
Let's face it - writing our own customer framework is fun, but what happens next? It becomes a maintenance burden to keep up with the framework yourself (or the poor soul who replaces you). And maintaining software is much, much more costly, especially when it comes to custom frameworks. Is the company in business to solve domain problems or in the business of maintaining frameworks?
I forget who said it, but I once heard a great quote - "The first rule to creating your own framework is: don't". Somebody else has probably gone through the effort of doing so and probably done the same work you would have done. Save yourself the time, effort, and testing.
There's many comments here as to the advantages of using a framework, and certainly I think in a good many cases they are perfectly correct.
HOWEVER
All frameworks come with the downside that they have a domain of problems that can be fitted into them. If your problem is well inside the scope of the domain then using a framework isn't an issue, and most of the time it's readily apparent if your problem is well outside the domain so you don't give it a thought. Issues arise when you try to force a problem into a framework that it just doesn't quite fit into or has some unusual non-standard feature - in which case you complete 90% of the code really fast then spend all the time you've saved figuring out how to bend or extend the framework so it can accomplish some obscure requirement. Because in these case your solution/extension has to plug into the framework it can often be more difficult to code than if you'd come to it independently.
In the wrong circumstances this can actually be disastrous. For example if a client asks for a project that you believe will fit into a framework solution and you quote accordingly, then after completing 90% you find the gotcha then you can be really up the creek, especially if it's some feature that the client is insistent upon (and it always is). These issues tend to arise because it is not always apparent from the word go where the gotchas might lie, particularly if you're using a framework you are less familiar with (and you have to from time to time).
This is really the same problem as arises with deploying any third party software in a project. Myself from experience I have no qualms about using frameworks or similar, but given the choice I will always go for the lightest, thinnest, wrapper I can find that will do what I need. That way I gain the advantages, whilst knowing that if issues do arise (and they are generally less likely to with a thinner wrapper) then figuring out how to work around them is likely to be simpler than learning an extensive code-base to the point where I can safely modify it.
The framework code is likely to be well-tested and relatively free of bugs. By using it you save yourself time testing/maintaining your own code to do the same thing.
And any time saved is good. Laziness pays off in programming.
One thing that you will be missing out on is all of the Validation that goes into a popular framework.
Your routines simply don't have the same exposure that the popular libraries have.
You may have a point.... however I wouldn't underestimate the power of many, as an example phpBB is as far as i'm concerned the bb solution to use. Why? Because there are many, many thousands of posts on their support boards and many people using it who are knowledgeable and can help people solve problems.
Therefore the only reason in your case to use a popular framework is the many others that use it, report bugs against it, fix it and support it. It'll be tricky to get the same coverage on your own libraries.
I would go against the grain here, and say, you should use your own custom framework, If the software you are building is the core of your business. As Joel would say, "Find the dependencies - and eliminate them". If you are just putting up a little website for your company, and you business isn't maintaining websites, then go ahead and use a framework. But when that website is your business, then you shouldn't depend on a framework from somebody else to let you get the job done.
I think the main reason is that when you use a common framework, there are a lot of people who are instantly familiar with your product.
Apart from that I think it's most important that whatever tools you use actually get the job done. If it happens to be familiar to other people, then that's a bonus.
I agree you should use your own custom framework. Not only is it easier for you to understand, but it provides the ultimate in job security!
Three reasons I can think of immediately:
A well-known framework will be familiar to other developers who may have to work on your project
A well-known framework will have resources like books, discussion boards, and other experts that can be used for finding out more information
Managers will often have a "don't reinvent the wheel" philosophy. In fact, existing solutions have probably solved the same problems that you'd discover if you create your own solution.
All of that said, there may still be a place for your own solutions. We wouldn't have so many frameworks (or scripting languages) to choose from if no one started something new.
Any experienced developer can build a framework -- the challenging part is convincing others that it's worth using. You'll need to create documentation and tutorials for it for those who plan to use or maintain it. You'll probably need to create a demo site to prove that its useful and actually works like it's supposed to.
That alone can be a considerable investment, not including bugs that could pop up in between. When its all said it done, it could be worth spending time learning another framework instead of making your own.
You mentioned CodeIgniter -- I personally feel like that's a pretty framework -- it doesn't get much more barebones than that.
What you essentially have is your own framework. So, it isn't a time-saver FOR YOU, because you have already spent the time to develop the framework. If you didn't have that to build from, it would certainly be easier and faster to use an existing framework than to roll your own.
What you need to look at is whether or not your framework is better than other options out there, and whether your familiarity with your own code outweighs having other eyes looking at it, and other people using it in enough different ways that the likelihood of any problems being found and corrected is much higher.
Also, if your framework is so much better than everyone elses', you might consider opening yours up to the community ;)
As you probably know: "time is money". So by using a popular framework with a lot of helpers, a lot of code examples on web and a big community you do more in less time.
Sometimes it if ok to use frameworks because you become more productive, but in some advanced and difficult projects it may happen so that the framework stays in your way and you have to find workarounds.
I think there is no definitive answer. You should put in balance the pros and cons and take the right decision for your project.
Usually I adopt popular frameworks very fast but not in critical parts of the projects and in time I extend their usage.
I think that if you don't see a need to use a framework then don't.
The reason I use a framework for example Django for python or Rails for Ruby or Webforms and MVC for ASP.net is because they make it easier and faster to write applications for them. In the case of Ruby and Python not using a framework for me would make me go crazy.
If you have something that works and don't see a need to use a framework I would say stick with what you feel is best. But, I would still keep up to date with frameworks.
I think they are more useful if you are starting from scratch and don't have the time to write your own. If you already have a codebase you developed over the years, they may be much less useful, but it may still be useful to take a look and see what they did.
For example, I am sure major game development shops are not using third-party tools, engines and frameworks, not because they are not sufficient, but they already have built their own since the 80's or whatever.
Plus, if you are using an off-the-shelf component, there is no way to exceed it in its particular area. If you need to be a market leader in a particular dimension, you should be building your own solution in that dimension, so you can lead. If you don't need this capability, using a third-party component that is just as good as yours may be a good solution as long as it is an easy transition. Time to train in the new tool and living with its idiosyncrasies may or may not be worth it though.
The other thing to consider is that if you can build something, you truly understand it. Otherwise, you don't. Now, you don't need to fully understand stuff to use them, so long as they "just work", but we all know how that goes... :)
Can you solve the problems you are given have with your code faster and more reliably than public frameworks?
If yes, then keep using your own.
If no, then find the framework that does a better job and run with it for that project.
It all comes down to which codebase gets the job done better(for the value of better given by the client. ;) )
Disadvantages.
Most frame works are not object orientated. (code igniter does show some promiss)
Most of the code is done via includes. trying to track down the problem is like pulling on a thread on a sweater, and having to unravel the entire garment to fully understand the creation.
Most frame works have poorly written documentation.
Most frame works try to do many many many things.
I find from my experience developing with frame works that it takes a good 3-6 months to get on top of the code base. And its only after that period of time that you will find out weather you are trying to fit a square peg into a round hole. Given that most php projects want to be finished before that period has elapsed, it will cost employers more to get any project using a big "frame work" to fruition.
Many of the php Frame works were written for php 4, and were written in a different enviroment. They have been extended greatly, but are showing their origins. The use of global constraints is particularly prevalent. I am hoping that php 6 puts most of them to death. Code igniter escapes most of this, but it is new, and has object orientated parts.
Some frame works have written code that is not needed, and causes problems.. eg: CAKE has a most excellent model view controller, but its session handling is a disaster. Unfortunately frame works are not written in a modular way. Often its an all or nothing option.
MOst programers "hack" the frame work to get it to do what they want. This leaves future programers sractching their heads. It also makes "upgrading" the frame work a impossibility.
I have yet to see a frame work that implements unit testing. (how do you know that you have not broken it).
give me a well written object any time. At least them you know the scope right off the bat.
Advantages are that it's already written and tested by multiple people therefore less likely to be bug prone.
Disadvantages are that it's not built specifically for your application and therefore will most likely perform worse.
All in all, I can't really see much reason to use one considering you already have your own...although it may be worth releasing that open source so others are able to bug check and recommend improvements.