I’ve been using several versions of dhtmlx since 2014 and I immediately fell in love with it! Rich features combined with attention to detail and excellent documentation allowed me to easily and quickly create beautiful and functional interfaces for web applications.
Now when I came back after a short break and saw dhtmlx6 it puzzled me. The limited API combined with the poor documentation no longer makes it as easy to do what was possible in the previous version!
Maybe I do not understand something? Maybe philosophy of the product was completely changed? Can somebody tell me what’s going on? Can somebody give me a link where the new paradigm is explained in details and real examples with clear code are given? At this point I doubt if I will continue to work with old versions of the product or will completely abandon dhmlx. I have no other ideas to look at dhtmlx6 and it really upset me because it was a really great product.
I feel you bro.
What I like with dhtmlx v6 is the interface the controls are very beautiful.
The downside is the lack of api, very few.
I wish they polish or put the form controls of dhtmlx v6 to dhtmlx5 that would be great.
I’d say it was a pretty significant shift in philosophy. It looks to me like they’re trying to move from a very Javascript/JQuery -heavy library to a lightweight library leveraging more CSS styling to accomplish what they were doing before, and unifying component data sets under a single object class to simplify data handling and manipulation instead of each component accomplishing similar tasks through its own interface functions. Unfortunately, that means a very massive overhaul of the entire library, and to keep things moving forward it looks like they’ve released a core library and are working to build it out to the level it was at before. That’s just going to take time, though, and that in turn is going to take patience from the users.
I can say that in my experience so far, data rendering for large-ish sets of data (up to a couple hundred rows) is much quicker than in previous versions of the DHTMLX library. That’s a big reason that I’m working to transition my pages to DHX6, at the expense of having to write REST API interfaces for my data. But I’m writing that off as “future-proofing” my pages somewhat, because lots of different front ends can use the JSON data the REST API provides in case I should ever need to incorporate something else or move away from DHTMLX for some reason.
If you’re not ready for taking that on, or the learning curve with DHX6 (it took me 3+ months to convince myself to even take the plunge to try figuring it out), the devs are very graciously committed to still supporting the DHX5 library for the time being, so that remains a viable usage option.
As far as the details and examples with clear code… well, that’s a bit of a hurdle right now. There’s basic documentation for DHX6, and example code for a lot of it. But it takes interpretation to figure out how to apply their basic example to what you want to accomplish. I’ve learned a lot through repeatedly digging through the “Getting Started” example and tweaking their code to break it or make it do what I want. I also use the Developer Tools of my browser a lot to explore the functions different components expose (console.log() is a big friend of mine) and see if there’s something I haven’t seen in the documentation that might help me.
I also spend a fair bit of time here in the forums when I hit a roadblock, trying to see if someone else has already struggled with it, or reported a bug or missing capability; usually I’m looking to see if the devs have provided a workaround that exposes something not (yet?) documented that I can leverage. I’ve picked up a number of useful things looking at topics that don’t even apply to an issue I’m having.
TLDR: DHX6 has some speed and simplicity improvements, but you have to commit time to reworking your approach from previous versions. If you can’t afford that time, then stick with the older versions for now; they’re not going anywhere for a while.
I totally agree with you.
I am also using this v6. What driving me to use this is the form controls. I like the styling(UI).
I don’t like the material design of the Vb5, having controls or inputs with border-bottom only.
I’m hoping they can add more api.
I like the 6 version. But I guess that the the open source philosophy can be improved and used to speed features releases. For example offer access to the original source code in a repository, github for example; then the development team could accepts commits to fix bugs or add new features.
They should let us see the ground code. So can help them with some improvements.
Please provide the source codes.
Well, they already provide the source code. The problem is that is not suitable to merge with the original source. Another improve could be to expose the internal architecture that they use to create components (internally they are using domvm). Advance users can use the same architecture to create custom components extending the existing ones. Custom grid cell editors can use this way.
They did provide but I feel like is not complete. I read the suite.js but I cannot find the dependency files they use webpack. I don’t know maybe I was wrong.
It’s hard to debug or extend the current core.
I need more time to dig their code.
I’m having hard time understanding it also. Their code is too advance for me.
I know I’m super late to join this conversation but I’m hoping that bringing it back to life will give this all some dev attention. Found this post scrolling endlessly through the dxh6 forum topic desperately trying to equate new treegrid methods to old normal grid methods. It doesn’t make any sense that the treegrid library in suite 6 contains no way for the treegrid to return how many rows it has, or that the only way to tell if a row is a top-level parent is to check if its parent is equal to the overall tree’s hidden private field _root, which isn’t documented anywhere and the only way I found it was scouring through the treegrid data type fields in Chrome’s debugger. Really felt like I should’ve just been able to equate the top level parents’ parent fields to null and compare that, but noooo. Took me hours when all of that should be basic API features available in seconds. Also, in previous versions dhtmlxGrid had the capability to have custom column types and cell editors. I’m trying to migrate a project from grid 5 to treegrid 6 for my work, and it’s kinda ridiculous to me that treegrid is supposed to be a more capable, upgraded, fancier version of grid but it’s missing basic functions like number of rows and public root identification and more advanced functions like custom column types that made grid 5 so appealing. They really need to get on the documentation grind. dhtmlx 6 has been out for almost a year, and it’s crazy to me that they didn’t release it with full documentation and API capabilities, but for it to be a year old and still not have that stuff readily available is ridiculous. I do appreciate that the forum is at least responsive fairly quickly, but I shouldn’t have to be asking the questions that I am when it comes down to it.
I agree with you @VitaminTussle. I’m having problem with missing API’s too and the documentation is somehow lacking for me.
I do think that this version 6 was made by different coder/dev.
This v6 is a strip version containing basic functionality only for simple and quick projects. It is not intended for projects containing lots of forms. This is not mature unlike v5.
The version 5 is suited for complex and big projects the only downside is that the design (UI/UX) not really eye-pleasing.
I use this v6 BTW writing this current complex project I’m working for my our inventory and payroll system. I had to write some custom script to be able to get functionality on v5 that is missing on v6.
So this version is a different from version 5, a rough minimal version for v5 with eye-pleasing controls/widgets.
I had to write a custom simple clean responsive tabbar since I don’t like the v6 tabbar when you have a lot of tabs.
Well… I think we found the best solution of the problem…
We just stoped using DHTMLX and buying now another framework.
I moved to v6 without hesitation once it came out. But after months of struggling, I’m afraid I have to move back to v5. The main reason for me:
- lack of many useful and powerful APIs, which existing in v5; even some APIs, which I think they should exist, but they are absent.
- although some problems are officially confirmed, they are not fixed or updated in time. So I’m wondering whether this new v6 direction is officially accepted for further development. Obviously, suite v6 is not on the emphasis of recent work for the team.
- lack of some documentation, although this is not very important.
- I’m planning to head back, but I don’t think this downgrade rational, which could lead to more difficult jump for me if v6 move forward in the future. So it’s a painful decision.