What Is ExtJS ExtJS 4+ Extensions Examples Tutorials

30Apr/150

ExtJS 6 vs. Responsive

A few weeks ago I was at SenchaCon 2015 and majority of the sessions I attended revolved around ExtJS6 and Sencha's responsive strategy. In summary: an effort has been made to converge ExtJS5 and Sencha Touch 2, but ultimately you will still be building a separate ExtJS and a separate Touch app. You do not end up with truly "one framework", which is what I hoped for. Read on for details...

VN:F [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
16Jan/150

How to “sencha package build” a “code” package

You can follow Sencha's guide all you want, but you won't be able to build a stand alone "code" package due to errors like:

com.sencha.exceptions.ExNotFound: Unknown definition for dependency : Ext.Component

To fix this, you need to add the following to your package's .sencha/app/sencha.cfg

package.framework=ext

VN:F [1.9.22_1171]
Rating: 7.5/10 (2 votes cast)
Tagged as: , , No Comments
13Jan/150

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 (1 vote cast)
6Nov/140

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).

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

http://cdn.sencha.com/cmd/x.x.x.xxx/release-notes.html

For instance:

http://cdn.sencha.com/cmd/3.1.2.342/release-notes.html
http://cdn.sencha.com/cmd/5.0.3.324/release-notes.html

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

VN:F [1.9.22_1171]
Rating: 8.0/10 (3 votes cast)
31Oct/140

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: 6.3/10 (8 votes cast)
Page 1 of 1212345...10...Last »