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.
Whatever shows up (significantly) on the hiring boards.
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.
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.
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/
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
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.
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.
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.
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.
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.
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).
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.
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
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.
It seems to me from my limited work with PHP to everything I've read about it, that it's a great language if you're just building a fairly small and simple website (since it's supported by every dirt-cheap web hosting service out there and is fairly C-like in its syntax, plus it's really easy ), but totally sucks if you try to scale it up to anything really serious and high-performance. So why does anyone bother? If you're doing heavy-duty stuff, pick something better suited.
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.
Stupid Slashdot; when are they going to get with the times and allow editing?
What I meant to say was:
and is fairly C-like in its syntax, plus it's really easy to embed into otherwise static HTML code.
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.
But how is a web application worse than having to write 12 native apps for 12 different platforms and beg the platform's owner for approval on 8 of them?
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.
The LSE didn't abandon .NET, they abandoned the shitty implementation they were given that happened to be on .NET.
.NET will scale _massively_ if you do it right. You could write a trading platform in super-modern C++ or OCaml or whatever the trendy kids are using these days and it could still perform like shit if it's not designed correctly.
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.
Flex was Java on the server side, so apparently just not using PHP didn't save the OP.
"If God created us in his own image, we have more than reciprocated"
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."
Flex/flash allows persistent sockets obviating polling which architecturally made a world's difference back then and to a certain degree still does for a certain class of applications.
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.
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.
You don't abandon a runtime environment, you abandon a product. The product they abandoned happened to be developed on .NET and the new one on Linux (why are we comparing .NET with Linux, they are not the same type of thing, btw).
Point is that platform choices are vastly subordinate to architecture, design, and implementation.
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.
t seems to me from my limited work with PHP to everything I've read about it, that it's a great language if you're just building a fairly small and simple website , but totally sucks if you try to scale it up to anything really serious and high-performance
As someone who works with PHP day-in, day-out... every day... every week... until the end of time (*sob*)...
No. It's pretty much a sucky language all along the gamut of use cases.
So why does anyone bother? If you're doing heavy-duty stuff, pick something better suited.
For a long time, you'd have been hard pressed to find something "better suited." Unless you wanted to use CGI or mod-perl instead of PHP, but that'd just be trading one misery for another (said as a long-time lover of perl)
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.
No. It's pretty much a sucky language all along the gamut of use cases.
How so? I used it for some simple website work, and it was extremely easy to get started and write simple code with it. I really don't get where all the hate comes from. Yes, the language is kinda messy compared to some others, but so is Perl. What's a better alternative? Java is verbose and unwieldy for a small, simple website, and not supported by cheap web hosts. Python maybe, but again it's frequently not supported by cheap web hosts, and it doesn't have a C-like syntax at all. And I don't think there's anything else that's so easy to embed into static HTML.
Every time I see someone complain about PHP, it just looks like a bunch of bitching and moaning, with zero constructive advice or suggestions for something better, and your post is no exception.
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.
What's a better alternative? Java is verbose and unwieldy for a small, simple website, and not supported by cheap web hosts. Python maybe, but again it's frequently not supported by cheap web hosts, and it doesn't have a C-like syntax at all. And I don't think there's anything else that's so easy to embed into static HTML.
I didn't say it was inaccessible. I said it wasn't a good language.
Every time I see someone complain about PHP, it just looks like a bunch of bitching and moaning, with zero constructive advice or suggestions for something better, and your post is no exception.
Because they've been listed elsewhere, endless times already.
That's just a few of the reasons. The only things PHP have going for it are accessibility to novice and/or weak developers, and wide availability. If you'd ever used it for anything more complex than a web forum, you'd have experienced first hand "where all the hate comes from."
Just because it's "the only game in town" doesn't imply quality (insert IBM/Microsoft/AOL comparison here).
Again, no suggestions for anything better. I've never seen them listed anywhere else, all I ever see is people whining about how bad PHP is.
If you'd ever used it for anything more complex than a web forum,
This implies that it IS a good language for simpler projects, which is exactly what I said before.
The only things PHP have going for it are accessibility to novice and/or weak developers, and wide availability.
These are extremely important features to many. What good is a language if you can't use it on most inexpensive web hosts? It's useless.
Just because it's "the only game in town" doesn't imply quality
Again, irrelevant. If it's the only game in town, then it's a lot better than the alternative, which is either nothing at all or something much harder to get working because it's not easily available.
If PHP were really so bad, someone would have come up with a better alternative by now. There's no shortage of programming languages out there, but PHP is doing fine, while there are practically no other alternatives, except maybe Perl which is pretty kludgy itself.
I've never seen them listed anywhere else, all I ever see is people whining about how bad PHP is.
Then you've never looked, and never gotten more than a toe into the pool to run into them firsthand.
This implies that it IS a good language for simpler projects, which is exactly what I said before.
No, it doesn't. It implies that if you've only scratched the surface of the language, you don't have the experience with it necessary to judge its quality.
These are extremely important features to many. What good is a language if you can't use it on most inexpensive web hosts? It's useless.
Irrelevant to the quality of the language. It's a question of design and philosophical flaws, not popularity, no matter how many times you try to use that excuse.
If PHP were really so bad, someone would have come up with a better alternative by now.
There are plenty of alternatives. Python, Ruby, TCL, Perl, etc. They're all better, even Perl, but less popular.
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
Most of those aren't supported on typical inexpensive web hosts, so they're useless. What good is a language if you can't actually use it anywhere?
And Perl used to be the king of server-side scripting, and it's all but died out. Are you going to try to argue that that was some kind of accident, and it really is better somehow even though everyone's given up on it?
You keep trying to brush off popularity like it's not important, when in fact it's one of the most important factors there is in a language. Popularity dictates support and availability.
Your excuses of popularty and being available on cheap hosting makes PHP work for simple developers to write bad code, and has nothing to do with the language being "good" for any project, simple or otherwise. Repeating your incorrect position over and over again will not make it any more true.
Regardless of your pointless metrics, it is a bad language because it objectively flawed in more ways than it has redeeming qualities.
You still don't get it. A "good" language by your metric is useless to me if I can't use it on cheap hosting. If I have to pay a fortune or go to a lot of trouble to use a language (because I need a dedicated server with root access or whatever), that's not "good", that's decidedly bad, no matter what you may think of it. You're like a snob that tells everyone to buy a Ferrari or Bentley because $100k cars are all crap. It doesn't matter how "good" something is if people don't have access to it.
No. YOU don't get it. "Useful to Grisnakh" and "well designed" are completely orthogonal concepts.
No, YOU don't get it. Please point to where I EVER said PHP was "well designed". I never said any such thing. I said it was good for certain uses, namely small sites. You're the one that went off on a tangent about good design, something I never said much about and certainly not in favor of PHP, since that's obviously one of its shortcomings. I'm only arguing for usefulness, and good design is not very well correlated with usefulness. For an analogy, look at Phillips screwdrivers. That's a totally shitty design, compared to Robinson and Torx heads, because it's so easy to cam them out. However, if you don't have some Phillips screwdrivers in your tool set, you're not going to be very useful since so much stuff is made with the things. And if you're designing something with screws, you have to consider using them because everyone has Phillips screwdrivers (not so much for Robinson and Torx), and they're at least better than flat-blade screws in most ways. Another analogy would be Ogg Vorbis vs. MP3; if you're releasing music for sale, you'd be pretty stupid to refuse to release it on MP3 even though it's a shitty format compared to Ogg Vorbis, since everyone's familiar with MP3, most people have no clue what Ogg is, and many devices (including everything from Apple) won't play Oggs.
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:"
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.
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.