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):
You can do these all day long; just hit up image search for “ie8 meme”.
However, let’s address this one:
Seriously, it’s almost 2016! Hot modern frameworks like Meteor and React are out, doing wonders with modern browsers, so why isn’t everyone running Chrome? While browser statistics might place IE8 at around 5% of the market share, there remains a “behind firewall” enterprise market, where such statistics are not easily obtained.
The reality is there still exists a large enough market of enterprises locked into IE8s due various reason. Those reasons don’t matter; the only thing that matters is that IE8 needs to be supported!
ExtJS 6: the right place at the right time
IE8 and IE9 are dying. I believe by 2020 they will be completely irrelevant, if not by 2018. At the same time, the mobile device market is booming past the desktop market. IE8 was released in 2009. This means it’s 6 years old and has another 6 at most to live.
Time will tell if my prophecy is true, but one thing remains clear: ExtJS 6 is a transitional technology, relevant for as long as IE8 and 9 remain relevant.
What’s so amazing about ExtJS 6 is sheer number of target platforms it has – more than any other framework in existence. Supporting Android phones AND IE8 in the SAME codebase? But wait…
Classic Toolkit vs. Modern Toolkit
One thing that initially put me off about ExtJS6 is that it still provided me with two sets of widgetry – essentially the ExtJS 5 set (“Classic”) and the Sencha Touch 2 set (“Modern”). Bear in mind that widgetry is only about 50% of the framework; the rest (the “Core” i.e. data, events, gestures, etc.) is luckily shared between the two toolkits.
However, the more thought I had given it, the more I came to realize that this may not be a con, but in fact, a pro. This can be seen as an opportunity for choice. Consider the different options for responsive strategies that this allows:
- Truly Single Codebase – Classic: why not utilize the slower ExtJS componentry all throughout? Sure, a tree panel might look kind of weird on the phone, and Adroid 2.3 will probably hang, but most recent phones will pull it just fine
- Truly Single Codebase – Modern: the reverse of the previous strategy; however with the heavily touch-oriented widgetry the desktop users might feel weird with iPhone-style date selectors; also this won’t work in IE8 and IE9
- Both Toolkits – Single JS file: we can get flexible; logic and data are still shared, but based on our interpretation of the User Agent, we will serve up either Classic or Modern componentry. It’s not truly a shared codebase on the UI side, but about 50% “behind the scenes” are still shared.
- Both Toolkits – Two JS files: for maximum optimization and user experience, but at highest dev cost, we can compile two sets of optimized Modern vs. Classic JS and CSS files. This is very similar to the previous strategy, with the exception of “which file to serve up” task would now be on the back-end side.
Conclusion
Sure, there are many solutions aiming to address responsive strategies and capitalize on the booming mobile market. How many of them take into account IE8? If words “IE8, smartphones, responsive, and single codebase” are requirements, there is no better solution out there than ExtJS 6.