nayajunimesh

5 ms·

1.
by nayajunimesh 5mo ago
I also wrote an interactive blog post sharing my thoughts on what I think makes a better markdown streaming UI here: https://nimeshnayaju.com/markdown . The library was a result of those opinions and thoughts.
2.
Show HN: Parse LLM Markdown streams incrementally on the server or client(github.com)
4 points by nayajunimesh 5mo ago|1 comments
3.
by nayajunimesh 7mo ago
Most AI chat applications (such as ChatGPT or Claude) stream their responses to the client as markdown text. As each new chunk of text arrives, the front end typically re-parses the entire markdown document to render the updated message. Th
4.
Incrementally parsing LLM Markdown streams on server/client(github.com)
2 points by nayajunimesh 7mo ago|2 comments
5.
by nayajunimesh 1y ago
That is a good point! How do you feel about fail-fast by default but being able to configure a validator to collect all errors (like Zod does by default)? Something like array(number(), { failFast: false }); We currently expose error as a t
6.
by nayajunimesh 1y ago
Hey, I did some benchmarks if you're interested - benchmarks results are in the README.md. https://github.com/nimeshnayaju/zod (Fork of Zod's repo which already included benchmarks comparing Zod 4 against Zod
7.
by nayajunimesh 1y ago
Hey, I did some benchmarks if you're interested - benchmarks results are in the README.md. https://github.com/nimeshnayaju/zod (Fork of Zod's repo which already included benchmarks comparing Zod 4 against Zod
8.
by nayajunimesh 1y ago
Hey, I did some benchmarks if you're interested - benchmarks results are in the README.md. https://github.com/nimeshnayaju/zod (Fork of Zod's repo which already included benchmarks comparing Zod 4 against Zod
9.
by nayajunimesh 1y ago
Hey, this comment was actually very helpful. While running benchmarks, I noticed my union validator was consistently underperforming, and your insight about try/catch deoptimization made it much easier to pinpoint the issue. I ended up
10.
by nayajunimesh 1y ago
Hey, thanks for the link! I was able to add the library to the benchmark quite easily. Here's the fork if you're interested: https://github.com/nimeshnayaju/valibot-benchmarks I have included the results I ob
11.
by nayajunimesh 1y ago
We actually use the idea of branded types in one of the validators (iso8601), and I also understand that it doesn't replace fully transformed values. https://github.com/nimeshnayaju/valleys?tab=readme-ov-file#i...
12.
by nayajunimesh 1y ago
I understand completely, and the library is intentionally unopinionated in that regard. We simply ensure that the value passed matches the provided schema and ruleset and refine the type in-place. In certain cases (like validating that an i
13.
by nayajunimesh 1y ago
With the fail-fast approach, yes - unless we introduce an option to collect all errors. In my own applications, I have found this to be a better default because the 'average' requests is valid and paying a constant overhead just t
14.
by nayajunimesh 1y ago
Thank you, this is quite helpful. Will take a detailed look very soon!
15.
by nayajunimesh 1y ago
We do use try/catch in a few places. However, in normal operations (valid input), no exceptions are thrown - the try/catch blocks are present in certain validators but do not execute their catch clauses. AFAIK, modern engines gene
16.
by nayajunimesh 1y ago
Yes, the primary focus is memory efficiency; performance improvement is a side effect of that. From my own benchmarks, I have found that to be the case. If you're validating thousands of objects per second or working with memory constr
17.
A lightweight TypeScript library for assertion-based runtime data validation(github.com)
30 points by nayajunimesh 1y ago|35 comments
18.
by nayajunimesh 1y ago
Most validation libraries like Zod create deep clones of your data during validation, which can impact performance in high-throughput applications. I built decode-kit to take a different approach: assertion-based validation that validates a