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).
Why I Hate Frameworks - a popular article (Score:5, Interesting)
Do you really need a framework? (Score:5, Interesting)
Yes, reuse is good. But too much functionality in one package is not necessarily good. Sometimes it is better to rely on multiple small reuse libraries than on one "all singing, all dancing" framework.
For instance, if you have a large number of teams, do they all have the same needs? If the teams have divergent needs, picking "the best compromise" in a framework can have negative implications on their productivity.
Also, is the quality of the framework consistent across the whole system? For instance, if you have network class libraries and gui class libraries, are they both equally good? Or are you sacrificing on one side to get the benefit of another?
What are your maintenance/upgrade needs? While it's relatively easy to keep 5 versions of a network library around for legacy applications that don't need to upgrade, it's a very different story to keep 5 different versions of
Do you need all of the functionality the framework is bringing you? It might be nice for you to have choice, but how does the size of the framework affect the end user? If your app is small (say 1 meg) compared to a large framework (say 25 megs), it might not be so good.
What's your backup plan? What if the vendor of your framework abandons it? Or refuses to fix critical bugs? Will you be able to find something else that you can use in its place? Smaller pieces can be replaced easier than bigger ones.
I know this isn't the point of the question. But before you decide what framework you want, I urge you to consider whether you *really* need one at all. There are lots of reuse libraries around for every kind of application. It seems likely to me that picking and choosing *exactly* what you want for each circumstance is going to give you better results.
My criteria (Score:5, Interesting)
2) Philosophy - I need to agree with the way they do things. Major reason why I ignored EJBs, but jumped on Spring
3) Cost - I hate having to spend unnecessary $$ when team members cycle, or we have to do an install. Free is best
4) Standards Based - Vendorlock is teh suck. I like the options of being able to swap a component if I'm unhappy with it, even if I know I'll never swap it.
5) Familiarity/Ease of Use - Will it ease into what we're doing? Can the team become proficient in it in a reasonable amount of time? Is there decent documentation available?
6) Licensing - I don't like unecessary limitations, or surprising my customers, so I avoid things like the GPL.
Re:Easy to decide... (Score:3, Interesting)
How Dilbert [dilbert.com] life was back then in the late 90's. Sure it was a long time ago, but I bet it's "good practice" someplace...
Documentation! (Score:4, Interesting)
Next I take a look at the amount of functionality offered, compared to the pain of learning the framework, and the risk of tying my code to someone else's code that may break or not work on some platforms. Another important thing to consider is how easy it would be to write your own equivalents of the bits of framework you need. If the benefit to pain/risk ratio is too low, I eliminate it from consideration. (That's always been enough to keep me away from Struts--it doesn't seem to do anything that's hard to do anyway, so it's not worth the pain and risk.)
After that, it might be time to look at specifics like how clean the API is, how mature it is, and so on.
Loaded question but a few a musings. (Score:5, Interesting)
1. Know what goals you have to meet. The eventual success or failure of a software project has more to do with having a strong vision of what it is you need to accomplish at the beginning regardless of platform or tool choices made before and during its development.
2. Be wary of selecting anything because it's cool. Many engineers, I think, fall into the trap of buying into cool toys rather than selecting mission critical tools.
3. Pick frameworks with a maturity directly proportional to the criticalness of the application you need to develop. If you are building something that is to be the the cornerstone of a company, you should pick well established frameworks that have a proven history and proven credibility to provide effective features. Conversely, feel free to experiment with less proven frameworks for applications that can afford to be less robust. A balance between sticking with tradition and building for the future does have to be taken into consideration.
4. Identify the top 3 features your application has to deliver and ensure your chosen framework excels at those features. Bells and whistles and future expansion are nice but make sure you take care of what's critical first before comparing extra features. This will help focus your evaluation and not get side-tracked by all the cool stuff a given framework might provide.
5. Experiment with possible options. There is no reason to select a framework based on paper analysis. Try as much to get your own hands-on experience.
6. If possible, interview other people who have used the framework in real applications. Get the opinions of people who have actually used your options in the real world. Don't let tech demos be your only guide.
Re:missing (Score:1, Interesting)
Re:Why I Hate Frameworks - a popular article (Score:4, Interesting)
It is claimed in that article that the distinction between a framework and a library is a subtle one. Not so, not so. Programming languages are themselves frameworks, whereas an add-on framework is often a poorly implemented, misunderstood, misappropriated, half-assed, dumbed down, broken programming language. It is an attempt to add task-based end-use assumptions to a language, to turn an existing language into a special purpose tool. That could be bad, unless the framework was designed by someone who understands programming language design, or if it is done in a language designed with such extensions in mind - CLOS for instance.
So either forget frameworks, or choose them as you would a programming language, and accept that you have to learn and play by their rules, philosophy, paradigm, what-have-you. Just as you wouldn't want to write C style code in CLOS, you would rather learn and use the CLOS special facilities. CLOS *is* a framework, as is C, as is any programming language. This is why Objective-C is the greatest language EVAR, it took two completely at-odds programming philosophies and bashed their heads together. C, fark your static type system and compile-time checking! Smalltalk, let me introduce my old friends malloc() and SIGSEGV!
Re:My criteria (Score:2, Interesting)
2) Open source, freely linkable and redistributable in any form.
3) Free.
4) Can be compiled to use stdc++, or use its own internal classes. Uses native controls etc where possible. Cross platform.
5) Very easy. Well documented.
6) Very flexible license, few limitations.
And what is this wonderful framework? wxWidgets.
Compiles on Windows, *NIX, Mac, Palm (!), PocketPC (!).
Has bindings in Perl, Lua, JavaScript and half a dozen other languages, but is native to C++.
Easy enough that a complete noob at C++ (myself) can get to grips with C++ and wxWidgets and have compiled apps running successfully with low resource use inside two weeks.
I recently referred it to a heavy duty programmer who has been in the job for a while (10+ years), and he fell in love with it after about 2 hours of using it. He loved it so much that his company's next major app is going to be written using it.
Here is how programmers did (Score:2, Interesting)
Until a lone coder, sick at the lack of progress on this front, turned up with version 0.1 in the language of his choice.
I hope we're not going to regret this
A Vision About This (Score:2, Interesting)
As I've begun writing applications for a living I've gradually been looking for a easy easy easy method of application development. Something that is truly RAD. For desktop applications I've settled on an old Amiga BASIC language and cross platform application framework called PureBASIC [purebasic.com] that's been ported for Linux, Windows and Mac OS X. However for web toolkits I still haven't found that "magic bullet" that makes things truly and absolutely simple.
One of the things I like about PureBasic is that it is a high level language that is at the same time compiled directly to machine code (with optional inline assembly language.) The resulting binaries are usually under 60k. Despite this it has a full featured Widget set that uses native widgets (and a GUI designer on Windows.) I kinda wish there was a (cross platform) web development language/framework out that was like this. You could write your application in it and you could instantly compile it to:
The language would have built in session managment. You could get arguments as built in variables that would be created automagically by the compiler based on the target. This idea really would work.
I was so enthused by this prospect that I pulled out flex and bison and began writing a grammar for the language. Of course, I had just finished arithmetic operations and string functions (and began reading the ISAPI documentation) when I realized the magnatude of what I was beginning. I just don't have time to get this done in the next year (even compiling to C and using MinGW/gcc/GC as I was planning.)
But if it WAS finished it would truly be an awesome tool. You might even build in a template toolkit, possibly even a content management system. And the whole application would be a tinly little 60k
Libraries are better than Frameworks (Score:2, Interesting)
As a Java programmer for many years I can relate to the above article, there is simply too many frameworks, config files and overhead required in proportion to the size of most projects.
In the end your choice should be about *overall productivity* which is different to everyone. Note you should compare it to the task at hand, some frameworks are simply better for certain tasks. This should include time required to learn a new framework/language/platform, development, maintenance, deployment, installation, setup, updates, etc.
I personally prefer framework/platforms that allow me to write the minimum amount of code, as any code I write is code I have to maintain. My weapons of choice for Web 2.0 projects are:
- Mono (Open Source / Crossplatform / Feature Complete )
- Boo (statically typed, Python-like language, with built-in templating so you don't need another framework to compensate for it)
- IHttpHandler (Lighter weight alternative to ASP.NET pages, akin to Java Servlets)
- JQuery (A must for Javascript apps - borrows the best features from Prototype, Behaviour, Moo.fx and more)
I was seriously considering RoR, but ended up going with Boo as it is statically typed, faster and has access to the