This is, admittedly, often a difficult question to answer. The truth is, we evaluate each scenario on a case-by-case basis and make decisions based on what is best for us and our clients. Sometimes these decisions may not be obvious, however you should know that much thought has gone on behind the scenes here at IPS to ensure we are making the choices that we feel are best for our products.
Javascript frameworks are almost an essential tool with today's fast-paced browser development and web advances. Browser updates from some vendors are almost weekly. We went from HTML 4 to XHTML 1 to HTML 5 within but a few years. And while everything a javascript framework does can be replicated in-house, it would consume a lot of development time that we would have to spend in order to keep pace with all of these changes, purely for compatibility reasons (e.g. no new functionality added, just to keep things working and up to date). We have long-ago determined that using a well-maintained javascript framework to facilitate javascript development is virtually a necessity, otherwise you quickly get bogged down trying to maintain javascript code just to retain compatibility with current browsers and newly available functionality.
What about PHP frameworks though? There are many out there (CodeIgniter, Zend Framework, etc.) and many are relatively robust, well tested and quite extensible. Why have we chosen to write our own underlying framework given this information? In researching whether to maintain our own framework or use an existing one, we had to weigh many pros and cons. For instance, one pro using third party PHP frameworks would be that we can skip all of the development of underlying classes (controllers, autoloaders, database connector and so forth) and jump into the higher level development. This is surely an important consideration to take into account.
On the other hand, using third party PHP frameworks ties us into that framework, and we expect the underlying codebase in the 4.0 series to last several years once it is released. What if the framework we choose to utilize is no longer maintained 2 years from now? What if a security issue arises in the third party framework, but it is not rectified quickly? We certainly can't leave our clients vulnerable to known security vulnerabilities while we wait for a third party to patch it. What if the framework developers release an important update, but it renders APIs incompatible with our implementation of the framework? We could find ourselves in a situation where we either can't update the framework easily, or we would need to recode many of the underlying usages of the framework in order to update. Additionally, frameworks often have many, many capabilities, many which we may not need or use. This can make our release larger than it needs to be, and/or cause our software to consume more resources than it would otherwise, if those features which we aren't using were not present. Of course, licensing concerns are also present - we have to be certain that any third party code we use is released under a license that is compatible with our commercial license. Finally, if we utilized a third party PHP framework, we would either have to (1) rewrite ALL of our code (just think of every database query that may be run - these would need to be passed through the framework rather than through our own database driver), or (2) write an abstraction layer on top of the framework to translate the requests we currently send to low-level classes so that they are compatible with the framework. No easy task, either way.
By writing our own framework we ultimately have better control of our software. We can tailor every class to our needs, ensuring that it is as efficient as possible within the confines of what we wish to accomplish, while still making these classes robust enough to handle everything we want to throw at it. We can ensure we do not have unnecessary classes and code, or features which aren't (and never will be) used. If a security issue is found, we have full control over the underlying code base and can address the issue quickly without waiting on a third party to release an update, or rewriting underlying API calls in our software if the framework changes how a class must be called. If we wish to implement new functionality, we can implement these changes directly in low-level classes efficiently. We do not have to work within the third party framework's design, artificially requiring us to utilize more resources (e.g. by extending a class vs implementing our changes into the base class to start with).
By writing our own framework, we face the "con" of spending the time up front to develop all of these low level classes we will need, however we feel the "pros" that this affords us in the long run are worth the time and trouble. It is a decision every developer or development company has to make as they approach a product, and everyone has different view points. The take away here, however, should be that we have indeed looked into available options, weighed the pros and cons against our goals and needs, and have determined after careful evaluation that sometimes it is best to use an existing framework, and sometimes we just need to roll our own.
- 10,787 views
