Impact of generating APP with Sencha CMD or not to do it?

Question

I'm just using ExtJS this way:

index.html:

<script type="text/javascript" src="extjs/ext-all.js"></script>   
<script type="text/javascript" src="extjs/classic/theme-gray/theme-gray.js"></script>
<link rel="stylesheet" type="text/css" href="extjs/classic/theme-gray/resources/theme-gray-all.css">

And generating my main screen:

Ext.create('Ext.tab.Panel', {
           plugins: 'viewport',
           items: [ tab01, tab02 ],
           renderTo : Ext.getBody(),
           listeners:{
                afterrender:function(){
                    // Do some post init routines...
                }
            }              
}); 

And I have some Javascript files containing all elements of each screen: Model, Windows, Store, Grids or Panels. All together in same file representing a screen semantic. I just find this way more easy to mantain the code representing each functionality.

I see nothing wrong with generating app by using Sencha CMD, but the app folder structure, even clean and keeping things in its place, grows too much and makes me spend some time to search code.

I need to know if generating app by using Sencha CMD is just a religion or I'll sufer in pain later if not do it.

Answer 1

Okay - this is somewhat of a subjective opinion, but here goes.

1) You will get in trouble later if you don't generally go along with the Sencha CMD structure. If your application is more than a single page/view, that is. If you stay on a single dialog, no SASS customisations, and generally not getting complicated, you won't see those problems. As your app grows - particularly if you start needing to share code between screens, such as models, you'll start to feel pain from this simple approach. And if you need to support mobile devices, you'll need to move away from this.

2) Even within the Sencha CMD structure, you can still group related classes in a single file, particularly if it's internal detail to the main class. For example, I nearly always define my ViewController and ViewModel classes in the same file as the View they are for. I often define new widgets in the same file as the View that renders them - breaking them out if they get more complicated or if I want to re-use them elsewhere. My only cardinal rule here is to never 'require' a class that's defined in this fashion.

3) With any such approach, a strong recommendation is to refer to your classes by aliases, not by the direct class name. This makes re-organising your code base easier - you can move and rename classes, and all you have to do is fix your 'requires' statements.