Show HN: Seen – Virtual list rendering with 1M+ notes
38 comments
·February 10, 2025nickzelei
Hm, this is cool but I’m not seeing the speed. I loaded this on my phone and did one scroll flick with my thumb. Immediately saw white screen and took multiple seconds to render the items. iOS iPhone 15 pro. I’ve run into this same problem before using tanstack virtual table and it’s usually do to a few things:
- Too much on band calculation blocking the renderer when the new items come into view.
- Not enough preloading of the items off screen
- Incorrectly calculating the virtual scroll height which causes inefficient re drawing during render.
Not sure what stack you’re running but it seems the table could use some optimization.
_bittere
You're right, those are some trade-offs I've had to make. Not using Tanstack Virtual Table though, wrote a custom implementation with some help from our friend ChatGPT. I'll look into making it render faster!
Etheryte
Out of curiosity, why SHA-256? I would wager using a non-cryptographic hash would be faster, no? In this context you don't need any of the crypto properties of it, so that could be an easy performance improvement for your cache.
It seems currently the scroll struggles when you jump around, e.g. when you click to the bottom of the scroll bar area, the scroll will jump twice, first as you click and the second time as it renders. This is not a big issue if you continuously scroll, but is very noticeable if you use page down or click on the scroll bar. At least on my system, there is a noticeable delay between scrolling and the items being rendered on screen, that might be a related issue?
Those notes aside, I could definitely see value for this in cases when you want to get a glance overview or similar of a large number of notes, it's a cool idea.
_bittere
No specific reason: it's a great hashing algorithm, and the first that came to mind. I'll look into other hash functions. Thanks for the suggestion!
Yes, I believe the two are related (and related to the scroll event handler). I'll look into that too!
cmgriffing
FNV-1a might be worth looking into. It's pretty fast
minaguib
Good stuff, but if you wanna bring it up a few notches see https://everyuuid.com/
gkbrk
Is it fast by default? Every time I scroll up and down I'm looking at empty space while the notes load in. And it's not just initial network delay, even if I scroll over already loaded notes it takes time to display them.
I think it would be a lot faster to do this with native HTML.
_bittere
Native HTML? As in actually rendering the 1M divs into the DOM?
null
billconan
how do you cache heights without rendering? It seems to be a chicken-egg problem, you need to know the heights to test visibility, but without rendering, you can’t know the heights? Or heights are obtained by invisible rendering in a hidden div?
_bittere
What Seen does is render notes off-screen first, then pack them up in the container. So yes, it does use a hidden div in a way. Some CSS styling does not let you measure the height, which is why Seen uses an off-screen div.
billconan
Thank you for the tips. the off-screen div can't set display to none right? otherwise the browser will skip rendering?
null
bloomingkales
Working with fixed heights makes virtualized lists more predictable, easier to implement.
Kuinox
I have a 1k€ PC and this takes half a second to display anything when i scroll.
_bittere
You're right The speed is a major issue for everybody. I'll try my best to improve it. Thanks for checking Seen out btw!
vivzkestrel
Since you made this library, you have the knowledge to answer this very specific problem to virtual lists. If you dont mind, can you please answer https://www.reddit.com/r/webdev/comments/1imtdtv/given_20_it...
_bittere
Yeah, sure! So there's a few ways you can think about it.
In a more general case where you can make no assumptions about what you're rendering, you first render whatever is on-screen (so that you can also calculate their heights and position other elements properly). Then you render everything else off-screen, measure the total height and set that as the height for your container (for your virtual list).
Then you could implement some sort of caching for the heights to reduce recalculation for future loads.
If you can make some assumptions, there are a lot of clever ways you could even skip the rendering-then-checking-height method completely. One example I can think of is for is images; the height of an image is already present in the metadata. You just have to multiply it with some scaling factor to make it fit in your UI. That's much faster compared to checking the height after rendering.
What Seen currently does is the first. But the next version is going to do the second: finding a way to set a note's aspect ratio constant across all configurations of screen sizes, so that you no longer have to wait for all that calculation to finish.
spiddy
This reminds me of https://news.ycombinator.com/item?id=42342382 on the blog https://eieio.games/blog/writing-down-every-uuid/ they mention how they tackled various challenges such as rendering.
lelandfe
If I tap and hold the scrollbar on my iPhone and scroll around, I’m looking at a blank page the whole time because the virtual list is waiting for me to finish.
isoprophlex
they're virtually all there, though! :^)
_bittere
Oh yeah, that's a known bug. You're right, the scroll event handler is waiting for you to finish scrolling. I'm looking into it though!
helb
I get zalgo-like glitches (overlaying notes) when resizing the viewport width in Firefox. Looks kinda cool though: https://i.vgy.me/JQsqZO.png
_bittere
Oh boy... I'll have to look into why that's happening.
mousetree
Cool name! (CTO of seen.com here)
G_o_D
i have created one such in past, though not <1s but one note - 167239 character long, total 662 notes takes 10s on initial load from server and rendering then its fast, CRUD operations doesnt lag, + filtering live search also fast enough fiktering 662 notes, only 2s
Edit: Thank you so much for taking a look at Seen! Yes, I know, it's really slow. And scrolling does not render notes instantly. And the title is a bit clickbait-y. I'll try my best to improve on it though. This is just a preview, the most basic version of Seen, and it's getting there. But, oh God, I almost got a heart attack when I opened up Vercel Analytics and saw ~1,500 page views, up from 10 or 12. Thank you again! It's such a weird experience showing something to the world for the first time as a 16-year-old and seeing so many people look at it.
Hello HN! I've been working on creating a new note-taking app called Seen. Right now, it's really just a preview: virtual-list rendering ~1,000,000 notes in a masonry layout, while trying to minimize CPU and memory usage as much as possible.
Seen currently has:
- A client-side search feature
- Creating, updating, deleting the topmost note (locally; no changes are saved to any server)
- Automatic repacking of the masonry layout when the window width changes
- A lot of bugs, I'm sure
I reached a point where I thought I was ready to show the Seen to the world, and this is it. It's pretty basic, I know, but I'm really proud of it.
Seen was born out of an experiment to see just how fast things can become if you use the right techniques, and will (hopefully) achieve this dream sometime in the near future. My vision for Seen is to create something that can handle a lot of notes while using the least amount of resources. If you've got any suggestions or bugs, they're welcome in the comments!
A little about how Seen works: during the first visit, Seen caches note heights for the specific window width. Seen also caches the HTML output for the Markdown notes. It caches height by the key SHA256(title + note content), and the Markdown-to-HTML renders by the key SHA256(note content). It uses this cache every other time instead of recalculating, meaning that if most of the content remains unchanged, Seen can render things pretty fast. Caches are saved to IndexedDB.
When window width changes, the amount of text that can fit in a line also changes. So, Seen caches heights for specific window widths as well, putting the width in the key. Scrolling triggers an event handler that calculates the current viewport and finds & renders all notes that are visible (or partially visible) with a buffer of a 600px.
When a note is deleted or inserted, the entire layout is re-rendered. I plan on optimizing this to only re-render the specific column, which is what happens anyway when a note is updated. Updated notes create new caches (as they should).