Ask Slashdot: How Do You Choose Frameworks That Will Survive?

First time accepted submitter waslap writes "I have a leading role at a small software development company. I am responsible for giving guidance and making decisions on tool usage within the shop. I find the task of choosing frameworks to use within our team, and specifically UI frameworks, exceedingly difficult. A couple of years back my investigation of RIA frameworks lead me to eventually push for Adobe Flex [adobe.com] as the UI framework of choice for our future web development. This was long before anyone would have guessed that Adobe would abandon the Linux version of Flash. I chose Flex mainly for its maturity, wealth of documentation, commercial backing, and the superior abilities of Flash, at a time when HTML 5 was still in the early stages of planning. Conversely, about 15 years ago I made a switch to Qt for desktop applications and it is still around and thriving. I am trying to understand why it was the right choice and the others not. Perhaps Qt's design was done so well that it could not be improved. I'm not sure whether that assessment is accurate. I cannot find a sound decision-tree based on my experiences to assist me in making choices that have staying power. I hope the esteemed Slashdot readers can provide helpful input on the matter. We need a set of fail-safe axioms" Read on for more context. The backing of Adobe, an industry giant, gave me what I later discovered was a false sense of security. I thought that the Flex framework would not get lost in a back alley like so many open source projects. We invested heavily in Flex and were disillusioned a couple of years later when Linux support for Flash was ended. (Linux support is vital for us for reasons outside this discussion.)

I had evaluated Adobe Flex alongside OpenLaszlo, which at the time had the ability to use a DHTML back-end instead of Flash with the flick of a switch. In retrospect, this alone apparently made it a better choice in the long run regardless of its flaky state when I first looked at it.

A similar scenario arose with CodeIgniter, which we chose for getting away from classical spaghetti PHP. CodeIgniter was recently dropped after we've invested a Tesla Model X worth of money into using it. (EllisLab Seeking New Owner for CodeIgniter.)

I am standing at a cross-roads once again as people are pushing Laravel [laravel.com] for PHP, and giving other suggestions. I am scratching my (sore) head and wondering how to prevent eventual failures in the future. It seems there is no way to predict whether a tool will survive.

Even in retrospect, when I consider my decision-making processes, everything was reasonable at the time I made the choices, yet some turned out to be wrong.

Comments

All roads may run ill...

[OmniGeek]

Been there, done that, wondered "What were we thinking?"

In selecting an instrumentation framework for a test system, we went through a careful process of defining what was important, listing the pros and cons of each competing option, ran some tests to see if both would run the instruments we needed, ... Aaaand chose the worse option of the two, as events ultimately showed. The choice was evidence-based, reasonable on the basis of what we knew at the time, and suboptimal. The system worked, but we had to do some ugly stuff to make it work.

Sometimes you just can't outwit Murphy.

one possible indicator

[DriveDog]

It may be difficult to tell, but I would ALWAYS choose a platform that had capable independent fans over one backed by an enormous corporation. Single entities abandon things seemingly on whims (OK, well actually, expectations of profit, sometimes by folks who can't predict there'll be wind accompanying a hurricane). But if there's a viable community of folks who aren't just fans, but are capable of providing some kind of momentum and support, then the platform will probably survive until something unequivocally better comes along (at which point you would probably want to switch anyhow).