April 08, 2009 at 11:12 AM · Posted under Blog · Tagged with planning
The main problem I see, is that with (especially good ones) frameworks, developers are moving towards these solutions for just about anything and everything, and for most parts of the web, this is fine. However, when developers become so clung to a framework whereby they think it is the solution for everything, stumbling blocks begin to materialise and the solutions become ugly.
For the most part, frameworks provide developers with an easy interface to generate websites at breakneck speed, thereby allowing the development community to industrialize the development process (cheers Khaless for the term). What this means is that we're able to pump out solutions at speeds never thought possible, especially with frameworks such as Django, RoR, CakePHP and others. However, what does this mean for development in general?
Using heavy-handed frameworks means that one thing is generally left behind - performance. The difference in performance between a site using a framework specifically tailored for it's product, and one that uses a generic framework which is built to cater for an endless number of options for websites, can be staggering. Of course, there is a tradeoff to this performance hit - development time. Development time is generally much more expensive than hardware (unless you're serving millions of page view per day), and so therefore (depending on the project) a sound and educated decision should be made, rather than simply jumping into your favourite development framework.
One of my close colleagues uses a particular framework for just about everything, and although this framework in it's own right is a great product which allows people like myself to develop applications very quickly - it's also one of the heaviest frameworks available, meaning it's one of the slowest to serve pages. For example, even though development of a mainly static website could be easier to develop using it, what we're doing is using a full-stack solution to serve basically static pages. What does this mean? We're effectively cutting down the performance from 1000s of pages/second to approximately 50 or under.
This brings me to my original point - use the right tool for the job! Big frameworks are great for spiking out and even developing the initial stages of products, so as to get it to the public in a quick and orderly fashion. However, as the needs for the product changes and popularity grows, the framework of choice can (but not always) become a real hurdle that could have been overcome earlier in the development process if the project was given it's due respect and investigated in depth for the right technologies and solutions to be used.
Alex Pooley said @ Apr 08, 2009 @ 11:39 AM
These are good points. Sometimes I use a framework for seemingly simple work because I know from experience that simple things get complex quickly. From the outside it may not look like I know what I'm doing, but I really do. Honest :)
Nate Klaiber said @ May 22, 2009 @ 11:23 PM
I am all about using the right tool for the job, but I would beg to say you don't understand all options available to you within the frameworks. You have so many options (as you would without the framework). Is your site comprised of mostly static pages? Let them be static and have something like nginx (or other quick response HTTP server) serve them up without ever having to load up the framework at all.
Not that caching is a solution, but you could potentially do the same with dynamic pages, managing your cache expiration accordingly so things can still get loaded up quickly.
It's a very sweeping statement to say that by using a Framework you are throwing performance down the drain - there are so many available tools to manage whatever aspect you are looking to improve.
I don't mean to come off as condescending, but this just feels like half-assed statements without understanding your options. It's like you want to dis-credit the frameworks because you don't like them (or feel afraid of them).
I think most programmers go through this, where they battle against the idea of a framework simply because 'heck, I could write that myself'. Then they realize the pattern they develop for themselves (whether it a procedural PHP library of often used functions, or a collection of PHP objects that serve different purposes like Email, Validation, Routing, Parsing, etc). When you get past that, and understand the frameworks and languages behind them, then you realize how they can make you more efficient and powerful as a programmer. I've used CakePHP, CodeIgniter, and now Rails full time. I tried to go back and use CakePHP for a recent client project and then realized how backwards their MVC is....it's more of a VC. At that point, I figured out what I needed to do to patch that brokenness. It didn't 'get in my way' necessarily, it just didn't offer what I felt it should - so I added it.
Kirk Bushell said @ May 26, 2009 @ 04:03 PM
@ Nate - first and foremost thanks for your post and feedback, greatly appreciated. You have however, made a few assumptions. You make excellent points but I never said I hated frameworks - I use them all the time. My main qualm is with developers who learn a single framework, then think it's the answer for all their development needs, especially if they haven't touched any others - this is ignorance at it's finest (of them, not you :P)
Also, I believe there are some instances where using a pre-built framework isn't going to serve your needs. If you're going to be having a fairly complex structure for your data, and it's related actions with other bits of data, using an ActiveRecord pattern may not be the best (or only) answer.
Katz said @ Jul 18, 2009 @ 09:07 PM
I am trying to explore other options apart from Ruby on Rails and I'm looking at Django as another possibly good option for other projects I might have. I have a background in PHP and have used CodeIgniter and Drupal (not a framework but it's module approach is good) in the past. I think pitfall of companies is that they choose the option which seems to be a solution because it's done like "Ubercart" which is a shopping cart module. They believe it can be easily tweaked and modified for all e-commerce projects which is wrong.
RSS feed for comments on this post
