https://github.com/mleibman/SlickGrid/wiki

“SlickGrid利用虚拟渲染，使您能够轻松地处理数十万个项目，而不会降低性能。事实上，使用10行网格和使用10万行网格在性能上没有区别。”

以下是一些最突出的结果:

自适应虚拟滚动(处理数十万行) 极快的渲染速度 背景后期渲染更丰富的单元格 可配置和自定义 全键盘导航 列调整/排序/显示/隐藏 柱自动调整尺寸和力配合 可插入的单元格格式化器和编辑器 支持编辑和创建新行。” 由mleibman

它是免费的(MIT许可证)。 它使用jQuery。

我有点看不到这一点，对于jqGrid，你可以使用虚拟滚动功能:

http://www.trirand.net/aspnetmvc/grid/performancevirtualscrolling

但话又说回来，数百万行的过滤可以完成:

http://www.trirand.net/aspnetmvc/grid/performancelinq

我真的不明白“好像没有书页”的意义，我的意思是……没有办法在浏览器中一次显示1,000,000行——这是10MB的原始HTML，我有点不明白为什么用户不想看到这些页面。

无论如何……

我能想到的最佳方法是在每次滚动或滚动结束前以json格式加载数据块。Json可以很容易地转换为对象，因此可以很容易地不引人注目地构造表行

(免责声明:我是SlickGrid的作者)

更新 这已经在SlickGrid中实现了。

有关如何使SlickGrid工作于大量行的讨论，请参阅http://github.com/mleibman/SlickGrid/issues#issue/22。

The problem is that SlickGrid does not virtualize the scrollbar itself - the scrollable area's height is set to the total height of all the rows. The rows are still being added and removed as the user is scrolling, but the scrolling itself is done by the browser. That allows it to be very fast yet smooth (onscroll events are notoriously slow). The caveat is that there are bugs/limits in the browsers' CSS engines that limit the potential height of an element. For IE, that happens to be 0x123456 or 1193046 pixels. For other browsers it is higher.

在“large -fix”分支中有一个实验性的解决方案，通过将可滚动区域的“页面”设置为1M像素的高度，然后在这些页面中使用相对定位，可以显著提高该限制。由于CSS引擎中的高度限制似乎不同，而且明显低于实际的布局引擎，这给了我们一个更高的上限。

我仍在寻找一种方法，在不放弃SlickGrid目前相对于其他实现的性能优势的情况下实现无限行的数量。

吕迪格，你能详细解释一下你是怎么解决的吗?

我建议你读一读

http://www.sitepen.com/blog/2008/11/21/effective-use-of-jsonreststore-referencing-lazy-loading-and-more/

(声明:我是w2ui的作者)

我最近写了一篇关于如何用100万条记录实现JavaScript网格的文章(http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records)。我发现，最终有3个限制因素会阻止你把分数提高:

div的高度有限制(可以通过虚拟滚动来克服) 在大约100万条记录之后，诸如排序和搜索之类的操作开始变慢 RAM是有限的，因为数据存储在JavaScript数组中

我已经用100万条记录(IE除外)测试了网格，它表现良好。有关演示和示例，请参阅文章。