Slashdot Mirror
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:
- 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).
You use the one your boss tells you that you are going to use.
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!!
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.
I think you've spent too much time on slashdot.
Do you even lift?
These aren't the 'roids you're looking for.
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.
...on your budgetary constraints, whether you're willing to invest in expensive frameworks that you have to pay for over and over again, or go FOSS. It will also depend on your company's systems. Some frameworks have relatively steep requirements.
, a quick inventory of what you have and where you're willing to go in the long run brings everything back to earth. Sorry if I didn't answer your question directly, but there are a lot of things to consider.
As much as its easy to suggest "use-this-or-that-framework-because-its-the-best"
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.
Hmm.... I think you should read this first, in case you didn't. http://discuss.joelonsoftware.com/default.asp?joel .3.219431.12
I think the very first question you should ask yourself is, do you really need a framework?
.Net or the JRE around. Are you sure you want to upgrade all the apps all at the same time?
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.
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.
Help me take back Slashdot. When did 'News for Nerds' become 'FUD and Conspiracy Theories for Extremist Nutjobs'?
Another upside is that there's no one but you who can fix or maintain it! ;-)
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.
"Can you name any website or application currently in production that does."
The Rails Wiki has a list.
Karma: It's all a bunch of tree-huggin' hippy crap!
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.
Have you ever been to a turkish prison?
If it is really popular, it must be really good. See C++, Java, XML, Windows, McDonalds, etc...
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
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
I usually start by asking myself, "what programming language am I most familiar with?" .. then, once I have that figured out, I spam "Ask Slashdot" until they post my question. By then, I've already lost interest and/or forgot about the reason for needing an application framework in the first place, so I close the loop by replying to the question with a completely offtopic (yet slightly humorous) comment.
That's just me, though. YMMV.
*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...
All's true that is mistrusted
http://discuss.joelonsoftware.com/default.asp?joel .3.219431.12
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
Runesabre
Enspira Online
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.
2 years and no mod points. Join reddit. Because openness is good.
As much as i hate to say it I think the market determines what you should use.
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 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
A framework ...
... Tapestry!
"... 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
main() {1;}
So are perls...
Switch back to Slashdot's D1 system.
Yeah great! Fear of learning new things is always the way to success...
A discussion for development language and framework for a relatively simple client application was raging, with the main contenders being Java, C#.NET and C++. Everyone had already come up with pros and cons of each of these, but no end to the deadlock came.
:)
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
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 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
I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
Ruby on Rails sets off like a Cimmerian for conquest.
Struts and Hibernate get consumed by an error trace of Cthulhuian proportions, if the supply of live sacrifices runs out, which it eventually shall, doomed one.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Singletons in the J2EE framework. Compare this monstrosity 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 :)
An important insight that is highlighted in the parent article is that Libraries are better than frameworks. The distinction being that Libraries contains code that you don't have to write where frameworks dictate the way you write code.
.NET Framework libraries.
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