Slashdot Mirror
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.
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.
That thing will be around FOREVER!
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
If the company which develops a closed source framework ditches it, you can't do anything about it.
If a company or any organisation which develops an open source framework ditches or otherwise nukes it, anybody else with an interest and the capacity to do so can take over or fork it.
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.
Maybe one reaosn PHP framworks come and go is how broken the underlieing language actually is and just how much a framework needs to do to compensate for that, leading almost to a new language that therefore needs a very big community to even survive.
For comparison of how simple a framework can be when the underlieing language is sane, just look at python flask. Not that i'm saying that's the solution to your particualr problem.
Whatever shows up (significantly) on the hiring boards.
Avoid vender locking as well as corporate politics.
This is a major problem for desktop applications too. In the company I work for, we still use C++/MFC for our development. (We only need to support Windows.) I have always felt that C#/.Net was not going to be around for long, and it seems I was right. Silverlight. Ditto. HTML/JavaScript? I can't see that being used for high-performance desktop applications (data acquisition, data display, analysis etc.). I thought Qt might be the way to go. Then Nokia got their grubby little hands on it. Then Microsoft got their grubby little hands on Nokia. Now, bizarely, Qt is "free" again (not controlled by any Evil empire), and I'm starting to feel happier about switching to Qt.
Choose the framework that supports, or can be extended to support, planned features of the product.
If there's something that will handle swapping out components (like your OpenLaszlo example), then it will by any measure be more resistant to a dying vendor's abandonment. Go for things that provide the most flexibility and choice.
And on the other side of the coin, if there's a vendor that is going to lock you in to a single One True Way, then they and their products should probably be avoided. A vendor's history is good to know, but not always reliable. Adobe's history would've shown a red flag, as they've dropped popular products at a whim before. A counter-example might be Microsoft's handling of .Net. While they haven't always had a clear roadmap, they've never threatened its overall survival, nor have they locked unapproved, unofficial, or competing libraries out of that ecosystem.
But in the end, setting an "offical", "supported", or otherwise "blessed" One True Technology For All Time is going to fail. Perhaps you should focus on becoming more flexible yourself, making informed decisions about new technology between projects or at periodic intervals instead of using the wrong tool for a job or hanging on to something long past its prime.
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.
Is "being around forever" the most important criterion? The first thing I would do is question the validity of your premise. The second thing I would do is say this is an interesting question regardless.
Are you sure you should be targeting the web? Maybe you should make the interface component a very thin abstraction, and build all of the intelligence elsewhere, where you're less subject to the whims and vagaries of the most volatile discipline in the IT industry.
Just raw dog it. You'll have more control, develop more expertise with the language you are making your application in, and you won't become dependent on a third party for updates/support.
I feel sorry for people who feel like they can't touch Javascript without jQuery, or feel they need a PHP PEAR extention instead of just writing in the functionality themselves.
Apache Flex (available at http://flex.apache.org/) became the natural progression after the proprietary strategy by Adobe failed.
There is never a way to predict the future... merely expect change and anticipate failure. When new frameworks are available, there are typically code-conversion utilities that demonstrate (or incite an appearance of) maturity. As any new technology is presented, the strength of attendance AND technical prowess of the developer community surrounding the technology is a reliable indicator to its longer-term viability.
A simple measurement is this: IF the tech should last for 4 years, then how much history and roadmap (and financial backing) is equally present? If there are sufficient history and roadmaps present, then how sound is the technical basis for the framework? Should the basis and direction apply to your problem, then it becomes a viable solution; otherwise, look elsewhere because it doesn't matter whether it sticks for 10 years or 10 months, it still won't solve your problem and thus be a viable option for you or your projects (or career).
The OP mentioned Flex as one of the examples. This isn't a PHP issue. This is a technology issue. The idea is to try to guess which technology will still be supported 5-10 years into the future.
My guess: you can't. I would say that you have a better chance with commonly used open source than you have with most commercial packages. But a better assumption to make may be that you'll simply be changing your technology in 5-10 years, and plan accordingly. I know that makes the business pull their hair, but would you expect to use the same car in 10 years? The same computer? If we can budge for those changes, and accommodate them, perhaps we can have a process to accommodate tech changes.
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.
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.
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
While it's not a complete answer, the degree to which a framework is open source is a significant factor.
If you use a proprietary framework, then it is possible that it won't get updated to support future platforms or that it'll be yanked out from under you entirely.
If you use an open source framework, it may become unpopular and difficult to support, or may even never get very wide support to begin with (cf. "GNUstep"), but the option to "keep it going" is there. Your future is more firmly in your own hands (or the hands of hired experts). It stops being "we have no practical choice and must stop using this" and instead becomes "the cost of using this is going up".
Does this mean "always pick open source"? I won't assert that it does. But, when all things are otherwise equal, some risks are certainly lower with open source.
Another factor is picking a runtime that's got demonstrated portability. You could be running open source all up and down in your own software, but if you were targeting Windows Phone 6 or Blackberry as your target platform, nothing would have saved you. But if you're running in an extremely portable interpreter (potentially including things like the JVM or CLR) that hides the underlying system from you, again, you have options you wouldn't otherwise. (Heck, a lot of Java code can even be portable between the JVM and Davlik.)
Pick a single product at a single version that wont work with anything else.
Second, make sure its old and obsolete already.
Third tie the whole company processes for everything under the sun even outside the project. Make sure they all use it and save data to its own format. Encrypt it to a password only you know.
Last note EOL of platform and quit.
One year before EOL offer your services for $250 as a consultant.
http://saveie6.com/
The chances of an API or framework surviving X number of years severely diminish when it's something oriented solely or mostly towards the web (or languages used mostly for the web). Past that, I think it's good to generally look for a.) open source b.) functioning versions on multiple platforms c.) answers for common questions even if you already know the answer, as a measure of ability to find help when you have a problem.
Sometimes closed source is the answer, but you have to head into it acknowledging that bugs will likely not be fixed, the framework may be changed capriciously at any time, and all development could stop at any moment regardless of the relative popularity of the framework. I don't work on traditional client/server systems, so this may not be practical, but generally if I'm going to use a private API/framework, I'm going to wrap it with my own framework that is designed closer to what I really want. This costs more development time in the beginning, but has saved me tons of work over the years and the whims of other companies cause them to make seemingly pointless large-scale changes to add a few small bits of functionality.
1) Open Source is always better, because the worst that can happen is it doesn't change. You don't have to worry about some company pulling the plug. Even if there are no more updates, you can always keep using the version you have, and if necessary, you can fix things yourself.
2) If you design your system right, you should be able to switch with a minimum of fuss. Note that even a minimum might still be quite a bit, but it should at least be plausible. Always write a library to serve as a compatibility layer, so that if you need to move to another framework, you just have to rewrite that layer. This might not always be feasible, but you should make an effort to insulate your code from third-party libraries as much as possible.
Side Note
Keeping the important/abstract business and data logic modular should reduce the impact of choosing something that dies later on. In the Java realm (just for example), there are frameworks that do their best to keep your code in Plain Old Java Objects, keeping your code relatively "vendor-clean". Using interfaces judiciously could be your savior later on.
Related Questions
Sadly, this isn't a technical question, it's a political question. You've got the following considerations:
- Is it a clean, well designed framework with good docs and good support?
- Can I count on the ecosystem it's designed for surviving?
- What's the owner's record on this?
Only the first is really technical. In the case of Flex, at the time you couldn't predict that Flash would fall from grace so fast and that Adobe would abandon the Linux version. In the case of Qt, well, there's always a need for embedded device GUIs - but there was a chance that after Nokia bought Trolltech it might have ended up being bought and killed by Microsoft when they bought Nokia. Luckily it was already spun off into Digia.
I guess you could collapse this into 'Do I trust the owner?' I don't trust Adobe, so I would have skipped Flex, but on the other hand Flash had a good long run. I know going in that any MS framework like XNA will be obsoleted in a couple years, but will be supported for quite a while at least. I trusted Trolltech, but then they got bought by Nokia - that's the sort of thing you can't really predict.
I've been faced with this kind of decision a number of times. I always remember: if I'm not filthy stinking rich right now, then I'm probably bad at predicting the future. Any attempt to do so should be taken with a huge dose of scepticism.
That said, I think that the practical answer is simple: invest a bit of time doing a bake-off of the likely candidates. Try to choose some real high-priority business features, and then get very small teams of 2 or 3 people each to use each of the frameworks to build production-quality functionality for those business features. Don't take more than a week to do this. To use your example, Flex vs. HTML5, you would get two small teams to try to build the _same_ functionality using the two different frameworks.
Evaluate your results based on how much the teams actually got done. (Remember: production quality, not prototype quality.)
Since you can't predict the future, I also strongly recommend good Agile Engineering Practices to help to build a system that is not just change-tolerant, but is actually easy to change.
Helping with organizational effectiveness is our job.
The only way to pick a framework that will survive is to NEVER USE ONE!
-The End
Perhaps he should have chosen the platform correctly. His problem was choosing the wrong platform, not the wrong framework. It doesn't matter which Flash framework he used if Flash as a platform didn't survive. Might as well have chosen ActiveX if he wanted to put himself in a corner.
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.
This sig has been enciphered with a one-time pad. It could say almost anything.
Well, not seriously. But short of precognition, a coin toss is as good a criterion as any as far as predicting the future longevity of a framework goes. It's one of the things that should be considered when choosing a framework, but it shouldn't be the top consideration. Give due diligence to the other important factors relevant to framework choice (age/maturity, degree of completeness, level of adoption, suitability to task, number of projects/products using it, nature and size of community, quality of development team, past history of development team members if known, quality of code if available, ...). If you've chosen well, some degree of longevity will come naturally because good frameworks tend to keep getting used (and thus supported). Beyond that, the only guarantee of longevity is your own willingness to support it yourself if that's at all an option.
It sounds like you've learned at least one important lesson, which is that backing by a giant corporation is no guarantee of anything. Except maybe that if they abandon a product or framework, there's not much you can do about it due to intellectual property considerations. It's been said many times before, but at least with free software, you can maintain the source yourself, build a community, or pay someone to make the changes you need to maintain your application. (Note that this isn't meant to say anything about the quality of the framework - commercially backed frameworks often represent the best of breed in that category, sometimes not. But if abandoned, that's where the story ends.)
Two frameworks enter, one framework leaves
Inflammatory though this comment is, I actually have to agree.
Adobe Flex was a steaming pile of crap.
Here's a clue: DON'T pick solutions just because they make your life as a developer easier if it comes at the expense of the user.
Asking people to think is like asking them to buy you a new car
Have you considered twitter bootstrap? http://getbootstrap.com/
Must be the time of year, I read the title as Fireworks instead of Frameworks, and my first impression was "don't light it".
I'm not saying all frameworks are bad... There are a bunch of frameworks out there that will definitely be there for a while. But I don't like to be constrained to a framework. At the beginning, things might seem like it's going well and development seems to be going so fast, until there's a requirement that your framework doesn't support. Then you spend the rest of your life figuring out how to work around the framework. I prefer to develop as much as I can independent of a framework (ie - building libraries), using whatever libraries necessary to get the job done fast, then use the code in the framework. If you have to change the framework, then a lot of your code is still usable without any framework dependencies.
Clearly, it's all the original posters fault. I mean, if only he had taken advantage of his ability to see into the future, then he could have avoided these problems.
But seriously, this is life. S**t happens. The only way to avoid the risk of choosing a failing framework, is to not use a framework at all. But writing everything from scratch can be complete overkill. It really depends on the project.
Heck, even behemoths like Microsoft have been known to put together big fancy frameworks/platforms, only to abandon them later.
Really, the only thing you can do is to follow best practise coding principles, such as making sure your code is as loosely coupled as possible. That way if you do have to make a paradigm shift, you will minimize the amount of effort required to recode.
Personally, when I look at frameworks I look at ones that have *already* stood the test of time. I look around and see all these people going crazy over every latest and greatest thing and I just shake my head. For some reason when it comes to technology, people just assume that new is better, and old is crap. And then you see companies like twitter abandoning their precious ruby on rails platform because the scalability was so bad. Or the London Stock Exchange having to abandon .Net.
Sometimes it's better to stay behind the curve and use stuff that has already proven itself to be stable and long term.
Disclose that you have no control over the frameworks. Make sure all the stakeholders understand that the world of UI frameworks is always changing and that you will not predict what the market will look like in 5 years. Then make your best guess.
"Not so," said Emacs.
Qt for local app development.
Wt for web app development. (http://webtoolkit.eu - C++/ Java/ Jython) It supports Twitter's Bootstrap theme as well.
The commonality between the two past the two letter names is a boon for your developers. True, Wt (C++) uses boost, Qt does not, but your C++ devs will get over it, as they are very close. You can however use Java or Jython with Wt. They will like it because Wt is a API copy of Qt, but for the web. I can actually share my abstract item model code between the two.
One reason to choose either toolkit is the amount of isolation and independence it gives you from the platforms. As CSS. HTML, and JS changes, your application code in Wt does not, the Wt library picks up the slack and automatically takes advantage of new features. Both only need a C++ compiler.Anyone's C++ compiler.
Keeping your application code, to your application, and not to a framework really helps. Even if you move, having it in OOP makes porting it later easier.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
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
Science & open-source build trust from peer review. Learn systems you can trust.
What I've found works well (90% of the time) is:
1. Look to see if people are hiring for that technology. If you check dice.com or something similar you'll see if companies are invested in it.
2. Are 3rd parties building "plugins" or "extensions" for it?
3. Does it make sense to you? Does it adapt well to your needs? Is it well designed?
While many frameworks may be cool or superior technologically, the sad thing about software is that popularity DOES matter.
Frameworks, Platforms, Languages.... which to choose for "longevity" isn't the right question.
Ask First: How long is the product's lifetime?
Will the tools used be supportable over that period? Most business applications don't live more than 10 years. Mostly because the data requirements completely change over that time.
Regardless of tools, if you really want to avoid the future "big rewrite" make sure the system is partitioned - all the way through the persistence/data layers. You should be able to someday migrate it in pieces.
From the Apache Flex webpage:
What happens to my projects if Adobe Discontinues the Flash Player?
It is true that current Flex projects are tied to either the Adobe Flash Player or Adobe AIR. We have been making great strides to compile projects to native JavaScript, therefore bypassing the Flash Player in the browser. Adobe has made a commitment to support the Flash Player and our current runtime for at least 5 years from the time they donated the project to Apache.
--
See for example the FlexJS project, that intends to run Flash directly on a JavaScript VM instead of the Flash Player VM.
For new embedded design I now use Qooxdoo, so the application work with any computers, tablets, or smartphone with any OS as long as it has a decent web browser. The usual setup is to use lighttpd web server for the statics Qooxdoo files and a FastCGI service for the JSON command parser. This allow remote operations and since the Qooxdoo part is static, this lower the load of the system to the minimum.
Best of all, the user don't have to install anything to use the application: It just have to enter the URL of the system.
The beauty of Open Source is -- it's Open Source.
Never choose a piece of software over a promise of what they say they will someday do. It's a false promise that can be derailed on their schedule, not yours.
If you choose an open source project, then embrace it. That means that you can track it as it continues development, and gets bug fixes, but if it "suddenly stops", then -- what's the problem? It's always doing what you asked it to do, now what it was promised to do. You have the source code, and you can maintain your own fork.
How long do you maintain the fork? Forever? No, you maintain it until you're sick of maintaining it. Until it's impossible to make it do what you want to do, then you gradually port away, just like everyone else does when they tire of software.
If you go status quo, the biggest risk is that some change in the underlying dev platform make be incompatible with your source base, but that's rare. Even then it may be practical to port to the new development kit, could be some simple syntax changes or build options.
But here's the key point. Something folks in your position seem to miss.
Whenever you choose something, No matter what the glossy lit says, no matter how bright the smile on the sales person, no matter how glowing the revues on the inter webs and blogs, YOU are RESPONSIBLE for ALL OF IT. Not just the features you use, but the whole kit. All that you allow in to your system, you're on the hook for. If you take that responsibility seriously, then you can see the advantage having access to the source code, having the ability to create a reliable build, and having the skill set to go inside and figure out how things work, and possibly even change it.
Up front, you can rely on the vendor, or the community, or Frank, the guy who wrote it on GitHub. But when they're gone, when it's 3am and the phone is ringing, it's YOUR phone, not theirs that's clattering away. So, IMHO, better to be on top of it all as much as possible, have as much access as you can get to chart your own destiny that rely on others.
You picked Flex _and_ PHP as winners? Damn dude, don't ever go to Vegas.
[FrLz]
The only way to guarantee quality, and longevity is to write your own frameworks. Well excellent third party frameworks exist you just can't trust they will be around for ever, if you're serious and you want the best product possible, you have to write it.
Then I would suggest you're not the right guy to be selecting frameworks at your company.
Repeat after me ... Flash is shit, and those who choose to use it are morons.
There wasn't room in the subject, but I should add "with stable APIs."
Things like Qt, GTK, OpenJDK, Apache, and PHP, to name a few. These are all so widely used that even if they were abandoned by their current maintainers, someone else would pick them up and at least patch them so that they continue to work. This someone wouldn't have to be you. And yes, I know everyone hates PHP, but the fact is, a lot of the old cruft is still there to ensure backwards compatibility, and much of it has been superseded by cleaner OO interfaces. Much like with Java, they're making a lot of effort to make sure that your old code will continue to work with at most minimal changes, and if you're looking for something that will work for you in the long term, this is really helpful.
Failing that, your best best bet are expensive proprietary frameworks that will contractually guarantee some term that the framework will be supported.
After that, big open source projects with less stable APIs (I'm looking at you, Drupal). Drupal is big at the moment, but their nasty habit of breaking everything every two or three years is likely to lead to a fractured community and eventual abandonment of the software unless they can get their APIs stabilized enough that modules will continue to work from release to release. It looks like maybe they're trying to do that, but the pattern thus far is that they haven't. Regardless, if you see a framework with a constantly changing API, you're probably taking more of a risk than you would be if you used a mature product, even if the userbase is large. On the other hand, a large userbase does provide a certain amount of protection against obsolescence. I'm not saying that Drupal is a particularly unsafe framework (I'm quite fond of it myself), just that their development process might lead to intractable problems down the line. Note that GTK and Qt make occasional major API changes, but these are infrequent, and there are so many users of the older versions that linux distros tend to keep the old code around just to make sure things will work.
After that, probably small open source projects. At least if those are abandoned you'll have access to the code. But before using an open source platform with a small userbase, make sure that you have the time and technical expertise to maintain it yourself if it's abandoned. Most likely, you don't. Also, large, complex open source projects with a small number of users tend (in my experience; I'm sure there are exceptions) to be buggy and poorly documented.
The worst offenders are free or cheap proprietary frameworks that don't come with any sort of guarantee, like Flex. In those cases, you're at the mercy of the whims of a commercial interest, and when the product you depend on becomes unprofitable, you're cut off with absolutely no recourse.
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).
I'm witnessing this process at $DAYJOB.
Not UI -- more a back-end thing. A data unification of sorts, for all kind of enterprise data, indexing, yadda yadda.
Instead of thinking about structures, picking up current usage patterns, doing some data architecture, cobbling up cheap prototypes to validate assumptions, folks are all excited thumbing through the Apache Software Foundation catalog as if it were Ikea. Elastic this, Kafka that, Storm there.
Many colorful Lego bricks instead of architecture. Sigh.
My take: keep your designs as abstracted away from the framework as possible. The rest will come.
God-tier: Open-source with corporate backing (many apache.org projects, maybe some google frameworks but they're usually not as well designed) Good-tier: Open-source without corporate backing but with an active developer community Ok-tier: Open-source with small community Shit-tier: Closed-source, especially if it's coming from a company.
If you are going to use a web browser as a user interface then you deserve every single problem and I hope you choose wrong every single time.
Choose the best tool for the job and be prepared to support it. Always create a PoC in a few frameworks first when evaluating a new target platform and you should get a feel for the way to go. Unfortunately you can't future-proof something against loss of support, but consider whether it should be brought up to date with a new framework if this happens (echoing previous comments about strict UI separation).
I have been a UI developer for 15 years and have a lot of languages and frameworks under my belt as there has never been a 'do it all' solution which gives the user a perfectly native experience.
Across the products we support/develop, I still come back to the following on a day-to-day basis and would consider new projects using these, too.
Cocoa - Apple desktop .Net - Windows desktop/Windows web apps
Qt/Gtk - Linux desktop/embedded
C#
CI/Node.js - Linux web apps
KnockoutJS/JQuery - Light web client functionality
Dojo - Heavy web client functionality (single page apps and embedded webkit)
I've never experienced mobile phone development, but I get the impression it gets even harder to choose the 'right' platform.
I found this report interesting/educational if a little old now:
http://www.visionmobile.com/product/cross-platform-developer-tools-2012/
-Rob
Look at the frameworks that have already been around for a while, thats the first place to start.
Don't chase bleeding edge technology unless you want to continue chasing it and replacing old frameworks that were shitty from the start but you were too busy chasing the bleeding edge to notice.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
If this was the analysis you did a couple of years ago, you need to re-think your analysis methodology. There is nothing in Flex that justifies using it over HTML + JavaScript + AJAX requests.
Flex has not held a competitive advantage since around 2007-2008. (Prior to that, the only real competitive advantage for it was pixel-precise positioning of elements cross-browser, which was troublesome for JavaScript + CSS at the time. I happened to develop software that required that specific use case.) Once browser compatibility improved, there was nothing stopping us from ditching Flex.
For PHP pick Symfony and just Symfony. For Python Django, For Ruby Rails. It's that simple. Symfony is beautiful PHP code, it's huge and has a much higher learning curve, but it's not going anywhere. Hell, Laravel uses some Symfony components.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
No one wants to invest in a burning platform, (Aside from Elop, who went from an already hot frying pan in to a cold skillet that was just put on the hot stove.)
Frameworks fail because of:
Political pressure - blame the consortiums and trade groups (HTML5, anybody?)
Commercial pressure - blame the manufactures trying to shuffle you from a free offering into a vertical
Declining development interest - something got invented that was better, or a sole supporting company cut funds
Declining support interest - can;t get support, means no new users to carry the torch
Frame works work when:
Open access - ideally to the source, but free to try. if it isn't free to try, then it can't compete without having customers locked in. Good toolkits are free because they can compete against other free and non-free options.
Open Governance - ideally not just by corporations, but by the non-corporate users.
Open Access and Open governance combined to accept patches for bugs/features
Effective - Not over designed or under designed. Over-designed forces you into a vertical, under-designed doesn't get the job done
Good support options - open bug tracker, mailing list and IRC channel at a minimum.and optional paid support. If your toolkit doesn't have an IRC channel it's not big enough to bet the farm on)
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
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.
How should cross-platform web-based video chat applications have been made without Flash Player? Support for getUserMedia isn't even 50% yet.
If a company or any organisation which develops an open source framework ditches or otherwise nukes it, anybody else with an interest and the capacity to do so can take over or fork it.
Nobody will be able to use this fork if the majority of revenue comes from people who own closed-source devices whose manufacturers refuse to implement the framework. This has become true of the iPhone and iPad, for example, whose Safari web browser can't run Flex despite the existence of Gnash and can't run Java applets despite the existence of OpenJDK.
In my experience writing your own framework for longevity purposes only makes sense if a) you work for yourself or it's hobby code or b) you get a written guarantee from your employer that you can open-source it or own it outright (latter is exceedingly unlikely)
You can accomplish b) by adding a dash of a). Develop the framework in your home office as a contractor and license it to your employer. Or are there laws keeping someone from being a 1099 contractor and a W-2 employee (or foreign counterparts) at once?
If your application has to integrate with other functionality already written in PHP, you may have to either a) write your own application in PHP on top of the existing code or b) turn the existing PHP code into a web service and call it through HTTP requests to localhost. And if you're in a hobby or small business, you might be on a hosting plan that allows only PHP and may have to pay more to upgrade to better hosting.
Firefox singletasking
For now. The Firefox team is moving toward a process per document. This will help with both the slowdown issue and the 32-bit issue.
Consider separation of your data structure from your view (MVC architecture), so the view is easier to replace if necessary.
I agree. However, a change in framework may require a change in programming language. How should an offline-usable application keep its data structure going in parallel in three different programming languages, one for each target platform?
(I've done other things too but) Having worked now for 26 years on one application . . . (monitoring system for manufacturing machines), no one ever asks the question first . . . Should we even be looking at frameworks?
.?", then . . . base the language/framework choice on that.
I know the "xyz" framework for Java will allow me to generate 2 trillion lines of code in 30 minutes that will run on any device known to mankind, but "xyz" wasn't around last year, and if this is another "20 year" project . . . will "xyz" even be around in five years?
If you're writing "conversion" code to move data off one system to another new one . . . that conversion is a "one time" deal. Use anything, Forth, Haskell, APL, heck, use Java . . . I don't care. And don't care what Framework you use to go with it. But if this is to be an application that will run for five (or ten, or . . . more) years, maybe that "xyz" framework or toolkit that came out last month, isn't the best choice.
No one ever seems to first ask "how long will this program/solution be around . .
Yet another case of . . . "we tend to solve the problems we've encountered before". If you're like me, supporting an ancient code base, the "flavor of the month" framework or toolkit, loses most of its merit. I suppose, if you're grinding away on "one time" solutions with overbearing requirements of "fast more so than better or maintainable" . . . frameworks look much more appealing.
jkh
No, I don't remember your name. But the memory mapped screen on a TRS80 from 1977 is from 15360 to 16383 if that helps.
You chose a framework once: Qt.
You chose a product the second time.
Therein lies the difference. The latter is at the mercy of one corporation's budget and marketting decisions.
I do not fail; I succeed at finding out what does not work.
When people talk about frameworks not surviving, what they are generally thinking is more in terms of 'will it still be sexy'.
There is an old saying, "The software is done when the last user is dead." Frameworks, languages, etc often stick around a LONG time past when they are the hot new thing, and chance are no matter which one you go with, a decade from now it will still be around and you will still be able to find people who know it well enough to be hired.
Look into what does the job NOW and focus on getting stuff out the door. You can always switch 5 - 10 years down the road.
you should make an effort to insulate your code from third-party libraries as much as possible.
But how is it possible to insulate one's code from platform changes that dictate language changes? Consider the shift from Java ME phones running apps written in Java to the iPhone running apps written in Objective-C, and from PCs running Flex apps written in ActionScript or Silverlight apps written in C# to the iPad running either web apps written in JavaScript or native apps written in Objective-C.
I went to an Adobe Flex party in Boston shortly after the Macromedia acquisition. The visuals were really good, the development model looked nice, I was pretty stoked. Then I found out that the SDK was proprietary and difficult to extend, that the licensing was deployment-based, and that the front-end was also proprietary and limited regarding devices it would run on.
That was enough to not look at it again. I just am reading now that they gave up on that, tried to give it away, and eventually dumped it on Apache.
Still today, look for an environment that is open, extensible, runs its output on standards-based devices, and also one that has a vibrant community and a good contribution model. Avoid monolithic solutions, but rather parts that do their jobs well and play nice with others.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I invite you to trying answering this rephrased Ask Slashdot: How Do You Choose Platforms That Will Survive? Better yet, seeing as how so many client platforms stress a single language to the exclusion of others: How Do You Choose Languages That Will Survive?
Working on the web? Learn JavaScript. Learn jQuery. Do not use things like SharpKit to turn one platform into another.
That doesn't help if you have to target platforms, plural, and these platforms don't expose the machine's full functionality to web applications. For example, more than half of web traffic comes from browsers that don't give the user a button to grant camera and microphone access to a web site. Or the machine might allow connection of game controllers but the web browser is unaware. Or the latest version of a web browser for a given platform might not implement technologies that let web applications run offline (application cache, localStorage, and IndexedDB). Would you instead claim that offline use, gamepad input, and audio and video input are poor fits for a web application in the first place?
Use JavaScript / jQuery for user interface goodness, not your entire application logic. APIs / web services / interfaces are your friend
If you'd prefer to run all application logic on the server, what should be used for a web application that can also run while the user is offline, such as on the laptop of someone riding the bus? "Problem loading page: You are offline" is useless.
Look to see if people are hiring for that technology. If you check dice.com
Bingo. This whole article is just a Slashvertisement for the job board that Slashdot's corporate parent owns.
In order to bet well on a framework, you have to pair general population with investment psychology. For example, let's look at Code Igniter.
CodeIgniter is a PHP framework. There are A LOT of PHP frameworks. The reason there are a lot of PHP frameworks is because of the language and the community. Most other languages are specifically built for web development, so the frameworks in them add all of the tools you need to handle web development more efficiently. Because PHP has so many of those tools, everybody rolls their own framework. As PHP frameworks become more mature, you start to see speed issues because unlike Java/Python/Ruby/.NET ALL of those PHP files have to get loaded on every request, creating a lot of disk I/O. It's server-suicide to use a PHP framework without APC configured. This leads to a conundrum of framework maturity vs framework speed in the PHP space. The language needed 5.3 and 5.4 to make frameworks REALLY feasible.
But without even getting into all of those details, the sheer fact that there are dozens upon dozens of frameworks in the language is generally a HUGE red flag. If there are that many choices, nobody has got it right. If there isn't one, distinct, clear leader in the space then there isn't going to be an ecosystem AROUND the framework contributing to plugins, etc. Additionally the framework fragmentation will generally mean that you will have a very hard time finding people who use the language who already know that framework. I spent 5 years as a CakePHP developer and I've lived everything I just described.
The end result is that if you want to use a framework PHP itself is a bad choice because there isn't a great option. PHP is great for many things, it's just a valid point in the framework discussion. Because of the level of framework fragmentation your choice of framework is basically "how do I want to organize my code" as the only actual benefit...which really is almost the same thing as just rolling your own.
If you look at other languages:
Ruby has Rails .NET has MVC
Python has Django
Groovy has Grails
For the last 2 years, I've been using Ruby on Rails. For one thing, it's basically the standard bearer for web frameworks. Within the ruby ecosystem, pretty much EVERYTHING makes sure that it works smoothly with Rails. It was really the clear choice from the time that I was making choices the only thing that prevented me from using it was the very stubborn "but I already know PHP" line. I looked at Groovy so I could deploy on Java infrastructure, but jRuby solves that problem for Ruby as well. If I was in a .NET shop, the choice would be MVC and if I was using Python it would be Django. Until PHP gets a "main" framework, there will not be a good framework option for PHP. Laravel seems to be going the right direction though, so that's one to keep an eye on.
In the front-end space, anything Flash based has pretty much always been a bad idea unless there is no alternative. Front-end web development should generally always follow a philosophy of graceful degradation, meaning everything should work without javascript and javascript should be used to enhance the experience with only a few exceptions on the actual-in-browser-application front. jQuery made graceful degradation EASY while also emphasizing compatibility (you could use jquery and prototype at the same time, that wasn't the case with most JS tools) and as such, took over in popularity.
The short answer to all of that is simply this: the market leader leads for a reason. Look for the market leader that works across the broadest set of platforms and you'll generally find your answer.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
HTML also has poor feature coverage according to caniuse.com for features that are standard in Flash Player. For example, Flash has 3D graphics, while WebGL is on only 32.43% of web browsers. Flash has webcam access, while getUserMedia is on only 47.23% of web browsers. Flash had cross-origin requests before HTML did, and even as of right now, 9.61% of browsers don't support XDomainRequest or cross-origin XMLHttpRequest. Considering replacing Flash animations with canvas animations? They won't play on 19.27% of browsers.
You don't have to pay someone to "fork/maintain" when the original developer goes away; open source projects generally get picked up by other commercial entities to maintain without you having to do anything. In fact, many open source projects you use and rely on have gone through that process without you even noticing.
Go by Gartners hype cycle when in doubt. Then realize Flex actually is in a much nicer place than most other frameworks.
You're also at the whim of the masses. Development platforms benefit tremendously from network effects. Success begets success. On the other hand, it was arguably Apple that killed Flash. HTML5 combined with their refusal to allow Flash on iOS devices was devastating to the platform. The popularity of the iPhone meant that everyone had to support it, and because that could be done in a generic fashion, there was no reason to build 2 versions of the same product, thus Flash died as a platform in a very quick fashion. Compare this with, say, Silverlight, which was an excellent platform, but everyone looked at it and said not interested, mainly because of the proprietary nature. I could give my users a superior experience with less effort, but it's not ubiquitous, so it's just not an option.
If you can identify frameworks that clearly don't have a future, you can improve your odds substantially. Just ask yourself, is it proprietary (Flash)? Is it ubiquitous (HTML/JavaScript)? Does it have a reputation as a clumsy and flawed platform (PHP)? Is it popular (jQuery)? If your answers are No, Yes, No, and Yes, you stand a pretty good chance of long term success. In my own shop, we've gone with C#/MVC and HTML/JavaScript/jQuery. Honestly, HTML and JavaScript is a pretty shitty platform. But sometimes popularity and ubiquity win the day. Meanwhile, it can safely be assumed that as long as Microsoft is around, C# will be well supported. Silverlight is a far superior platform, but it's a dead end and we want to be certain to avoid dead ends.
I got a good chuckle out of that. Hopefully you had your tongue firmly in cheek when you wrote that.
"Convictions are more dangerous enemies of truth than lies."
Before investing a ton of time even building a toy project, I usually will try to eliminate some candidates based on:
- Is it Open Source (you can always update it yourself if it gets abandoned, and if it's reasonably popular, chances are someone else will if you don't have the chops)
- Documentation and learning curve (which significantly affect uptake)
- Existing ecosystem (libraries/modules/plugins/extensions/whatever)
- Community (both size and median skill level -- to develop ecosystem and provide support)
- Core developer culture (how do the BDFLs or equivalent make decisions about what to include/exclude in new releases; what's participation in core development and discussions like, etc, etc.)
- Community culture (check out mailing lists)
- Shortcomings (What do members of the community most often complain about about the framework? Are there reasonable workarounds? Does the core team have plans to address them, or are there well-maintained forks that do?)
Build a toy project in each framework that exercises the major features that you need in your line of development (e.g. for a web framework I might build a simple blog or to-do list with authentication and an admin panel). Get a sense for how ergonomic the basics are, how well it matches the way you work, how much work it saves you building wheels from scratch, what the learning curve is like, what the documentation is like... then try to push it to do something minor that looks like it's outside of the center of the framework's wheelhouse -- see how flexible it is.
When I hear RIA, I think of Gmail
And even then, only 57.52% of browsers support the IndexedDB needed to store messages for offline viewing.
not Farmville
So for things like FarmVille, with what would you replace Flash? Cookie Clicker uses HTML5, but I wonder how gracefully it degrades on downlevel browsers.
Please don't do this in an RIA. Just do a full blown application.
Good luck installing "a full blown application" shipped as .msi on a Mac or installing "a full blown application" shipped as .dmg on a non-Apple PC. You end up having to ship not one but twelve "full blown applications": one each for Windows 7, OS X, X11/Linux, Android, iOS, Windows RT, PS3, PSP, Xbox 360, Windows Phone, Wii U, and 3DS, and eight of these twelve platforms need the hardware maker's permission before the app will even run.
Why would I want XSS attacks to be allowed rather than blocked?
CORS has absolutely nothing to do with XSS. XSS means opportunity for an attacker to inject script into your application. CORS retrieves the resource as data, not as script, and your script interprets it. The closest attack to CORS is CSRF, the submitting of forms, and that's why CORS sends an OPTIONS request before any POST that isn't standard form data. You want it because your web application integrates resources provided by other entities with whom you have contracted to provide resources.
Again - most things don't need animations at all.
Most don't; some do. With what would you replace Flash used in the vector animations seen on places like Newgrounds and Albino Blacksheep? Rendering them to WebM or H.264 would cause the file size to increase by an order of magnitude.
I learned a long time ago, that success on any project is learning to manage change.
For whatever reason, software tools just keep changing.
1. Separate your layers. As others have said already (MVC...) ...
2. Try not to use special functionality in a particular choice of technology. This will make getting off that particular technology choice easy when porting to a different vendor or technology. You can be a bit of a pain enforcing this, but ultimately, it is good. It requires good judgment. For example, I personally would have avoided using lamda expressions in any language prior to it being availabe in c++/Java/.NET.
3. Learn to use bridges. Sometimes you can't port something due to a lack of resources or time or whatever. Don't be afraid to throw computing power at the problem. I have a simple rule that will probably annoy people. If enough time has passed to outdate your technology choice, chances are computing power has increased enough that you can ignore many performance concerns you had at the time you developed the product. Throw up a webservice proxy or whatever between components.
4. Keep your APIs simple! This one, I can't stress enough. If at all possible, keep your APIs simple between components. If you can stick to basic strings and int or whatever, more power to you. Just try to keep it simple. It will make interoperability a million times easier.
5. Stay away from all encompassing frameworks that give you everything.
6. Keep some skilled staff on board for the build process and who know the ins and outs of frameworks.
I think you get the point.
They'll only pick it up if there is a benefit to them doing so. Obviously EllisLab feels there are not enough benefits to 'owning' CodeIgniter. They don't want to put the time and money into it without it paying back some way. And it is obvious from the link that it isn't. I would bet you have seen a few open source projects that you used tools from die. Did you offer to start supporting any? Why? Not knowing the technology is not an answer. Not getting enough benefit out of learning a new technology, or from learning the code base, or from your free time being used up to start supporting it... That is the answer.
The bigger the project the more time, money, and sweat goes into it. The bigger it is, the less likely someone or some group will want to spend all their free time away from family, friends, downtime, to make something that others will benefit from without anything in return for themselves. This is the economics of life. You make a distinction between open and closed source that is complete bullshit. In both worlds people do stuff that is beneficial for them or leave it eventually (whether quickly or not).
Most open source projects end because people were not getting any benefit from the hours they put into it. Initially the benefit might have been fun or the dream of making money. After they spend enough time away from things that really matter without it helping to pay the bills, the project gets dropped. Large or small project it doesn't matter. CodeIgniter is obviously not paying the bills for EllisLab. Who says it will for anyone else?
-- I ignore anonymous replies to my comments and postings.
Catalyst is one of the oldest MVC frameworks and very actively developed. Catalyst is also very stable, a few years ago the Catalyst team implemented the new Moose Object system for Perl and older Catalyst code still generally works. When I upgrade a system running Catalyst or redeploy my applications to a new system the major headache is from missed dependencies, but once I sort them out it is unusual to have to change code, and deprecations are infrequent and get long notice periods. When the new MOP object system (it is based on the Moose Object extension Catalyst already uses) ships in an upcoming Perl release your old Catalyst Code is still going to work, and as each release of Ruby and the path from Python 2 to 3 show, those other languages don't maintain the stability that Perl does.
minds, get scrambled like eggs, abused and erased. Hard Hearted Alice is who you want to see.
When Internet Channel came out, it supported Flash, and there was a site called WiiCade showcasing Wii-friendly Flash games. In September 2009, Internet Channel was upgraded to Flash Lite (compatible with Flash 8 and some features of Flash 9).
The faster the technology rises, the faster it falls. Things like Flash become sensations for fickle reasons. Then the next thing comes along and everybody who's anybody switches. Yet all the crap dumped into the tech upon demand of the fickle people remains, weighing it down.
Technologies which mature more slowly (if you're willing to wait for them to mature) tend to have better staying power.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
You know it's not really all that difficult to see the writing on the wall for some technologies.
Flash in particular you could see coming from a mile off. It was a web browser plugin that hated the web. It tried its best to fight against web technologies at every turn. Many aspects of the web - URLs for discrete resources, the DOM for discrete page elements, source-based delivery, cross-platform authoring, open-source authoring, etc. - were actively subverted by Flash. So all the forward progress for the web that improved or relied on these things fell by the wayside for Flash.
Likewise with PHP frameworks. With few exceptions mainly relating to lock-in, everybody who's got any taste and skill abandoned PHP years ago or never took it up in the first place. As a consequence, this leaves the people driving PHP forward very poor stewards. PHP is a zombie at this point - the killing blow has already been struck, it's already dead, it's just going to take a while for this to become so obvious it cannot be ignored. Competent people don't do things like cause security issues because they make releases after ignore failing tests.
You say that you deliberately eschewed open-source, but if you look at where the forward progress for the web has been coming from, it's predominantly open-source projects.
I just don't see how you can have any understanding of this industry and continue to make those kinds of choices.
Bogtha Bogtha Bogtha
Just kidding. :)
But seriously, I think Ruby on Rails will be around for a very long time since it already has a lot of momentum, and isn't entirely subject to becoming stagnant when a single company loses interest in it. For better or for worse, Rails has a lot of fanatics that are utterly devoted to the project, which can be annoying, but it also lends an air of longevity to the project.
Also, there is no such thing as a good front-end framework that does everything you want it to do, but that said I would recommend checking out backbone.js. You'll spend more time and money trying to shoehorn a UI framework into working for a large application than you would having a few good developers build and maintain your own internal framework.
Just as an investor can do world-class research and due diligence, with no guarantees that his investment will provide a positive return, there's no fail-safe way to choose a framework that will thrive.
Do your best, and good luck.
That that is is that that that that is not is not.
Unless you are using a programming language over than I am, you are using an object oriented programming. It is a huge mistake to forget the basic tenets of OOP. In this case, its Encapsulation that you need to leverage. If you hide the framework behind some of your own classes and use good design practices, you can hot-swap APIs with minimal fuss. One minute working on good design will save you an hour of programming and a year of debugging.
We still maintain apps in Struts 1. So I don't think you can go wrong with Java for longevity.
If you choose something you have the source to, and can control the deployment of (by compiling it into your program or including it as DLLs), then you win.
I use Delphi and Lazarus, and even if those two aren't super popular, it doesn't matter - the capabilities aren't going to *decrease*, and I don't have to cajole the user into installing some certain version of Java, .net, IE, etc. (And the libraries are written in the language itself, so they can be statically linked into the EXE for a portable app).
Something like QT and/or GTK are also probably safe. Something like Adobe Flex is most certainly not because you have to convince people to install it, and you con't have the source for and can't control flex itself.
Java?
Until you run into one of the things that Java doesn't handle by itself, such as gamepad input, OpenGL graphics, webcam access, etc. Then you have to install native code. Or until you run into a platform that doesn't have a JVM. I know of plenty of platforms with a web browser but no JVM, and I can list them if you wish.
not having to beg each platform's owner (like Apple, Microsoft, Nintendo, or Sony) for permission to run your application
I'm not talking locked down environments here; I'm talking environments in which you'd actually play a game or use multimedia software, i.e. at home/on your own computer.
A lot of people prefer to "actually play a game" on their own game console at home, and game consoles other than OUYA are locked down environments. They don't run Java applets or Java applications.
14% of your customers who do not like Metro
My aunt's PC runs Windows 8. So does my PC at work. On both of these machines, I installed Classic Shell, which lets me avoid the Windows Start Screen (and thus most of Metro). Windows 8 thus ends up feeling like Windows 7.
Progress too slow and corps and grannies resisting change [who] stick with XP
In less than six months, there's going to be a grandmapocalypse bigger than anything you see in Cookie Clicker.
It's not about picking the right one. Beta was way better than VHS. Blu-Ray was way better than HD-DVD. Sony lost. Then Sony won. You won't predict it with any degree of precision. Don't try.
You can choose multiple solutions. Odds are that both or many won't all fail at the same time. So you'll better stagger your mistakes.
Or, you can do what I do. I built my own framework. Then it's mine. It's supported by me. It does what my business needs it to do.
Roll your own. It ain't hard.
It is not objective but much like other self-fulfilling prophecies, I think reputation is important in choosing a framework. Also, if the company or group puts in place the right tools for taking into account the feedback from the community, then it sounds right. A forum can be either good or bad news. You need to check if it's only about PR stunts and lame excuses or if they truly address technical problems and develop the features requested.
Yes, usually that benefit is called "money".
Just like most closed source projects.
You seem to operate under the erroneous assumption that open source products are not for profit or that people don't make any money of them. That's wrong. While open source licenses don't guarantee longevity, but all things being equal, your risk is much lower when the product you use comes under an open source license than under a closed source license.
Qt is cross platform, I was assume if it had to be replaced, it would be by something that is also cross platform. If not, you would probably be looking at ideas/techniques like SOA, and wrapping your model with services.
Qt is cross platform
Until I get to a platform that A. doesn't have Qt, or B. allows web applications but forbids native applications entirely without the express written approval of the hardware manufacturer. Such platforms include Apple and Microsoft mobile devices and all major game consoles. For such platforms, I'd have to rewrite the view in JavaScript + HTML + CSS, and I'd have to rewrite the offline portion of the model in JavaScript.
If not, you would probably be looking at ideas/techniques like SOA, and wrapping your model with services.
But on which machine would these services run? Running the model on the client would require rewriting the model in multiple languages if different platforms require applications to be written in different languages. I can give examples of platforms that accept only one language if you wish. Running the model exclusively on a server may work for some apps but not for apps intended to have an offline mode.
Especially if you're in PHP or another high-level language which can be very rapidly developed.
The problem, of course, is that it takes much more skill to build something good without a framework. The hard part is finding the right people. People who don't need "frameworks". You may not be able to find or afford programmers of the requisite quality.
Really well written code won't be significantly benefited by the inclusion of stylistically different one-size-fits-all code written and supported by other hands.
Until I get to a platform that A. doesn't have Qt, or B. allows web applications but forbids native applications entirely without the express written approval of the hardware manufacturer.
The original topic did not indicate which platforms, so the big three desktop platforms were assumed (by me). You are seeking a one-stop solution for deploying to any platform ever created deep in a slashdot thread. So here goes:
Contribute any missing platform support to kivy.org
It's impossible for a UI framework to stay relevant for more than a few years, unless it's based around a slow-moving standard too big for corporate interests or bottom-lines to affect.
Your choice to use something other than HTML5 because HTML5 wasn't ready yet, was good. However, you probably should have used something HTML4 related at that time.
As someone who's been predicting Qt's demise ever since he learned Nokia had bought it, I can only shrug and wish I'd been there to tell you so.
Do not rely on corporate frameworks, ESPECIALLY open source ones. Corporations treat open source projects as hot potatoes the second money gets tight. They only keep them on board to reduce costs and gain a little PR magic with the less-cynical geeks. As soon as it starts costing resources to improve and especially if the non-paying user base gets uppity (which, as a monied stakeholder, you can't control), out the window it goes.
Since corporations get their fingers into everything they rely on, your rule of thumb should be the ratio of unattached volunteers (those working on the project in their spare time regardless of who they work for -- meaning their employer had no influence on their choice to volunteer with that project). If total project brain drain is just one cost-cutting decision away, that framework is dead code walking.
Every trollism an AC posts is prefixed, in my mind, with "A. Coward whined, in a weak and cowardly voice:"
stay away from C#. M$ is quietly killing it.
No, I'm not under the erroneous assumption that open source projects are not for profit, etc. I am pointing out the flaw in your comment; that even open source projects must provide some benefit to the person working on it (whether money or shear satisfaction). And when that benefit fails to materialize it will be dropped. Look at your comment. If a maintainer of a project stops maintaining it (like EllisLab is about to do), just because a lot of people are using an open source product doesn't necessarily mean someone else will take it up. They will only do it if there is something in it for them, regardless of the currency. i.e. a profit.
-- I ignore anonymous replies to my comments and postings.
When a lot of people are depending on an open source project, the ability to earn a profit from maintaining and supporting is pretty much automatic because there are a lot of potential customers with unmet needs. Sorry, but the flaw is in your understanding of economics.
Despite what people say, it's alive and doing well, it's NOT going to die given it's market share in enterprise. For intranet, you don't even need to use applets, just JNLP for a full desktop app, merely delivered by browser.
Not that I like it though. Two years ago we started to invest in Silverlight, building our own framework on it for RAD. Even though it seems dying today, it's still the very best choice for business apps in terms of development speed, runtime performance and functionality, far surpass HTML/JS and Flex because it allows very low-level controls such as pixel shaders, weak object reference and IL code emitting.
Good points about other languages such as Python, Ruby and Groovy - none of those languages is as popular as PHP, but they are harder to get started with than PHP, and perhaps as a result are generally chosen by more experienced programmers.
These smaller communities of more experienced programmers do seem more likely to create and choose a dominant framework - while Django is not the only Python framework, it is by far the most popular, with the most addon modules.
PHP isn't a completely bad language, but it does have a lot of problems that drive many experienced programmers to other languages. And the sheer number of frameworks in PHP is a huge problem.
Generally a strong framework without a single commercial backer is best - a strong core team of developers is more resilient to future decisions and competition than a single company whose strategy decisions can alter the future of a framework.