How to decouple javascript programming from frameworks?

Question

I have one question about Javascript frameworks. I'm using ExtJs on my application, but there are many problems with licensing and such things, so i wonder about this thing.
Is there a way to follow some strategies in developing Javascript so that i could easily switch from one Javascript framework to some other framework?

Answer 1

If you did that, I have a feeling you would have developed your own JavaScript framework. I doubt that's feasible. Better choose one at the beginning and stick with it.

Answer 2

I think it is never really easy to switch entirely from one Framework to another without rewriting most parts of the application. Especially the JavaScript Frameworks are extremely different. I don't really know any realistic alternative to what ExtJS offers (I know they had some licensing issues but I still don't get why commercial application developers are so hesitant to pay the 330 to 1300 $ for what the Framework has to offer. And if you Open Source it you don't have to worry about licensing anyway).

What you should do is to get rid of any JavaScript Framework specific code on the Server side (make the data transfer as generic as possible). This makes it way easier to switch to another Framework on the Client side even though you'll probably have to rewrite most of the codebase there (but only there) (I don't even see an easy way to e.g. just switch from Prototype to jQuery and they are relatively similar to each other). The only JS Framework I know that has a "Library Independent" approach is JavaScriptMVC (you can e.g. switch between native, jQuery or Prototype for underlying functionality, but even they are considering to base it entirely on jQuery for the next relase).

Answer 3

Let me try to blow in some fresh air into the discussion.

The major problem with many Ajax libraries and frameworks is that every and each of them have different (and proprietary as well) API. Moreover different libraries also enable and promote different programming models. This is all indeed reasonable, since there is no API standard that have all features that frameworks have to offer. However many frameworks forget that there is quite a basic API and programming model that lays in the browsers natively - XML (in simple case HTML) for layout, CSS for styling and DOM for scripting. This bundle is not only available from browsers, but also for example in Gecko XUL technology, Flex and Silverlight too.

There is a Javascript GUI Framework that brings that natural programming model back to the hands of developers - Ample SDK. Working with that you can layout your interface in a XML appliance (XHTML, XUL or SVG1.2), style the UI with CSS3-featured rules and still write code against standards-based API DOM (Level 2/3) - all cross-browser.

Having choosen for that approach you can make sure that tomorrow, when browsers have all implemented the basic features (mentioned above) equally good you can reuse lots of application javascript code, since it will then run natively!

Indeed that was part of the story - interacting with the View (although many javascript frameworks and libraries do not draw any line between M, V and C - that is the pain). Coding Javascript application is often way more than just interacting with DOM, and then MVC and PAC code architectures come in place. They have proven their efficiency, they are implementation-agnostic. Pick one implementation (as suggested by Daff - PureMVC, for example) or create your own.