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.
