nayajunimesh
Joined 4 years ago
Karma
20
Submissions
18
Member since
Mar 18
Recent submissions
Comment · 6 months 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.
Comment · 8 months 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. This works, but it can quickly slow down the UI for long responses.
I’ve been obsessing over ways to make this more efficient, so I wrote a markdown parser that can parse streaming markdown (semi) incrementally. Instead of re-processing the whole document each time, it only parses what’s new, processing each line only once. Block‑level nodes are buffered until they’re complete (for example, once a paragraph is done and won’t be extended by more text).
The API is intentionally simple, but there’s an experimental mode that surfaces all finalized nodes (both top‑level and nested), so you can take more control over how and when you render.
Here’s a demo if you’d like to see it in action:
https://markdownparser.vercel.app/
I’ve spent a lot of time thinking about this problem, so if you’re working on similar issues, I'd love to chat.
Comment · 1 year 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 tree structure so that it's easy to map an error to a value or build custom error messages (we only provide debug error message) and I haven't been able to come up with a satisfactory error API that accommodates multiple error paths, but you raise an excellent point. Thanks for pointing out.
Comment · 1 year 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 3, so I simply integrated my validation library)
https://github.com/nimeshnayaju/valibot-benchmarks (An unofficial benchmark suggested in another comment comparing Valibot against Zod)
Comment · 1 year 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 3, so I simply integrated my validation library)
https://github.com/nimeshnayaju/valibot-benchmarks (An unofficial benchmark suggested in another comment comparing Valibot against Zod)
Comment · 1 year 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 3, so I simply integrated my validation library)
https://github.com/nimeshnayaju/valibot-benchmarks (An unofficial benchmark from another user comparing Valibot against Zod)
Comment · 1 year 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 updating the validation logic to not use try catch frivolously and I saw significant performance improvement.
For benchmarks, I forked Zod, which already included benchmarks comparing Zod 4 against Zod 3. Here are the results (in README.md) if you're interested:
https://github.com/nimeshnayaju/zod
I noticed significantly better performance than both Zod 3 and Zod 4 across most validation scenarios (especially validations that involved rules like min/max length, etc), with the exception of simple object parsing.
I also forked another benchmark suggested in a different comment if you're interested (I noticed similar results).
Comment · 1 year 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 obtained from running the benchmark in the README.md. I'd love for you to also take a look at the changed code to see if I may have missed something with the integration. Curious to hear your feedback too!
Comment · 1 year 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...
Comment · 1 year 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 input is ISO8601 format), we refine the input type to a branded type (we have a Iso8601 branded type). At runtime it's just a string, but at compile time TypeScript treats it as a distinct type that can only be obtained through validation. But, it is still not transforming or parsing the data in the way that the blog post intends, which is by design.
https://github.com/nimeshnayaju/valleys?tab=readme-ov-file#i...
Comment · 1 year 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 to be thorough on rare invalid cases can be wasteful.
My overall takeaway has mostly been to not optimize for the worst case by default. Keep fail-fast as baseline for boundaries and hot paths, and selectively enable “collect all” where it demonstrably saves human time.
Comment · 1 year ago
Thank you, this is quite helpful. Will take a detailed look very soon!
Comment · 1 year 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 generally don’t impose large steady-state penalties merely for the presence of a try/catch when no exception is thrown; the measurable cost is usually when exceptions are actually thrown. When an element/property fails, the catch is used to construct precise error paths. That’s intentionally trading some failure-path overhead for better developer diagnostics.
In the new few days, I'll prepare benchmarks to compare with Zod and Valibot!