How Do You Decide Which Framework to Use?

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:

1. perceived ease of use (e.g. easy to learn, easy to adapt)
2. perceived usability (e.g. improving developer performances, reducing work, faster development),
3. perceived sustainability (e.g. perceived long term support, supporting standards, clear project directions) and
4. perceived fit to specific developer requirements (e.g. suited language, suited functions, suited architecture).

What are your criteria? Do you support the factors listed above? I am not asking for a preference on a specific software framework, but rather an explanation on the non-trivial task of framework selection, which might be very usable for both frameworks developers and framework users."

Comments

Easy to decide...

[moronikos]

You use the one your boss tells you that you are going to use.

Re:Easy to decide...

[hutchike]

So true! I worked at a place where our boss decided that every framework class was to be wrapped in a bespoke wrapper with a slightly polluted API, meaning all my skills were unportable and my pay check never rose too high (until I quit).

How Dilbert life was back then in the late 90's. Sure it was a long time ago, but I bet it's "good practice" someplace...

Go for the hype.

[croddy]

Personally, I'd pick Ruby on Rails. Not that I have any technical reason to prefer it, mind you... but man, it's so jam-packed with alliterative goodness and it's all Web 2.0'ed out and shit. And it has some crap called a scaffold. Do you have any idea how many struts it takes to build just one scaffold? No? Well it takes a lot!!

Difficult to answer

[IntelliAdmin]

This is almost as bad as asking "What programming language to use for a project" It all depends on the needs and experience of those involved. Sometimes it means rolling your own, other times it is better to get one that has been fully tested in the field for some time. Either way it is a silly question to ask.

Re:Difficult to answer

[Tony Hoyle]

More to the point, the design will answer the question for you (as it does for the 'what programming language' question).

You design the application *then* you start making technical decisions about implementation - not the other way around.. there's already too much crap produced by people who *must* use the latest wizzy 'framework' and then design an app to use it regardless of the functional requirements.

Re:Difficult to answer

[Dlugar]

So the answer to the submission is "Whatever is needed." Another pointless article.

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:missing

[larry bagina]

Do you also think linux is easy enough for your grandmother? Do you also think ogg vorbis has widespread use?

I think you've spent too much time on slashdot.

Framework schmamework

[quantum bit]

I've played with a bunch of frameworks based on Java, Ruby, Python, etc... However for my last few projects I decided to go "old school". Since the target platform was Windows, that meant plain C and Win32 API. No MFC or anything. Staticly linked libpq if I need database access. Extra plus is that without C++ or COM frameworks, I can use mingw gcc on my BSD workstation to cross-compile.

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.

Do what the rest of us do

[gadzook33]

Evaluate each one based on what's important to you. What language do you use? What platforms do you support? What libraries do you incorporate vs write yourself? I'm not sure there are shortcuts to answering any of these.

Why I Hate Frameworks - a popular article

[hermank]

Hmm.... I think you should read this first, in case you didn't. http://discuss.joelonsoftware.com/default.asp?joel .3.219431.12

Re:Why I Hate Frameworks - a popular article

[russellh]

snarky. reminds me of why I dislike joel on software.

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! ..but to answer the poster's question, first choose a language that best matches your problem domain, ensuring (hopefully) the minimum size of the framework and minimizing philosophical contradictions between it and the host language.

Do you really need a framework?

[wrook]

I think the very first question you should ask yourself is, do you really need a framework?

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 .Net or the JRE around. Are you sure you want to upgrade all the apps all at the same time?

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

[TrappedByMyself]

1) Established - Needs to be stable and in heavy use. New stuff is fun to play with, but not an option for paying customers.
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.

Let me tell you about this better web technology

[ad0gg]

ColdFusion, yup thats right. You can have your struts and scaffold, my website is power by cold fusion. Let me tell you it picks up the honeys when i say i work with cold fusion. Good luck picking up a lady telling them you work on struts, scaffold or java beans.

Here is how my boss did

[2Bits]

That reminds me of a (quite large) project a few years ago. We were deciding what language to use, what framework, what methodology, etc. And the boss asked:"How many frameworks can we use in the project?" We gave a few, and he wrote down one himself. He then drew one on each corner of a paper, put his pencil in the middle, and spinned. It pointed to COBOL, which is the one he wrote down.

Imagine the look on our face... One of the colleagues later told us he almost peed in his pants for that experience.

Seriously though, this story is just a bit exagerated, but not that much, the selection process was almost like what I just described :)

You know, I was wondering

[bradleyland]

I was wondering how hard it must have been for the submitter to write that summary without mentioning Rails at least once. It feels almost like bait.

bloop bloop

Frameworks?

[Theatetus]

*shrug* I use Lisp. Most frameworks take about 4 or 5 macros to emulate. Not really worth the time to download any of them.

Those who don't use Lisp are doomed to reimplement it...

Documentation!

[metamatic]

The first thing I do is try to browse the documentation. If there isn't any, or it's no good, I eliminate the framework right there and then. (That kills SWT/Eclipse.)

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.

[Runesabre]

There are so many criteria you have to consider that are so situational specific that it would be near impossible to write down the complete guideline. But I think there are a few solid guidelines to start with or consider.

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:Simplicity is key

[Serveert]

HQL has major limitations but you can rip out into native SQL using createSQLQuery() I believe. Map it into a hibernate class and you're golden.

When selecting aggregates, JDBC works well. But Hibernate is pretty amazing if you are aware of its limitations. 90% of my code uses hibernate, 10% uses jdbc.

And the code that uses hibernate is pretty neat, it cuts down dev time significantly. I use hibernate tools in eclipse, point it to the DB and it generates all the classes, parsing foreign keys, making the associations.

Don't get me wrong, I like to be unique and cynical, against the grain if you will, but hibernate, despite the jerk off creator of it, is amazing and useful.

I'm starting to sour on frameworks

[Jerf]

I've been developing for about ten years now; not as long as some people, but enough to be getting over the ten year hump for competency. As a result, I don't expect that everybody can pick this idea up and run with it, but it might color how you look at the frameworks.

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:

1. The resulting framework is quite often nearly impenetrable to an outsider, so when it's wrong, it's really, really wrong; even an open source framework might be of only dubious value since you're unlikely to be able to unravel all of the pieces in any useful amount of time.
2. As you add pieces together, the complexity of the whole increases geometrically. (Not "exponentially" as the term is commonly abused.) This can be mitigated by maturity, both of framework or core developer, but that's more rare than you might think. But the thing is, you are very unlikely to need all of the pieces. If the framework does 40 things, at a complexity of 1600, but you only need to use it for 12 things, at a complexity of 144, you're gaining an awful lot of complexity. (The numbers are of course made up, but the idea holds; don't try to over-rationalize the figures.) What's worse, as mentioned in the previous point, you might want to do 3 things that the framework fights you on, and now you're either going to have to give up on those 3 things, make unbelievably ugly hacks to get each of them half-sort-of working, or scale a huge learning curve to fix the framework that you are now significantly invested in, but know effectively nothing about the insides.

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

What is a framework?

[SickLittleMonkey]

A framework ...

"... dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on your application. The framework captures the design decisions that are common to its application domain."

Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software.
Quoted from Tapestry in Action by Howard Lewis Ship.

Howard continues: "Frameworks are very useful; instead of your having to start with a clean slate, the design is partially filled in and the path to follow is clear. Many design decisions are already made for you, decisions that leverage the combined experience of the frameworks' authors and users."

And that's why when weighing up JSF or Struts, I chose ... Tapestry!

Re:Use what you know

[mattoo]

Yeah great! Fear of learning new things is always the way to success...