Ext-all.js VS ext-all-debug.js

What is the difference between using ext-all.js and ext-all-debug.js?

Does the change to ext-all.js from debug.js change to performance?

Can we assume that the transition from debugging to a normal file will not have any other effects on the application?

Also, can anyone suggest what ext-base.js is doing?

+4
source share
4 answers

Ext-all is basically a miniature version of the debug version. The profit is that it significantly reduces the size of files so that clients load less. External databases are the main functions of ext. If you are using only the ones that you could just include in this file instead of the huge set in ext-all.

The external site used to have a custom js builder in which you could select only the functions you need, and it would create custom js for you only with these modules

+7
source

There is full debugging so you can debug extjs code. It performs the same operations as ext-all.js. Using ext-all.js will improve performance since the file size is much smaller, so clients can download and access them faster.

The same thing happens with ext-base-debug and ext-base.js. They contain the operations that ext-all.js depends on, for example, Ajax operations. Sharing these files will not affect your application.

Use ext-all-debug and ext-base-debug during development. Switch to ext-all.js and ext-base.js when they are produced.

+5
source

THIS INFORMATION IS CHANGED FOR THESE USES ExtJS4.1.

After implementing and optimizing the application, I liked a lot, it was confused which process was optimal for the "production implementation".

This most recent documentation for this ended up in this Sencha document: http://docs.sencha.com/ext-js/4-1/#!/guide/getting_started

It was hard to determine, but the key for me was step number 3. Deploying the application.

What are these four steps for?

  • cd for root
  • sencha create jsb - this creates a manifest of the classes used. - It can also be modified prior to assembly, if necessary.
  • sencha build - creates two files (all-classes.js, app-all.js) - all-classes.js is not minimal for viewing. - app-all.js is a finished file
  • The setup for prod is the rest included in your production file:
ext-all.css //minified-css, concatenated and dusted is optimal. ext/ext.js //non-debug app-all.js //minified, concatenated, app + framework files (only classes used). 

Hope this helps someone. :)

+3
source

differences between "ext.js" and "ext-debug.js":

  • "ext-debug" is not compressed (or "minified").
  • "ext-debug" does not start through the Cmd optimizer.

These files otherwise contain exactly the same code. In addition, both flyers load the required classes from the src folder. In short, both of these files are designed to support debugging.

To improve performance, to reduce downloads to as many files as possible, you can use Sencha Cmd. something like that
sencha fs minify -yui -from=ext-debug.js -to=ext.js

For Cmd ext 4.2.2 partitions, the doc set is more relevant and you can access dec here

Hope this can help you.

0
source

All Articles