Is Ext well suited for a big and highly interactive application?
I'm evaluating Ext for our project but I think It doesn't suit very well. Please, correct me if I'm wrong:
1)Ext doesn't have data binding or an implementation of observer pattern, so isn't good choice for application whose data change in more complex patterns and require UI to refresh itself to reflex those changes.
2)UI patterns has so many variations that mean something different for each person. But trying to use those patterns names, I would say MVC is not a good pattern for interactive client application that have complex UI logic, something more in the line of MVP is better.
3)Ext UI Components are tightly coupled with not-UI Components. For example, Grid is coupled with Store and Model. We don't need Store and Model, but can't connect our own classes with Grid because there aren't interfaces that define a contract of how Grid interact with data sources.
4)We want our application logic to be independent of Ext. Use our own Model with Ext UI components. With this low coupling, changing the UI components in the future doesn't generate a great impact on our application.
Ext seems to be a whole prescription, not being easy to use each components isolated, permeate deeply in application, to the point of even changing the css style of the whole application.
I apologise that someone in the community has felt the need to vote your post down. You're a bit off the mark in a few places but someone has clearly misunderstood the purpose of the voting system if they think that post deserved a -1.
1. Data binding and observer. The whole framework is based on the observer pattern via Ext.util.Observable. Almost every class fires events, see the docs for the events of each class. Not sure what you mean by data binding. ExtJS uses models and stores as abstractions for the data and the components are bound to them.
2. Not sure exactly what point you're trying to make here. The MVC is a new addition in ExtJS 4 and is very much optional. A lot of developers seem very happy with it though. If you prefer to go in a different direction there shouldn't be anything to stop you other than the time required to write an alternative.
3. Components like grids are indeed dependent on models and stores but this isn't as bad as you imply. For the vast majority of use cases it satisfies the requirements and moving to a contract/interface system wouldn't really be much help. In practice the contract would require you to reimplement pretty much the whole of the store class. Given that, you'd be better off just subclassing the existing classes to modify them as required.
It's a little difficult to speculate about what you mean but in general the idea is that a proxy/reader is used to map a data source into models and stores. It sounds like you may be trying to mix together a load of different client-side technologies into one UI, which is a risky strategy irrespective of which technologies they are. You may find you're trying to push web browser a bit too hard and you're definitely leaving yourself more exposed the more third-party technologies you use.
4. You can use ExtJS in various different ways but the most common way is to write the whole UI in ExtJS, as you suggest. You can use it in little pieces but if you only want bits then you might be better off using a lighter-weight alternative. ExtJS is very well-suited to a 'big and highly interactive application' but you seem to want to use it without using it.