Is it possible to loosely couple an application to its framework?

Loosely coupling your application to its framework essentially means you are going to write a proxy framework. Writing that proxy framework is a lot of work, and if you ever switch to a new framework you'll have to do a lot of work to make the proxy framework support the new framework. Of course, different frameworks use different idioms and patterns, which will make the proxy framework either very complex (if you try to make it fit to everything) or very limited (if you go for the lowest common denominator). Either way you'll have to struggle with that proxy framework.

Is having the ability to change frameworks on a whim worth all this trouble? Like I said, you won't be able to change it on a whim because you'll have to adjust the proxy framework, which might turn out to be more work than adjusting the application code directly.

No can do.

You can design in a way that's portable across frameworks. MVC is MVC, and the principles are roughly the same whatever language or platform is used.

The actual code, however, is going to be very framework or language dependent. The only way to abstract yourself from that would be to code based on a intermediate framework. Then you can have the intermediate implementation change (from F3 to .NET ?) without changing the application. Which is a lot of work, assumes non leaky abstractions, and just moves the problem without solving it: you're now tied to your intermediate framework.

On a more positive note: consider expressing some of your tests (BDD style) in a platform independent from your implementation. Those might survive major rewrites.

I once saw Robert C. Martin give a talk where he said something along the lines of "the first decision you make is the hardest one to change later".

So my advice is to try to delay this decision if you're not exactly sure what you want to use yet. Identify pieces that you can define now, and which would easily remain independent of whatever framework you end up using.

Framework lock-in can be a serious issue, but it helps to look at the problem as one of portability. Portability is not an absolute attribute, but relative to your starting point and where you might possibly want to go. By analogy, then, software is portable only in so far as you have already ported it to other environments.

Most of the development of an application inside a framework tends to be glue code, the stuff that binds the components of your framework together. Configuration files may abstract a certain amount of the glue in some systems but a lot of the fine details have to be done in code.

On the other hand, business rules and processes can be abstracted from the application. The hard part of abstraction is when the rules are implemented directly by the framework; security, accessibility and process sequencing tend to be enforced by your framework and may be the hardest to see.

If you can separate the glue portion of your application from the business rule and business process and business data portion, then you will be able to make some portions of your solution portable.