What Is ExtJS ExtJS 4+ Extensions Examples Tutorials


ExtJS 6: Responsive HBox vs. VBox

A basic ExtJS6 Classic Toolkit responsive technique for going from vertical to horizontal based on tall/wide screen, is by using responsiveConfig on a Viewport running Border layout, and change desired child's regions from i.e. South to West. However, what if you want to do the same, but using an HBox vs. VBox layout, to get that additional flex functionality? Turns out it's not as straightforward, however still pretty simple. You just need to use Box layout (ancestor of HBox and VBox) with "vertical" boolean config changing inside the responsiveConfig of the viewport. Here is the sample source code from Sencha Fiddle; click the link below to experiment with it in different window sizes:


VN:F [1.9.22_1171]
Rating: 6.3/10 (6 votes cast)

ExtJS 6: the best IE8-Modern Web Apps

Recently I wrote about my dissatisfaction with ExtJS 6 for being an "ExtJS 5 + Sencha Touch in disguise".

However, I came to realize that the beloved IE8 browser is essentially what's paying my bills. IE9 as well. It is easy to make jokes about how bad the browser is (compared to the latest and greatest):

one does not simply debug ie8

ie8 and open source bad time

You can do these all day long; just hit up image search for "ie8 meme".

However, let's address this one:

its 2015 who still uses ie8

VN:F [1.9.22_1171]
Rating: 9.0/10 (9 votes cast)

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: 8.1/10 (13 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)

Responsive Design in ExtJS 4

I think this has been a hot topic lately: making web sites that adjust based on resolution of the device the user is using to browse. Now I'm not going to make this post about Sencha Touch. Even though in my "perfect responsive strategy" I would be using both ExtJS and Sencha Touch (and I can write more about that if you care to comment about your interest), this post is going to be only about ExtJS.

In this example we'll be achieving the very common "navigation collapses to menu" effect, demonstrated here in my Android 4.x LG Intuition, by rotating the device from horizontal to vertical:




VN:F [1.9.22_1171]
Rating: 8.2/10 (22 votes cast)