_bittere

The agents I used kept getting stuck trying to find the right Solar iocon to use. So I built search-solar: a dead simple CLI tool to search Solar icons based on categories and tags.

search-solar also returns an import command for using with Solar's react-perf package (https://solar-icons.vercel.app/docs/packages/react-perf)

It's fascinating to see a project like Bun, already mature enough to run in production, and yet still improving everyday even if it's a 1.1x speedup. To me, that shows how committed the team is to deliver performance.

Exams in a week! I found out that it's actually pretty easy to fill an entire 150 page notebook with rough work in <2 days.

Done, just added E2EE.

When you open Lichess to solve a puzzle:

- The server sends all puzzle information, including the solution, to the client

- The client is responsible for validating your moves

- The client is also responsible for telling the server whether you have solved the puzzle or not.

However, the client does the 3rd step by just sending a request with some formdata, which has a key called "win". Basically, the client does not send your sequence of moves to the server to have the server verify them but directly sends whether you solved the puzzle or not.

Many, including me, have discovered this bug independently and tried to report it to Lichess. I've tried contacting Lichess 2-3 years back when I originally discovered this, but Lichess has always responded with "puzzles aren't competitive; exploiting them doesn't matter." (https://github.com/lichess-org/lila/issues/16393#issuecommen...)

Admittedly, they are correct: puzzle rating doesn't really matter. So, here's a little web app I made to exploit this. You just need to copy and paste your LILA2 cookie from Lichess. Requests are made through a proxy to set the Origin header.

The source code is at: https://github.com/bittere/lisolve

Oh boy... I'll have to look into why that's happening.

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.

Thanks for the feedback! Yes, that is true; the scrolling is a big issue right now. Working on it though. Thank you for checking out Seen!

Native HTML? As in actually rendering the 1M divs into the DOM?

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!

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!

Yup, that is true. And yes, it could really be much faster. This is an early preview though, and I'm working on it!

Also, Seen does have search. The problem with making it work with Ctrl+F would be to render all 1M notes (or at least some "shadow" version of them), which would really slow everything down. But again, maybe there is some other way - speed is one of the major concerns, and I'm working on it!

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!

While that is true, it's not guaranteed that all notes will be of the same height. Some notes might have more content, some might have less; which is why we need all the fancy JavaScript rendering.

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.

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!