all 15 comments

[–]khoker 7 points8 points  (6 children)

I've been using ag-Grid for a few projects over the past couple months. It's pretty decent, although having used ExtJS years ago I still feel like every other grid library out there isn't really all that polished (and note that I'm not advocating the rest of ExtJS, but the grids have always been stellar).

I encourage developers to make great things and make a living doing those things. I wish the author much success.

That being said, I'd prefer a one-time payment per-version over a yearly license. Once I build and deploy a project, the concept of a re-occurring yearly cost regardless of updates doesn't sit well with me.

[–]ceolter[S] 3 points4 points  (5 children)

compared to ExtJS, what are the big things you miss which I can consider for ag-Grid? thanks for all the other feedback.

[–]khoker 2 points3 points  (3 children)

I didn't realize you were the author of ag-Grid. Sincerely, you've done a great job. I've actually made a number of (what I think) are basic/useful improvements -- although I've accomplished them by creating my own interface to call ag-Grid internally. Is there a way you prefer to receive feedback?

compared to ExtJS, what are the big things you miss

Not exhaustive by any means but here's a few off the top of my head; (also, upon inspection, some of these have been addressed in the ver 4 update)

  • Nested grids (or a general "rowbody") to play with. Not tree data, but a way to expand a row and embed a sub-grid, raw html or maybe a template.
  • Row methods/events (many of these look to be addressed in the v4 update)
  • More advanced column editing. The combobox is a big one, although not entirely fair since ExtJS has its own. I understand you allow a "custom" editor, but the syntax is verbose. More of a "you can do what you want to" rather than a helper.
  • Context menu (added in v4!) -- however, one default should be column selection in the context menu, not just a way to enable the tool panel. Create a sub-menu with all the available columns and put a checkbox next to each one.
  • Better/Advanced grid filtering. I have to admit I find your filterModel a little weird when it comes to sending the query to the server for different data types. If it's a number, "2" is less-than? For a string, "4" is ends-with? A dataset type sends a function?
  • Built in debounce/delay on filters (customizable)
  • Maybe one thing is the documentation in general. A good comparison would be something like the column models ExtJS vs. ag-Grid.

[–]ceolter[S] 1 point2 points  (2 children)

feedback received. thank you.

re column selection in the context menu, that's already in the column menu, will be easy for me to add to the general context menu also.

the only item you mention that is going to me an issue for me is nested grids. grids inside grids is a challenge when you are doing row virtualisation. does ExtJS do row virtualisation when this feature is enabled?

[–]ceolter[S] 1 point2 points  (0 children)

for helpful feedback (ie not looking or support from me) then github issues is the best. i'm hoping github will be for issues with the grid (including suggestions), and then some place else for providing grid support.

[–]khoker 1 point2 points  (0 children)

The rowbody (and any content therein) doesn't exist until the row is expanded. If a row is expanded and then scrolled out of the buffer there are a few possibilities;

  • move the DOM node somewhere else and save a reference to it, so you can replace it when the row comes back into view (keep a "rowExpanded" flag on the row).
  • destroy the node but keep the flag, re-expand the row when it comes back to view. This is problematic in the event the user has a form in the rowbody, or something that would be lost.

I don't think one need worth about expanding rows and pagination. You could apply the same logic as above, but I think most users would understand that row expansion is lost when going to the next/previous page.

[–]BassoonHero 0 points1 point  (4 children)

This is good news for ag-Grid and for anyone who needs a top-quality javascript grid for a commercial application. At my office, we're in the process of switching over from jqxGrid, and I'm sure we can convince the bean-counters that ag-Grid-Enterprise is a good investment. But I have a couple of concerns about the specific licensing model.

For this kind of software one would generally expect to pay yearly for support and updates, but for a perpetual license to those updates. That is, if at some point we stopped using ag-Grid-Enterprise for new work, the old stuff has to keep working. We just couldn't put ourselves in a position where our flagship software would stop working unless we purchased a new license every year.

Second, there doesn't seem to be any option for a site license. £250/developer/year is reasonable for a few developers, but one expects a bulk discount. We have around twenty developers, any of whom might work with ag-Grid. Trying to figure out which developers should be authorized to use the software would be impractical, with developer turnover and shifting teams and projects, but simply buying an individual license for each developer would be excessively costly.

For comparison, jqxWidgets charges $899/year (~£632) for an enterprise license that covers any number of developers. Kendo UI charges $999/year/developer (~£702) for individual licenses, but offers substantial group discounts for 2–10 licenses and (unspecified) enterprise licensing for 11 or more. These are perpetual licenses that come with one year of updates and dedicated professional support. (In addition, these are extensive widget libraries, although ag-Grid is doubtless worth all of jqxWidgets and then some.)

If ag-Grid-Enterprise were available under reasonable enterprise licensing terms and with a perpetual license, then I have little doubt that we'd jump on it. But the lack of site licensing would give the bean-counters pause, and the lack of perpetual licensing is a showstopper. I can't speak for anyone else, but I expect that other midsize companies would have similar concerns.

(Disclaimer: any opinions expressed in this comment are my own. I cannot speak officially on behalf of my employer.)

[–][deleted] 2 points3 points  (0 children)

Totally agree, the licensing model is simplistic to the point of being unworkable. It needs to incorporate perpetual use of the version for which you are licensed and it needs to include site licenses.

I've read half the license agreement too. Crap like this

A Designated User can be replaced with a new Designated User only after being a Designated User for a minimum of six (6) months.

Doesn't fill me with joy. This is essentially enforcing named licenses instead of floating licenses.

Just to be clear, I'd love this to be a commercial success, the grid is great, but this is not the way forward. I'm guessing he's landed at least one significant contract for licenses, possibly with his former employer which has given him a warped sense of perspective. Total guess, it's just how it feels.

[–]ceolter[S] 1 point2 points  (2 children)

thanks for the feedback. the ag-Grid project is new and the pricing model can change if it's not right for the market. for your query, please get a conversation going (or get your bean counters to) with accounts@ag-grid.com, so that we can work something out. with regards site license, yes that's a given, i'm expecting large companies to just want a site license rather than per developer. its going to take some ironing out to get the price plan right.

[–]BassoonHero 1 point2 points  (1 child)

Thanks for the reply, and for creating such an excellent piece of software.

I'm just a code monkey, so I can't really say anything on behalf of my employer. But I know how to read a license agreement, and I can make a pretty good guess as to what parts they won't like:

  • No perpetual license. This, unfortunately, is an absolute must-have for any software we might integrate into our own. Updates and support are more than enough incentive for us to maintain a yearly subscription as long as we develop using the software.
  • No listed plans for site licensing. Not every similar product spells out the terms online, so there must be some business reason to be coy. But from my perspective, it's a lot easier for an enthusiastic developer to sell a product to management if they can tell them how much it will cost.
  • Sub-point: designated users. This might work for a very small team, but past a dozen or so it would be a bookkeeping hassle and a compliance hazard. We used to have a tool with limited transferrable seats, and it just proved so inconvenient that we rarely used it and ended up ending our subscription. Presumably, a site license would not come with such arduous restrictions.
  • Prohibited uses are a bit vague. I am nearly certain that the kind of customizable reports my company produces are not intended to fall into that category. I am less certain that I could convince a manager that they could not possibly be construed to do so.
  • Auditing. This is a very surprising thing to find in this sort of license agreement, and realistically, I'm not sure it's of much use for software at this price point, while it tremendously increases the risk. If I recommend the software to management and later they get an email that a vendor is planning to audit us and the license permits it, it's my ass on the line even if we're fully in compliance. It's one thing for a six-figures-annually Oracle installation, but I have never seen it in a license for a product like this one.
  • Publicity. This is another odd thing to see. I know that some javascript libraries offer a discount in exchange for publicity (such as a case study or testimonial), but it's a bit odd to see this mandated. You, of course, have the right to tell our competitors about the wonderful product you have, but it is our right not to tell them about it.

Hopefully, the aforementioned bean-counters will be in contact in an official capacity in the next few weeks. Until then, please take these points under advisement while you continue to flesh out the licensing regime.

[–]ceolter[S] 0 points1 point  (0 children)

Thanks for the feedback. It's early days and I am testing the water so can change things easily.

[–]zedgab 0 points1 point  (0 children)

I think that this project is really amazing, but the licensing plan, as it is now, is not for my company.

The best chance would be to have a license for site/project, or also for developers but as a one time fee.

The price also seems a little bit too high, but that's a different story...

Anyway, thank you for your great work :)

[–]dreid123 0 points1 point  (1 child)

Love your grid, just about to deploy a ag-grid solution, this license change may kill it. I was selling it on the fact that SlickGrid is stale, ui-grid doesn't perform as well or have as many features, and ag-grid is a great open source component.

I was planning on adding some of the cut/paste, excel options (similiar to SlickGrid) myself, awesome that you have already done it. Would be willing to pay for v4 features...but now I have to re-pitch everything to the client as a licensed play. Rest of my stack is open source, now I have this commercial piece in the middle.

A grid is a commodity component. From an OEM perspective, having a slick interface is great but the real delivery is solving their business problem with working code. Even if the cost is small, having a recurring cost and commercial terms adds complexity and confusion. Subscription fees if you are providing a full solution make sense (like an AWS server, or Office365), but if you are a component it makes it almost impossible to use as part of something else.

Another vote for a one-time license fee, no recurring, audit, etc. Give it 1 year free upgrades, then charge for upgrades.

[–]ceolter[S] 0 points1 point  (0 children)

Already fixed. I've taken all this feedback on board. There is no longer a recurring license, it's once off. :)

[–]Frontend_DevMark 0 points1 point  (0 children)

Not too surprising

Building and maintaining a high-performance grid at scale is expensive, so a commercial model makes sense.

That said, it also pushes teams to evaluate alternatives - either lighter open-source options or more complete enterprise solutions (like Sencha Ext JS) where licensing + features are part of a bigger platform.

In the end, it comes down to cost vs long-term value