Thanks for the feedback. I think the lag might have been mainly due to the page loading and rendering 400+ job rows at once and is not related to the animation, though there might also be some hydration issues with the animation. Agree that the lag isn't good UX, I will look into getting it fixed soon.
Aside from the lag, I was hoping folks might appreciate the artistic of the animations where companies are resolving around a remote coding home :)
Thanks for sharing that you run into the same issue. Agree that something is wrong, perhaps scrolling causes the table to re-render for some reasons. I will look more into it and getting it fix next. There are techniques to optimize performance such as only render visible rows. I haven't spent much time testing it on mobile web and will enhance the mobile web view & experience upcoming.
Thanks again for your note! You are totally right that something is wrong. I took a closer look and fixed 2 issues that should massively improve the performance now if you would like to try again.
Below are more details---
Issue 1. Table with a link overlay in every cell
I initially used an off shelf table component to move fast and didn't take a closer look at the implementation. It turned out this component renders a link overlay in every cell to allow user to click table row to be taken to the job link. So 400 jobs with 6 rows end up rendering 2400 link overlays.
The reason it attaches a link overlay to a cell instead of a row is due to a well known bug with Safari, where you can't use `position: relative` in table row `tr` https://bugs.webkit.org/show_bug.cgi?id=240961. Attaching it to each cell works for small number of rows but causes performance issues with large number of rows.
I fixed it by rolling out my own table with css grid instead. It is not as semantic as it no longer uses table, thead, th, tr, td, but thanks to Safari, it is a tradeoff I am okay with.
Bug 2. Unnecessary re-render on Zustand store rehydrate
I used Zustand store to filters preference and save it to browser's local storage. On page load, it fetches from local storage to update the state or store rehydrate . I didn't use shallow comparison initially and caused the table to render even if the prev and new state is an empty array due to comparison by reference. Using shallow comparison minimize an uncessary render.
Seems correct. I might not use you average-user-device (iPhone SE 2016) but liked your idea and clicked the link. The page freeze for ~15s for the first load but then refresh only takes ~4s. The animation is smooth if I’m not scrolling the list. Scrolling seems hard to handle as the new items takes 2s to appear. Do you use a virtual table [edit: just read you sibling comment saying you don’t, yet] or heavy JS for styling the list? I usually have no problem scrolling long text lists. Another guess would be the logos size but I’m not in my computer to check it out. For context: I know my device is old but it handles fine most sites that don’t have too many ads, js shenanigans or super heavy assets.
Kudos to you, I’m sure my 2012 mbp will handle it fine though :-)
Sorry for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks.
I shared the root cause in a sibling comment and am forwarding it here:
Below are more details---
Issue 1. Table with a link overlay in every cell I initially used an off shelf table component to move fast and didn't take a closer look at the implementation. It turned out this component renders a link overlay in every cell to allow user to click table row to be taken to the job link. So 400 jobs with 6 rows end up rendering 2400 link overlays.
The reason it attaches a link overlay to a cell instead of a row is due to a well known bug with Safari, where you can't use `position: relative` in table row `tr` https://bugs.webkit.org/show_bug.cgi?id=240961. Attaching it to each cell works for small number of rows but causes performance issues with large number of rows.
I fixed it by rolling out my own table with css grid instead. It is not as semantic as it no longer uses table, thead, th, tr, td, but thanks to Safari, it is a tradeoff I am okay with.
Bug 2. Unnecessary re-render on Zustand store rehydrate I used Zustand store to filters preference and save it to browser's local storage. On page load, it fetches from local storage to update the state or store rehydrate . I didn't use shallow comparison initially and caused the table to render even if the prev and new state is an empty array due to comparison by reference. Using shallow comparison minimize an unnecessary render.
I've also got poor performance on a pixel 3a, but the freeze was only about 2 seconds.
As to the other, I never appreciate animations or scrolling hijinks on a website. It makes it harder to use and slows it down. But,I'm a grouchy old fucker.
Sorry again for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks
The animation stops because it gets blocked and appears to be locked up due to an issue with the table taking too long to render and another bug causing the table to re-render again.
Thanks for the feedback. I think the lag might have been mainly due to the page loading and rendering 400+ job rows at once and is not related to the animation, though there might also be some hydration issues with the animation. Agree that the lag isn't good UX, I will look into getting it fixed soon.
Aside from the lag, I was hoping folks might appreciate the artistic of the animations where companies are resolving around a remote coding home :)
How come scrolling the table lags on my $700 phone?
You can render tens of thousands of rows at once without lag, something is wrong.
Thanks for sharing that you run into the same issue. Agree that something is wrong, perhaps scrolling causes the table to re-render for some reasons. I will look more into it and getting it fix next. There are techniques to optimize performance such as only render visible rows. I haven't spent much time testing it on mobile web and will enhance the mobile web view & experience upcoming.
You don't need to only render visible rows. There are only 400. You just insert them into the Dom and that's it.
Thanks again for your note! You are totally right that something is wrong. I took a closer look and fixed 2 issues that should massively improve the performance now if you would like to try again.
Below are more details--- Issue 1. Table with a link overlay in every cell I initially used an off shelf table component to move fast and didn't take a closer look at the implementation. It turned out this component renders a link overlay in every cell to allow user to click table row to be taken to the job link. So 400 jobs with 6 rows end up rendering 2400 link overlays.
The reason it attaches a link overlay to a cell instead of a row is due to a well known bug with Safari, where you can't use `position: relative` in table row `tr` https://bugs.webkit.org/show_bug.cgi?id=240961. Attaching it to each cell works for small number of rows but causes performance issues with large number of rows.
I fixed it by rolling out my own table with css grid instead. It is not as semantic as it no longer uses table, thead, th, tr, td, but thanks to Safari, it is a tradeoff I am okay with.
Bug 2. Unnecessary re-render on Zustand store rehydrate I used Zustand store to filters preference and save it to browser's local storage. On page load, it fetches from local storage to update the state or store rehydrate . I didn't use shallow comparison initially and caused the table to render even if the prev and new state is an empty array due to comparison by reference. Using shallow comparison minimize an uncessary render.
Seems correct. I might not use you average-user-device (iPhone SE 2016) but liked your idea and clicked the link. The page freeze for ~15s for the first load but then refresh only takes ~4s. The animation is smooth if I’m not scrolling the list. Scrolling seems hard to handle as the new items takes 2s to appear. Do you use a virtual table [edit: just read you sibling comment saying you don’t, yet] or heavy JS for styling the list? I usually have no problem scrolling long text lists. Another guess would be the logos size but I’m not in my computer to check it out. For context: I know my device is old but it handles fine most sites that don’t have too many ads, js shenanigans or super heavy assets.
Kudos to you, I’m sure my 2012 mbp will handle it fine though :-)
Sorry for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks.
I shared the root cause in a sibling comment and am forwarding it here: Below are more details---
Issue 1. Table with a link overlay in every cell I initially used an off shelf table component to move fast and didn't take a closer look at the implementation. It turned out this component renders a link overlay in every cell to allow user to click table row to be taken to the job link. So 400 jobs with 6 rows end up rendering 2400 link overlays.
The reason it attaches a link overlay to a cell instead of a row is due to a well known bug with Safari, where you can't use `position: relative` in table row `tr` https://bugs.webkit.org/show_bug.cgi?id=240961. Attaching it to each cell works for small number of rows but causes performance issues with large number of rows.
I fixed it by rolling out my own table with css grid instead. It is not as semantic as it no longer uses table, thead, th, tr, td, but thanks to Safari, it is a tradeoff I am okay with.
Bug 2. Unnecessary re-render on Zustand store rehydrate I used Zustand store to filters preference and save it to browser's local storage. On page load, it fetches from local storage to update the state or store rehydrate . I didn't use shallow comparison initially and caused the table to render even if the prev and new state is an empty array due to comparison by reference. Using shallow comparison minimize an unnecessary render.
I've also got poor performance on a pixel 3a, but the freeze was only about 2 seconds.
As to the other, I never appreciate animations or scrolling hijinks on a website. It makes it harder to use and slows it down. But,I'm a grouchy old fucker.
Sorry for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks
That seems to have fixed it.
Mine stopped exactly at the animation, before proceeding.
Sorry for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks.
The animation stops because it gets blocked due to an issue with the table taking too long to render.
Sorry again for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks
The animation stops because it gets blocked and appears to be locked up due to an issue with the table taking too long to render and another bug causing the table to re-render again.
My phone froze for 5 seconds
Sorry for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks.