What Is ExtJS ExtJS 4+ Extensions Examples Tutorials


Debugging ExtJS “Layout Run Error”

Recently I had to fix a lot of "[E] Layout run error" errors in an ExtJS 4.2.0 app. While I like to think I know ExtJS layouts fairly well and consider them one of the best parts of ExtJS, this experience has shown me a "darker" side of ExtJS layouts. When you're dealing with many (10+) layers of Containers, it seems there exist many unpredictable combinations of layouts that will result in "[E] Layout run error" in console, sometimes with functional implications, and other times without. Sometimes the smallest things can cause this error; i.e. I had a configuration setting on a Container:

style: { height: '54px' }

...and while everything looked and functioned correctly, a "layout run error" was being logged; changing the configuration to an explicit height solved the issue:

height: 54

The following 2-step approach has worked for me in systematically resolving numerous of these layout run errors:

VN:F [1.9.22_1171]
Rating: 10.0/10 (4 votes cast)

Old Versions of Sencha CMD

Sencha CMD is a must-have if you're doing any professional ExtJS or Sencha Touch app development. You can always get the latest version from Sencha's product page, but what if you wanted to get an older version? Sure, upgrading to the latest version is an option, but we all know how smooth those upgrades can go (or not, especially if you messed with the build scripts).

Older versions with release notes are available via this URL pattern:


For instance:


So, the caveat is that you have to know the exact version which you're after!

VN:F [1.9.22_1171]
Rating: 8.8/10 (5 votes cast)

ExtJS vs. Meteor & React

I've recently been looking into these emerging frameworks and wanted to highlight a few of their interesting features in contrast to ExtJS. This is by no means an objective comparison (and the frameworks are too far apart to really be compared that way), but rather an analysis of some interesting performance-oriented features that are addressing some of the most common performance/load issues associated with large HTML-based web applications like those usually developed in ExtJS.

ExtJS vs. Meteor

Here I got introduced to the concept of "isomorphic". Now this has nothing to do with the "polymorphism" inheritance concept you might encounter in classical programming. In a nutshell "isomorophic web framework" means your new MyPanel() (which results in a few divs of DOM) can be created either on server-side or on client-side. To understand this easily, consider the problem that this can pattern can solve really well: achieving "instant" page load times.

One of ExtJS' "new-school web app" weaknesses is that even in the "smallest possible app scenario" when using standard Sencha CMD builds, even a bare app will come with almost a megabyte of JavaScript. Compare this to the old-school methodology of having the server-side supply the DOM in the initial index.html request ready to roll? The browser was able to render the UI instantly upon loading index.html. By contrast, with ExtJS upon getting index.html you have nothing to show yet (perhaps a loading spinner). Oh no - we're just getting started. Next, we need to load the JS file, parse it, then finally create the DOM and display it on the screen. Any lower-mid grade hardware, even with Chrome, will have a noticeable delay in load time, when compared to the "old school" "DOM up front in index.html" approach.

There are a couple of approaches to alleviate the ExtJS weakness described above; I described "code segmentation" using Sencha CMD in this article: http://www.sencha.com/blog/blazingly-fast-load-times-for-apps-built-with-ext-js-and-sencha-touch/

Now what about Meteor and it's isomorphic capability? I don't know how well it works in practice, but just bear with me as we contemplate this mix of old- and new- school approaches. Imagine that your few divs of DOM for a new MyPanel() were not created after the JS code was loaded, parsed, and executed. Instead, they were delivered as part of the initial index.html payload. So, the initial rendering was instantaneous. The server-side (in node.js) executed new MyPanel() and generated the necessary DOM; then it got included in index.html. While new MyPanel() can still be executed on the client side, the server-side capability can provide instant UI on load. This however, doesn't address any behavioral aspects as those would still require a heavy amount of JS to be loaded. So, even though UI might become available instantly, any attempts to interact with the app too quickly might be met with the same old "loading spinner", until JS resources are ready and available. Still, the "instant UI" capability here is a serious advantage.

Perhaps ExtJS can be implement something like the existing "renderTo" configuration, but called "integrateInto", so you could "assign" a Panel to some pre-existing DOM node that correctly matches the panel's DOM anyway.

ExtJS vs. React

Here I want to explore the "Virtual DOM" concept utilized by React and contrast it with ExtJS' buffered grid. First, let's take it to the basics.

Let's say you have a grid with a "Cost" column, with values like "$5.00". Above the grid you might have a separate label called "Total" which adds up the Cost values in the grid. Let's say you provide application-wide capability to switch currency via some dropdown.

What's the most straightforward approach to updating the DOM whenever a user changes the global currency? Find all the related notes that are displaying currency and update their innerHTML. However, this might cause multiple browser reflows and repaints as you perform the operation modifying various parts of the screen.

React takes a different approach. It maintains a "Virtual DOM" tree (just detached DOM, I believe), where it updates innerHTML of the related nodes. Then it compares the Virtual DOM vs the real one, and based on any delta it swaps out the highest-needed-level DOM to perform the entire update in 1 "sweep", 1 reflow, 1 repaint - instead of multiple ones. This is my understanding, at least.

It sounds like an excellent idea and could perhaps be of tremendous use in web applications with very inter-connected UIs. However, let's consider a scenario that is a far more common cause of performance issues: large data grids. ExtJS' infinite grid really excels here by hyper-optimizing the presentational and scrolling experience. Regardless of how many rows of data you have, only a few are shown on the screen at any given time, and when you scroll, those rows' DOM nodes shuffle and get their innerHTML updated with the relevant data for their new row positions. I do not believe there is a more efficient approach out there.

That being said, while I think React's "Virtual DOM" approach has a lot of potential, when it comes down to enterprise app development and hyper-optimizing, you're still going to address each UI component on an individual basis, as is with ExtJS' infinite grid, which at that point couldn't benefit from the "Virtual DOM" anyway.

VN:F [1.9.22_1171]
Rating: 7.2/10 (15 votes cast)

ExtJS 4 and 5 vs. IE 6 thru 11

Get a neck stretch and a clear picture of legacy through modern IE support in ExtJS 4 and 5:

ExtJS 4 & 5 vs. IE 6 thru 11

Note that the Neptune theme, which shipped in an ExtJS 4 dot release, does not support IE6. It makes use of transparent PNGs, which aren't supported in IE6.

One of the greatest advantages of the ExtJS framework is how far back it supports IEs. The interesting thing here is the "adaptive markup" that it generates, say for a framed panel with gradient headers:

  • Pre-IE9: a "heavy" table frame with every edge and corner having a sliced image of the frame
  • IE9 (introduced round corners): still a bit of framing for the header gradient image if used with rounded corners
  • IE10 & 11: minimal markup utilizing CSS3 effects
VN:F [1.9.22_1171]
Rating: 10.0/10 (4 votes cast)

shrinkWrap in ExtJS 4 and 5 Containers

ExtJS Containers and Panels are typically sized by their parent container's layout. Traveling up the layout chain typically leads to a Viewport, which occupies the available screen space; i.e. (view in Sencha Fiddle):

sample viewport

Now what about those times when you want to use these beautiful panels as the actual content, rather than as holders of other content? In other words, how can we make the Panels size based on their content (rather than as dictated by their parent's layout)? The end result might look something like this:

sample panel shrinkWrap

Read on to find out how its done and what caveats exist...

VN:F [1.9.22_1171]
Rating: 9.3/10 (6 votes cast)
Page 3 of 1412345...10...Last »