Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Unknown Lamer posted 1 year,2 days | from the common-lisp-is-forever dept.

Programming 227

First time accepted submitter waslap writes "I have a leading role at a small software development company. I am responsible for giving guidance and making decisions on tool usage within the shop. I find the task of choosing frameworks to use within our team, and specifically UI frameworks, exceedingly difficult. A couple of years back my investigation of RIA frameworks lead me to eventually push for Adobe Flex [adobe.com] as the UI framework of choice for our future web development. This was long before anyone would have guessed that Adobe would abandon the Linux version of Flash. I chose Flex mainly for its maturity, wealth of documentation, commercial backing, and the superior abilities of Flash, at a time when HTML 5 was still in the early stages of planning. Conversely, about 15 years ago I made a switch to Qt for desktop applications and it is still around and thriving. I am trying to understand why it was the right choice and the others not. Perhaps Qt's design was done so well that it could not be improved. I'm not sure whether that assessment is accurate. I cannot find a sound decision-tree based on my experiences to assist me in making choices that have staying power. I hope the esteemed Slashdot readers can provide helpful input on the matter. We need a set of fail-safe axioms" Read on for more context.The backing of Adobe, an industry giant, gave me what I later discovered was a false sense of security. I thought that the Flex framework would not get lost in a back alley like so many open source projects. We invested heavily in Flex and were disillusioned a couple of years later when Linux support for Flash was ended. (Linux support is vital for us for reasons outside this discussion.)

I had evaluated Adobe Flex alongside OpenLaszlo, which at the time had the ability to use a DHTML back-end instead of Flash with the flick of a switch. In retrospect, this alone apparently made it a better choice in the long run regardless of its flaky state when I first looked at it.

A similar scenario arose with CodeIgniter, which we chose for getting away from classical spaghetti PHP. CodeIgniter was recently dropped after we've invested a Tesla Model X worth of money into using it. (EllisLab Seeking New Owner for CodeIgniter.)

I am standing at a cross-roads once again as people are pushing Laravel [laravel.com] for PHP, and giving other suggestions. I am scratching my (sore) head and wondering how to prevent eventual failures in the future. It seems there is no way to predict whether a tool will survive.

Even in retrospect, when I consider my decision-making processes, everything was reasonable at the time I made the choices, yet some turned out to be wrong.

Sorry! There are no comments related to the filter you selected.

IE6 (5, Funny)

ArhcAngel (247594) | 1 year,2 days | (#45214089)

That thing will be around FOREVER!

Re:IE6 (4, Insightful)

homey of my owney (975234) | 1 year,2 days | (#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 (3, Interesting)

tepples (727027) | 1 year,2 days | (#45215733)

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:IE6 (3, Insightful)

mwvdlee (775178) | 1 year,2 days | (#45215461)

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

Re:IE6 (2)

RavenLrD20k (311488) | 1 year,2 days | (#45215621)

Kinda like "Death by snu snu".

Open source survives (1)

Anonymous Coward | 1 year,2 days | (#45214113)

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.

Re:Open source survives (4, Insightful)

Anonymous Coward | 1 year,2 days | (#45214193)

Thanks captain obvious.

Most folks who want to use a framework have no interest in forking or taking over the project. They want something that works that they can use to save them time. Writing your own from scratch, or maintaining can be a lot of work. That's why some folks are willing to pay for a framework. They defray the cost by only paying for a small portion of the development cost that's shared with others.

If they can pay someone in-house to fork/maintain, they can probably afford someone to write a customized framework that fits their use-case better than a generic one from either an open or closed source provide.

Re:Open source survives (2, Insightful)

Anonymous Coward | 1 year,2 days | (#45214241)

Capttain Obvious (GP) here...

You don't have to do it yourself, just piggyback on somebody else who takes over the project.

Look at what happened when Oracle lost interest in OpenOffice, or when they started to do weird things with MySQL.

Re:Open source survives (1)

LurkerXXX (667952) | 1 year,2 days | (#45214305)

Sometimes no one else takes over the project.

I refer you to Sourceforge. There are a lot of projects on there that haven't been touched by anyone for a long, long time.

Re:Open source survives (2)

MightyYar (622222) | 1 year,2 days | (#45215497)

But, for the most part, those are small projects which are unlikely to have won the submitter's approval in the first place. His other examples were giant projects like Qt and Flex. You can bet that if Adobe open sourced Flash, someone would maintain it for Linux.

Re:Open source survives (1)

Grishnakh (216268) | 1 year,2 days | (#45214381)

Most folks who want to use a framework have no interest in forking or taking over the project. They want something that works that they can use to save them time.

Right, but if that framework gets dropped later, you're going to spend a LOT more time trying to switch to another framework than you ever saved by adopting the framework in the first place. So maybe you shouldn't even bother with the framework unless it's a sure thing.

Finally, even if an open-source framework gets dropped, that doesn't stop you from using it. You can keep using the most-recent release of it, indefinitely, or until you're ready to make a change to something better. You can also maintain it yourself (which would only consist of bug-fixes), which again is surely less time than you'd need to invest to switch to something altogether different.

Finally, this guy's big problem wasn't with a framework per se, it was in adopting Adobe Flash (not Flex; they just needed that to create Flash sites). That's quite different from frameworks because it relies on clients/customers/visitors to have Adobe's Flash plug-in installed on their system, which of course is a problem on Linux systems (which apparently is very important for his business for some reason). Anyone should have seen this coming; you can't rely on a proprietary client program on Linux for web browsing, and Flash on Linux has always been a giant problem. Yes, HTML5 wasn't ready at the time, but that just means you have to make do with less or be happy with a site that doesn't have so much "flash". It's no different than targeting Active-X; you're at the mercy of MS there to keep supporting it for everyone's client system, something that obviously didn't happen and is causing massive problems with web apps developed with Active-X.

When you want something to have real longevity, you can't target the cutting edge; you have to target the lowest common denominator, and stay farther behind in technology.

Re:Open source survives (1)

fast turtle (1118037) | 1 year,2 days | (#45215559)

Another mistake in depending on Flash is the lack of ADA compliance. Come on folks. If you're doing any god damn commercial website designwork, then you absolutely have to comply with either ADA rules in the US/EU. Otherwise you'll eventually loose business and end up going under. This means by all means do not depend on Flash or even javascript. If I hit a site that depends completely on either of those technology, then I'm probably never going to return even if you're the only place to get the last twinkie on earth before the zombies get me.

Whither Chatroulette? (1)

tepples (727027) | 1 year,2 days | (#45215837)

How should cross-platform web-based video chat applications have been made without Flash Player? Support for getUserMedia isn't even 50% yet [caniuse.com] .

Re:Open source survives (1)

Sique (173459) | 1 year,2 days | (#45215785)

But the problem is that then the original task of the framework to provide a high level interface to often used tasks and to abstract from the actual platform is also limited to the moment the framework gets abandoned. Any later development, any necessary adaption to emerging new platforms or to changes in the current platform are out of reach with the framework. Thus you are stuck with more and more outdated platforms you are supporting.

It's the same reason some shops still have to support Windows 98 or WinNT 4.0, because some important software was developed using a framework whose development was abandoned around 1999, and there is no replacement yet.

Re:Open source survives (1)

turbidostato (878842) | 1 year,2 days | (#45215049)

"Most folks who want to use a framework have no interest in forking or taking over the project."

Unless really needed.

There.

"If they can pay someone in-house to fork/maintain, they can probably afford someone to write a customized framework"

Bullshit on itself and bullshit-plus once you consider the hidden costs and hindrances of such a decision.

Re: Open source survives (1)

Anonymous Coward | 1 year,2 days | (#45214251)

Agreed, with one caveat: widely adopted open source projects survive, because eventually they get too big to fail.

Re:Open source survives (2)

Melkman (82959) | 1 year,2 days | (#45214721)

But that depends on other parties with the will and capabilities to support the framework having an interest. Being open source definitely is an advantage but by no means a guarantee a project will survive. Sturgeon's law applies to open source software just the same as to proprietary software.

The request of the submitter for a fail-safe set of axioms can never be answered. With fail-safe systems tending to fail by failing to fail safe. But with common sense a few indicators of long term viability are easy to give:

1) Who controls the software ?
If it is a single party chances are good it will be abandoned at some point in the not so distant future. Open Source can help with this point but as said earlier it is no guarantee. There are many open source projects which are for all practical purposes developed by a single company. These projects are just as likely to be abandoned as commercial software.

2) Who uses the software ?
The more people use the software the less likely it is it will be abandoned. For commercial proprietary software a big user base means income and companies are not in the habit of slaying the goose that lays the golden eggs. For open source software it means there is a bigger potential pool of contributors to continue development if a main developer exits the project.

3) How long has the software existed ?
New software is continuously written and released. Again according to Sturgeon's law 90% will be crap. It will take a little while before the writers realizes their software belongs to this majority and stop supporting it. The longer software has been actively developed the less likely it is to be crap and discontinued.

4) What was the motivation for creating the software ?
If the motivation is a specific goal other than meeting the needs of the users expect the software to be abandoned if it becomes clear that the goal is unrealistic. If the goal is met the software might be continued. Think about lock-in strategies and subverting standards in this regard.

The choice for Adobe Flex had issues in at least point 1, 2 and 3.

Not on closed source devices (2)

tepples (727027) | 1 year,2 days | (#45215861)

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.

Write your own! (5, Insightful)

Anonymous Coward | 1 year,2 days | (#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! (4, Insightful)

JustinKSU (517405) | 1 year,2 days | (#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:Write your own! (1)

rsborg (111459) | 1 year,2 days | (#45214745)

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 outside the company).

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) or c) you never plan on leaving that employer.

Even with option (a) above, if I decided later on to join a company, I've found employers very resistant to licensing my IP (or buying it) - almost all the employment contracts indicate that if I do own such IP, that an agreement exists that any use/licensing is not authorized. Sure, if it's open-sourced, it's easier to get employers to adopt it, but again, I've never been in a position where I've either been allowed to open-source my work or had time outside of work to develop it independently.

As a contractor (1)

tepples (727027) | 1 year,2 days | (#45215907)

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:Write your own! (1)

miketheanimal (914328) | 1 year,2 days | (#45214761)

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.

Re:Write your own! (1)

crazyaxemaniac (219708) | 1 year,2 days | (#45214841)

I agree in that a pure framework is just a design pattern and that would be easy to implement. The really useful part of these frameworks is likely the libraries they are bundled with. Sure, somebody with the right experience can duplicate all the work of another person but there's obviously the problem of the duplicate of effort and the waste of time. In the case of code that have many users it is also benefiting from the experience of a large community. If the framework/library is open source there's really nothing preventing you from become familiar with the parts of the code you use. When it comes down to it I don't think it's really a matter of developer experience so much as the time it takes to learn another person's code and managing the risks of that external code changing. Really it seems there are benefits to each approach but certainly there are many benefits to using community developed code.

Re:Write your own! (0)

Anonymous Coward | 1 year,2 days | (#45214845)

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.

Ahhh ... how much fun it would be to be so young and dumb again.

Re:Write your own! (-1)

Anonymous Coward | 1 year,2 days | (#45215207)

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.

Ahhh ... how much fun it would be to be so young and dumb again.

(From the original AC on this thread.)

I'm 46 years old and my business card says "CTO". You are clearly not the guy/gal I would hire.

Re:Write your own! (1)

angel'o'sphere (80593) | 1 year,2 days | (#45215381)

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 evaluating other frameworks.

Hint: 90% of the stuff on the internet with the phrase "framework" in them are no frameworks but simply fancy class libraries.

does it have to be PHP? (0, Offtopic)

js_sebastian (946118) | 1 year,2 days | (#45214139)

Maybe one reaosn PHP framworks come and go is how broken the underlieing language actually is and just how much a framework needs to do to compensate for that, leading almost to a new language that therefore needs a very big community to even survive.

For comparison of how simple a framework can be when the underlieing language is sane, just look at python flask. Not that i'm saying that's the solution to your particualr problem.

Practical answer (5, Insightful)

micahraleigh (2600457) | 1 year,2 days | (#45214163)

Whatever shows up (significantly) on the hiring boards.

Re:Practical answer (4, Insightful)

Sarten-X (1102295) | 1 year,2 days | (#45214719)

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.

Re:Practical answer (1)

gstoddart (321705) | 1 year,2 days | (#45215603)

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.

Open Source (0)

Anonymous Coward | 1 year,2 days | (#45214173)

Avoid vender locking as well as corporate politics.

A problem not only for web apps. (1, Interesting)

TheManInTheMoon (1495657) | 1 year,2 days | (#45214177)

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.

Re:A problem not only for web apps. (0)

Anonymous Coward | 1 year,2 days | (#45214419)

I have always felt that C#/.Net was not going to be around for long, and it seems I was right.

Care to back that up at all? Because I've seen zero evidence you are correct on that one.

Re:A problem not only for web apps. (0)

Anonymous Coward | 1 year,2 days | (#45214465)

Dude, you're SERIOUSLY behind the times with your opinion about HTML5/CSS3/Javascript. Welcome to the new millennium... about 13 years late.

http://www.youtube.com/watch?v=BV32Cs_CMqo&feature=youtu.be
http://alteredqualia.com/canvasmol/#Ethanol

Whole C++ engines/frameworks have been ported to javascript with tools like Emscripten. The browser javascript engines in use today are optimized to the point that you're getting near-native performance (http://asmjs.org/spec/latest/)

JS is running on both the client and the server these days. Honestly, there's very little left that you couldn't do with javascript. You could probably implement an old-school RDBMS in it now-a-days, but who'd want to? RDBMS's themselves are becoming old news.

Re:A problem not only for web apps. (1)

viperidaenz (2515578) | 1 year,2 days | (#45214971)

RDBMS's themselves are becoming old news

I know right! RDBMS is not Web Scale!

Re:A problem not only for web apps. (1)

Blaskowicz (634489) | 1 year,2 days | (#45215685)

Nice Unreal tech demo (your first link). But :
- it's probably running on a 4GHz Intel CPU, we don't all have that.
(there are little pauses too, relatively short and infrequent)
- Firefox singletasking. Do anything else in the same browser instance and stuff will get slow and annoying. As an end user you need to juggle with profiles with "firefox -p" and reconfigure stuff from a blank profile. And well I'm trying it with firefox already open, doesn't work, it opens a new window and not a new instance (even with ssh -X localhost. I have to ssh from another machine)
- How much memory does that use? Launching heavy stuff on a 32bit firefox that already uses over 1GB will fail.
- Everything is written in C++ and stuff, then compiled in a restricted javascript subset. So, Javascript/HTML/CSS is great! Just don't use any Javascript, HTML or CSS feature.

In effect it looks like kind of running a program that targets the JVM in your browser, but without needing the Oracle plugin and with different limitations. And you still.. a framework to build your application in.

That said I'm devil's advocate here, it's impressive stuff. For one thing it'll be useful on Firefox OS devices.

Re:A problem not only for web apps. (1)

gl4ss (559668) | 1 year,2 days | (#45214485)

but c# is around still.. metro and wp.
qt ain't bad and is going to be somehow, through some way, usable for a long time.

I just choose the toolkits based on what I have to use, so qt was used when it had to be.. and avkon when it had to be..

point being, don't get as a person married to a toolkit.

Re:A problem not only for web apps. (0)

Anonymous Coward | 1 year,2 days | (#45214491)

I have always felt that C#/.Net was not going to be around for long, and it seems I was right.

What makes you say that? .NET has been around for over a decade now, and I don't see any sign of it going away any time soon. There's a gradual shift from WinForms to WPF, but hardly an overnight break.

Re:A problem not only for web apps. (1)

interval1066 (668936) | 1 year,2 days | (#45214631)

There was nothing plainly broken about Qt under Nokia, at least from anything I could see, and its still the only truly cross-platform gui framework around for native applications. As for the web, I would bet on RoR, at least for the forseeable fututre. For mobile apps, well, That's going to be interesting. HTML5 seems like the way to go, not even Qt for Android seems usable to me right now. But the OP has a point, its a difficult situation. Best thing to do is pick one and be prepared to maintain it yourself, hopefully its a foss angle.

Re:A problem not only for web apps. (1)

scorp1us (235526) | 1 year,2 days | (#45215439)

Qt has only gotten freer.
GPL - Trolltech
LGPL - Nokia
LGPL - Digia

Nokia kind-of had a negative affect in that desktop stagnated why mobile was developed, but now that Digia is in it, desktop will be the focus again.

You will be happier switching to Qt. I started my professional career as MFC, but quickly found and liked Qt. It's API is so much better. Even if you are onyl targeting desktop, it makes sense. There are a few caveats though. Qt is notoriously bad at servers - web servers. TCP servers are ok. But there doesn't exist a web server in Qt proper. LibQxt (Qt extension library) has one though, that is pretty good.

What is the future of the product? (3, Interesting)

kawabago (551139) | 1 year,2 days | (#45214185)

Choose the framework that supports, or can be extended to support, planned features of the product.

Re:What is the future of the product? (1)

Pino Grigio (2232472) | 1 year,2 days | (#45215775)

Perfect answer. Please mod this guy up ^.

Choice is good. Lock-in is bad. (0)

Anonymous Coward | 1 year,2 days | (#45214187)

If there's something that will handle swapping out components (like your OpenLaszlo example), then it will by any measure be more resistant to a dying vendor's abandonment. Go for things that provide the most flexibility and choice.

And on the other side of the coin, if there's a vendor that is going to lock you in to a single One True Way, then they and their products should probably be avoided. A vendor's history is good to know, but not always reliable. Adobe's history would've shown a red flag, as they've dropped popular products at a whim before. A counter-example might be Microsoft's handling of .Net. While they haven't always had a clear roadmap, they've never threatened its overall survival, nor have they locked unapproved, unofficial, or competing libraries out of that ecosystem.

But in the end, setting an "offical", "supported", or otherwise "blessed" One True Technology For All Time is going to fail. Perhaps you should focus on becoming more flexible yourself, making informed decisions about new technology between projects or at periodic intervals instead of using the wrong tool for a job or hanging on to something long past its prime.

Hindsight is 20/20 (5, Insightful)

nitzmahone (164842) | 1 year,2 days | (#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.

Forever (0)

Anonymous Coward | 1 year,2 days | (#45214235)

Is "being around forever" the most important criterion? The first thing I would do is question the validity of your premise. The second thing I would do is say this is an interesting question regardless.

Are you sure you should be targeting the web? Maybe you should make the interface component a very thin abstraction, and build all of the intelligence elsewhere, where you're less subject to the whims and vagaries of the most volatile discipline in the IT industry.

Answer: Don't. (0)

Anonymous Coward | 1 year,2 days | (#45214237)

Just raw dog it. You'll have more control, develop more expertise with the language you are making your application in, and you won't become dependent on a third party for updates/support.

I feel sorry for people who feel like they can't touch Javascript without jQuery, or feel they need a PHP PEAR extention instead of just writing in the functionality themselves.

Apache Flex (1)

atom1c (2868995) | 1 year,2 days | (#45214249)

Apache Flex (available at http://flex.apache.org/ [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).

It isn't about PHP (1)

Anonymous Coward | 1 year,2 days | (#45214269)

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.

Qt (5, Insightful)

BreakBad (2955249) | 1 year,2 days | (#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.

All roads may run ill... (5, Informative)

OmniGeek (72743) | 1 year,2 days | (#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... (5, Interesting)

superflippy (442879) | 1 year,2 days | (#45214681)

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.

open source is a factor (1)

DdJ (10790) | 1 year,2 days | (#45214329)

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

First (3, Funny)

Billly Gates (198444) | 1 year,2 days | (#45214335)

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.

Re:First (1)

angel'o'sphere (80593) | 1 year,2 days | (#45215471)

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.

Desktop vs Web (0)

Anonymous Coward | 1 year,2 days | (#45214341)

The chances of an API or framework surviving X number of years severely diminish when it's something oriented solely or mostly towards the web (or languages used mostly for the web). Past that, I think it's good to generally look for a.) open source b.) functioning versions on multiple platforms c.) answers for common questions even if you already know the answer, as a measure of ability to find help when you have a problem.
 
Sometimes closed source is the answer, but you have to head into it acknowledging that bugs will likely not be fixed, the framework may be changed capriciously at any time, and all development could stop at any moment regardless of the relative popularity of the framework. I don't work on traditional client/server systems, so this may not be practical, but generally if I'm going to use a private API/framework, I'm going to wrap it with my own framework that is designed closer to what I really want. This costs more development time in the beginning, but has saved me tons of work over the years and the whims of other companies cause them to make seemingly pointless large-scale changes to add a few small bits of functionality.

Two things (1)

Anonymous Coward | 1 year,2 days | (#45214349)

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.

Tracking the Scene (1)

Joe Hare (3407133) | 1 year,2 days | (#45214389)

Part of picking libraries/frameworks is staying up-to-date on how things change over time in the community for that language/platform. Getting a feel for the trends and how the current trends compare to previous ones will help you make this decision.

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
  • Is it backed by a recognizable/reputable company?
  • Is anything good written in it that you've used?
  • Is there paid support? Not that you'll use it, but are there humans somewhere that will claim responsibility for this product?

You're at the whim of the owner. It's political. (0)

Sarusa (104047) | 1 year,2 days | (#45214409)

Sadly, this isn't a technical question, it's a political question. You've got the following considerations:
      - Is it a clean, well designed framework with good docs and good support?
      - Can I count on the ecosystem it's designed for surviving?
      - What's the owner's record on this?

Only the first is really technical. In the case of Flex, at the time you couldn't predict that Flash would fall from grace so fast and that Adobe would abandon the Linux version. In the case of Qt, well, there's always a need for embedded device GUIs - but there was a chance that after Nokia bought Trolltech it might have ended up being bought and killed by Microsoft when they bought Nokia. Luckily it was already spun off into Digia.

I guess you could collapse this into 'Do I trust the owner?' I don't trust Adobe, so I would have skipped Flex, but on the other hand Flash had a good long run. I know going in that any MS framework like XNA will be obsoleted in a couple years, but will be supported for quite a while at least. I trusted Trolltech, but then they got bought by Nokia - that's the sort of thing you can't really predict.

Bake-off (3, Insightful)

under_score (65824) | 1 year,2 days | (#45214423)

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.

You were (and still are) an idiot. (-1)

Anonymous Coward | 1 year,2 days | (#45214433)

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.

Translation: A couple of years back you were an idiot.

I hope you're smarter now.

This was long before anyone would have guessed that Adobe would abandon the Linux version of Flash.

That's not the reason why you were an idiot a couple of years ago.

I guess you're not smarter now that you were back then.

I'm not going to read the rest of your post, cause you're not going to understand our advice anyway.

Re:You were (and still are) an idiot. (1)

calzones (890942) | 1 year,2 days | (#45214673)

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.

The Only Way (0)

Anonymous Coward | 1 year,2 days | (#45214461)

The only way to pick a framework that will survive is to NEVER USE ONE!

-The End

Flex is a Framework but Flash is a Platform (4, Insightful)

omnichad (1198475) | 1 year,2 days | (#45214495)

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.

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

Dracolytch (714699) | 1 year,2 days | (#45214575)

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.

Tools won't survive. (0)

Anonymous Coward | 1 year,2 days | (#45214955)

"Not so," said Emacs.

Re:Some notes from a seasoned web developer... (0)

Anonymous Coward | 1 year,2 days | (#45215101)

This is good advise. The best predictor of future behavior is past behavior. Pick something that already is widely used, it will take longer to vanish, and your developer pool will be more experienced.

Flash on Linux of course is the exception to this guideline, but on hindsight, an indicator might have been that Flash on Linux was a port and when it's time to trim the fat, you don't trim your active development platform (Windows).

Re:Some notes from a seasoned web developer... (0)

scorp1us (235526) | 1 year,2 days | (#45215259)

I am in pretty strong disagreement with your advice, bleeding edge advice aside...
MVC separation is ideal but expensive. Either in development time or performance. Today's approach would to be provide a REST webservice as the controller database as the model and a JSON client as the UI

Resist the platform. These change. Do not bother to learn JS beyond he basics. Do not learn jQuery. JQuery is no better than raw JS. I have compared it a number of times, LOC are roughly the same, it's just syntactic sugar. JavaScript, CSS, HTML all change. These changes should not impact you. Your application does _something_ the /what/ is important, not so much the /how/. Look at AJAX - it (XML) was the end-all be-all until JSON came around in a relatively short amount of time. And We're on the cusp of WebSockets. The application developer should not care about the state of the web development. Web development isn't top down, a number of very different technologies have been assembled and I refuse to believe that this is the best application development system we can come up with. 5 very different techs - HTML, JS, CSS, HTTP and MIME are all in constant development. (MIME is old, but what about MIME+xop or MIME+mtom?)

A good platform will isolate you from all that and allow you to work on your application. That's why I prefer Wt (http://webtoolkit.eu) which will isolate you from all that nonsense.

Re:Some notes from a seasoned web developer... (0)

angel'o'sphere (80593) | 1 year,2 days | (#45215615)

While your post makes sense in some way, it makes nomsense in others, e.g. "Don't resist the platform" Sorry, I program in JavaScript regulary. Doing simple stuff in the environment of Java based tools. However I *never* will learn JavaScript properly and I will *never* use it to program anything "cross platform" inside of a web browser.
For that we have GWT etc.

The rest of your post mentioning "tools" etc. makes pretty clear that you neither know what a tool is (hint: make is a tool, or awk ) nor what a framework is (hint: jQuery is no framework)

Re:Some notes from a seasoned web developer... (1)

multimediavt (965608) | 1 year,2 days | (#45215645)

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 know this is more than a one-off project or you are just really a good dev you will want to make sure that the product is as serviceable and extensible as possible, even if you're doing C# or .NET stuff, or Tomcat, or Ruby, things that have been around a while and evolved. Just because it's good today doesn't mean it will still be good five to ten years from now.

You will always have things like deprecation to deal with no matter what. You should be dealing with these framework disappearances in a similar way to you dealing with legacy functions that are no longer supported. As the person making the decisions you should also be doing annual evals and almost constant research into emerging frameworks that may be useful or have more longevity to what you are currently using. In the web world there are few instances where you can rest on your laurels and stick with one framework for long. Things change WAY too fast and you need to account for that going in. The desktop world tends to change at a slower pace to the web and that seems why those frameworks tend to stick around longer. The web is much more buzzword, tech-o-the-day oriented. Keep up or get left behind! Basically, use what works today, but keep an eye on tomorrow with your code structure knowing that in a year or two you may have to retool.

Re:Some notes from a seasoned web developer... (0)

Anonymous Coward | 1 year,2 days | (#45215911)

I agree with pretty much everything said here. Although I like staying with bleeding edge - I just make sure I have that strong separation of concerns to insulate me from the fallout.

Toss of a coin (1)

c0d3g33k (102699) | 1 year,2 days | (#45214651)

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

Thunderdome! (1)

tippen (704534) | 1 year,2 days | (#45214655)

Two frameworks enter, one framework leaves

Twitter Bootstrap (1)

rdsingh (643439) | 1 year,2 days | (#45214683)

Have you considered twitter bootstrap? http://getbootstrap.com/ [getbootstrap.com]

Firework? (2)

danomac (1032160) | 1 year,2 days | (#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".

Use libraries, not frameworks (1)

purpledinoz (573045) | 1 year,2 days | (#45214809)

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.

Re:Use libraries, not frameworks (1)

BitZtream (692029) | 1 year,2 days | (#45215739)

So what is your magical definition of framework versus library? Last I checked, they were the former was just a buzzword for the latter, or perhaps a collection of libraries.

From a practical perspective, saying they are different illustrates how much you don't understand what either is.

Clearly the OP has only himself to blame (0)

ilsaloving (1534307) | 1 year,2 days | (#45214815)

Clearly, it's all the original posters fault. I mean, if only he had taken advantage of his ability to see into the future, then he could have avoided these problems.

But seriously, this is life. S**t happens. The only way to avoid the risk of choosing a failing framework, is to not use a framework at all. But writing everything from scratch can be complete overkill. It really depends on the project.

Heck, even behemoths like Microsoft have been known to put together big fancy frameworks/platforms, only to abandon them later.

Really, the only thing you can do is to follow best practise coding principles, such as making sure your code is as loosely coupled as possible. That way if you do have to make a paradigm shift, you will minimize the amount of effort required to recode.

Personally, when I look at frameworks I look at ones that have *already* stood the test of time. I look around and see all these people going crazy over every latest and greatest thing and I just shake my head. For some reason when it comes to technology, people just assume that new is better, and old is crap. And then you see companies like twitter abandoning their precious ruby on rails platform because the scalability was so bad. Or the London Stock Exchange having to abandon .Net.

Sometimes it's better to stay behind the curve and use stuff that has already proven itself to be stable and long term.

Make sure everyone understands (1)

EMG at MU (1194965) | 1 year,2 days | (#45214879)

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.

I am in your situation and here is what I did (1)

scorp1us (235526) | 1 year,2 days | (#45215021)

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.

How To: (Best Guess) (4, Interesting)

snadrus (930168) | 1 year,2 days | (#45215081)

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.

My Criteria (4, Insightful)

cowdung (702933) | 1 year,2 days | (#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.

Depends (1)

mugnyte (203225) | 1 year,2 days | (#45215153)

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.

Flex is not dead yet (1)

ByteSlicer (735276) | 1 year,2 days | (#45215179)

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 intends to run Flash directly on a JavaScript VM instead of the Flash Player VM.

Qooxdoo (1)

jcdr (178250) | 1 year,2 days | (#45215219)

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.

Adopt, don't Use (0)

Anonymous Coward | 1 year,2 days | (#45215235)

The beauty of Open Source is -- it's Open Source.

Never choose a piece of software over a promise of what they say they will someday do. It's a false promise that can be derailed on their schedule, not yours.

If you choose an open source project, then embrace it. That means that you can track it as it continues development, and gets bug fixes, but if it "suddenly stops", then -- what's the problem? It's always doing what you asked it to do, now what it was promised to do. You have the source code, and you can maintain your own fork.

How long do you maintain the fork? Forever? No, you maintain it until you're sick of maintaining it. Until it's impossible to make it do what you want to do, then you gradually port away, just like everyone else does when they tire of software.

If you go status quo, the biggest risk is that some change in the underlying dev platform make be incompatible with your source base, but that's rare. Even then it may be practical to port to the new development kit, could be some simple syntax changes or build options.

But here's the key point. Something folks in your position seem to miss.

Whenever you choose something, No matter what the glossy lit says, no matter how bright the smile on the sales person, no matter how glowing the revues on the inter webs and blogs, YOU are RESPONSIBLE for ALL OF IT. Not just the features you use, but the whole kit. All that you allow in to your system, you're on the hook for. If you take that responsibility seriously, then you can see the advantage having access to the source code, having the ability to create a reliable build, and having the skill set to go inside and figure out how things work, and possibly even change it.

Up front, you can rely on the vendor, or the community, or Frank, the guy who wrote it on GitHub. But when they're gone, when it's 3am and the phone is ringing, it's YOUR phone, not theirs that's clattering away. So, IMHO, better to be on top of it all as much as possible, have as much access as you can get to chart your own destiny that rely on others.

Not a good track record there.. (1)

FryingLizard (512858) | 1 year,2 days | (#45215359)

You picked Flex _and_ PHP as winners? Damn dude, don't ever go to Vegas.

Write it (1)

Murdoch5 (1563847) | 1 year,2 days | (#45215383)

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.

LOL .... (0)

Anonymous Coward | 1 year,2 days | (#45215451)

I chose Flex mainly for its maturity, wealth of documentation, commercial backing, and the superior abilities of Flash

Then I would suggest you're not the right guy to be selecting frameworks at your company.

Repeat after me ... Flash is shit, and those who choose to use it are morons.

Large, old, widely-adopted open source projects. (4, Insightful)

Lendrick (314723) | 1 year,2 days | (#45215453)

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 (3, Informative)

DriveDog (822962) | 1 year,2 days | (#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).

Framework Fetishism (0)

Anonymous Coward | 1 year,2 days | (#45215493)

I'm witnessing this process at $DAYJOB.

Not UI -- more a back-end thing. A data unification of sorts, for all kind of enterprise data, indexing, yadda yadda.

Instead of thinking about structures, picking up current usage patterns, doing some data architecture, cobbling up cheap prototypes to validate assumptions, folks are all excited thumbing through the Apache Software Foundation catalog as if it were Ikea. Elastic this, Kafka that, Storm there.

Many colorful Lego bricks instead of architecture. Sigh.

My take: keep your designs as abstracted away from the framework as possible. The rest will come.

General rules (1)

comrade1 (748430) | 1 year,2 days | (#45215517)

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.

You deserve problems (0)

Anonymous Coward | 1 year,2 days | (#45215569)

If you are going to use a web browser as a user interface then you deserve every single problem and I hope you choose wrong every single time.

My thoughts on this... (0)

Anonymous Coward | 1 year,2 days | (#45215577)

Choose the best tool for the job and be prepared to support it. Always create a PoC in a few frameworks first when evaluating a new target platform and you should get a feel for the way to go. Unfortunately you can't future-proof something against loss of support, but consider whether it should be brought up to date with a new framework if this happens (echoing previous comments about strict UI separation).

I have been a UI developer for 15 years and have a lot of languages and frameworks under my belt as there has never been a 'do it all' solution which gives the user a perfectly native experience.
Across the products we support/develop, I still come back to the following on a day-to-day basis and would consider new projects using these, too.

Cocoa - Apple desktop
Qt/Gtk - Linux desktop/embedded
C# .Net - Windows desktop/Windows web apps
CI/Node.js - Linux web apps
KnockoutJS/JQuery - Light web client functionality
Dojo - Heavy web client functionality (single page apps and embedded webkit)

I've never experienced mobile phone development, but I get the impression it gets even harder to choose the 'right' platform.
I found this report interesting/educational if a little old now:

http://www.visionmobile.com/product/cross-platform-developer-tools-2012/

-Rob
 

Open your eyes? (1)

BitZtream (692029) | 1 year,2 days | (#45215647)

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.

Flex was dead in the water years ago (0)

Anonymous Coward | 1 year,2 days | (#45215659)

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.

If this was the analysis you did a couple of years ago, you need to re-think your analysis methodology. There is nothing in Flex that justifies using it over HTML + JavaScript + AJAX requests.

Flex has not held a competitive advantage since around 2007-2008. (Prior to that, the only real competitive advantage for it was pixel-precise positioning of elements cross-browser, which was troublesome for JavaScript + CSS at the time. I happened to develop software that required that specific use case.) Once browser compatibility improved, there was nothing stopping us from ditching Flex.

Pick the winning horse (1)

segmond (34052) | 1 year,2 days | (#45215663)

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.

How frameworks survive (1)

scorp1us (235526) | 1 year,2 days | (#45215687)

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)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?