Ask Slashdot: How Do You Choose Frameworks That Will Survive? 227
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.
A problem not only for web apps. (Score:1, Interesting)
What is the future of the product? (Score:4, Interesting)
Re:A problem not only for web apps. (Score:4, Interesting)
Re:All roads may run ill... (Score:5, Interesting)
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.
How To: (Best Guess) (Score:5, Interesting)
Step 1: Ensure your whole toolchain (libraries, tech, etc) is either open or too commercially essential/purchasable to obsolete (Win32 libs).
Proof: There are old PHP code that hasn't been touched in 10 years but can be improved easily.
More proof: When the incompatible Python 3 came out, years went by where the other environment was maintained, and now for most code you run the converter and you're set. No commercial interest would have taken that much care.
Step 2: What is BIG? _Size-big_ On most resumes for the field big.
Proof: Oracle's Java interpreter is so insecure that you can't use it in browsers anymore, yet it persists everywhere it can because the engineers know it.
Step 3: Don't put a lot of dependent code on-top of it
Frameworks don't last, but neither does the product you're creating. If you don't have much code atop the framework, moving to another will be easy. If it will take a lot of code to make your tech work on a framework, it's better to fail fast. Keep your code atop the framework modular so you know where your integration points are.
Step 4: Be the integrator.
If you rely on many small libraries (who doesn't), be sure you are-or-run the glue and not their compatibility. It's more code, but allows you to entirely replace a library that doesn't live up to your changing needs.
Step 5: Model Linux's ecosystem: standards win since they're multiply-implemented. /proc sources of the C API wrappers source from.
As the most research-able long-lived full system, you see lots of libraries, fickle front-ends, separate long-running processes (daemons) to manage long-running and security-intensive operations. Large programs are broken into smaller programs which are each audit-able, replaceable, reusable, easier to divide labor, etc. Programs with the longest life depends on standard wrappers like the C libraries (which many libraries implement identically-enough) and not on the fickle kernel
Design for multiple languages (Score:4, Interesting)
The best you can do is design so that moving to something else is possible instead of painful.
How is this possible when widely used frameworks are designed for one language and one language only? For example, the web runs on JavaScript, but if I remember correctly, Flex used ActionScript and Silverlight used C#. I can see rewriting the user interface when switching frameworks, but rewriting the application logic in a different language for each framework can get very tedious and introduce plenty of bugs.
Re:How To: (Best Guess) (Score:5, Interesting)
Step 5: Model Linux's ecosystem: standards win since they're multiply-implemented.
I'm surprised there hasn't been more mention of standards here, although I've had variable success with standards myself, and good success with open non-standard systems.
Good chioces: Qt, VTK, OpenGL has been extremely long-lived.
Mediocre choices: XML, wx (I moved to wx from Qt when TrollTech went insane over licensing, but have been slowly migrating back in recent years as wx support has decayed on platforms I'm interested in.)
Bad choices: XSLT, VRML
I still use XSLT for some stuff, but VRML was a mistake. Apparently you should stay away from four-letter-acronyms.
Summary: although I prefer standards over non-standards, open vs closed is the fundamental divider between good vs bad bets. Not everything open will survive, but nothing closed will.