Possible to improve x-for performance with large lists?

[ragulka]

I ran into some performance issues with x-for while trying to implement a country dropdown in Alpine with keyboard support. The issue becomes apparent when trying to navigate the list with keyboard up/down arrows while having browser devtools open.

I've created a minimal test case for Alpine, Vue and Vanilla JS:

• https://codepen.io/ragulka/pen/QWyNZxv - Alpine
• https://codepen.io/ragulka/pen/GRoZYbZ - Vue
• https://codepen.io/ragulka/pen/QWyNJyQ - Vanilla JS

The Vue and Vanilla JS test cases doesn't seem to suffer from any kind of performance issues (even with devtools open), while Alpine becomes rather sluggish.

My guess is that this is partly due to Alpine not using Virtual DOM. However, given that even vanilla JS does not suffer from such issues, could any optimizations be made to how x-for is re-rendered?

[mblarsen]

Yeah, it is quite noticeable. Nice job on providing the codepens.

[ryangjchandler]

Hi @ragulka - the performance difference is quite noticeable. Great work on providing three different CodePens.

A couple of thing to note:

• Vue uses a Virtual DOM and will only update the necessary elements. This is something that Alpine doesn't currently do, since Alpine re-renders an entire component when any piece of data changes.

• Whenever a piece of data changes with Alpine, it needs to re-evaluate each expression and update the DOM accordingly, which will also have a larger performance impact compared to Vue and Vanilla JS. This isn't noticeable when the DevTools are closed, but when they're open, the DevTools is also evaluating and keeping track of each point in the stack. Alpine will have many more points to track compared to the Vanilla JS example.

• x-for has some overhead compared to a simple Array.map. When Alpine renders a list, it first checks if the array item being evaluated exists as an element, using the :key binding. If not, it then creates it. This allows for smart re-ordering of elements, without destroying each one. It also means that any elements that are not affected by the data change maintain their internal state (event listeners, attribute values, actual element properties). This overhead is worth it in my opinion, it makes the state of a component much more reliable and predictable.

[ekwoka]

If you don't have actual ids, just don't put the key at all, and it'll use index.

Beyond that, I'd need to see more code to have any sense. Would be helpful if you made a separate discussion for your case.

[dfallman]

Would be interesting to understand what people have tried to do to speed up x-for especially when working with large lists.

We have 1000s of lines and are experiencing a slowdown, but not to the point of it being useless. Each of our lines are also quite complex and need to circle in and out of multiple javascript functions to be rendered.

A couple of things we've found is that:

1. Nested x-for loops and x-for loops with x-ifs tend to slow things down substantially. I assume that has to do with the lack of shadow DOM and something like Vue's computed properties. Both of these would be amazing to have with Alpine as well, even in the form of a choice / plugin. Is there any work undergoing/planned to add something like this to Alpine?

2. We found that use of Tailwind's line-clamp-x seems to slow the browser down quite dramatically. We're actually not sure why this is the case but we noticed a pretty dramatic increase in performance by just using something like overflow-hidden instead. This might be more of a Tailwind and/or browser issue, but could impact performance.

[ekwoka]

@dfallman I'm curious what you mean about vue's computed properties as it applies to this.

On 2. yes, line-clamp does some layout thrashing, so adding large amounts of elements with it can be an issue, and the way Alpine adds elements could probably be improved to handle this (swap all elements at once, instead of one at a time). Since the clamp has behaviors that require it to check the layout before being able to finalize what should render, and it would likely be doing it for every element added. Could be, maybe not.

There are some approaches I've been investigating to give simple apis for handling high numbers of components from a for loop trying to depend on just a few values that often don't actually change the result of the expression, like some kind of view into the data that reduces how often expressions need to be reevaluated, but haven't quite found something that seems elegant enough to put into Alpine core.

[dfallman]

@ekwoka that is perhaps specific to our implementation, where we have a master list of >1000s of objects that each needs to check with/be double-bound with ~10-ish js functions, sorted into a handful of different views, and then handed over to x-for to be displayed. Computed properties would likely speed up the first part of this rendering significantly. The second part of the rendering would likely be sped up by a virtual DOM.

I'm curious as to if/when a (perhaps optional?) virtual DOM is on the horizon for Alpine, or whether it's even been discussed? Listening to a few of @calebporzio podcast appearances you get a sense it's not going to happen (?) I think that's a shame in a way as it appears to hold back Alpine's usefulness for larger, more data-intensive projects.

We're basically looking to do a re-write in Vue/Nuxt.

[ekwoka]

Virtual Dom is almost definitely not on the table (though I don't speak for Caleb).

Virtual Dom just isn't actually faster. For example: Solidjs doesn't use a virtual Dom, and it's the fastest framework. Virtual Dom is pure overhead.

The things that can cause large loops to be slow wouldn't be changed with virtual Dom at all.

It's in how expressions are bound.

And yes, Alpine is just not meant for large data intensive projects, though it can be made to be pretty okay at it.

[andymerskin]

I wonder if a plugin could be written along the lines of Tanstack Virtual, to handle this?

[shashank-brightness]

Any thoughts on this? as I am now even facing harder scrolling issue for alpine js array of objects in UI even when there is no nested loop inside. I did not know about 60 FPS concept earlier but it looks like it is same thing which prevents us to scroll naturally in chrome browser.

[ekwoka]

Thanks for this.

I might try whipping up an alpha plugin with that library and see how well it works for the case.

there may be factors that are a bit more unique to Alpine's use cases that would make a generalized virtualizer not good enough.

[calebporzio]

We've recently merged a PR to improve keyboard navigation performance in large lists drastically for the X-listbox and X-combobox components. Just a heads up.