Jump to content

Invision Community Blog


Managing successful online communities

bfarber
 Share


Use a third party library/framework, or build it in-house?

One question I have seen surface in the past (and present), revolves around how we decide when to use a third party library or framework, and how we decide when to develop something in-house entirely. For instance, in the 4.0 Suite we will utilize jQuery (a third party javascript framework), however we will build our underlying PHP framework in-house. How did we decide to go that route? There are several PHP frameworks on the web, many of which having licenses compatible with our commercial license, so why didn't we choose one of those to kickstart 4.0 development?

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.

 Share

Comments

Recommended Comments

The "pro" of the third-party framework is mostly good and full documentation and large developers' communities. I wish you framework will be clean, consistent, well documented and will supply backward compatibility ;) It is hard to develop on IPS right now as there are some inconsistencies, some places in code that are abandoned but not deleted, undocumented features, missing documentation articles, tiny developer community to help with code...

Link to comment
Share on other sites

The "pro" of the third-party framework is mostly good and full documentation and large developers' communities.

Doesn't mean that those developer communities will provide assistance with IPS products.

 

 

It is hard to develop on IPS right now as there are some inconsistencies, some places in code that are abandoned but not deleted, undocumented features, missing documentation articles, tiny developer community to help with code...

If you come across such, you should report it in the bug tracker.  Something that may seem abandoned may very well have a reason for remaining.  However, by reporting it, if it's something that was supposed to be deleted, then it can be taken care of.  Shortens the code which in turn provides a slight improvement to resource usage and speed.  Holding back on something doesn't help, report it so IPS can take a look at it.

Link to comment
Share on other sites

ah ratts...I was hoping to see codeignitor in 4.0 :(.

 

I've been messing about in codeignitor for the last several weeks, its a lovely framework, it has cut development time for most of my other projects that do not use IPS, by more than half. I've been finding myself dreading to go back to the current IPS framework cause it feels so outdated in comparison. 

 

well heres to hoping the next framework for IPS 4.0 is as clean and nice as CI is. I'm stoked about jQuery being the default in 4.0, prototype is nice and all but its documentation is lacking to say the least :).

Link to comment
Share on other sites

But with a popular framework vulnerabilities are found quicker.

I much doubt that popular & robust frameworks like Zend would dissappear, so thats an unlikely scenario.

Using such third party framework would also be a boost to the addon community.

 

Anyway, I hope that you will produce somethign even better than Zend and CI.

Link to comment
Share on other sites

Both frameworks are very good. I'm having a hard time deciding which to use myself. Bootstrap does a good job of providing a clean UI to work with. Foundation is powerful but requires more UI work to make it look good.

Link to comment
Share on other sites

Both frameworks are very good. I'm having a hard time deciding which to use myself. Bootstrap does a good job of providing a clean UI to work with. Foundation is powerful but requires more UI work to make it look good.

agree, there are more good responsive framework like Golden Grid or Amazium... but i guess bootstrap is best

Link to comment
Share on other sites

@Wolfie, it is not about reporting bugs, it is about development experience. I develop in IPS and Symfony2 and can compare assistance directly. While Symfony2 is made for developers, IPS is made firstly for customers without coding experience. While there are hundreds of ready solutions for symfony2 and strong developers' community (not one), IPS developers' community is tiny. Even IPS developers themselves admit that it is difficult to synchronize different branches. We - third party developers here - have the same difficulties. Even more difficulties if we do not use default language and default skins. At some places we are entirely depended on the decision of IPS like "not allowing hooking into IPSText" or "making FURL not customizable without rewriting core files" or "not providing fixes until next release" or "not supporting test installation where errors can be reproduced before committing these errors into production".

 

I like to see new framework, well-documented, clean and consistent and at the same time I am afraid that there will never be sane and strong developers' community. However, I also understand that IPS is not really interested in building up developers' community as the most clients are just looking for settings in admin panel and are entirely satisfied with the possibilities offered. ;) This is just a remark from developer's front :D

Link to comment
Share on other sites

Both frameworks are very good. I'm having a hard time deciding which to use myself. Bootstrap does a good job of providing a clean UI to work with. Foundation is powerful but requires more UI work to make it look good.

 

I'm developing a new application using Foundation. Originally used Bootstrap because that's the framework everyone talks about, but when I discovered Foundation, the better grid (every column becomes its own twelve-column grid) won me over, so I switched. That, and I like that it's less opinionated about how your site should visually look, since my app needs to have a distinct design for the users' enjoyment anyway.

Link to comment
Share on other sites

Another consideration is page load time. A shared library/framework is likely already cached on a users system.

 

The difference is marginal, as our framework would be cached too after the first load.  This is not a big consideration I think.

Link to comment
Share on other sites



Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy

×