What Ext JS Even Is

You open a legacy internal app - a CRM, an admin console, a trading desk - expecting JavaScript and find a wall of nested objects: xtype this, items that, panel inside tabpanel inside viewport. No HTML to grep for, no document.querySelector, no JSX. And somehow this soup renders a polished, desktop-grade interface that real money depends on.

Nothing here is magic. It's one consistent idea wearing unfamiliar clothes.

Stated once, plainly: in Ext JS you don't build the UI, you describe it. You write a tree of plain JavaScript config objects - "a panel containing a grid and a form" - and the framework reads that description and does the rest: creates the objects, lays them out, renders the HTML, wires up events, manages their whole life. You write the what; the framework owns the how.

📝 Ext JS - Sencha's comprehensive JavaScript framework for data-intensive enterprise web apps: admin consoles, CRMs, trading desks, dashboards. It started around 2006 as an extension of the YUI library (hence "Ext"), grew into a full framework, and is now owned by IDERA - predating React, Vue, and Angular, so it solves the same problems with conventions invented years earlier.

The one big idea: config in, UI out

A minimal Ext JS application that puts a panel on the screen:

Ext.application({
    name: 'Admin',

    launch: function () {
        Ext.create('Ext.panel.Panel', {
            renderTo: Ext.getBody(),
            title: 'Users',
            width: 400,
            height: 200,
            html: 'A panel, built from a config object.'
        });
    }
});

What just happened: Ext.application({...}) declares the app and hands Ext a launch function to run once the framework finishes booting. Inside it, Ext.create('Ext.panel.Panel', {...}) asks the framework to build one component from the config object - pure data: title, width, height, html, and renderTo: Ext.getBody() telling Ext where to drop it in the page. You never wrote a <div>, never touched the DOM. You described a panel and Ext turned that description into real, rendered HTML.

The part that makes Ext feel like Ext: components nest.

Ext.create('Ext.panel.Panel', {
    renderTo: Ext.getBody(),
    title: 'Users',
    width: 500,
    height: 300,
    layout: 'vbox',
    items: [
        { xtype: 'textfield', fieldLabel: 'Search' },
        { xtype: 'button',    text: 'Add user' }
    ]
});

What just happened: the outer Panel now has an items array - its children. Each child is also a config object, but instead of a full class name we used xtype: 'textfield' and 'button' are short nicknames for component classes. Ext reads items, sees each xtype, creates the matching component, and stacks them inside the panel (layout: 'vbox' lays children out vertically). Scale that up - panels inside tab panels inside a viewport - and you have the entire UI of a legacy app.

💡 The mental shortcut for reading any Ext JS file: find the outermost config object, then follow items downward like branches of a tree. The shape of the nested objects is the shape of the screen. You're reading a blueprint, not instructions that run top to bottom.

Components, containers, and xtype

Three words the rest of this guide leans on (Phases 2 and 3 go deep - this is the teaser).

📝 Component - every visible thing in Ext JS is a component: a button, a text field, a data grid, a panel, a popup window. All descend from a common base class, which is why they all take config the same way and share the same lifecycle. Container - a component that can hold other components via its items array (a Panel is the classic container). xtype - the short string name of a component class ('grid', 'form', 'button'), used so Ext can create children lazily, only when needed. Components nest inside containers via items; xtype names which one to make.

Classic vs Modern: which toolkit is this codebase?

Ext JS ships in two flavors, called toolkits, and knowing which one you're looking at saves real confusion.

📝 Classic toolkit - the older, mature, desktop-focused widget set. This is where the famous, deeply-featured data Grid lives, along with the dense forms and windows enterprise apps are built from. If you inherited a big internal back-office app, it's very likely Classic. Modern toolkit - built for touch and mobile. Same core concepts - components, items, xtype, stores - but the widget packages differ, so a few class names and options won't match between them.

A codebase picks one (or builds both via Sencha Cmd, the build tool we'll meet later):

// app.json (an Ext JS app's config file)
{
    "name": "Admin",
    "toolkit": "classic",
    "theme": "theme-triton"
}

What just happened: the app.json at the root of an Ext JS project declares the toolkit outright

• your fastest answer. No app.json handy? Class names mentioning Ext.grid.Panel and themes like triton or neptune point to Classic; paths under modern or touch-flavored components point to Modern.

⚠️ Don't mix advice across toolkits. A snippet for the Modern Grid may use config options that don't exist in the Classic Grid, and vice versa. Include the toolkit name in searches - "Ext JS classic grid column renderer" - or you'll burn an afternoon on options that never applied.

Why it feels so different from React

If your instincts come from React, Vue, or Angular, Ext JS will feel alien - knowing why is the fastest way to stop fighting it.

The first difference is config vs. markup. React uses JSX, a template that looks like HTML. Ext JS has no templates and no JSX - you write plain JavaScript objects that describe components. { xtype: 'panel', title: 'Users', items: [...] } is an ordinary object literal. The structure of your data is the structure of your UI.

The second is how much the framework owns. Modern front-end work is "pick your libraries": React for views, plus a router, a state library, a data-fetching library, a bundler - all your choice. Ext JS is the opposite: batteries-included to the extreme. Widgets, layout engine, class system, data layer, charts, theming, even the build tool - all Sencha's, all shipped together. That's why it feels like its own universe rather than a library dropped into a project: it is the project.

💡 New to a framework calling your code instead of you calling its? That inversion of control is shared by every framework - see What a Framework Even Is. Ext JS just takes it further: it owns more of the stack than almost anything else you'll meet.

So when newcomers call Ext JS "weird," they mean: no JSX, config instead of markup, a custom class system instead of plain ES classes, its own data layer instead of fetch plus a state library, slow Java-based builds, and docs that were historically thin and often paywalled. Every one is real friction - but none is chaos. It's a consistent system with consistent rules, and that's learnable.

📝 Where you'll meet it: greenfield Ext JS is rare today - new projects reach for React/Vue/ Angular. What's not rare is maintaining the enormous body of revenue-critical enterprise software already built on Ext JS. That's the job this guide prepares you for.

Our running example: a users admin screen

To keep every phase grounded in something real, we'll build one small feature across the guide: a users admin screen - a table of users on the left, an edit form on the right that fills in when you click a row.

{
    xtype: 'panel',
    title: 'User Administration',
    layout: 'hbox',
    items: [
        { xtype: 'grid', title: 'Users', flex: 1 },   // the list, on the left
        { xtype: 'form', title: 'Edit',  flex: 1 }     // the editor, on the right
    ]
}

What just happened: a top-level Panel lays its children side by side (layout: 'hbox') and holds two components - a Grid and a Form, each taking an equal share of the width (flex: 1). Both are empty placeholders right now. Coming phases fill the Grid with columns, feed it real users through a Store, wire the Form to edit the selected row, and hold it together with Ext's MVVM tools. You can already read the shape of the whole feature, because the config tree is the feature.

Recap

• The one idea: in Ext JS you describe the UI as a tree of plain config objects, and the framework instantiates, lays out, renders, and manages it. You write what, not how.
• Everything visible is a component; containers hold other components via their items array; xtype is the short string name Ext uses to create a component (often lazily).
• Two toolkits: Classic (desktop, the mature widget set with the famous Grid) and Modern (touch/mobile). Check app.json's toolkit to know which one a codebase uses - don't mix advice.
• Why it feels alien vs. React: config objects instead of JSX/templates, and a batteries-included framework that owns the whole stack instead of a library you assemble from npm pieces.
• Where you meet it: maintaining big, revenue-critical enterprise apps - greenfield is rare, but existing codebases are everywhere.
• Running example: a users admin screen (a Grid of users + an edit Form) we'll build across the guide.

Quick check

Three questions on the config-driven model, the toolkits, and how Ext differs from React:

[
  {
    "q": "What is the core idea behind how you build a UI in Ext JS?",
    "choices": [
      "You write a tree of plain config objects describing the components, and the framework instantiates, lays out, and renders them",
      "You write HTML templates with placeholders that Ext fills in",
      "You imperatively create and append DOM nodes with document.createElement",
      "You write JSX that compiles to component calls"
    ],
    "answer": 0,
    "explain": "Ext JS is config-driven: you describe the UI as nested config objects (parents with an `items` array of children) and the framework builds, lays out, renders, and manages everything. No HTML, no JSX, no manual DOM."
  },
  {
    "q": "What does `xtype` mean in an Ext JS config object?",
    "choices": [
      "The short string name of a component class, used so Ext can create the component (often lazily)",
      "An HTML element tag like 'div' or 'span'",
      "A CSS class applied to the rendered element",
      "The unique id of an existing component instance"
    ],
    "answer": 0,
    "explain": "`xtype` is the short nickname for a component class - `'grid'`, `'form'`, `'button'`. Ext reads it inside `items` to know which component to create, and can defer creation until the component is actually needed."
  },
  {
    "q": "What's the main difference between the Classic and Modern toolkits, and how do you tell which a codebase uses?",
    "choices": [
      "Classic targets desktop (the mature widget set incl. the Grid), Modern targets touch/mobile; check the `toolkit` field in app.json",
      "Classic is the free version and Modern is the paid one; check your Sencha license",
      "Classic is written in JavaScript and Modern in TypeScript; check the file extensions",
      "There is no difference - they are two names for the same widgets"
    ],
    "answer": 0,
    "explain": "Both share the same core concepts (components, items, xtype, stores), but Classic is the desktop-focused mature widget set and Modern is built for touch/mobile, so some widget packages differ. The `toolkit` field in app.json tells you which one outright."
  }
]