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 you and your team already know how to use.
You use the one your boss tells you that you are going to use.
I would've thought things like prototype.js and ruby on rails would be better examples of frameworks in proliferate use today than those provided in the blurb.
but then again i could just be karma whoring. so whatever!
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!!
SimCity metaphor time: Ruby on Rails gets built in "light commercial" zones. These sort of Java frameworks are "heavy industrial."
Anybody ever do anything with Spring? At JavaOne last year the Spring sessions were always the most popular but it seems it's hardly made a squeak since then. I guess with EJB 3.0 coming it's not quite the God send it once was, but still.
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.
Perl - POE
Python - Zope
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.
Thinking of if you really need to use any of framework or not is also important.
...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.
If you don't like what you see out there, or you don't know any better, you can just write your own. I came up with Lampshade, but open-source software definitely fosters the mentality that you shouldn't necessarily just use what other people provide, when you're able to contribute something yourself. Of course, once you've written it, you want someone to use it.
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'?
EJB (Enterprise Visual Baisc) used to be the worst solution, people don't want even include it as an option. GREAT!!! THANK YOU!!!
Uh, both JSF vs. links above point to the same JSF vs Asp article.
Got something on JSF vs Struts?
When you hear hoofbeats, think horses, not zebras
Another upside is that there's no one but you who can fix or maintain it! ;-)
What you really need to look for is a mature product. Market share helps, but I keep waiting for that announcement that Ruby on Rails has some horrendous security hole because it's a 1.0 release. What you need is something that has been expanded upon, revised, and rethought a few times after having been deployed in the field. For me, if I need MVC, I pick Struts. For database abstraction, Hibernate is pretty slick. Both of those packages have been around the block a few times, so I'm fairly confident that any custom problems that I might see, have probably already been solved.
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.
I wait a year or so to see which ones come out a sure winner before picking up on it.
Hibernate and Spring are two good examples of good projects with lots of mindshare.
Struts, however, I don't like. I don't like JSP or JBoss either.
Those are examples of the wrong solution to the problem; the complexity of the solution being too high.
Echo2 looks very promising, and I expect I'll be doing future development on it.
The first test is the 10 minute rule. Start by downloading the framework or project, compile it, get it to run and read the docs. If in 10 minutes you feel productive then you can move to the next steps.
An amazing framework will be easy to use, well documented, intuitive and will make you feel smart & productive all within 10 minutes.
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?
I've been thinking about software architecture for a while now and it's even more important in the case of a framework. I realized from using my own architecture and seeing its own flaw that a design that flows naturally from the way a person thinks is usually easy to use and coherent. What I mean is that when I'm using some part of a framework (like .Net) and I need to do something new, I would often go online and research it really quick like searching for a node using XPath when using the XML parser class. I mind not know the name of the method/property or exactly how I can call it, but I guess that it is there because it ought to and seen like a common desire most other people would have. A counter-example would be .Net Datagrid. It's a datagrid so I expect it to be easy to use it to display data in row form. It is so tied into ADO.Net, however, that it is clunky to use for anything other than database data. On the other hand, I think their XML parser is fairly good as I've stated above. I didn't know right off which method would support search by XPath but it seems that they would and I was right. So for me #1 is the most important. I don't want to think about the framework nor remember every details. I want to design my project and be fairly confident that the framework will support what I do.
EvilCON - Made Famous by
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
Factors? Evaluate?
Dude. I have no say in any of this. My wife makes these decisions.
Struts and Hibernate get dual-wielded by rank 14 rogues.
... or at least help http://opensails.org/
They have to have a special page on the framework's official website to answer the question, "So, who the heck even uses this framework?" And then they give examples like "BellyButton.com" (maternity site). And that's supposed to be proof that it's good enough for mission-critical production use?
"You design the application *then* you start making technical decisions about implementation - not the other way around.. "
Well that explains the KDE framework then.
If you use Scheme, you don't need a framework -- it is powerful enough.
If you use CAML/ML, there are also typically libraries of combinators (e.g. CML) that allow you to get done what you need to get done.
People make frameworks for less powerful languages, because that's the only way you can get stuff done when your language requires so much effort to get things done.
http://www.thebricktestament.com/the_law/when_to_
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
You decide which framework to use the same way you decide which ANYTHING to use! You research the choices, go through the available information on each, and quickly become overwhelmed with the details.
Then you get the one featured the most prominently in ads!
You do have Adblock disabled, right?
"You use the one you and your team already know how to use."
Well Bob Villa is all set then.
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.
Whenever I use a third-party framework (for web development, both server-side and client-side), I spend half my bug-fixing time looking through the framework's code. It's frigging annoying! I don't know if my code's just that advanced, or if I have that much bad luck picking frameworks, but I always seem to be hitting the limitations of any frameworks I use.
Nowadays, the first thing I do upon downloading a framework is to open a couple of its files and look at the coding style, see if I can figure out what's going on. If I can't make it out on a glance, if it's badly documented, or if their curly brackets look at me from the wrong position... I ditch it. It's not worth the effort. I'm far more effective just re-inventing the wheel on my own for the small parts of the framework that I'd otherwise use. And at least that way I know the code will do precisely and exactly what I need, rather than being a general-purpose tool-building factory factory factory.
*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
I pick the one that does things my way.
I tend to use lots of factories, singletons, stateless objects, data access components, transactions, and data validators.
I can either write and implement a lot of these myself, or I can pick a framework that does it as much of it as possible for me.
An interesting story, I was messing with an application awhile back. Something completely different, and i was using this framework because of its connection management. I then discovered that it everything interesting I was doing in the other peoject was already built into this one.
Incidentally the framework I'm talking about is Spring. I picked it because I like what it does.
I also profess to being a Struts hater. I can do most of what Struts does without it. The same applies to Spring, but with Spring I don't have to extend somebody elses base classes to write interfaces to separate my own code from the frameworks. Then again I do tend to code to the interface anyway, but I'm still not necessarily extending somebody elses base classes.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
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
Is this a subtle jab at MySpace as well? If so, roffles.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
Good luck picking up a lady telling them you work on struts, scaffold or java beans.
On the other hand, rubies are a girl's second best friend.
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
No other language has these features AFAIK, except as a separate function library.
You need to make sure you use the simplest framework BUT does !!!everything!!! you need.
There's a lot of over-engineered crap out there. eg. EJBs were in fashion but they were always over-engineered. Spring's in fashion now but when the honeymoon's over people will realise that Spring is just wrapper technology for existing frameworks and that it's hyped up junk too. Another example: Try and do anything complex with Hibernate and HQL. In the case of DB, SQL works so well. Plain JDBC and SQL with a little bit of intellgent in-house or 3rd party framework wrapping really isn't that bad for goodness sake people.
At the end of the day you have to choose and use them, but you don't need to swap yourself with design patterns that give you flexibility you don't need and want.
Choose a handful of well known, well proven frameworks. Less frameworks is better (which is why J2EE has turned into a nightmare - too many frameworks and too much reliance on one another).
These posts express my own personal views, not those of my employer
1-4 Address valid points, but each project is different and sometimes the overbearing factor is performance.
When developing web applications one of the largest bottlenecks can be rendering of templates. I always use clearsilver for templating, it's written in C and orders of magnitude faster than any other template engine I've come across.
The issue then becomes, which framework uses clearsilver? I didn't find a satisfactory solution using similar criteria as 1-4, so I hacked clearsilver support into cherrypy. I'm sure there's many other solutions out there.
The basic point is that every project is different, so different criteria should apply to selecting the appropriate framework.
O...crap....
I look at how the framework matches with the requirements, cost, our knowledge of it, if new howz the learnng curve, ease of use On the app side wxwidgets has been my favorite, but worked quite a bit on python and .NET based on need.
Have worked on very few web related projects, Ruby on Rails is miles ahead of others here.
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
That was hilarious!!
Y
I think the main reason Lisp isn't popular is it isn't perfectly standardized, and doesn't play well with others. If someone would just fix up the foreign function interface, and add a bad-ass selection of packages (like for Python), all other languages could go suck it. Hell, if you don't like Lisp, you could implement Java in Lisp using a few handfuls of macros, and the end result might even be faster than the JRM (seriously).
"As far as ruby on rails... who in the business world uses that?"
Mostly people who you won't notice until they pass you like you're standing still:-)
http://www.welton.it/davidw/
Even worse:
Most advice you get on a question like this on slashdot is bad advice...
Most guys here have no clue what they are talking about...
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.
... what has worked for them before, on similar projects. Which may not always be the best solution, but it is usually the one that will get them up to speed in the least amount of time.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
I always wonder what will happen with all these bright shining frameworks in some years?
If I rely on such a framework for my application and my application should last for - let's say - 5 years, it may well be that development and support for this framework has died out by this time.
And it may happen that you need to port your applications to a never hardware, a newer operating system and - maybe - to a newer version of the underlying programming language (such as Java). You may think that 5 years are a long time and there is probably no application that lasts longer - but you forget that applications are evolving and parts of your code may exist for many, many years.
For instance, there is still need for COBOL programmers that have to maintain/port old code for applications that are 15 years old. I wonder from where I'm going to get Java-Struts or JSP programmers in 15 years from now?
I would recommend to choose open-source frameworks/libraries, as you at least have the possibility to fix things by yourself if the support for the framework is gone.
I'm really curious if these frameworks are cost-effective in the long run.
I think that all this eye candy, IDE's, frameworks, etc. are more of a hindrance than a help. They certainly don't do anything to improve programmer's skills either. I see people start thinking in terms of their tools (when all you have is a hammer everything looks like a nail) and pretty soon they can generate 10,000 lines of code in 10 minutes, but can't add feature X because the framework doesn't support it and they can't even find where in the generated code to begin to modify it to try and accomplish the task. The pity of it is that there's usually a really direct way to do what is necessary, that will run faster, accomplish more with less resources, and improve maintainability. But it may not be as easy to a novice programmer who realizes that with the framework they only have to write 5 lines of code and name two objects. He doesn't care that it takes a lot more resources, or that he can no longer actually determine what is and isn't needed to do the job, because he can't even think that way any more.
I'd like to see political correctness removed from programming and let's bring the computer science back into it. It would be much more advantageous if we started mastering the algorithms and the science behind them than to keep arguing about who's gui widget is 'cooler' to use.
Now where did I put that fire suit ...
"Can there be a Klein bottle that is an efficient and effective beer pitcher?"
Back when dinosaurs ruled the earth I used a thing called Clarion (MS DOS) which was fantastic for running up database applications quickly to show to the user what was possible. In fact one of these lasted 15 years! (The oldest thing in the office by far except the people.)
I'm currently trying to find a framework that lets me bash in a few schemas, press a button and hey-presto we have a starting point for discussion where the user can see why I've been 'getting everything back to front' as they see it 'cos I have the vision and they have blinkers.
Trying to find an industrial strength framework that actually works (for me) out of the box is taking a lot of time.
Being of the Old School I'm not too happy with the relative opaqueness of application generators. If I was to commit to developing a real app using a framework then I'd need to spend a lot of time finding out how it really works. At this stage in their evolution I'll postpone that investment for about a year. My criteria are (1)Robustness (2)Portability (3)Good docs (4)Tweakability.
Sorry, Pal, but you're not up to date.
Rails is soooo last season. Get a life!
django is what's on.
We suffer more in our imagination than in reality. - Seneca
This blog entry by Ignacio Coloma tells a little bit about the subject. You should diversify risk, and get some frameworks that are bleeding edge of technology, but not all of them. The percentage of risk you can afford is up to you, but keep near the majority if you want to be safe.
Look at the community, are newbies treated as human beings or as filth that shouldn't bother the LEET people. Is there a forum, a wiki, mailing-list... and how active are they? And is documentation updated regularly and more or less in sync with the latest version.
I wrote this small-footprint servlet-based content creation framework for an internal project at IBM Research. The framework is easy-to-understand and easy-to-use. You can download the library from
/ wa-hamlets/a -hamletprg-i.html/ wa-hamlets3/
http://www.alphaworks.ibm.com/tech/hamlets
Articles can be found on IBM developerWorks:
Introducing Hamlets: http://www-128.ibm.com/developerworks/web/library
Programming Hamlets: http://www-128.ibm.com/developerworks/edu/wa-dw-w
Implementing Hamlets: http://www-128.ibm.com/developerworks/web/library
It's a great cross platform library for iBook, PowerBook, MacBook, iMac, the mini, Power Mac, and every other significant system I can think of.
I first look at the website. If it looks like crap, I'm away.
This may sound silly - and it is funny, I admit - but there's a serious end to it.
If the people in charge don't have what it takes to build a website that doesn't look like someone did doo-doo on my screen, chances are their framework and documentation is a pile of half-backed bits and pieces. This is usually true on a larger scale. This rule doesn't apply to non-oss tools though.
When it get's into the details I look at language used, databases supported and the general liveness of the community and friendliness towards new users. Widespread usage is a criteria aswell when builing for now and future customers. Example: Because PHP is used everywhere, I'm willing to make a tradeoff against Python, even though I think Python is some much better as a PL. For most cases that is. In a way, dynamic languages are sort of frameworks themselves.
We suffer more in our imagination than in reality. - Seneca
I wrote this small-footprint servlet-based content creation framework for an internal project at IBM Research. The framework is easy-to-understand and easy-to-use. You can download the library from
/ wa-hamlets/a -hamletprg-i.html/ wa-hamlets3/
http://www.alphaworks.ibm.com/tech/hamlets
Articles can be found on IBM developerWorks:
Introducing Hamlets: http://www-128.ibm.com/developerworks/web/library
Programming Hamlets: http://www-128.ibm.com/developerworks/edu/wa-dw-w
Implementing Hamlets: http://www-128.ibm.com/developerworks/web/library
You might have a long wait if you wait for "the current gods to be superceded"... you could still be happily employed as a Cobol programmer thinking in those terms. Which isn't a bad thing, but it's not my cup of tea.
Due to the economics of programming languages, once something (Cobol, C++, Java) gets entrenched, it's just not going to disappear overnight.
Something like Ruby on Rails will see its market share grow primarily for new projects, where, if it is successful, it will comprise a larger and larger portion of them over time. Cobol isn't gone, but you don't see many brand new projects launched in it.
And, let's face it, it's very new, so of course you're not going to see banks running on it right now... duh:-)
http://www.welton.it/davidw/
If you stuck using a language which suffers from lack of high-level concurrency, fault tolerance and distribution built in, then you have to use many different frameworks to make up for this and you're back to the original post which could be restated "How do I choose a framework to support a language which lacks high level mechanisms for concurrency, fault-tolerance and distribution?"
I'll explain my position...
I am a framework programmer in OO technologies for the last 15+ years. I've built frameworks and frameworks for frameworks. Although I take a fond interest in the many good frameworks out there, I am no longer in the framework business and am in the position of choosing a framework for my application needs. I'm building Web 2.0 type web apps for large user base (whatever that means to you).
Here's what I've decided from looking back at my own frameworks and using many others:
1 - Most application frameworks do two things: a) provide a declarative model for your app and b) encapsulate concurrency issues. The declarative model ensures your app programmers stick to the application domain and not the intricacies of how for example the MVC interactions work. Encapsulating concurrency issues (either in the O/R or the UI frameworks) keeps your app programmers from shooting themselves and each other in the foot over concurrency which is always tough to get correct.
2 - The other things that frameworks do well is distribution and fault tolerance. We find that there seems to be a separation in the framework world where declarative and concurrency issues get handled in the application frameworks and fault tolerance and distribution tasks get delivered in the form of application servers / containers.
When I started looking for a framework for my web apps, I looked hard at these four issues: declarative app model, concurrency, fault tolerance, and distribution.
At some point in my search, I stumbled upon erlang where I found that concurrency, fault tolerance and distribution were handled at the language level (or at least deeply and consistently embedded in the VM and libraries).
This left only a declarative framework for providing a high-level structure for my apps. This in turn means my "framework" needs are very small and simple.
Some other posts today mention that deficiencies in the language are the reason for needing so much framework infrastructure. I have to mostly agree with this position...I have not found any other language solution that removes 3 out of the 4 framework jobs as well as I can in erlang.
If you are stuck with a mainstream language choice, then I would suggest other criteria in picking a framework: The DRY approach of rubyonrails produces much more maintainable framework solutions than the Java approach which has large communities of vendors working on separate frameworks which produce overlap and pattern nuance.
good luck,
I recently installed JBoss 4 with EJB3, and played with it a little bit. And it produced a jaw-droping "keeewl" effect on me, that I didn't experience since I discovered c++. (Granted, I never worked with anything like this before.) With ejb3 annotations, it's dead simple to code, and it can really DO STUFF. Sure, it can be a bitch to get hello world running in 5 minutes, but once you break the ice, it's beautiful. I'm looking forward to doing something for real with it.
''Why I hate frameworks'' is a fun and good read. Reflects my experience too with these frameworks that's suppsoed to make things easier for you. Now, they have alot of easy to do stuff, it's just that about 95% of that is a total waste of time, doesn't help you with your ultimate solution, and you'll have to do it over again for the almost-compatible release due next month.
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
Why, Emacs, of course !
How's parent offtopic? He should be modded insightful
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
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 :)
But all coders work on java beans, or at least a caffeinated product closely related to them :P
In the hope that I can save someone, please spread the word that when choosing frameworks a good tip is to not use JSF.
I'm using it at work and it's making my life a misery.
I think the general case is: don't use a framework which isn't designed by one person.
I had two full time jobs in a row using Struts/Hibernate, and I kept telling my colleagues that Spring/Hibernate or WebWork/Hibernate would be better/easier/faster/cleaner. They didn't listen. Then I discovered Drupal and realized that it was all the framework I ever needed and quit my job. I've never looked back.
You can write your applications that would be portable to:
Basic GNUstep/OpenStep/Cocoa frameworks are FoundationKit and AppKit.
More information about GNUstep frameworks can be found on the project wiki pages.
First they ignore you, then they laugh at you, then they fight you, then you win.
Will it provide the services you need?
How much of the framework are you willing to write?
How hard is it to integrate your code with the framework?
How easy is it to seperate your code from the framework?
If the chosen framework goes tits-up, how easy will it be to change frameworks?
Does it support the platforms you use?
Would you want to monkey with the framework?
Would you want to contribute your changes to the framework?
2. Support
How many other people outside the company use the framework?
Does the framework installation and usage overhead match the size of the team(s) who get to use the framework internally?
When was the last release?
How often is it released?
How active is the dev/users list?
Is there a book on it?
Are there any big names/companies actively supporting your chosen framework? Do you trust those names/companies?
Patriotism is a virtue of the vicious
For Python, the Twisted framework provides many of the things that applications commonly need.
Far, far too many things to list, which is why some newcomers get confused trying to take in too much at once.
Focus on what you need to do a sepecific job!
http://twistedmatrix.com/
If you want to be the sexiest man in a geek's party, go for ColdFusion.
When all other constraints are equal, the ninety second rule is a good test. If I get the general idea how to work with a framework in a minute and a half, it's probably ok. I use this rule mostly for my hobby projects, since the main constraint is time. In professional projects I can usually allocate more time to learn about different frameworks (but the result is often similar to the ninety second rule, so the remaining two days spent on evaluating something is just so that I can say something more intelligent than "Well, I didn't get the other one, from the front page of their web site").
At university there was another post-grad who, at her dissertation, got the question why she used one Monte Carlo (simulation program) over the other. "Well", she said, "the first ones didn't return my mails in a timely manner, and the other ones, well, they are Chinese" (she is Chinese herself). There's a lot to it. Clarity is key.
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
You really need to be looking for some more criteria when you're evaluating them. In addition to the criteria you mentioned, here are others
Adaptability
Efficency
Availability of tools (IDEs, Graphical Contruction Wizards, Component analyzers, memory analyzers, profilers)
Robustness (Error checking, logging, etc)
Support Availability
Quickness of Dev Time
Maintainability
Platform Compatability
License Compatability with Product Business Goals (Talk with the Mgmt/Marketing folks about this in terms of which each allows)
Cost to Procure Experienced Developers for the Framework (*Even if you don't think you'll need to hire)
Experience with underlying technology
If you define all of those in writting, you will have many fewer choices, and you'll sound like you know why you're recommending your final choice when you do.
--Michael
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
Suppress your "ooh shiny" tendencies and gushing like a schoolgirl (" is like drinking unicorn giggles!") and address the following:
1. If it's replacing an existing tool or technology, identify how (flash-cut, gradual, new implementation only, etc.) and with what expected effort the transition will occur.
2. Discuss the drawbacks as well... if it's worthwhile, they will seem manageable when compared to the expected benefits.
3. If it's a "live" or "production" environment, show that some level of stability and maturity has been reached. Also, adoption by other major players help quell concerns that this is just the next flavor of the month.
My clients usually decide if Java or .NET.
I prefer framework based on XML/XSLT, and to be able to easily move code between Java and C#.
I build Xml with code and do presentation using the same XSL in both platforms.
You have to use the minimum of frameworks that are necessary to implement the given business requirements but you should not use fewer than necessary because then you are not implementing business requirements, then you are implementing the frameworks.
As a contractor I have seen the good the bad and the fugly. Normally the fugly means no frameworks at all, so they write their own application servers, it's terrible for the project (how are you still doing, ADP mutualfunds, after almost 2 years of that bullshit?) But it's great fot the development shop (how are you still doing, Intelliware, still building custom app servers?) As a contractor who is brought in the very beginning of a project like that into a political game, but cares about all his projects to succeed, I must voice the concerns of these approaches but it doesn't necessarily go well with the powers in place who have money and/or to gain on design defficiencies.
On the other hand I have seen the terrible misuse of frameworks and various 'technologies' within the same project, to the point, where the team is prevented from solving the business problems and are forced to solve the framework problems (hello Boomboat, writing for Bell Canada, how is that Vitria to BEA Weblogic to the various data-sources thing going? Implementation of business rules still takes forever and ever and you are still forced into the distributed transaction mode for no reason and still have those terrible troubles with the connectors?)
In any case, the design dictates the necessity for the frameworks. The frameworks that you chose must be known to the developers within the company, so that they could support them. The best way to do this is to make sure that all projects within the same business space use the same frameworks, so that there is plenty of knowledge within the firm to support any old and new development without running into resource problems.
You can't handle the truth.
OMG, The Symbionese Liberation Army!
Several of them!
All kidding aside, ColdFusion has a number of different frameworks available for development such as Mach-II, Fusebox, and Model Glue.
See http://oodt.jpl.nasa.gov/better-web-app.mov
But with pythons you'll get all the freaky ladies!
I tend to use the language I know. I tried using a language I didn't know once. I installed a few new servers, put some software on them, was told it would all be magical. I waited for it to grow, or program itself. It didn't. I was dissapointed so I ended up doing the project in PHP and will never try anything else again.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
I'm a CS student and at my university we have a compulsory two-semester software project that students are supposed to participate in during their third and fourth semesters. The course tries to emulate the business world: The customer tells the world that he wants a software that does X (with requirements like "should work like, you know, Amazon"), then the project groups have to work out offers, specifications etc. during the first semester and implement the thing during the second. In the end one software is actually used in the real world. (Isn't it great how students can be abused for cheap labor?)
What our "customer" wants is reengineering of an online biblioraphy getting about a hundred unique hits a month. In Java. Use of an appropriate framework recommended.
I'm the one in charge with deciding on which technologies my group uses (except for the mandatory stuff like MySQL). I would have went with Struts (because the university offered a free Struts course), but I decided against it (because I forgot about the course until it was over, also Struts is quite heavy according to my research). I compared JSF against Tapestry; JSF will probably become an industry standard, while Tapestry will not, but Tapestry is easier to deploy than JSF. Since we don't care about industry standards and need to implement the whole thing with about one man-month of work (spread across seven people, including the earning phase) JSF is out of the picture. In the end I settled on Tapestry for the following reasons:
- We don't care about industry standards so it doesn't matter whether Tapestry will become one.
- We have neither the time nor the resources to use anything that introduces more complexity than absolutely necessary, flexibility be damned. The project is already stealing enough time from the other courses.
- Tapestry can be integrated into random HTML or XML just by adding a few parameters to a tag. There is no Java knowledge necessary to integrate the Tapestry parameters into a new layout. This is good since it allows people to play around with the HTML layout with no knowledge of the program whatsoever, as long as they just put the Tapestry stuff in the right place.
In the real world I'd probably last for about five minutes if I kept making such decisins, but then again I'm a student. I'm supposed to make bad decisions.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
We all seem to be skipping the question "Do you need to use a framework?"
If the answer to that is yes -- which, IMHO, is far from clear in many cases -- then you must be able to answer the questions "Why?" and more specifically "What benefits can using a framework offer?"
When you've answered those questions, you know what you're looking for, and that is how you choose your framework.
If you can't give good answers to those questions, perhaps using a framework isn't the right choice for your project.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
This kind of a question is very difficult to answer. First, are you and your group reasonably familiar with the project you have ahead of you and what kinds of problems you must surmount to successfully complete the project? Get a few people in your that have the most experience with projects like you hope to tackle with the new framework. Second, it's clear you don't personally have much experience with using any of the particular frameworks, or you wouldn't be asking the question in the first place. But are there a couple people in your organization, new people, perhaps without the domain experience of others but with a familiarity with using particular frameworks in other contexts. Get all those people in the same room and have them figure out how each framework could contribute and hinder the goals of your project. It's that easy, and that hard.
"Provided by the management for your protection."
One more point:
Frameworks are great when they provide 100% of your needs and very little of your non-needs.
But when they fail to provide a few of your requirements they become a jail. You just might not be able to do something at all, and will certainly spend much more time on implementation than if you didn't have a framework at all.
The agile manifesto (www.agilemanifesto.org) does a great job of stating that we need to be adaptive and resiliant rather than try to anticipate the future:
Responding to change over following a plan
And this directly conflicts with frameworks in my opinion - since a framework could be a great fit today, but a tight enclosure tomorrow.
I always choose the one with the coolest name, that's probably the best.
If both projects have cool names, then the one with the most bitchen logo.
If both projects have cool names, and bitchen logos, then I usually try and use both since that will make my program even more cool and bitchen.
The main problem I have run into with frameworks is that they make easy things easier and hard things harder.
What I mean is this: Choose any framework, and find an enthusiast. He will show you in ten minutes how to create a simple, single-form application accessing a single table in a database (or, the equivalent for whatever domain the framework addresses.) He will say, "See how easy it is to produce a working application with this whiz-bang modern marvel?
And, he is right, up to a point. If all you want to do is seventy-five duplicates of that trivial case, you can be done in a week. But, real-world applications quickly spider out into areas that your framework of choice doesn't handle.
These dark corners usually come in several flavors: the framework designer didn't anticipate them, the interface to external resources is limited, they don't match the framework's model, or they are genuinely hard problems.
At this point, you have to use the framework's hooks and escapes to finish the project, and that is where most of them break down and stop helping you. In fact, at that point, most of them become a royal pain in the buttocks.
So, to my thinking, the most important feature of a framework is how easily it lets me use a different paradigm to code things not covered by its internal architecture. That may include calling code written in other languages, accessing external resources, breaking a problem into parallel threads or processes, etc.
I had forgotten how much cooler teenagers look when they are smoking. Oh, wait
You're trying to build a strategy to migrate from .NET 1.1 to .NET 2.0. In a couple of years time, MS will have introduced .NET 2.1, or .NET 3.0 or whatever, and you'll be back to square one, migrating your application into a new framework. You have to ask yourself, What business am I in? Are you in the business of delivering solutions to customer problems, or are you in the business of applying another vendor's solution to the problem they created?
All of the popular frameworks are immature. They'll be completely different in a couple of years, and if you're lucky -- I mean really lucky -- they'll incorporate some sort of backward compatibility to let you leverage your existing code base. I wouldn't count on that though.
Of course, all that being said, if your principle work product is billable hours, then by all means go with the latest and greatest framework. The customer gets some great whiz-bang that they can pay another chunk of big money to upgrade in a few years. I mean, have you tried to hire an entry-level ASP programmer lately?
this proliferation of frameworks has made java a piece of crap. that and setting classpaths.
I don't understand why there are so many commments here to the tune of "Well, it depends on what your writing," "It depends on the skills of your team," "It depends on what the phase of the moon is when you start your project," etc. What a bunch of hogwash.
It's incredibly simple, and I'll tell you how. Go to Google. Search for "framework". Through a few keywords related to the product that you intend to write if you want, but it's not really necessary. Adding a preferred language to the search may help. (I prefer the Google defalt- English.) Print out the results- at least the first page, and if you want, add the second and third pages for completeness. Skim through the results and cross out any that are clearly not relevant to your search. Cut out the rest and put them in a hat / jar / bowl / whatever. Then...
Take the hat / jar / bowl / whatever to the paper shredder and run them all through one at a time. Now, get back to work and quit wasting time on such a stupid question.
If I don't put anything here, will anyone recognize me anymore?
I've noticed too many places decide this based on "what does Microsoft bundle in with Windows?", where Windows itself is chosen because "hey it looks like my Pee-Cee!"
In many ways a framework's restrictions (often in the form of implicit assumptions) and how the framework treat you when you decide to break a restriction is more important than the feature set provided. If you're building a project of any significant complexity, you're eventually going to bump into a wall in your framework. You want to do something one way, but the framework doesn't. Some frameworks will totally block you from rolling your own solution; the framework can't cope with code not strongly tied into the framework. Some frameworks will let you roll your old solutions, but yank most or all of the tools you've been leveraging in the framework. From experience, using a powerful framework's Model-View-Controller system, then having to reimplement significant portions from scratch because the framework can't cope with the user interface you want to provide is a nightmare.
Search 2010 Gen Con events
I was under the impression it was an ORM layer. Seems that by definition you can't have more than one framework in your project.
sic transit gloria mundi
Indeed. Not only are there multiple procedural (Fusebox) and OOP (Model-Glue, Mach-II) frameworks for ColdFusion to handle the UI controller layer of an app, there is a massive push within CF to create supporting frameworks that can work with any of them. These include:
Reactor: a dynamic inline database abstraction API which reads database metadata and automatically generates Record, Data Access Object, and Table Data Gateway objects on the fly, complete with validation and caching.
Tartan: a command-driven service framework which allows the model-layer components to respond to requests from multiple types of controllers, including HTML controllers like Fusebox or Model-Glue, as well as Flash Remoting calls or AJAX requests.
ColdSpring: a dependency-injection framework that manages the creation, caching, and dependencies between all of your model components. Includes aspect-oriented programming capabilities as a bonus.
I've never quite figured out why Slashdot readers are so hostile to CF, which is an extremely powerful and capable platform when used correctly. You laugh at MySpace (which actually runs on BlueDragon.NET not ColdFusion Server, do your homework people) and yes its performance sucks, but this is because the system was designed and created in a horrible way, not because of the underlying platform. Some great things are happening in the CF world if any of you would take the time to break out of your stereotyped mindsets and bother to actually learn something. For example, the power of dynamic typing ("duck typing") and "mixins" that Ruby has popularized is fully implementable in ColdFusion because it too is dynamically typed.
Just because you heard once that ColdFusion sucked 6 years ago or because a popular site that ran on ColdFusion like MySpace sucks, doesn't mean you can't open your mind a little and objectively evaluate the technology based on its merits.
A few years ago I wrote a few large apps for which I had to write my own code that generated code to speed up the process :)
After going through that experience and making the decision to migrate to PHP I was not to rewrite my tools to write code all over again, so I started looking for PHP frameworks that were similar to the tools I had written on the other language.
Achievo Toolkit (ATK) from http://www.achievo.org/atk http://www.achievo.org/atk came very close to what I was looking for and I haven't seen anything like it, yet.
I make my framework decisions based on usability, efficiency, learning curve and not based on hype. In my opinion, hype, does not always translates into great quality.
ColdFusion, yup thats right. You can have your struts and scaffold, my website is power by cold fusion.
ColdFusion, by itself isn't a framework. It's a language. A framework for coldfusion is Fusebox
Fusebox somewhat introduces the concept of MVC to Coldfusion. A framework is supposed to reduce code duplication, and make stuff like CRUD a lot easier.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
For web apps I think Python. Then I try to do what I can with mod_python. Then the fear and loathing people have of Apache 2 kicks in. Then I have to move on to Cherry Py, Twisted, etc. etc. Then I get frustrated and go with PHP although all I want is mod_python 3.
For the desktop, Win32 API if I have to do Windows. I simply was never able to adapt to MFC. My code has the benefit of running on every Win32 platform without fail and with better performance.
On the Mac I just go with Cocoa because I'm "not supposed" to use Carbon anymore. SDL/Open GL for games and graphics. Never DirectX (although I like it a lot). Sometimes Allegro. Maybe one day ClanLib out of curiosity.
Not that this is the subject, but I'd recommend Mach-II. It has event-based implicit invocation and loose-coupling. ;) It's been working well for me.
> A major precondition for the success of a software framework is [its] acceptance...
Not necessarily. The financial success of less desirable, less innovative, less secure, and/or less refined technologies is typically propelled by market sway, however ill founded; and of course, the prevailing sway is not necessarily motivated by fairness, or pure rules of better development. As we look back on the last 25 years for instance, it is obvious that principal market sway has ascribed to a circuitous route which is neither financially or programmatically advantageous to the market masses.
COM/ActiveX is a good example. Is the interface based inter-object communication technique of COM/ActiveX inherently superior to the pointer-based (but COM compliant) techniques of Delphi? On the contrary, ActiveX/COM is inherently an open door to insecurity; requires many times the processing cycles; imposes many times the resource footprint; consumes far more resources at run time... and is designed only to do things we may better do without. You can "improve" upon or elaborate the techniques of COM all you want, but there is no real security (even though the very purpose of COM is inter-object communication in circumstances which *require* security), and COM can *never* be as efficient as pointers, because pointers *are* the most simple, optimal technique.
Yet, on into the many "futures" of COM, the greater masses have been drawn.
An endless serial of further technologies/frameworks are based on COM and its succeeding generations. But what do they provide us? They likewise can only be open doors to security breaches, and yet beyond this impermissible fault, they provide us an inherently inferior way to do something we may not want to do at all (if a consistent purpose is *best* technique). The infrastructure makes that way redundantly complicated, because many steps and skills are required to accomplish the very same purpose which can be accomplished, straight-forward, with pointers. *Then*, a "framework" implements the requisite skills (so that those without the requisite skills can implement the technology -- with this "framework" *therefore* inherently *involving* methods of administrating the many redundant layers of complexity)... and the result therefore is still something which can be no more simple (or better) than using pointers.
Adherents will argue that we need COM methods of interaction for DLLs and other infrastructures. But do SQL servers deploy COM? Hardly so. Why? Because optimal approaches are vital.
Undaunted by insecurity, or by inherently inferior resource consumption, reliability, and processing speed... COM adherents (of many "frameworks") build COM/ActiveX objects into web pages and applications, as if here too we require (or benefit from) COM functionality. But COM is neither more efficient in a DLL than optimized techniques of addressing objects and passing arguments; and what good software design always requires is method-specific optimization -- stripped, direct ways of accomplishing objectives.
The formula for enduring sof
It amazes me that anybody still can mention win32, etc these days. IMO it should now be obvious for everybody that to develop anything decent cross-platform is the way to go. In the web development there's AJAX/PHP/Java/... and in the binary application programming there is wxWidgets/QT/... .
See also http://wyoguide.sf.net/papers/Cross-platform.html
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
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.
I've settled with wxWidgets/wyoGuide (see http://wyoguide.sf.net/ ) for binary applications development and now start delving into the Dojo-toolkit (see http://dojotoolkit.org/) plus PHP for web development. These are the best ways for me to do cross-platform development.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
Priority list: #1 of 1. #1 - Quality, accessible, comprehensive documentation.
Cost of framework is not an issue these days, since most popular frameworks are open source and free, but hidden costs are a different matter that deserve careful consideration. An approach that favors traditional solutions, or trendy ones, may end with a very labor-intensive production system, which is costly. Many people that use the highly popular J2EE frameworks are writing unnecessary code, because these frameworks mandate so, and this code will require maintenance, and that represents costs too. Also adds to the hidden costs the fact that the programmer is writing code that could have been avoided with a different approach. Beyond the [hidden] cost factor, I would also note these ones: * Stability, performance. * Easy of use, which affects productivity. A QuickStart path is also highly desirable, it leads to rapid achievement, which facilitates framework adoption. People like to achieve results quickly, framework and library developers use to forget that fact too often. * Good and abundant documentation. This is crucial to sustain adoption by new comers with minimal costs. How fast can you put a new programmer into the production line, with the expected quality? that affects productivity, and keeps away or closer to the diminishing returns area. * Availability of high quality sample code. You need templates to start producing quickly * A commercial-friendly license, like LGPL. * Beware of framework dependencies on 3rd party components with unfriendly licences. Best regards, Martin Cordova www.martincordova.com