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."

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.

Oh yeah, ol' school baby!

[MacDork]

Another upside is that there's no one but you who can fix or maintain it! ;-)

My Views

[INeededALogin]

perceived ease of use (e.g. easy to learn, easy to adapt)
In the business world this is huge, because time is money. That is the reason that Developers use these tools instead of developing new code from scratch.

perceived usability (e.g. improving developer performances, reducing work, faster development),
This might be hard to measure unless someone has used it in the past. Reviews of Toolkits are also hard to find and many places are gonna be bias.

perceived sustainability (e.g. perceived long term support, supporting standards, clear project directions)
Huge, you have no idea how many times I have seen projects go with some new library that disappears from the world the next year pushing you to dead links in google. The project has to have a firm backing by something. Like, libraries coming from the Apache team is a great example of something you can rely on in the future, but libraries from some random person who made a gnome lib just doesn't make sense.

perceived fit to specific developer requirements (e.g. suited language, suited functions, suited architecture).
This is a given I would say. When I look for a toolkit, I usually start with this as my search parameter(example: "Python iTunes" or "C++ XML").

Now, I don't have much to add to the list since I believe it is a good list, but I would also say that being a rebel when selecting toolkits will set you up for failure. Selecting your friends toolkit or some open source toolkit to save $1,000 will often find the blame for outages coming down on you.

So, a criteria should be stability. What state is the code in. If the code has 700 bugs logged against it, then it might be a problem. Also, how many people are currently implementing the toolkit. While it is a falacy to think that the majority is right, I look at it as survival of the fittest. Toolkits that are useful, supported and implemented, tend to be re-implemented if they were successful as people move around from company to company.

Re:missing

[Trejkaz]

"Can you name any website or application currently in production that does."

The Rails Wiki [rubyonrails.org] has a list.

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.

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!