Why Frameworks Suck
Development frameworks are supposed to be our friends. Instead, they often just get in the way. Frameworks suck.
What’s a framework?
A framework is a set of libraries that attempt to make certain tasks easier. For example, instead of parsing an XML file character by character each and every time you need to work with XML, you might have a set of functions to help you do that.
$elements = $XML->parse(); Now imagine that kind of simplicity with all your other common tasks like sending e-mails, creating and validating forms, or managing a database. This is a framework.
Where do frameworks come from?
“I like to share”
Frameworks are made by developers just like you and me. For the most part, once you’ve been developing for any length of time, you simply begin to build a collection of functions and classes that you use on a regular basis. Some even take that extra step to unify the API for the framework; remove duplicate code, clean up naming convention, make it modular.
Then, with such kindness, they share it with the world! Do a search for “PHP Framework” on SourceForge and you’ll instantly catch a glimpse of how expansive the framework space is.
Framework in mind
Some developers actually set out to build a framework as a project unto itself. I’d imagine this to be a little trickier as you might not have thought through enough of the use cases to solve the problems that the framework is designed to solve. Like, building an e-mail class to e-mail people but not supporting encoded headers for internationalization, just because you didn’t think about it.
Brother from another mother
You’ve programmed in Java all your life and now find yourself in PHP land. What are you to do? Make a framework, of course! One that mimics all the features of your favourite language. A mimic framework seems to make sense but in actuality, it really only makes sense to other programmers who used to use Java and are now looking for its PHP counterpart. This is a fairly common approach and one I’ve fallen into from time to time. For example, I’ve made echo functions in just about every other language I’ve used.
The concept makes sense on the surface. You’re in your comfort zone. You get to use the methods and properties that you know and love. Nothing slows you down. But you slow down any developer who works on the project after you. They not only have to know the language for the project, they also have to learn the framework or worse, learn the language that the framework is attempting to mimic.
Learning a Framework is like learning a language
And this is ultimately why I think frameworks suck. Learning a framework is really like learning a language. You want to save to a file; here is what you need to type to accomplish that. What you type could be native to the language or it could be part of a framework. But once you’re using it, it’d be a lot of work to take it out. You certainly can’t replace a framework once you’ve started using it.
And what happens when something goes wrong? A framework adds a level (or more) of abstraction to the overall rendering process. As a result, when something goes wrong, more work goes into understanding how the framework ticks than solving the problem (assuming you didn’t build the framework yourself and would already have intimate knowledge of it).
Is it really that bad?
In actuality, no. Having a framework does make your life easier but know it inside and out. That’s something that may only come from developing your own.
To give you a personal example, to try and save time on a project, I decided to use Smarty. One particular feature relied on a certain level of error reporting. No biggie except the framework already in place was set up to e-mail us whenever any PHP error occurred. Suddenly, we were receiving e-mails on each page load.
It’s situations like these that you can never predict or plan for. When they happen, just hope that someone else has run into something similar and documented it. Otherwise, prepare to spend some time testing.
The exception (there’s always one)
If ever there was an exception to the rule, it’s Ruby on Rails. It has the large benefit of being the de facto web application framework for the Ruby language. Ruby was rarely mentioned of before Rails made its appearance. Now, anyone learning Ruby for the first time is likely learning the Ruby on Rails way. As such, learning the framework is learning the language. They’re practically one and the same.
That’s not to say there aren’t or will never be other frameworks for Ruby. There is and there will be.
What do you do?
So, did you build your own or use something already out there?
Conversation
Good read. This is exactly how I feel about "Frameworks" that are suppose to ease my programming needs. It might ease the need for the programmer who programmed the framekwork, but not me. As for Ruby and Rails, Ruby, itselfs, seems way too complicated without Rails...
I made an image resizer where as I am sure that I could have used some extension of php like pear to do the same thing. I am also guessing that if there is a pear version, it is better than mine, but it gets the job done.
My 2 cents are here: http://www.silverstripe.com/blog/frameworks/
PS: It would be cool if your trackbacks were posted like comments.
I am not a fan of frameworks either. Sure, I have build 'something' (yes, I wouldn't want to call it a framework) myself, but it isn't much more than a bunch of classes and commonly used functions.
I don't mind using classes that were designed to solve a single, isolated problem, but as soon as it's going beyond a single, isolated problem, I tend to first look into doing it myself.
The best example of a framework in recent times is the protoype js framework - simply because for the most part you can use the bits you want, (which are well constructed) while ignoring the less useful or less well constructed parts.
As an example, the inheritance and class parts are great, but the DOM manipulation functions leave a lot to be desired...
I think that you need to distinguish between a framework and a class library.
A framework can be very light, but should allow for limitless extension. So, if the framework developer has forgotten to add support for encoded headers, the framework user can add this as simply as possible - for example, by subclassing the EmailHeader class or something.
When I think of frameworks, I normally think of something that defines the "execution model", like Model View Controller frameworks. If it's just a bunch of useful tools, that's more like a class library.
It's critical that a framework encourage / allow for elegant coding. The problem is that elegance is in the eye of the beholder, which is why so many people decide that they can do it better than anything available out there.
I build a framework that basically only contains a controller, a model and a view.
These parts are easily to seperate and can be changed independently.
Then i have a shitload of classes for my personal use, they are not really part of the framework. They are just part of some applications.
I think it's the type of frameworks that can be really useful.
The others are those that try to offer a solution for anything but don't really do, and thus only limit the developer because they are not easily extendable or hava a stupid API.
In german you'd call these "Eierlegende Wollmilchsau" a dictionary calls them "all-in-one device suitable for every purpose".
One of the other problems with using an existing framework is knowing ahead of time whether it'll serve some, most, or all of your needs right off the bat.
The difference between a framework and a class library in respects to what I talk about above is negligible. In actuality, I'd consider a framework a library of libraries. As a result, they usually have a specific design pattern in place to connect all the pieces together, whether that's a page controller, model-view-controller, or some other model.
ps: I had originally disabled trackbacks due to trackback spam but that all seems to have disappeared so I'm bringing them back...
How does the .NET framework fit into this? It seems like learning that framework is learning the language.
I think if you know the ins and outs of a framework architecture, then it should be ok to use it. Otherwise its best for folks to start with something fresh like learning how to use PHP date() ;)
Isn't this mainly a discussion of Using the Right Tool for the Job?
If you have a set of problems to solve, and Framework X provides facilities for doing so, then its use might be beckoned for. Of course, it is incumbent upon the sensible developer to understand ahead of time whether these tools are appropriate and what baggage might come along with them, in order to make a viable design decision.
I think your title is misleading. Your arguement for why frameworks suck boils down either it was gradually put together over time out of convenience, put together at once with poor design or that it was a port from something else (which almost always is not as good). Good frameworks (like Rails) are worthwhile. It's all about the right tool for the job.
Interestingly enough, I'm in the process of making my own framework (on PHP of all things) simply because I didn't want a framework that was a port of Struts or Rails. Once you put that clause on things, the number of PHP frameworks drop dramatically. It's not publicly available at this time but a self-hosting demo site is available at http://www.remarableumbrella.com/rf/
Ben: the problem is that you can't "just know" which framework is going to solve your problem. It's only going to happen from actually using it. And you still have the learning curve of the framework. What are the methods and properties and arguments? And once you decide that a framework isn't working for you, how do you just switch it out?
You could patch it yourself and working in your own solutions. If you modify the framework source, then you've just eliminated your ability to upgrade when a new version of the framework is made available. Assuming the framework is open source, you can hope to push your changes into the core development.
Rod: Yes, .NET is an unusual beast in that you don't really have much choice but to use the framework to develop in. The framework is the language.
Of course, had to put the typo is the worst spot. http://www.remarkableumbrella.com/RF/
Daniel: You're right, I suppose it is a little. In retrospect, maybe it should say "Why (most) Frameworks Suck", which I think is accurate.
Jon: I guess so. Perhaps the frustration stems from the "many tools for the job" phenomenon in the web development world.
The domain of problems when developing for the web is typically much smaller than, say, when developing a desktop OS application. When I see "framework" I start to think Cocoa and the like on Mac OS X. There are a multitude of frameworks for different facets of the OS; you learn what you need to in order to achieve your end. (And you subclass and categorize when you need to, thanks to the OOP nature of them, oh we lucky Mac devs!).
Perhaps you are lamenting the amount of choice you have? :) Or are you advocating avoiding third-party implementations altogether and just rolling your own from primitives?
I've been looking a for a good 'general purpose' PHP framework for a while. For the most part, I use my own classes/functions and a few PEAR libs, but sometimes that's just not fast enough for my liking.
I've been keeping an eye on the following frameworks:
Seagull
CakePHP
and more recently symfony-project
They are all interesting, but I think I would have to invest quite a bit of time to be confident enough to develop solely within a chosen framework. Unfortunately, that's time I don't really have.
Cheers;
Poncho
I have tried a lot of php frameworks and i never really found what i was looking for. So i tried to build my own pseudo framework around smarty and some other cool classes i found on the net...
Now i am a happy ruby on rails developper ! Rails is exatly what i wanted as a framework (some exceptions though). And the language rocks !
Learning a framework is really like learning a language.
This is what has kept me from picking up someone else's framework. That being said, I do have a great library of functions that I rely on...
I'm really very reluctant to adopt a framework. What you've exposed are really the major points for being that way.
I really prefer seedworks.
http://www.martinfowler.com/bliki/Seedwork.html
But my own ones. When I start a project I use to copy some base classes from my previous one. And it keeps evolving...
I would say most PHP, javascript frameworks/libraries suck because they don't come from the most authoritive parties. They're mostly built by one person or really small group. That results in not so modular/re-usable, not the most solid in functionality or performance, etc--basically, most of the time, they won't be suitable for wide audience. And who knows the future of those.
Now, compare those libraries with the ones come with, say, Java, C++, or C#. They come from Sun, C++ committee, or Microsoft. So much resources spend on those libraries it's so stupid not to use them when applicable because they're guaranteed to provide the most usability and performance.
Joshua,
I feel exactly the same about most of the frameworks I've seen. Either not enough developers to really offer a good scope of functionality, or too focused on one particular application type.
I'll be very interested to see what Zend come up with for their collaborative PHP framework.
Cheers;
Poncho
On a smaller level, I think this is why there are people on each side of the Textpattern and WordPress camps. Textpattern has its own tags, that mimic XML / XHTML, and so are easy to pick up for front-end designers. WordPress uses more raw PHP in templating, so it appeals more to developers.
People that swear by Textpattern say "I don't want to learn PHP" and people that swear by WordPress say "I don't want to learn proprietary tags, plus I already know PHP." I'm somewhere in the middle (but use TXP mostly). Hopefully that wasn't too off-topic. ;)
Poncho,
To counter what you're saying, I think that frameworks focused on a particular application type are a really good thing.
By focusing on a smaller class of applications, it's a lot easier to deliver a good result.
Of course, this means that you're going to have to use more than 1 framework in your programming life, but that's just a case of "the right tool for the job".
I wrote a bit of a framework in PHP and javascript, well several modules that I use to save time. They aren't congealed into one massive thing yet.
One is a Validation module. I can write the validation parameters in HTML on form elements, and it does both javascript and PHP validation for me :) I've also got a nice AJAX object, modeled after someone's EventManager I use (CPL'd). Also had some nice PHP code that would turn a DB request into XML file (which is really HTML), and the javascript would plop it right into the page. Made things nice.
I'm also learning Ruby on Rails, which is very nice. A common thing to do in web apps (like make a bit table listing, with sorting and paging, much like phpMyAdmin tables) took 1/3 of the code in RoR as our PHP equivalents. Mostly b/c of Ruby's ability to pass blocks :) Get's rid of a lot of if's, and makes things far more extensible.
Good call on .NET. I've worked with it, and the framework is indistinguishable from the language. You can't go outside the framework to do anything (well easily anyway). It's easier to get dirty when using Rails than in .NET.
Just wanted to point people to another post on frameworks. This one featured on SitePoint. Quote of interest:
hehe...yeah i noticed. Congrats and nice post!
Frameworks should make developing easier. The problem is some of them, being a suit-all solution, are just too complex and feature-heavy that learning them is like learning a whole new language. The good thing about them is they rely on convention, so when the whole team knows the convention it's just easier for everybody.
Also, most of frameowrks I've seen are implementations of MVC. Studying them is very useful if you wanna implement your own light-weight personal framework.
This article sounds very good. Thanks.
I belive that if you dont have the time to study a framework..dont go for it...but if you have some extra spare time, spare it to learn a framework...a framework is only good, if you know its backs and fronts and knowing how to use them...personally, i think symfony is a good php framework...but one that you have to learn in advance...before starting to develop with it...
You got some good points there. It's hard to learn a new framework, because it not only adds a new layer of complexity on top of a base language, but if something doesn't work the way you want it, it can take a long time to figure out how to customize the darn thing.
I just released a preview of a new framework for PHP 5 that I've tried very hard to design so each part of it can be customized or replaced easily, as well as use concepts that are easy to understand for roll-your-own PHP types. Check it out at http://www.willowgarden.org
(yeah, I'm late, but you linked this post yourself)
Saying that Rails is 'the one exception' is just bs. Django is very close to the level Rails is at, and is, in my opinion, just as good if not better. What's the reason exactly Rails is "the" exception?
Veracon: See my response. :)
I have to say I agree with you on this one.
I have looked at the few PHP frameworks out there at the moment, but none really appealed to me. So rather than spend time to learn every little aspect of a certain framework, I decided to build one myself only for me and with the features that I needed.
I've created three entire CMS's and a variety of small scripts / plugins / etc., but nothing I'd like to consider a framework.
That said, however, I'm planning on diving into Django, because I want to do more than just another PHP CMS, and I don't want to build a PHP-based framework that I can re-use myself for all the various sites I have planned. I want to get into Django (and really learn it, and Python) so that I can make proper use of it and just spit out sites more quickly and easily. I believe that it can offer me that, and I'm willing to spend time learning it fully so that it does.
I agree. We went with a lightweight framework using Yahoo dom and event, thats it. So, in our behaviour framework, developers can use thier own libraries, but they would have to include them as a package, which means all dependants have to come, meaning your happy face widget is 100k. And sharing also. Those the 2 problems I see.
Hi Jonathan,
Nice site and nice comment system, however I think you've made a big oversight by lumping framework and libraries together in one pot. Your description absolutely desribes a library and it's a shame only 1 person out of the current 36 comments has picked this up.
A library is something a developer would use to abstract and simplify a small, specific task, ie resize an image, or create a draggable item in the GUI. In terms of patterns what the Facade pattern does is very close to what you'd expect from a library.
A framework is totally different, and as pointed out earlier it's suggested workflow and approach for building a program or web application. A decent framework will allow you to incorporate a number of the best of breed libraries to help you build the required application. Hopefully it won't rewrite libraries that have been done many times before, although this is a very typical MO in PHP.
The Zend framework is a bit mis-marketed in this sense (not unlike some microsoft products) because it provides some framework components (mvc stuff) and some libraries (Zend_Filter, Zend_Cache). Like many "frameworks" these are just rewritten libs that were probably better in their first incarnations written 5 years ago in PEAR.
In my view a decent framework would be one built on top of an existing and reliable set of libraries, and didn't get in the way too much.
The java and .NET libraries have around 1000 packages each, and they are 'built in' in the sense that you don't choose them, they are vendor-preferred. Ruby and python are the same, and though their library base is smaller it's just as robust. Perl is similar to PHP in that it's a free-for-all in terms of which 3rd party libs you want to grab, but CPAN has long been the main choice.
PHP on the other hand has something of a library crisis. Although PEAR is clearly the most complete and extensive set of libraries numering greater than 400 packages, it is recently trendy to disapprove of PEAR for various fuzzy reasons. It is worth pointing out there there is not even a close second to PEAR, say with 300 libs, or maybe 100, or maybe 50 - nada.
Anyways, looks like this has turned into a rant. In brief, I think the question shouldn't be "why do frameworks suck", but rather let's look at how other languages are benefitting from stable and preferred libraries, and could we chop the SF 630+ frameworks down to a tenth by doing the same for PHP.
Maybe with PHP and small-time web development the best framework is your personal one.Using an available framework is probably a second choice.
This is apparently supported by the fact that there are at least 70 frameworks available, which makes me guess there are many thousands of personal ones.
http://www.coldscripts.com/PHP/Scripts/Programming/Framework/
I always came upon blog like this writing about frameworks, libraries and stuff, and always came close to believing it, until I myself discovered that in the actual fact, a framework , does helps you a lot in programming and developing applications. But I am not denying that learning a framework is something that one cannot skip or avoid, and yes, learning it takes almost the same effort as learning a new language, but less hectic provided that you know the language that the framework is written in.
If you are looking for some decent framework that can really ease your programming stuff, than I would advice to spend some time learning it inside out, and then only will you be able to debug your application should something bad happens, and really make use of the framework libraries. Look for one that have great documentations, and great set of libraries also, one that I would suggest is symfony, a PHP5 framework, which not only have great documentations, but they also have large community support, and just recently wrote a book about the framework, owh, and yes, they even have Yahoo guys interested with it. Ruby on Rails is another sample of good framework, but I have never tried them on any real project.
Yes, learning a new framework is quite hard, but if you can learn a new language, than there's no reason why you can't learn a framework, give it a try, and make sure you have the ample time to slumber yourself with it.
I think that using your framework or other's frameworks depends very much on the project size and the languages for it.
For exampla for one big project for mine, it was easyier to use my php framework becouse it is design for that type of projects. But the on other side I have to use prototype & scriptaculous becouse there was a lot of js goodies and I didn't have time for building the js stuff from scratch.
p.s. The easyes way to learn a framework(thats my opinion) is to start reading its source and understanding it. In this way you will understand not only the framework, but the coding style and technique of its creator(s).
.NET frameworks suck for end users because they have to download the frameworks to use an application. It reminds me of VBRUN hell back in the 90s. For instance, I just downloaded this benchmark tool, and I have to download a specific .NET framework. Stuff like this should be transparent to the end users.
I built my personal framework the other night and even consider to unify everthing, but then again.. yes.. learning frameworks is like learning a new languages.
I tried CakePHP and was very happy with it, contributed and all that, but there was always something not going "my way". I realized that soon after i finished to write my SmartyView for their MVC model. I can't let go, no matter how nice a framework is. Once you are used to something like Smarty you will always miss it.
After reading this post i think i will not try to bother anyone with my approach. There are really way to many frameworks, powered by armys of contributors. I suggest every coder out there to build their own and go on with it. It is fun and worth it.
I feel that frameworks can be over-killer for small projects and only pay off when working on large ones with several developers. In those cases a set of conventions and a shared way of doing things comes handy.
I've worked with both Django and Rails, and found that Rails is more pragmatic and flexible. The key for Rails is that their interfaces are well thought, flexible and most times they stick to the natural way of thinking.
Regarding PHP I've found this comparison
of PHP ports of Ruby on Rails framework and where it seems that Akelos might be the best framework for PHP, they have not only ported Rails, but have added a simplistic internationalization layer and have solved some PHP problems in a simple way.
Bermi (the guy who coded Akelos) has ported Rails and sticked to their philosophy for simpleness. The bad point it's that Akelos is quite new and needs to get a community around it. In the article they've penalized it for being short in documentation (inline docs match Rails API docs), but I found that ALL RoR docs can be used for Akelos and that's a sort of community share.
In your example for handling a file, thats fair simple in PHP, so they just added a static function for handling files named as the PHP one but on the Ak:: namespace, so if you do Ak::file_put_contents('/hi/there', 'Hello') it will work as PHP one but will be restricted to the application directory and will create folders as needed (if you run PHP as a different user it will work transparently via FTP). They haven't reinvented the PHP wheel, they've made PHP go on Rails.
Finally I would say, whether Ruby, PHP, Java or Python I prefer to work with frameworks that mimic Ruby on Rails, that helps me not to learn a new language every time I have to work in a different platform. Rails language is plain English and that makes things go smoother.
On my point of view, i HATE smarty-template cause they mix output with programming-alike. I know that smarty got the major part of template-driven classes but i found one that share my point of view (ie: leaving the code on one side, the template on another)...
You should try Xtemplate then. I personnally add 2 more functions (compacting the output and transfert a template result directly to a string). And i must say that is working really well that way.
With Xtemplate, you manage all php code in a php file (even with dynamic output row) by 100%. The template tags are fully custom of course.
I'm using this for my clients projects and for myself. With it, when the php codes are done, the clients/me can concentrate on the design part without any restrictions.
Giving it a try is to adopting it... at least virtually of couse.
regards,
I like build all thing by myself, all under my control. But sometimes use other frame work is really a effective way.
I've used a lot of frameworks in a lot of languages, and found that developing my own is the best thing I've done. A framework is as much about methodology as the code it provides, and the best way to match my methodology for building websites to a framework was to build my own.
Of the frameworks I have used Rails and Fusebox are my faves, and my own Framework takes what I believe to be the best elements from both.
during my three years as a professional PHP developer I pieced together what I would very loosely call a framework. I realized I was moving towards a reusable, efficient code base, but never became fully satisfied with things. Then along came Ruby on Rails - they got it right. I have since fully embraced the Rails community and don't think I will ever go back to the chaotic, inconsistent nature of the PHP realm. Not to say i think it's a bad language - its definitely a very good language - Ruby is just more of a joy to write!
Well, I love this conversations, because i now decided to go with an framework. I am tired of finding libraries on the way.
In my openion all are about need , If any projects require something which is avaiable in a framework why dont use them? But the main problem is there is many... Decision making is tough.
Thanks nice article.
This site now is running on CakePHP right?
Fixing certain tedious tasks is therefor not a bad thing, right. Why re-inventing the wheel, if the wheel has been programmed numerous of times already?
Because it's not up to the specification. It's the same thing with just buying a house and having one purpose built for you.
PHP is such a loose language, and it's own function naming scheme isn't even consistent in some respects. I think PHP benefits from from a framework simply because it makes things more consistent. I've looked at my code compared to that of my friends, and everyone does everything different, and to me, it's much more confusing to sift through custom libraries/class files and try to figure out what's going on, then figure out how to mix it in with my existing code. A framework simply makes things more consistent, and from my experience, much quicker to develop with. If you use a popular framework (Cake, Symfony, CodeIgniter etc) you usually have a pretty good set of documentation to go along with it that other developers can reference. How many times have you built a site from the ground up with your own framework/code and provided decent documentation (or any documentation) for possible future developers?
I'm surprised there hasn't been any mention of CodeIgniter yet. So far it's my framework of choice. It's extremely flexible, consistent, and doesn't force you into a template system, or even force you to use models if you don't want to.
A lot of Ruby people are already moving away from Rails and going to stuff like Merb...