There is still a painful lack of comparisons between Sencha and DHTMLX (and other frameworks) on the web, so, as a developer that has worked with both for several years, here is an update of my experiences and an expansion of what I wrote at the beginning of this topic. It will be long but I hope it will be helpful:
I’ve been developing very rich and complex Web pages for years (not mobile), and so far, most of my code has been a hybrid of both libraries. My original reasoning several years ago was that Sencha/ExtJS seems to be more comprehensive, offers great looking components, and thanks to its popularity, will also be the most mature and reliable. Therefore I started with it.
However, much to my surprise, their combobox and grid components were unusably slow, and their RTL support consisted of community hacks. So I replaced some of their components with DHTMLX components that performed 100 times better, and made a hybrid.
How could Sencha combobox and grid components be so slow and yet still be so popular you ask? Either because typical apps don’t use large amounts of data, or the developers are forced to program their interface the way Sencha wants, with paging and/or filters. But if your users need the interface to work a different way and, for example, require 2000 values in a combobox, then you’re stuck. People have asked about this on the Sencha forums, and the typical reply was that they’re doing it wrong.
I had similar ‘support’ experiences with Sencha layouts that didn’t behave as they should e.g. a table layout with no way to control the widths, and a column layout that didn’t auto-resize. The answer was basically that ‘we didn’t intend it to work that way’. This is a common theme in the forums where code is criticized for not doing it the Sencha way instead of admitting that the components are not always practical for real-world uses.
Sencha’s motto seems to be: “Sencha: the framework that makes you work the way Sencha wants you to.” As ‘web2solutions’ said above, DHTMLX is not obtrusive. This is a general issue that expresses itself in many ways, including the ability to work with other third-party components better, and the ability to use non-OOP code when you need it.
I also found that I was fighting with Sencha quirks and breaking my head over little annoyances more and more often. Whereas DHTMLX coding almost always seemed easy. I tried learning the ‘Sencha way’ for years, but no matter how good I got, I was still fighting quirks and even bugs thanks to the complexity of the code, and it was making me relatively unproductive. I went through the learning curve and still wasn’t reaping the benefits! So I started wondering whether all this hoopla regarding Sencha’s carefully designed, consistent and comprehensive framework wasn’t just another way of saying that it is an over-engineered and impractical framework that just imposes standards on you for no good reason. Any small benefits you gain from its consistently designed framework is lost thanks to its impractical approach that makes you work much harder for simple things!
Since then, I bought and upgraded both libraries. Upgrading Sencha involved 2 weeks of debugging and finding workarounds to new quirks and things that broke. Upgrading DHTMLX was easy.
Sencha, years later, FINALLY released official RTL support, and a grid that performed much better with a dynamic rendering design. But, the combox was still unusable for large lists, data loading was still slow, the whole framework became heavier and slower, and the footprint became bloated. DHTMLX, on the other hand, has made their library much more comprehensive and comparable to Sencha in terms of features, and it is still fast.
Sencha got too heavy, too claustrophobic, and too unproductive thanks to its over-engineered and complex code as well as its misguided philosophy. What kind of library prioritizes correct coding standards over performance? What kind of framework ignores RTL support for 5 years? Seeing as I had so much code already written in Sencha, spent so much time on it and even bought it twice, I really didn’t want to move to 100% DHTMLX. But it all got so annoying that I did it anyways.
Now, I am about to start a mobile app. This time I’m skipping Sencha Touch and going straight to DHTMLX Touch based on the above experience.
The only disadvantage with DHTMLX I found so far is the lack of options for dynamic auto-resizing layouts for things like forms and fields that fill the screen. So I had to write my own layout component that does this.
Also, I would like it if both frameworks supported components that use only styles instead of images, allowing code to change colors and sizes on the fly for any individual component easily. I had to jump through hoops for this capability in BOTH frameworks.