Hey Luis,

thanks for your message and appreciation. I admit the performance in some parts of the work package table has deteriorated. In OpenProject 6.0., the major change that causes an impact is:

1. Inline Creation and Editing in the Table

The entire table has become an editable grid where any attribute that was previously editable only in the split and full screen can now be edited in a spreadsheet-like manner within the Table.
While this does improve the possibility of editing a bunch of different attributes on a number of work packages, it does require a significant amount of processing and additional requests. When we decided to release 6.0., we were already aware that this causes the table to initially load slower and behave more sluggish, we wanted to gather experiences from more users on how the feature behaves and how we can improve it.

For the next patch release, we have already included an optimization on how the scrolling in the table behaves, but I agree with you that we have quite a lot of work ahead of us to move forward and improve the perceived performance.

Release Notes
https://www.openproject.org/open-source/release-notes/openproject-6-0-0/inline-edit-in-work-package-list/
https://www.openproject.org/open-source/release-notes/openproject-5-1-0/inline-create-for-work-packages/

2. Sharing of data of work packages between views

When you moved between table and split or full view in OpenProject 5.0., most of the data that was already available in the table was requested again before you could start editing.
We now have this information (except activities, attachments, watchers, etc.) available in the table and thus moving between views has become significantly faster and without loading in between them.

Release Notes
https://www.openproject.org/open-source/release-notes/openproject-5-1-0/automatic-synchronization-between-work-package-split-screen-and-work-package-list/

Depending on your computer and browser, the perceived performance in the table may be significantly different to 5.0. We do see acceptable performance with both Chrome and Firefox and sluggishness on IE11, but the performance worsens when using more than 50 work packages per page. The fact that we’re not there yet is that many of the optimizations still possible require changes deeply in the pre 5.0 table structure and cost us quite some time.

I assure you that we are actively working on those topics, so I welcome you to try OpenProject 6.0. again due to the many reasons that did improve ;-)

Best,
Oliver

thanks for your information!! I will try again on the next patch release.

Please! Please! Please! Would it be hard to replace your table with the community version of HansonTable? Its performance, aesthetics, api, and documentation is absolutely top notch. These guys started an entire company around that one product, ’cause making a performant JS table is deceptively hard work.

I know you guys have sunk a lot of time into your own version, and I know how badly it sucks to abandon code that took forever to write. (And I’m a big fan of your work!) But consider the following: current tables struggle with 50 packages per page. HansonTable can render 10,000 rows without breaking a sweat. It might take less total time switching over, then optimizing+reoptimizing large swaths of code. Why 10k rows? Imagine how amazing it would be for the user to get rid of pagination completely.

The community (basic) version is MIT licensed, so don’t know if that would be an issue with your licensing? The code comes in three flavors: vanilla JS, AngularJS, & Polymer.

10,000 rows http://jsfiddle.net/handsoncode/Lp4qn55v/
other demos https://docs.handsontable.com/0.29.0/demo-sorting.html
features https://handsontable.com/features.html
documentation https://docs.handsontable.com/0.29.0/demo-sorting.html
source-code https://github.com/handsontable/handsontable