ExtJS/Sencha vs DHTMLX

I just wanted to share my experience here also to help you DHTMLX guys and also for other users wondering about this.

My background: I have been programming with BOTH ExtJS/Sencha and DHTMLX for the past 2 years and I’ve been programming in general for 25 years.

I recently decided to switch completely to DHTMLX because I got tired of updating two frameworks and skins, and making them work together, and I liked DHTMLX more. Reasons:

  • Performance. I started with dhtmlxGrid because the ExtJS Grid was horribly slow, then used more and more dhtmlx components and always found professional, mature, speedy components.

  • I found I was more productive with dhtmlx. APIs were simple, common tasks didn’t require many lines of code and a lot of head-scratching to accomplish everything.

  • Smaller footprint. Faster load time.

DHTMLX at first lacked some components and functionality to be a complete GUI framework, but now I feel it is more than ready.

Don’t get me wrong. Sencha/Ext JS has its advantages and they seem to be pushing the boundaries with graphics lately. And if you need a framework that you want to extend and custom program a lot, then Sencha may be for you.

But I feel that it is over-engineered for most cases, as if doing things ‘correctly’ and making everything adhere to OOP and design patterns got priority over productivity and performance. I even tried to suggest functionality that makes more sense from a development point of view and they argued back with some kind of internal rule that made no sense.

In short, DHTMLX seems to have a better and more practical attitude for most cases where you need either individual web components or a straightforward web GUI framework. DHTMLX should be more recognized and I think you guys should point out the advantages I listed above.

I am evaluating sencha touch / dhtmlx touch.

In what sense you believe that sencha allows more customization and extentions that dhtml would not?

First of all I don’t have enough experience with the Touch products - I was talking about the regular suites.

Second of all I didn’t say customization. I said custom programming. DHTMLX is very customizable and allows you to set styles anywhere, etc.

Where Sencha may be better is when you want to program your own components, or component extensions, or custom events, etc. Since it is very object-oriented and it has a component model framework common to all their components, and an abstracted event system, this is somewhat easier to do, as well as to maintain/upgrade. It also systematically exposes every piece and aspect of its components via API so that you can manipulate whatever you want without digging into their source code as often.

But like I said, if you don’t intend to go that deep into their components, or to make your own components, and most web projects don’t, then I recommend DHTMLX for the reasons I stated above.

For example, let’s say you want to convert a text component into a spinner (if it didn’t exist), or you want to create a new kind of graphical menu, or you want to use a non-standard data source for your grid and abstract all of this for other developers so that they can use your extensions as part of ExtJS… this is what I mean by extending. It’s a full-blown development framework. But the price you pay is some productivity and performance - at least from the versions I’ve seen so far. This was serious enough for me to switch.

If anyone else has opinions on this, I’d love to hear them.


did you compare it with the new version of ExtJS 4?
Looks like they have a complete new structure inside (like dhtmlX will have in 3.0).


ZevToledano, thank you very much for sharing your experience and the comparison. We appreciate your valuable feedback, which will be useful for other users who’s choosing between dhtmlx and ExtJS.

I have more issues …

1 - DHTMLX is incredibly flexible … I write my RIA modules with meta-programming tools. DHXTML is perfect for writing apps in this way ou “manual” way. Now we have the fantastic DHTXML designer, but I must confess, I still using my “writer” tools

2 - DHTMLX is not obstrusive …

3 - DHTMLX gives you freedom, you can easily program both OO and Procedural mode. It is essencial for novice developers.

excuse my bad english

My cents …

Well let’s be honest :
Extjs is the most complete ui framework for the web out there, but and a big but it is very hard to work with.
For example if we want to draw a grid and load data from server, in extJs you need a lot of code in dhtmlx it is done easily with less code.
Dhtmlx api looks more clear and understandable to me and that is why i’m sticking with dhtmlx even if it’s not as big (ui set number).

This was an interesting read and made me try out DHTMLX.

But the first thing I am noticing is that, where ExtJS is always perfect, DHTMLX has some css-related discrepancies between online images and examples, the GPL downloadable pack, and the Skin Builder.

The first thing you will notice is that half of the labels aren’t updated to the fonts specified. If you use the formbuilder css, some stuff is in a different location than with the combined css.

Even if it’s just small stuff, an hour of fiddling and figuring out what to manually change doesn’t feel rock-solid.

DHTML is definitely easier than ExtJS, and also definitely less advanced.

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.

I just like to add two important subjects that shouldn’t miss in the comparison.

Most important: Licensing.

Not everyone wants to jump on the commercial bandwagon (yet). ExtJS is fully dual licensed open sourced. You can use everything, just don’t expect any support or visual builders.

DHTMLX on the other hand, when you go a little bit more advanced, every little thingie that comes in handy is only available for the commercial pro version.

Pretty important: Documentation.

ExtJS’ documentation is far completer, easier to navigate and search, and extensively supported with examples. The DHTMLX one is kinda meager IMO.

Personally, I find myself working around DHTMLX quirks a lot, and working around the open source version limitations, sometimes making ugly solutions.

For simplicity in coding, DHTMLX definitely wins.

That’s why, IMO:
Simple-ish things: Definitely DHTMLX
Complex things: ExtJS

I agree about the licensing comparison. But since I develop commercial apps (I paid for both libraries), this didn’t make an impact on me specifically. Also, I believe this license difference doesn’t apply with mobile.

Your comment on the documentation however is puzzling. DHTMLX documentation always had a lot of examples, even years ago when ExtJS didn’t. Granted, ExtJS documentation is more professional looking and more ‘well written’, but I never felt that DHTMLX was unclear in any way, and I still feel it has MORE practical code examples today than ExtJS. Think about the individual API and how many times you have seen examples for those, not just code examples for the component as a whole.

And as far as your conclusion is concerned, I strongly disagree. I made very complex solutions with ExtJS for years because I used to think like you, and ended up suffering so much that I switched. I’m guessing you find it limited because you are using the open-source version and had to program the advanced stuff yourself. In that case, then I must clarify that I am talking about the paid/Pro version.

At least I got RTL from DHTMLX when I paid for it, whereas ExtJS only added that this year to all its versions. I had to ‘hack’ ExtJS for years even though I paid for it.

P.S. I just looked a the licensing page for DHTMLX and only four components have Pro versions. So I presume the rest offer the same features in both versions…

No, there are lots of enhancements in components that are available depending on whether you have the open source or pro version of a certain components

Like this small detail I just encountered: Radio button in grid. Vertical grouping is in the open source version. Horizontal grouping is only in the commercial version.

There are lots of these ‘small’ details that make you want a commercial version if you make something with a little more-than-basic functionality.

I understand that DHX and Sencha want to make money, but sometimes I don’t get these limitations. I’m not gonna buy a commercial license for projects I don’t need to sell. Developers who want to sell their closed product need to buy a commercial license anyway. So why the obstacles?

Sencha does it too. The framework is completely open, but they don’t make a GUI builder available for free anymore, which is quite annoying. DHX has a GUI builder online which is very convenient for building a draft of the layout.

Yes, grid is one of the four components I mentioned that has Pro versions.

I can’t speak for DHTMLX and their business model, but many companies offer ‘Lite’ free versions of components with limitations, meant only for small apps or personal web sites, but as soon as you try to build something more complex for companies/organizations/enterprises, you hit the limitations.

Whether these limitations generally define whether the app is meant for personal use or not is another issue - a tricky one at that. In my experience, I find that even simple users often require complex functionality and the only sane way to limit products is by the amount of usage (users, tables, size, installs, etc as applicable). But this approach isn’t always possible or appropriate either, especially with products that are only embedded components.

Think about it, how would you, as a commercial company that makes components, differentiate between personal and business apps? It’s not easy.

Like Sencha does. Like Red Hat does.

FOSS project? Unlimited, free.
Want to package it, sell it, make a profit? Commercial license.
Want support? Commercial license.


That is such a misleading lecture for several reasons but I am afraid that if I comment, this will go way off topic. For example, the chart shows only growth, not actual profit or revenue. And it compares growth of companies that are in different stages. Also, support and services are no way as profitable and easy to live on as licenses, and I know this from experience. Also, last but not least, companies like Red Hat are profiting on OTHER people’s work.

Open-source is very nice for many reasons, but it is not such a clear-cut paradise when it comes to business. It’s very easy to sit there and tell companies to provide their work for free or make it all open-source, it’s quite another issue to explain how to make it profitable.

There is also the issue of trusting your users that download your free software to pay when the time comes.

And as far as Sencha’s business model is concerned: You are forgetting that they started as open-source based on open-source libraries. Once again, extending and building on the free work of others. They started as pure open-source and then they suddenly switched to a dual license model, causing a lot of controversy and angry people. So, first of all, if open-source is so great, and revenue from support is so good, why switch the license model? Second of all, if they are less restrictive in their free model, perhaps it is because of this legal background?

oreillynet.com/onjava/blog/2 … s_and.html

P.S. Found this at MODX: A community-based content management system based on Ext JS that wanted to stop using it for several reasons, some of them overlapping things I said earlier:
markhamstra.com/extjs/2013/ … re-jquery/

They don’t consider or compare any alternatives to ExtJS or jQuery though.

I just wanted to throw in a few comments here…

Dhtmlx has also become my #1 framework of choice. There are so many things which can be done in this framework–so many it is hard to remember. For example, putting a container in form. What’s that? You have a form and you want to drop in a grid or a tree or a layout. One line of code in the form then create the object and that’s it. It works in every browser, it loads before you can blink your eyes and it works every time.

Another hardly unknown item is the Layout View. With this you can make single page web apps in nice neat modules called Views. Simply change the view, ajax some data, maybe call a url pushstate() function and bam. The benefit here that the page structure is cached so only data is moving from server to client.

That’s the dhtmlx way. Things work, they work fast and there are lots of programmer APIs. Sure there could more. For just about everything I’ve wanted to do, I’ve either found an API or was able to create a prototype.

I experimented with extJs and it drove me batty. After making a few pages, it was clear that the programming effort was vastly more time consuming. For example, just getting data on the page, you need to map the data to a model and then map the controller to the model too. In dhtmlx the data contains the mapping either by json field names, array position or by xml id (or position). So there are 1/3 the moving parts—this equates to faster development and it easy to maintain. Seriously, how many times have you ever had a data->field mapping problem that could not figure out in 20 seconds as it was being developed? There is no need to jump through so many hoops. In reality, this strict MVC framework makes it easier for the developers of extJs to create the product. In the end, it makes it harder for us end users to create our apps AND and it will always run slower than it could. Json already contains the data mapping–just use it.

I’ve also worked on an app where we had to use jqueryUI (thanks to some unmentioned person who now uses dhtmlx). jqueryUi (not to be confused with “jquery”), also drove me batty. One group created the window object and then another group created jqgrid, can’t image why there might be problems when you try to put a grid in window. Things like seeing double scroll bars would appear in some browser and not in others . There were grid to window sizing issues. This has never happened in dhtmlx. The grids snap into windows, layouts and containers exactly to the pixel.

All in all, if you want a product that works and performance is a high priority, dhtmlx has got it.

Same goes for dhtmlx touch. In it’s current release(version 1 or something), I created an iPad app which controls a credit card reader for a Point of Sale app. Apple accepted it on the first look. It is a one page web app written in HTML5. It runs fast and it looks great. I did used only Apple’s X code and dhtmlx touch.

The power of dhtmlx is vast and wide. And it is only getting better!

Ah I missed the latest updates for this topic.

I don’t want to stir too much, but one comment I cannot leave unanswered:

ZevToledano: “companies like Red Hat are profiting on OTHER people’s work.”
They are also doing a lot of development and commit this back to the community. They sponsor Fedora, some of the ‘other’ people who do this work.

Apple is also profiting on years of OTHER people’s work. Forking BSD. And they take it one step further; only take licenses compatible with closed source code, and keep all the essentials under wraps. Now they are the richest company in the world.
That makes me sympathetic to Red Hat and annoyed with Apple.

I’m not gonna respond to your Sencha licencing issues. I’m well aware of that, and it’s not my place to defend other company’s business models. Not Sencha and not Dhtmlx. Why do you? Are you a Dhtmlx employee?
All I care about is my options. With Dhtmlx they are more limited. I explained why it doesn’t HAVE to be that way, and I’d like to leave it at that.