Read the License Agreement
The license agreement changed a few times early in the life of ExtJS, and can be restrictive depending on how you intend to use the product. The Sencha licensing FAQ site does a good job explaining the specifics. https://www.sencha.com/store/licensing-faq/
Use Sencha CMD
Several tools that are packaged with ExtJS require the app to be organized in a specific way. It is possible to use a custom directory structure for your application, but it can be a maintenance concern in the long term as the framework matures and is upgraded. For instance, in the last two upgrades, 4.0->4.1 & 4.1->4.2, the expected structure of the app changed significantly as new tools and concepts are introduced. The example that comes to mind in the last upgrade was the introduction of packages. Starting your project by creating an app using the Sencha CMD tool, and then using it to upgrade the app (which then is responsible for changing the app’s directory structure, if necessary) can be a major time saver.
Not only do they give you conveniently named accessors for view elements to use in place of lengthy dom queries, but they give you a level of abstraction – limiting references to a potentially changing UI/DOM to one place, and saving the price of continual DOM queries by holding references to DOM elements.
Use the framework to build your UI, don’t build a UI and then try to use the framework
Don’t fight the framework. If you’re working with a UI/UX person, be sure they are at least familiar with ExtJS and have read through the examples. Building interfaces using ExtJS constructs as the building blocks instead of building an interface and forcing the framework behind it can save a lot of time and go far in managing the expectations of users.
Be sure you know which browsers you’re supporting and test in all of them
Extend base classes, do not edit them
Occasionally, there will be the need to tweak how base classes function to suit your needs or to make up for default functionality that changed between versions of the framework. To save yourself from upgrade pain in the future, use Ext.override (http://docs.sencha.com/extjs/4.2.1/#!/api/Ext-method-override) and change only what you need to change and only where need it. This will prevent any undesirable behavior in places where the out of the box functionality does suit your needs, and/or where it is used internally by the framework.
Do not be afraid to dig into the source
You will see cryptic error messages, and sometimes they’ll originate from Ext files rather than those of your app, especially if they happen while the app is starting up. Learning how to navigate the source while debugging and also from the API docs is a great help. The source is obviously the truth for what is happening in the framework, but also serves as a great location to find implementation examples that you can use in your app.
In our application, we have only one source of consistent performance issues in ExtJS – data grids. The main thing to keep in mind is the amount of time it takes to render the full width and height of the grid. If you need to load a lot of data in your grid, limit the amount of data that is rendered by using the buffered renderer plugin (http://docs.sencha.com/extjs/4.2.1/#!/api/Ext.grid.plugin.BufferedRenderer). Also, try to limit the number of columns in your grid either by not displaying them at all, or by allowing the user to configure what is displayed. Both of these will help prevent unnecessary rendering of off-screen elements when the grid is rendered and re-rendered (for instance, when the window is resized).
Learn to read the API docs
The ExtJS API is quite rich, and learning how to read the API will help you be productive every day. The docs are presented in a very slick way, and allow you to quickly search for classes, filter elements within a class, view the source from any listing in the API doc, and they include working examples.