Skip to main content

When is a PHP project too small for a framework?



I'm about to start on a small, static website project: no database or CMS required. Basically, a brochure website.





I used the CodeIgniter framework recently to develop a full-blown web application, and I'm wondering if it appropriate to also use CI for smaller, simpler sites.





Typically for a static brochure site I would write regular PHP pages with a few includes thrown in to save on repetition (i.e. HTML with a sprinking of PHP), but this time around I'm wondering if my new friend CodeIgniter might be able to streamline the development process.





Is it sensible to consider a framework for such a simple project, or is it overkill? I'm worried that I might be the proverbial carpenter whose only tool is a hammer, and sees every problem as a nail!



Source: Tips4all

Comments

  1. I think almost never, the needs change and come more with time... so it is better to have a good base using a framework to wait the future needs. but if your project will not have a long live time and your needs are reaaally simples then i think is not necesary use a framework.

    ReplyDelete
  2. I personally would never develop a site outside of a framework for anything more than a single page brocure-ware site. I work so much faster inside the framework.

    I'm a Python/Django developer but here's my take.

    I've done some small non-framework sites with PHP and I don't know how PHP frameworks compare to DJango, but if they're anything alike the fact remains that I'm far more proficient developing within a framework than to code something from scratch by hand.

    It helps me stay organized if nothing more than giving me the VC of the MVC. Django provides me with a lot of built-in tools, like form handling, that make my life much easier even for small sites.

    I'm going to presume PHP frameworks provide similar things, maybe not though.

    You also can't anticipate how the site will grow over time. It's easier to maintain something built in a framework, and if you ever need to extend the site in the future it's nice to have some structure behind it.

    ReplyDelete
  3. Since I tend to either inherit bespoke frameworks, or write my own, I would peg it at about 3 pages: if it's more, then setting up a framework is worth it. And if it needs a DB, then odds are good you'll end up with more than 3 pages, anyway. :-)

    ReplyDelete
  4. If you don't need a database, CMS and is just a simple static HTML/css/PHP page, I don't think you can go wrong creating a site without a framework. Plus, if you have been using frameworks for a long time, you can have a break and do "code for code" and have a feel what it's like to code from scratch :)

    ReplyDelete
  5. I recommend Rapyd, a "minimalistic and rapid PHP framework".

    ReplyDelete
  6. Site is never small if the client is there who may want to ask you to add more functionality at any time :)

    ReplyDelete
  7. How long is a piece of string?

    I use CodeIgniter (specifically PyroCMS) for crappy 5 page brochure-ware but that is purely to let clients admin their own pages easily with a WYSIWYG.

    Any client will say "Wow, news, contact form and I can get me some of that Twitter too?!" so I just dump it in there to save everyone time.

    If you are developing from scratch there is no point if the content is static. Something like CodeIgniter helps with DB interaction, Form validation and the breaking down of multiple pages into logical chunks i.e Controller classes and methods.

    If you have no db-content, don't handle forms and don't have many pages then there is litterally no point adding the overhead.

    That said, try my Twiny framework for literally the smallest MVC framework around.

    ReplyDelete
  8. For a simple site like that. why even use a framework why not use something like concrete5. Overkill? definitely. but hey it is easy and requires almost no coding so upkeep is a breeze.

    The site would be up and running in less than an hour and it makes you look good in the eyes of your customer and that can't hurt.!

    ReplyDelete
  9. I don't think any project is too small for a framework, I think some frameworks are too big for small projects. Everyone hopes their website will grow. So no matter how small the site is now, growth will be easier to manage if you start with a framework.

    ReplyDelete
  10. The only case when framework would be an overkill is with a throw-away scripts, such as when you need to quickly automate something that you won't need to do again ever. For anything that will enter execution cycle more then few times framework is a probably would be better.

    ReplyDelete
  11. If it requires under several hours of work - then it is small. Anyway if you plan to devote more than "several hours" - definately use a framework AND a control revision system.

    ReplyDelete
  12. It depends. If you're positive this is all the site you're working on will ever be, or migrating when future needs arise, then I can't see why there would a reason for using a framework, unless you feel more comfortable working with one.

    As a personal example, I recently worked on a semi-static website, for which I put together a minimal framework which worked as a caching preprocessor for static html, inserting common html-elements into preset places. This allowed for some dynamic content, yet still using only static html for content.

    I'd say you're answer lies within a formula consisting of future development needs, your own working preference, and performance.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex