How Do You Decide Which Framework to Use? 291
GPolancic asks: "Software frameworks are increasingly popular software reuse technique, because they provide infrastructure functionalities to an application, or a layer of an application and therefore
reduce the work of a software developer. Numerous complementary (for example: Struts and Hibernate)
and competitive (for example: JSF vs. Struts or JSF vs. ASP.Net) software frameworks are available as both proprietary and open source software. A major precondition for the success of a software framework is their acceptance, which is related to market share or community size. On the other side, application developers need to review and select the best available software framework for their needs. Which factors do you evaluate before you decide to use a specific software framework?"
"Our presumption is that software developers mostly evaluate following software framework characteristics based on:
- perceived ease of use (e.g. easy to learn, easy to adapt)
- perceived usability (e.g. improving developer performances, reducing work, faster development),
- perceived sustainability (e.g. perceived long term support, supporting standards, clear project directions) and
- perceived fit to specific developer requirements (e.g. suited language, suited functions, suited architecture).
Easy to decide... (Score:5, Insightful)
Difficult to answer (Score:5, Insightful)
Framework schmamework (Score:5, Insightful)
It was a little more work up front, but I've gotten nothing but extremely positive responses about the interface. The application binary usually is under 50k, even the larger ones don't break the 100k barrier. They're extremely quick and responsive on modern machines, and still very usable on older ones. I like to do processing asynchronously (i.e. user types a few characters and a DB query kicks off in the background when they stop typing) and it keeps things snappy. It's pretty easy to literally run circles around all the bloated apps eating up tens of megs of memory or more.
It all depends (Score:2, Insightful)
As much as its easy to suggest "use-this-or-that-framework-because-its-the-best"
Do what the rest of us do (Score:3, Insightful)
Re:Oh yeah, ol' school baby! (Score:2, Insightful)
Re:Framework schmamework (Score:2, Insightful)
OH NOES! It'll never handle it!
Are your win32 calls supported by WinXP and Win2000?(probably) How much effort would it take to port it to linux? Are you helping lock your organisation onto a single software platform?
Re:Difficult to answer (Score:4, Insightful)
You're all missing the point. The question isn't "Which Framework Should We Use?", the question is "How Do You Decide Which Framework to Use?"
The answer the first question is, quite obviously, "Whatever is needed." But the second question is asking, in essence, "What factors do you use in determining 'whatever is needed'?" That seems like an interesting question, and I'm surprised people don't seem interested in discussing it.
Dlugar
Re:Easy to decide... (Score:3, Insightful)
Let the market steer your decisions. (Score:2, Insightful)
If you are working on a product you have more flexibility to choose your own frame work, but if you are consulting or responding to RFPs then you have to choose a framework that the client is familiar with and comfortable with.
If you are going to be doing work for government or larger companies they probably already have a lot of time and money invested in a framework, so if you plan on doing work for them you better be able to develop in their framework.
Marketing also plays a big role, Microsoft, Sun, IBM and the other players spend big money targeting the decision makers in IT. If you decide to go with a framework by one of the big players you can leverage some of the marketing to your advantage.
If you have a good team of developers the framework isn't as important as you may think, a good team will be able to make a successful project regardless of the framework; so choosing the framework to match the market and your clients is an important decision.
I recomend that you evalute your potential customers and see what they want then train or hire developer with knowledge of that framework.
I'm starting to sour on frameworks (Score:5, Insightful)
I'm really starting to sour on frameworks. Libraries, love 'em to pieces. You want to take care of all the bit-bashing in the video card and present me an OpenGL interface, thank you very much. You want to give me a proper 21-st century file abstract like the KDE io-slaves, you have my gratitude. But you start bundling together five or six different technologies, each themselves fairly simple, and give me this unified framework or something, and in short order I'm likely to be cranky. This is especially true for things that are themselves fairly easy, like emitting HTML.
The problem is two-fold:
Especially in this age of using more dynamic languages, I'm finding I'm a lot happier taking smaller libraries and tying them together with my own frameworks, which I understand and can make sing and dance in exactly the ways I need them to with only the minimal complexity.
One important point here is the scale of development. If I'm going to do a three-week project, I'm going to probably go ahead and use a framework. But the larger the project, the larger the team, the more time that geometric price has to come up and bite you in the ass, where you Absolutely, Positively Need this thing the framework can't do, and it has to be done by tomorrow.
Also depends on your skill level, of course. And one of the cardinal Laws of Programming is that there are no Laws of Programming, only tradeoffs. I don't expect everyone to agree, I'm not pitching this so much as throwing it out as food for thought. Caveat, caveat, caveat.
I don't do Java, but my guess is that Hibernate, to the extent that it is a framework, is probably a win because it's so mature. But then again, you can also look at it as a really big library, because it sure does seem to play well with a lot of things. I think one of the distinguishing charateristics of a "framework" as I mean it in this post is that it is well-nigh impossible to glue two "frameworks" together, and sometimes even adding the capabilities of an additional library is an exercise in frustration. But the upshot is, I'm finding in practice that I'm a lot happier and more effective in the medium and long term, even on my own projects, with libraries that I tie together myself and not "frameworks".
While I'm not dogmatic about any particular one of them, the Agile-style development really help with this, and I might not feel this way without their influence. Automated Test (unit tests, usu
Ah, my pet peeve :) (Score:3, Insightful)
Singletons in the J2EE framework. Compare this monstrosity [theserverside.com] with a sigleton implementation in any sane language, including the simple, non-J2EE Java. Mind you, I'm not bashing J2EE here , the singleton issue is the price you pay for scalability.
Using Java for GUI on Windows. Most GUI libraries built on top of the winapi at least let you get the window handle from their widget implementations so that you can get straight through to win32 and do your hacking there (possibly fkcuing up the lib, since it doesn't know about your updates, but that's another issue :) ). This is not the case with Java - if a winapi function is not reflected in the Java API, you are pretty much screwed.
Persistence frameworks. "You won't have to write a single SQL statement for the rest of your life!". But if the statement generated by the framework is suboptimal, then guess what? Yup, screwed again.
Good luck choosing your framework. I hope I scared you to death, because, in my opinion you cannot be too scared of frameworks :)
Re:Easy to decide... (Score:3, Insightful)
Just tell your devs to use "the standard of the industry" == what everyone uses (struts) even if it's a fucking piece of crap (struts) and if dozens of projects have failed because of this heap of dung (struts).
Because that way, you protect your ass: if the project fail, can't be your framework choice, you chose "the standard of the industry", it's obviously because of the devs... or the marketting... or the hardware... but not you.