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:
So, the caveat is that you have to know the exact version which you're after!
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.
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.
Get a neck stretch and a clear picture of legacy through modern IE support in ExtJS 4 and 5:
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
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):
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:
Read on to find out how its done and what caveats exist...
Diving into ExtJS 5 and talking to some of the engineers behind it I'm forming the conclusion that there are 3 distinct scrolling systems being employed in ExtJS 5. What are they?
- For traditional "mouse-only" desktops - using the native browser overflow: scroll
- For mobile "touch-only" devices - using Sencha Touch's kinetic "momentum" JS scrolling
- For hybrids that have both mouse and touch support (i.e. MS Surface or Google Pixel) - using some sort of a hybrid of #1 and #2 where the JS kinetic scroller kicks in on tap-drag
I'd love to dissect this on an HTML level...