Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming

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

Posted by Unknown Lamer from the common-lisp-is-forever dept.
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.
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:

  • IE6 (Score:5, Funny)

    by ArhcAngel ( 247594 ) on Wednesday October 23, 2013 @01:22PM (#45214089)
    That thing will be around FOREVER!

    • Re:IE6 (Score:5, Insightful)

      by homey of my owney ( 975234 ) on Wednesday October 23, 2013 @02:09PM (#45214731)
      The problem is you're thinking about it all wrong. The decisions were probably all right at the time. If you think there's a crystal ball that will tell you what the future will bring, you're going to look long and hard. The right decision is right for now. The best you can do is design so that moving to something else is possible instead of painful.

      • Design for multiple languages (Score:4, Interesting)

        by tepples ( 727027 ) <tepplesNO@SPAMgmail.com> on Wednesday October 23, 2013 @03:10PM (#45215733) Homepage Journal

        The best you can do is design so that moving to something else is possible instead of painful.

        How is this possible when widely used frameworks are designed for one language and one language only? For example, the web runs on JavaScript, but if I remember correctly, Flex used ActionScript and Silverlight used C#. I can see rewriting the user interface when switching frameworks, but rewriting the application logic in a different language for each framework can get very tedious and introduce plenty of bugs.

        • Re:Design for multiple languages (Score:4, Insightful)

          by lgw ( 121541 ) on Wednesday October 23, 2013 @03:28PM (#45215993) Journal

          Accept that the price of using a framework is probably re-writing everything every few years. Don't lie to yourself about it. This is the fundamental problem with frameworks: even if they don't go away, mature projects often hit their limits.

          I don't think that any framework is a good plan for a well-funded successful project - for the few projects that make it there. So I'd say: take the framework that gets V1.0 done quick and easy. Probably the framework will die, but that's OK because probably your project will die first. If the project is one of the very few that really takes off and is a big deal 2-3 years later, then you'll have the resources to do it right.

    • Re:IE6 (Score:4, Insightful)

      by mwvdlee ( 775178 ) on Wednesday October 23, 2013 @02:55PM (#45215461) Homepage

      +1 Funny and -1 Not Funny in one sentence.

    • That thing will be around FOREVER!

      I've heard It's going to marry OpenVMS in a same-endian wedding.

  • Write your own! (Score:5, Insightful)

    by Anonymous Coward on Wednesday October 23, 2013 @01:26PM (#45214133)

    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.

    • Re:Write your own! (Score:5, Insightful)

      by JustinKSU ( 517405 ) on Wednesday October 23, 2013 @01:57PM (#45214581)

      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.

      This is a challenging option in a corporate environment when you need to hire someone to support said framework after you have left the company unexpectedly.

    • Re: (Score:2)

      by rsborg ( 111459 )

      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.

      Sorry, This doesn't necessarily work either. If it's produced at a workplace, that code is now owned by them. I've had this happen to me before where, on my departure, I wasn't given permission to open-source my framework, it was "competitive advantage" that stayed with the company.

      Instead, if I had used an existing framework, I would have a much stronger angle to open-source fundamental changes (ie, ones that aren't part of the business logic) that would benefit others (possibly me in my future role outs

      • 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?

        • Re: (Score:2)

          by rsborg ( 111459 )

          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 it's not illegal, it's generally not practiced/advised. I'm sure it's something that'd be red-flagged on financial audits. In this case, it'd be best to just stay 1099 or corporate supplier, and not actually be employed by your customer, so basically still option (a).

          However, these days it's much more preferable to not go 1099 (you can't do that for more than 1 year at a time), so consequently major corps hiring contractors generally require you incorporate or work for one of their existing contracting

    • There can be a lot going for this. I work on a quite large web application written in Python, used by medium-to-large companies. It uses a custom MVC framework which I started 4-5 years ago. Like AC, we understand it, there are no hidden corners, and when we need to modify it to do something we need, we do so. Downsides are documentation (you can't rely on others to do it), and maybe recruitment.

    • Very good post.

      I evaluate frameworks in a simple way:
      o do I understand it
      o would I write it in the same orma similar way

      Well, if the first is false, the second is false, too, obviously.

      However I encountered so many frameworks that simply don't come to the point, don't really simplify the programmers work, that my main point is "is it designed / written in the way I would do it."

      That comes to the point of my parent: there is nothing wrong in writing your own. You should do that once. That will help you in

    • To anyone who starts preaching the religion of code reuse

      I'd argue that when you write it for yourself, the reuse will be perfect, because the parts you write you'll use repeatedly, and the parts you won't use you won't write in the first place.

  • Practical answer (Score:5, Insightful)

    by micahraleigh ( 2600457 ) on Wednesday October 23, 2013 @01:28PM (#45214163)
    Whatever shows up (significantly) on the hiring boards.

    • Re:Practical answer (Score:5, Insightful)

      by Sarten-X ( 1102295 ) on Wednesday October 23, 2013 @02:07PM (#45214719) Homepage

      This is an insightful answer, and I wish I had mod points now.

      What's on job listings gives a good indication of what other companies have invested in, and what they're going to need support for in the next decade.

    • Whatever shows up (significantly) on the hiring boards.

      Do you think that's an indication of what will survive, or merely what a bunch of HR people have been told is the latest buzzword they need to ramp up on?

      I'm not sure it's a sign of longevity so much as it is a sign of what's effectively trending on twitter.

      • I guess it's kinda like 'Ask the Audience'.

        The answer is open-source answered by companies you might trust.

        Perhaps IT staff more experienced/intelligent/informed than us have reached a conclusion that we happen to be seeking.

      • As a parlor game, yeah, I think that is a pretty good indicator of what will survive. If industry goes in a direction (i.e. more than just MS or Oracle) the devs follow. Sometimes the other way around, but either way I believe what shows up on the jobs boards survives. If a company is dangling money/positions they have skin in the game, and while they can change that its a better indicator than, well, internet talk.

        More seriously, the reason why I pay more attention to the boards (although it is hard to

    • Whatever shows up (significantly) on the hiring boards.

      That's a double-edged sword. While it indicates that the framework is heavily used, it could also indicate serious problems with the framework that require excessive amounts of manpower to maintain it.

  • What is the future of the product? (Score:4, Interesting)

    by kawabago ( 551139 ) on Wednesday October 23, 2013 @01:30PM (#45214185)
    Choose the framework that supports, or can be extended to support, planned features of the product.

  • Hindsight is 20/20 (Score:5, Insightful)

    by nitzmahone ( 164842 ) on Wednesday October 23, 2013 @01:31PM (#45214217)

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

  • Qt (Score:5, Insightful)

    by BreakBad ( 2955249 ) on Wednesday October 23, 2013 @01:36PM (#45214273)

    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.

    • 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?

  • All roads may run ill... (Score:5, Informative)

    by OmniGeek ( 72743 ) on Wednesday October 23, 2013 @01:40PM (#45214327)

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

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

    Sometimes you just can't outwit Murphy.

    • Re:All roads may run ill... (Score:5, Interesting)

      by superflippy ( 442879 ) on Wednesday October 23, 2013 @02:05PM (#45214681) Homepage Journal

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

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

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

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

  • 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 han

    • Re: (Score:2)

      by tepples ( 727027 )

      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.

      On the other hand, companies that were tied to the JVM ended up getting blind-sided by Apple's choice not to make the JVM available at all on the iPhone and iPad.

  • First (Score:3, Funny)

    by Billly Gates ( 198444 ) on Wednesday October 23, 2013 @01:40PM (#45214335) Journal

    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.

    • Well, happens all the time.
      But the risk is that you get sued into oblivion instead. Don't know the proper english term,,but something like "insensible engineering conduct" comes to mind, simoly fraud would be the next.

  • Bake-off (Score:4, Insightful)

    by under_score ( 65824 ) <mishkin@be[ ]ig.com ['rte' in gap]> on Wednesday October 23, 2013 @01:48PM (#45214423) Homepage

    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.

  • Flex is a Framework but Flash is a Platform (Score:5, Insightful)

    by omnichad ( 1198475 ) on Wednesday October 23, 2013 @01:52PM (#45214495) Homepage

    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.

    • 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?

      • I don't think anyone's expecting HTTP/HTML to go away for a long, long time. And this person was creating an RIA using Flash instead. HTTP/HTML is in the hands of standards groups and Flash is in the hands of one corporation. Even if HTML5 is just buzz and mostly dies away, that's not going to require a rewrite. ActiveX was the first example of a closed platform going away, and I was surprised then how many people made such a poor choice. Java is fine for running on the server, but Java Applets are alm

        • 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

          • When I hear RIA, I think of Gmail - not Farmville.

            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.

            Please don't do this in an RIA. Just do a full blown application. The vast majority of RIA's are not games - there's a lot of things that don't need fancy graphics at all. I just don't know what this poster was doing in their app.

            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.

            This is a security risk. Why would I want XSS attacks to be allowed rather than blocked?

            Considering replacing Flash animations with canvas animations? They won't play on 19.27% of browsers.

            Again - most things don't need animations at all. I'm considering that it wasn't likely that the projects in question were graphics-heavy.

            • 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, X

  • Some notes from a seasoned web developer... (Score:5, Insightful)

    by Dracolytch ( 714699 ) on Wednesday October 23, 2013 @01:57PM (#45214575) Homepage

    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.

    • 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.

      I will second everything you said and add some more web dev wisdom. I am assuming that the OP is developing middle-ware or other web apps (social, ecommerce, etc). Sound development practices should mitigate the impact of changes in component architectures, from data stores to UI you need to compartmentalize as much as possible and use each underlying tech as they were intended.

      I have developed dozens of web apps from FileMaker Pro (mid to late 1990s) to PHP/MySQL today; with a few things in between. If you

    • 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 [caniuse.com]. 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 off

    • All those are good recommendations... except when they are not. Companies do programming not for its own sake, but to make a profit. And making a profit, sadly, often doesn't involve delivering the best possible product.

      For example, if you don't get paid for longevity, providing it is going to cost you. For example, if you bid for some government contract but aren't required to do the long term maintenance, you may well choose tools that let you get the job done quickly and cheaply, but for which you know t

  • 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

  • Firework? (Score:3)

    by danomac ( 1032160 ) on Wednesday October 23, 2013 @02:07PM (#45214715)

    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 librari
  • 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.

    O

  • How To: (Best Guess) (Score:5, Interesting)

    by snadrus ( 930168 ) on Wednesday October 23, 2013 @02:32PM (#45215081) Homepage Journal

    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.
        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 /proc sources of the C API wrappers source from.

    • Step 5:
      Frameworks usually have no standards.
      They are single entities like Qt or Wt or zApp or even MFC.

      The C library etc. is a library hence the name, and not a FRAMEWORK.

      Your Step 3 makes pretty clear, you don't know what a framework is.

    • Re:How To: (Best Guess) (Score:5, Interesting)

      by radtea ( 464814 ) on Wednesday October 23, 2013 @06:20PM (#45218137)

      Step 5: Model Linux's ecosystem: standards win since they're multiply-implemented.

      I'm surprised there hasn't been more mention of standards here, although I've had variable success with standards myself, and good success with open non-standard systems.

      Good chioces: Qt, VTK, OpenGL has been extremely long-lived.

      Mediocre choices: XML, wx (I moved to wx from Qt when TrollTech went insane over licensing, but have been slowly migrating back in recent years as wx support has decayed on platforms I'm interested in.)

      Bad choices: XSLT, VRML

      I still use XSLT for some stuff, but VRML was a mistake. Apparently you should stay away from four-letter-acronyms.

      Summary: although I prefer standards over non-standards, open vs closed is the fundamental divider between good vs bad bets. Not everything open will survive, but nothing closed will.

  • My Criteria (Score:5, Insightful)

    by cowdung ( 702933 ) on Wednesday October 23, 2013 @02:36PM (#45215143)

    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.

    • 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.

  • 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 shoul

  • From the Apache Flex [apache.org] 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 [apache.org] project, that

  • 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

  • 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.

  • Large, old, widely-adopted open source projects. (Score:5, Insightful)

    by Lendrick ( 314723 ) on Wednesday October 23, 2013 @02:54PM (#45215453) Homepage Journal

    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.

  • one possible indicator (Score:4, Informative)

    by DriveDog ( 822962 ) on Wednesday October 23, 2013 @02:55PM (#45215457)
    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).

  • 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.

  • 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

  • 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.

    • Mod parent up. I have made the same experience ( and have seen other software architects make identical experiences ) over and over again. No-SQL frameworks against Oracle or MySQL RDBMS products. Open programming languages vs. "product" ( proprietary ) languages. Products, as TFA so well describes Flex with calling a duck a duck, vs. frameworks ( Qt ). I am currently looking for a security solution for what is gonna be a server-side piece of software. I will never, never ever ever, choose a product for t
  • 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

  • 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 o

  • Devil is in the research (Score:3)

    by MillerHighLife21 ( 876240 ) on Wednesday October 23, 2013 @04:06PM (#45216525) Homepage

    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
    Python has Django .NET has MVC
    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.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close