Why not just use Modern

[TimPigden]

Hi,
My contractor is telling me "classic for desktop, modern for mobile, simple as that".
But I specifically do not need to target legacy desktop browsers (this is a commercial decision).
So is there other reason to use Classic? Do we have feature parity yet?

[mitchellsimoens]

For Ext JS 6.0 and 6.2 yes, I would say modern for mobile. However, 6.5.0's modern changes that. I'm starting work to convert some apps over to modern, in some aspect 6.5.0 modern is better than classic toolkit. 6.5.0 will be released very shortly.

[niallobrien]

This is exciting - will it be relatively easy to go from 6.5 to v7 when it's released? Thanks in advance.

For Ext JS 6.0 and 6.2 yes, I would say modern for mobile. However, 6.5.0's modern changes that. I'm starting work to convert some apps over to modern, in some aspect 6.5.0 modern is better than classic toolkit. 6.5.0 will be released very shortly.

[jvandemerwe]

...in some aspect 6.5.0 modern is better than classic toolkit.

Can you elaborate on that a bit more? I am developing everything with the Classic (desktop) Ext JS and migrating my apps would be a job that could cost me a lot of time. But I am open to developing new ones with the Modern toolkit. What would I miss and what would I gain?

[mitchellsimoens]

One of my favorite things we've done yet isn't a flashy new component or something is moving to object forms of certain configs like plugins like:

plugins: {
    gridcellediting: {
        triggerEvent: 'tap'
    }
}

We've been trying to move internal code to use this as it's great for merging the objects for when you extend a class and you want to configure some configs within that object. Prior, if it was an array of objects, you'd have to duplicate the object in it but now it's as simple to add/change configs within it. Of course the "old way" is still valid:

plugins: [{
    type: 'gridcellediting',
    triggerEvent: 'tap'
}]

but that's not easily changed when you extend, the old way is an override instead of a merge. I know, this change isn't a reason to use modern over classic, it's actually just something I really love and we are looking at other opportunities to do the same thing.

Another change I love is what we're calling "standard buttons" which is on Ext.Panel. Just like the object form of plugins, you can define buttons on a panel to an object where the key is a name of a standard button and the value is the callback (can accept a string to resolve on a VC):

Ext.Viewport.add({
    xtype   : 'panel',
    title   : 'Standard Button Example',
    buttons : {
        ok     : function () {},
        cancel : function () {}
    }
});

And the buttons are "weighted" meaning on a Mac the buttons will be ordered as Cancel Ok but on anything else like windows it would be Ok Cancel, this mimics native platform button orderings. For more on this, visit the standardButtons docs.

Ok, nothing to make you move over to modern yet.

How about classic's action column? It's been an important component in classic for years but Sencha Touch and therefore modern toolkit hasn't had anything similar. This was a surprise by Don as instead of just keeping the same functionality, he decided to make it so much better.

Each cell can have tools and are bindable also: http://examples.sencha.com/extjs/6.5...ern#grid-tools

Not only can each cell have tools, group headers can aswell: http://examples.sencha.com/extjs/6.5...idheader-tools

So cell and header tools are a better concept that just a single action column but are not api compliant with classic. We aren't going out of our way to separate the api but since there hasn't ever been an easy transition between the toolkits we are taking the opportunity to improve the api since a lot of it we aren't actually breaking anything, modern toolkit got a lot of new features.

Ok, cell tools are neat but still not making you move over?

Excel is a great program that's been around for centuries. One feature of Excel that many use is the ability to drag the selector to copy values to the newly selected cells. Modern has that: http://examples.sencha.com/extjs/6.5...selection-grid Select a cell and drag the selector in the bottom-right of that cell down as many rows as you want and notice the value copied to those cells. This example by default only allows for y axis dragging but you can enable x axis or both to be draggable.

Layouts have always been CSS based in modern which javascript around just to manage the CSS styles since Ext JS is very javascript config based. This is nothing new but is worth mentioning since classic is largely javascript based meaning there is lots of calculations done by classic on each layout reflow that in modern the browser can do much faster.

The drag and drop functionality in classic has been largely unchanged for many years, it works and it works great. Modern got a big drag/drop upgrade including HTML5 file drop from your computer to browser: http://examples.sencha.com/extjs/6.5...dern#drag-drop The implementation in modern's drag/drop is a much simpler design and to be fair is actually in the core package which is shared between the toolkits but classic has some plugins that use classic's drag/drop functionality not the new one so I still mentioned it here.

There are more, I haven't taken the time to compile an exhaustive list as we are working hard to get 6.5.1 out very soon with 6.6.0 starting very soon also.

Two big reasons to stick with classic would be accessibility and locale. Modern doesn't have 100 parity with classic so depending on what your app needs, there may be other reasons that you simply couldn't make the move to modern.

[LesJ]

Sencha needs to document performance gains by moving to the modern toolkit. I'm sure there are substantial performance gains (in the grid for example), but they need to be documented.

Improved performance numbers is what what would make a lot of people use the modern toolkit.

[mitchellsimoens]

We actually currently have someone measuring performance and getting a concept of automated measuring working (have a server being delivered for the agent to run on even).

[LesJ]

There are more, I haven't taken the time to compile an exhaustive list as we are working hard to get 6.5.1 out very soon with 6.6.0 starting very soon also.

Is the 6.6.0 release supposed to achieve feature parity between the toolkits or is it still planned for the 7.0 release?

[mitchellsimoens]

tbh I'm not sure what came of the scope meeting, I've been pretty heads down on 6.5.1 to pay attention to that just yet.

One thing that would help, is to make sure features don't slip under the radar. If you find a gap (big or small) then go ahead and open a thread over at in the bugs forum (we can open non-bugs from there too of course). We have done diffs and manually marked some based on api differences among many other things but we are human too

[hakimio]

@mitchellsimoens you forgot to mention that Material design theme currently is only available for modern toolkit.
Anyway, do you know if there are any plans to introduce border layout in modern toolkit?