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

IE6

[ArhcAngel]

That thing will be around FOREVER!

Write your own!

[Anonymous Coward]

Depending on what you're doing, you should consider writing your own framework. I love using the one I wrote from scratch 10+ years ago: it's proven, high quality code, there are no secret corners I don't understand, and I know how to fix or modify it to do new things. It's also small and fast because it only needs to solve the problems *I* encounter.

To anyone who starts preaching the religion of code reuse, I think you're just scared of the unknown ... or not a very good programmer. The sorts of things most people need a "framework" for are so simple that any experienced programmer should be able to do it.

Practical answer

[micahraleigh]

Whatever shows up (significantly) on the hiring boards.

Hindsight is 20/20

[nitzmahone]

Ultimately, it's nearly impossible to predict market forces and corporate decisions. You made a good choice in both cases based on the information available. There were good communities and significant momentum behind both frameworks at the time. You could post-mortem the decisions endlessly and surely find "signs" that you could use when evaluating for next time, but guaranteed there will be different forces in play when (not if) it happens again. Don't beat yourself up about it, and don't let anyone else, either.

Qt

[BreakBad]

Firstly don't design your software around the view. Consider separation of your data structure from your view (MVC architecture), so the view is easier to replace if necessary.

With that said, I've done extensive development in Flex, openLaszlo, and Qt (PySide). I really enjoy all three, but lean towards Qt development (PySide/PyQt). I tend to get quality (designed, tested, nerd approved) product out much faster. Furthermore I'm not a big fan of the lore that comes with the flash plugin, or browsers in general. Of course I do deal with some cross platform inconsistencies with Qt.

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.

Re:All roads may run ill...

[superflippy]

I worked on a project this year to completely rewrite a company's signature application from the ground up. Objectively, you'd think that's something you never, ever want to have to do. But, having done it, I think planning a complete overhaul & rewrite into the product's lifecycle is probably a good idea.

Since the application was first written about a decade ago many, many features have been added with each upgrade. The scope and customer base have expanded. And programming technology has changed hugely during that time.

Rewriting the entire application is a massive effort, sure. But to truly modernize and streamline it, to get rid of the legacy cruft and take advantage of new tools that didn't exist 10 years ago, I think it's worth it. I also think it would've been wise to do this sooner than we did (though that wasn't possible in this case for business reasons).

So maybe when you're choosing a framework, don't worry about whether it'll be the right solution forever. Plan to reevaluate your decision every 3-5 years and change frameworks if something better comes along. And, yes, absolutely adopt the MVC model, because then you don't need to replace every part of your application if one becomes obsolete.

Some notes from a seasoned web developer...

[Dracolytch]

Truth be told: Tools won't survive. They're notoriously fickle. That said, this is one place where good development practice can really help. Here are some of my guidelines:

Get off the bleeding edge. Let the youngsters and startups do the bleeding. Learn from them, and use cutting-edge tools after they've matured a bit and have widespread market adoption. Yes, I was late to the jQuery party. No, I don't feel bad about that, as I could have just as easily chosen a failed alternative and been left with something that's damn near impossible to maintain.

Quality separation of concerns is VITAL for survival. Keep your data store separate from your business logic, and for Knuth's sake, keep your UI the HELL away from everything else, since the UI is the most volatile bit.

Don't resist your platform: Working on the web? Learn JavaScript. Learn jQuery. Do not use things like SharpKit to turn one platform into another.

Use things for which the were initially intended, and ignore many of the add-on features. Use databases to store data, not as process engines. Use JavaScript / jQuery for user interface goodness, not your entire application logic.

APIs / web services / interfaces are your friend... Not just to use, but for you to enforce separation and flexibility.