DEV Community: Dmitry Zakharov

I Ditched My Keyboard for Voice Coding 🎙️

Dmitry Zakharov — Wed, 08 Apr 2026 10:22:00 +0000

This is something that wouldn't be possible even five months ago. The tools to write with voice already existed, but dictating all the brackets and quotes in a programming language? A nightmare. But then AI changed everything.

I'm working at Envio, the fastest blockchain data provider and indexing tooling, and today I'm able to write 100% of my code using AI. So instead of dictating code itself, I use my voice to tell Claude which code it should write. This is the key insight that makes voice coding actually viable.

But let me start from the beginning.

Why I wanted to ditch the keyboard

My main motivation was frustration with the ergonomic setup. I got really used to the Mac keyboard, but working on my laptop is a painful experience for my neck and wrists. For a long time, I wanted to move away from the laptop keyboard to something else. I bought an MX Ergo S mouse and a Glove80 split keyboard, but the learning curve to switch to them was just too much for me.

So I thought — what if I try to get rid of the keyboard completely? Instead of learning to type on a new split keyboard, what if I start speaking instead? Speaking is sometimes even faster than writing. In my case, it's not such a big benefit because I type quite fast, but when you're in a flow, it might win you a few seconds.

WhisperFlow: The first try

I started my experience with WhisperFlow — my colleagues recommended it to me. It was good, but not good enough. So I postponed it for a few months.

But then I finally decided that I'm going to stop using my laptop keyboard. I need a change. Next week, I'm going to start using WhisperFlow 100%. Through friction, but I'll do this.

I quite quickly reached the 2,000 words quota, so I upgraded to the pro plan. The experience was actually quite decent. My workflow is fully AI-driven — I use Claude to write all the code, giving it detailed instructions and following best practices of AI-driven development. And it worked quite well with voice, with some learning period, but it didn't make me sacrifice my performance.

But there were frustrating things. WhisperFlow quite often didn't get me right. The auto-correction helped in some cases, but it didn't fire 100% of the time. You still had to reread the output and fix it from time to time.

Initially, I started fixing errors with the keyboard. But by the second day, I finally switched to MX Ergo as my mouse and used it to select the text with errors. Then I used WhisperFlow again to re-dictate correctly. This worked quite decently.

There's also a command mode where you can select some part of the text, say a command like "fix grammar" or "make this sound more professional", and it sends it to an LLM to return a modified output. An interesting feature, but after discovering it, I actually never used it. The times I tried to use it on a big text to fix grammar, it just said servers are overloaded. So it didn't work. But I think this has decent potential.

Switching to Aqua Voice

After working with WhisperFlow for a week, I had frustrations with it getting only about 80% of my speech right and the need to frequently correct it. So I asked Claude to recommend me a more accurate and fast solution for voice typing. It suggested Aqua Voice, saying that a lot of Reddit users praise its accuracy and speed — they use their own model.

I decided to give it a try. The subscription costs $10, compared to $15 for WhisperFlow. Their own model was available only on the paid plan, and the free model didn't work well.

Aqua Voice was faster, but the accuracy was maybe only a few percent better than WhisperFlow. If you want more accuracy, in my experience, there's almost no difference.

What was frustrating in Aqua Voice is the much worse awareness of cursor placement. In WhisperFlow, if you place your cursor somewhere in the middle of the text and dictate a few words, it just puts them perfectly there. But Aqua Voice always capitalizes the words and adds a dot at the end — super frustrating when editing already written text.

Aqua Voice claims a feature where they can access your page, see the words already present, and use them as context. But I didn't see it used well. They also don't have a command mode like WhisperFlow has (which I didn't use anyway). Still, I think this might be the future of voice typing, so I'd like to have it in my arsenal.

WhisperFlow vs Aqua Voice: The verdict (so far)

	WhisperFlow	Aqua Voice
Accuracy	~80%	Slightly better
Cursor awareness	Great	Frustrating
Command mode	Yes	No
Price	$15/mo	$10/mo
Speed	Good	Faster

For now, I'm going to try switching back to WhisperFlow because I really value the ability to edit parts of written text with voice. Maybe my experience will be frustrating — usually it's much easier to notice when something got worse than subtle improvements. If so, I'll update this article after a few more weeks.

The results

I'm only two weeks into this. This article itself was dictated with Aqua Voice, with some AI formatting afterwards. But here's what I can already say:

My neck got much more relaxed. I almost don't type anything unless I need to write some really specific numbers or code examples for documentation. I also started using a stand for my laptop and having the monitor in a better position for my neck. The Glove80 is still not used — I use the F5 button to start voice dictating on my laptop standing on a stand. It's a bit tough on the hands to reach for it in that position, but it's already much better than it used to be.

I'm quite happy with how it goes. I think voice dictating is the future of programming and how we interact with AI.

What about Claude's built-in voice input?

You might be wondering — Claude has voice input, why not just use that? I tried it, and I didn't like it. The problem is that it automatically sends the message when you finish talking, so you don't have time to actually think.

The way I use a dictating tool is: I press F5 once and start speaking, sometimes with long pauses to think about what I want to say next. When you're typing, it's easier to structure your thoughts — you can pause, reread, adjust. Then I press F5 again to commit the message. With Claude's built-in voice input, whenever you have a pause for a few seconds to think, it just immediately submits what you've said and starts answering you, even though you're not done yet.

Another benefit of a standalone dictation tool is that it works everywhere. I use it in Claude, in Discord, in Telegram, in my editor — anywhere I need to type. I even started using voice dictation on my iPhone via the free Microsoft SwiftKey keyboard app.

If you have any recommendations about other voice dictating tools I should try, give me a suggestion. Follow me on X, and if you're curious, check out HyperIndex — the project I'm working on at Envio. It's an ultra-fast open-source indexing framework for blockchain data, and you can see how my daily work looks like.

Zod v4 got 17x Slower than v3 🚦

Dmitry Zakharov — Sat, 03 May 2025 16:56:00 +0000

Hey everyone! 👋

I'm Dmitry, the creator of Sury—the fastest schema library out there. If you’re a fan of Zod (and who isn’t?), you’ll want to read this. Today, I want to share some surprising findings about Zod v4’s performance, what it means for you, and how to avoid the pitfalls.

Zod v4: 17x Slower? Not Quite, But...

Let’s start with a little clickbait:

Zod v4 became 17 times slower, and nobody noticed 🙈

This is 100% true, but of course, that’s not the whole story. Let’s dig in.

Recently, while prepping for the big Sury v10 release, I decided to rerun my benchmarks with Zod v4. The results? Fascinating.

For a non-trivial schema, Zod v4 is now 8x faster than before.
But when you create a schema and use it just once (a common pattern in React components), performance drops significantly—down to about 6 ops/ms.

You might think, “6 ops/ms is still fast!” But in UI-heavy apps, every millisecond counts. If you’re using Zod in your React components, this could mean a noticeable performance hit.

Schema from the benchmark

import { z } from "zod"; // 13.5 kB (min + gzip)

const zodSchema = z.object({
  number: z.number(),
  negNumber: z.number(),
  maxNumber: z.number(),
  string: z.string(),
  longString: z.string(),
  boolean: z.boolean(),
  deeplyNested: z.object({
    foo: z.string(),
    num: z.number(),
    bool: z.boolean(),
  }),
});

What Changed in Zod v4?

My hunch was that Zod v4 started using eval (or, more precisely, JIT compilation via new Function) for validation. This isn’t a bad thing — libraries like TypeBox, ArkType, and even Sury use similar techniques for speed.

But there’s a tradeoff:

Schema creation becomes slower (because of the JIT compilation step).

Although, it's not a problem for most users, because:

Validation becomes much faster (once the schema is compiled and used multiple times).

Zod v3 was already a bit slow at schema creation, but v4 takes it further. If you’re creating schemas on the fly (again, think React), you might feel the slowdown.

Is Eval/JIT Bad? Not Really.

There’s a common myth that eval/new Function is always slow or unsafe. In reality, when used carefully, it can unlock incredible performance. Sury leans heavily on JIT compilation and is still almost on par with Valibot, which is designed for quick initialization.

Here’s a quick comparison (min + gzip):

Library	Import Size	Parse (same schema)	Create & Parse Once
Sury	4.27 kB	94,828 ops/ms (JIT only)	166 ops/ms
Zod v3	13.5 kB	1,191 ops/ms (no JIT)	93 ops/ms
Zod v4	13.5 kB	8,437 ops/ms	6 ops/ms
Valibot	1.23 kB	1,721 ops/ms (no JIT)	287 ops/ms
TypeBox	22.8 kB	99,640 ops/ms (only assert support)	111 ops/ms
ArkType	45.8 kB	67,552 ops/ms	11 ops/ms

Full comparison in Sury’s README

What Should Zod Users Do?

If you’re using Zod in a backend or for long-lived schemas, you’ll love the new speed. But if you’re creating schemas dynamically (like in React components), you might want to benchmark your app or consider alternatives.

Zod v4 does offer both normal and JIT-optimized parsing, so you might be able to tweak your usage. But it’s worth being aware of the tradeoffs.

Also, there should be a way to disable JIT compilation for those who don't want it. I don't know the exact API or whether it's exposed, but I've seen that this option exists in Zod's internals.

Enter Sury: The Fastest Schema Library

Okay, shameless plug time! 😅

I built Sury to solve exactly these problems:

Blazing fast parsing and validation (thanks to JIT)
Tiny bundle size and tree-shakable API
Great TypeScript inference and developer experience
Standard Schema and JSON Schema support out of the box
Declarative transformations and automatic serialization

Sury is already used in production by many companies and is compatible with tools like tRPC, TanStack Form, Hono, and more.

Here’s what using Sury looks like:

import * as S from "sury";

const filmSchema = S.schema({
  id: S.bigint,
  title: S.string,
  tags: S.array(S.string),
  rating: S.union(["G", "PG", "PG13", "R"]),
});
// On hover: S.Schema<{ id: bigint; title: string; tags: string[]; rating: "G" | "PG" | "PG13" | "R"; }, Input>

type Film = S.Output<typeof filmSchema>;
// On hover: { id: bigint; title: string; tags: string[]; rating: "G" | "PG" | "PG13" | "R"; }

S.parseOrThrow(
  {
    id: 1n,
    title: "My first film",
    tags: ["Loved"],
    rating: "S",
  },
  filmSchema
);
// Throws S.Error with message: Failed at ["rating"]: Expected "G" | "PG" | "PG13" | "R", received "S"

// Or do it safely:
const result = S.safe(() => S.parseOrThrow(data, filmSchema));
if (result.error) {
  console.log(result.error.reason);
  // Expected "G" | "PG" | "PG13" | "R", received "S"
}

And yes, Sury also uses JIT under the hood, but with a focus on both creation and validation speed.

Final Thoughts

Zod v4 is a fantastic library, and Colin (the author) did an amazing job supporting both normal and JIT-optimized parsing.
If you care about performance—especially in dynamic or UI-heavy scenarios — benchmark your usage.
If you want the fastest schema validation, smallest bundle, and next-gen DX, give Sury a try. (And if you like it, a GitHub star would make my day! ⭐)

Thanks for reading! If you have questions, feedback, or want to see more benchmarks, let me know in the comments or ping me on X. See you soon with more updates! 🚀

Welcome Sury - The fastest schema with next-gen DX 🚀

Dmitry Zakharov — Mon, 28 Apr 2025 18:45:14 +0000

Recently I wrote a comprehensive article about a JavaScript Schema library from the future where I introduced ReScript Schema and demonstrated some truly groundbreaking features you won't find in any other library. I highly recommend checking it out first.

While the feedback was overwhelmingly positive, I noticed that despite having TypeScript support, many developers were hesitant simply because of "ReScript" in the name. So after months of dedicated development, I'm excited to present you Sury - a TypeScript-first schema validation library that brings all those amazing features while staying true to its ReScript roots 🔥

What is Sury?

It's a schema library you'll definitely want to use:

API that's easy to read and write, similar to TS types and without noise
Nice type inference with real types on schema hover
The fastest parsing with explicit throws
Convenient error handling with readable error messages
And more after the code example ☺️

import * as S from "sury";

const filmSchema = S.schema({
  id: S.bigint,
  title: S.string,
  tags: S.array(S.string),
  rating: S.union(["G", "PG", "PG13", "R"]),
});
// On hover: S.Schema<{ id: bigint; title: string; tags: string[]; rating: "G" | "PG" | "PG13" | "R"; }, Input>

type Film = S.Output<typeof filmSchema>;
// On hover: { id: bigint; title: string; tags: string[]; rating: "G" | "PG" | "PG13" | "R"; }

S.parseOrThrow(
  {
    id: 1n,
    title: "My first film",
    tags: ["Loved"],
    rating: "S",
  },
  filmSchema
);
// Throws S.Error with message: Failed at ["rating"]: Expected "G" | "PG" | "PG13" | "R", received "S"

// Or do it safely:
const result = S.safe(() => S.parseOrThrow(data, filmSchema));
if (result.error) {
  console.log(result.error.reason);
  // Expected "G" | "PG" | "PG13" | "R", received "S"
}

Honestly, I think that's already enough to make you like Sury and want to try it in your next project, or at least leave a star on GitHub ⭐

Well, probably that's still a lot to ask for, since I've only shown ~10% of the features so far 😅

Let's continue with the ecosystem talk - the most important part of any library.

Ecosystem

Standard Schema

Set aside the performance, transformations, and serialization features for now, even though they're some of the library's greatest strengths. These features become truly valuable once you have a robust ecosystem to use them with - which was the main focus of the Sury (ReScript Schema v10) release.

A major enhancement is native support for Standard Schema, which is already integrated with over 32 popular libraries. Previous versions required explicitly calling S.toStandard, but now every Sury schema automatically implements the Standard Schema interface.

Here's an example from the newly released oRPC showing how to replace Zod with Sury:

import { ORPCError, os } from '@orpc/server'
- import { z } from 'zod'
+ import * as S from 'sury'

export const listPlanet = os
  .input(
-   z.object({
-     limit: z.number().int().min(1).max(100).optional(),
-     cursor: z.number().int().min(0).default(0),
-   }),
+   S.schema({
+     limit: S.optional(S.int32.with(S.min, 1).with(S.max, 100)),
+     cursor: S.optional(S.int32.with(S.min, 0), 0),
+   })
  )
  .handler(async ({ input }) => {
    // your list code here
    return [{ id: 1, name: 'name' }]
  })

And it just works - faster, smaller and more flexible 👍
You may notice the .with calls which might look unfamiliar. This is a new feature introduced in this release that I'll definitely talk about later.

JSON Schema

But what's more important and much more widely used is JSON Schema. I used to support it only for ReScript users, but now it's time to share some gold with TypeScript users as well 🫡

// 1. Create some advanced schema with transformations
//    S.to - for easy & fast coercion
//    S.shape - for fields transformation
//    S.meta - with examples in Output format
const userSchema = S.schema({
  USER_ID: S.string.with(S.to, S.bigint),
  USER_NAME: S.string,
})
  .with(S.shape, (input) => ({
    id: input.USER_ID,
    name: input.USER_NAME,
  }))
  .with(S.meta, {
    description: "User entity in our system",
    examples: [
      {
        id: 0n,
        name: "Dmitry",
      },
    ],
  });
// On hover:
// S.Schema<{
//     id: bigint;
//     name: string;
// }, {
//     USER_ID: string;
//     USER_NAME: string;
// }>

// 2. Use built-in S.toJSONSchema and see how everything in the Input format
//    It's just asking to put itself to Fastify or any other server with OpenAPI integration 😁
S.toJSONSchema(userSchema);
// {
//   type: "object",
//   additionalProperties: true,
//   properties: {
//     USER_ID: {
//       type: "string",
//     },
//     USER_NAME: {
//       type: "string",
//     },
//   },
//   required: ["USER_ID", "USER_NAME"],
//   description: "User entity in our system",
//   examples: [
//     {
//       USER_ID: "0",
//       USER_NAME: "Dmitry",
//     },
//   ],
// }

Offtopic: Serialization

In the example above I used several advanced features of the library. Let's take a moment to explore one of Sury's most powerful capabilities - bidirectional schemas. Every schema can both parse and serialize data without needing separate decoders or encoders.

Let's see how this works with our previous example:

// You can use it for parsing Input to Output
S.parseOrThrow(
  {
    USER_ID: "0",
    USER_NAME: "Dmitry",
  },
  userSchema
);
// { id: 0n, name: "Dmitry" }
// See how "0" is turned into 0n and fields are renamed

// And reverse the schema and use it for parsing Output to Input
S.parseOrThrow(
  {
    id: 0n,
    name: "Dmitry",
  },
  S.reverse(userSchema)
);
// { USER_ID: "0", USER_NAME: "Dmitry" }
// Just use `S.reverse` and get a full-featured schema with switched `Output` and `Input` types
// Note: You can use `S.reverseConvertOrThrow(data, schema)` if you don't need to perform validation

And while we're at it, I'll quickly show why Sury is the fastest schema library out there. Sury heavily relies on JIT optimizations by inlining all validations and transformations using new Function. It's not something new and used by other libraries like TypeBox, ArkType and even Zod@4. But they mostly do basic validations, while Sury embraces transformations as it's core primitive:

// This is how S.parseOrThrow(data, userSchema) is compiled
(i) => {
  if (typeof i !== "object" || !i) {
    e[3](i);
  }
  let v0 = i["USER_ID"],
    v2 = i["USER_NAME"];
  if (typeof v0 !== "string") {
    e[0](v0);
  }
  let v1;
  try {
    v1 = BigInt(v0);
  } catch (_) {
    e[1](v0);
  }
  if (typeof v2 !== "string") {
    e[2](v2);
  }
  return { id: v1, name: v2 };
};

// This is how S.reverseConvertOrThrow(data, userSchema) is compiled
(i) => {
  let v0 = i["id"];
  return { USER_ID: "" + v0, USER_NAME: i["name"] };
};

Neat, right? 🤯

Internal Representation

Let's go back to ecosystem talk. While Sury provides JSON Schema integration out of the box, having a good internal representation is crucial for a schema library. It enables building custom tools and growing the ecosystem. In this version, I've made significant progress by representing every schema as a discriminated union, similar to JSON Schema.

This design allows you to easily reason about and work with the Input and Output types of your schemas in your code. Here's another advanced example of Sury usage where you can use the internal representation of the input type, to create a dynamic schema for parsing environment variables:

const envSchema = <T>(schema: S.Schema<T>): S.Schema<T, string> => {
  if (schema.type === "boolean") {
    return S.union([
      S.schema("t").with(S.to, S.schema(true)).with(S.to, schema),
      S.schema("1").with(S.to, S.schema(true)).with(S.to, schema),
      S.schema("f").with(S.to, S.schema(false)).with(S.to, schema),
      S.schema("0").with(S.to, S.schema(false)).with(S.to, schema),
      S.string.with(S.to, schema),
    ]);
  } else if (
    schema.type === "number" ||
    schema.type === "bigint" ||
    schema.type === "string"
  ) {
    return S.string.with(S.to, schema);
  } else {
    return S.jsonString(schema);
  }
};

S.parseOrThrow("1", envSchema(S.boolean)); // true
S.parseOrThrow("1", envSchema(S.schema(true))); // true
S.parseOrThrow("1", envSchema(S.number)); // 1
S.parseOrThrow("1", envSchema(S.bigint)); // 1n
S.parseOrThrow("1", envSchema(S.string)); // "1"
S.parseOrThrow("[0, 1, 2]", envSchema(S.array(S.int32))); // [0, 1, 2]
S.parseOrThrow("1", envSchema(S.boolean.with(S.shape, (input) => {
  field: input,
}))); // {field: true}
S.parseOrThrow("true", envSchema(S.number)); // Failed parsing: Expected number, received "true"

This demonstrates how the schema's input type information can be used to modify the schema dynamically, while preserving the original output type that we want.

Sury Ecosystem Future

The Environment Variable example is inspired by my library ReScript EnvSafe, which enables ReScript users to safely access environment variables using Sury. Over 3 years of Sury development, I've built many tools on top of it. While some remained internal, others evolved into powerful ReScript libraries like ReScript Rest and ReScript Stripe.

I believe porting these libraries to TypeScript will make them even more powerful and accessible to a wider audience.

Furthermore, since libraries like ReScript Rest and ReScript EnvSafe are fundamental to most projects, I plan to integrate them directly into the core Sury library:

// Comming soon ↓

import * as S from "sury";
import { handler } from "@sury/fastify";
import Fastify from "fastify";

const config = S.config((s) => ({
  port: s.env("PORT", S.number.with(S.port), { devFallback: 3000 }),
  host: s.env("HOST", S.string, { devFallback: "localhost" }),
  debug: s.arg("--debug", S.optional(S.boolean, false)),
}));
// It'll throw if the env variables are not provided
// unless NODE_ENV is "development"

const getPosts = S.route({
  path: "/posts",
  method: "GET",
  input: (s) => ({
    skip: s.query("skip", S.int32),
    take: s.query("take", S.int32),
  }),
  responses: [(s) => s.data(S.array(postSchema))],
});
// A simple example with query params,
// but it also supports body, headers, path params

console.log(S.curl(getPosts, { skip: 0, take: 10 }));
// curl -X GET /posts?skip=0&take=10

const fastify = Fastify({
  logger: true,
});
// Fastify is just an example. It can be any other framework

handler(fastify, getPosts, ({ input }) => {
  console.log(input); // { skip: 0, take: 10 }
  return [{ id: 1, title: "Post 1" }];
});
// A simple RPC like API. You don't need to think about the transport layer at all

fastify.listen({ port: config.port, host: config.host });

S.fetch(getPosts, { skip: 0, take: 10 });
// fetch("/posts?skip=0&take=10")

The example already works for ReScript users and would be a great addition for TypeScript users as well. In the next version of the library, I'll focus on polishing the features and making them part of the Sury ecosystem. And thanks to the tree-shakable API they won't be included in the final bundle if you don't use them.

New API Features

Coming back to the current Sury release I promised to explain some new API changes in detail.

S.with

S.number.with(S.min, 1);

From the version every schema comes with the .with method. It's a tiny sucrifice for the tree-shakable API, but it allows to modify schemas in a more readable way. Originally you'd write:

S.min(S.number, 1);

Might not be bad with a single modifier, but what if you need to apply multiple ones?

S.optional(S.max(S.min(S.number, 1), 100), 1);

Damn, that's a lot of noise just to apply a few modifiers.

This was a problem with a modular API, so I've added a new .with method which is as simple as:

function with(fn, ...args) {
  return fn(this, ...args)
}

And it even works with custom helpers you define:

const even = (schema) =>
  schema.with(S.refine, (n, s) => {
    if (n % 2 !== 0) {
      throw s.fail("Expected even number");
    }
  });

S.number.with(even);

Thanks to this, Sury has a modular API with good tree-shaking, making it 3 times smaller than Zod@4 by default, while staying very readable and using simple functions.

In the next version I'll also extend it to modify validation error messages:

// Coming soon ↓

S.string.with("Your value must be a string");

S.min

Nothing much to say here. All modifiers became polymorphic and can accept any schema as an argument:

S.min(S.int32, 3);
S.min(S.string, 3);
S.min(S.array(S.number), 3);

S.meta

Inspired by zod@4 release I added S.meta API. It's a simple way to add metadata to your schemas:

const schema = S.schema({
  foo: S.string,
}).with(S.meta, {
  description: "User entity in our system",
  examples: [{ foo: "bar" }],
});

You can use it with S.toJSONSchema or directly by accessing the schema fields:

console.log(schema.description); // "User entity in our system"
console.log(schema.examples); // [{ foo: "bar" }]

S.to

Added in the previous release as S.coerce and renamed to S.to. But it's worth mentioning again and again.

This API quicky became the heart of Sury and allows to transform data from one type to another. The most optimised implementation under the hood and automatic serialization support.

const schema = S.string.with(S.to, S.union([S.number, S.boolean]));

S.parseOrThrow("1", schema); // 1
S.parseOrThrow("true", schema); // true
S.parseOrThrow("foo", schema); // Failed parsing: Expected number | boolean, received "foo"
S.reverseConvertOrThrow(1, schema); // "1"
S.reverseConvertOrThrow(true, schema); // "true"

Might not look like a big deal, but I'm very close to make the feature even more powerful and flexible:

// Coming soon ↓

const userSchema = S.schema({
  id: S.bigint,
  name: S.string,
});

S.parseOrThrow(
  {
    id: "1",
    name: "John",
  },
  userSchema.with(S.to, S.jsonable)
); // { id: 1n, name: "John" }
// Automatically convert bigint to string
// and makes other fields compatible to JSON

S.reverseConvertOrThrow(
  { id: 1n, name: "John" },
  userSchema.with(S.to, S.jsonable)
); // { id: "1", name: "John" }
// Instead of using JSON.stringify, inlines JSON by itself in the fastest way

What's next?

Sury RC is already out and ready to use. Might be early in some places, but the core API been used in production by many companies for almost 3 years and decently reliable.

Definetely give it a try and leave a star if you like the library!

https://github.com/DZakh/sury

From my side I'll continue working on the library and adding more features.

And if you have any suggestions or feedback, please let me know!

Q&A

What about ReScript support?

I primarily use ReScript and am one of the core maintainers of the language. I'll definitely continue to support it. Even though TypeScript is the main focus now, ReScript users also greatly benefit from the changes.

What about `new Function`?

Sury uses new Function under the hood. This approach makes it the fastest schema library available, but also means it cannot be used in environments that don't allow dynamic code evaluation, like CloudFlare Workers. Most users won't be affected, but might be an issue for some. Regarding safety of the approach you shouldn't be worried. Everything embeded to the generated code is escaped and thoroughly tested. Also, other libraries like TypeBox and Zod@4 use new Function under the hood as well.

What about Zod?

I'm a big fan of Zod and find it the best choice regarding the ecosystem and developer experience it provides. Although, despite its large size, it's tailored more toward the frontend world. If you're developing a backend or an application with high throughput, you should definitely give Sury a try.

What about TypeBox?

TypeBox is another great library, but it's tailored more toward validation rather than transformations. Also, I find TypeBox's API not as readable as Sury's. But the library definitely has some great ideas to get inspired by, such as having JSON Schema as a first-class citizen. I strongly consider adding this for Sury v11.

What about X?

There are many other great libraries out there, and some provide features that Sury currently lacks, such as multi-error support and global error message customization. However, Sury stands out by excelling across many important aspects:

Readable API
TypeScript inference
Performance
Bundle size
Tree-shakable API
Extensibility
Serialization
Asynchronous parsing
Standard Schema & JSON Schema support

I'll write a separate honest deep comparison article soon, but for now I'll leave you with a table comparing Sury with other popular libraries:

	Sury@10.0.0-rc.0	Zod@4.0.0-beta	TypeBox@0.34.33	Valibot@1.0.0	ArkType@2.1.20
Total size (min + gzip)	14.1 kB	25.9 kB	31.4 kB	12.6 kB	45.9 kB
Benchmark size (min + gzip)	4.27 kB	13.5 kB	22.8 kB	1.23 kB	45.8 kB
Parse with the same schema	94,828 ops/ms	8,437 ops/ms	99,640 ops/ms (No transforms)	1,721 ops/ms	67,552 ops/ms
Create schema & parse once	166 ops/ms	6 ops/ms	111 ops/ms (No transforms)	287 ops/ms	11 ops/ms
JSON Schema	`S.toJSONSchema`	`z.toJSONSchema`	👑	`@valibot/to-json-schema`	`T.toJsonSchema`
Standard Schema	✅	✅	❌	✅	✅
Eval-free	❌	⭕ opt-out	⭕ opt-in	✅	⭕ opt-out
Codegen-free (Doesn't need compiler)	✅	✅	✅	✅	✅
Infered TS Type	`S.Schema<{foo: string}, {foo: string}>`	`z.ZodObject<{foo: z.ZodString}, {}>`	`TObject<{foo: TString}>`	`v.ObjectSchema<{readonly foo: v.StringSchema<undefined>}, undefined>`	`Type<{foo: string}, {}>`
Ecosystem	⭐️⭐️	⭐️⭐️⭐️⭐️⭐️	⭐️⭐️⭐️⭐️⭐️	⭐️⭐️⭐️	⭐️⭐️

What about me?

I'm a full-stack developer building the fastest Block Chain indexer. I'm also a core maintainer of ReScript language and creator of many open-source libraries.

And finally, I think it's time to wrap up and get back to building Sury!

Thanks for reading and see you on X 🫡

JavaScript schema library from the Future 🧬

Dmitry Zakharov — Fri, 21 Feb 2025 18:01:18 +0000

ReScript Schema - The fastest parser in the entire JavaScript ecosystem with a focus on small bundle size and top-notch DX.

Why did you not hear about it then, and why should you learn about it now? I started developing the library three years ago, and today, it's at a point others have yet to achieve. I'll prove it in the article, but before we start, I'd like to answer a few questions you might already have.

What's a parser?

One of the most basic applications of ReScript Schema is parsing - Accepting unknown JavaScript data, validating it, and returning the result of your desired type. There are dozens of such libraries, and the most popular ones are Zod, Valibot, Runtypes, Arktype, Typia, Superstruct, Effect Schema, and more. Also, even though this is slightly different, validation libraries like Ajv, Yup, and others also stand really close.

Is ReScript Schema faster than all of them?

Yes. It's ~100 times faster than Zod and on par with Typia or Arktype (benchmark). But often, besides validation, you want to transform data incoming to your system, and here, ReScript Schema overperforms any solution existing in the JavaScript ecosystem.

What's ReScript? Isn't the library for JavaScript/TypeScript?

ReScript is a robustly typed language that compiles to efficient and human-readable JavaScript. And yes, ReScript Schema is written in ReScript, but it also has a really nice JavaScript API with TS types. You don't need to install or run any compiler; npm i rescript-schema is all you need.
It makes ReScript Schema support 3 languages - JavaScript, TypeScript, and ReScript. This is especially nice when you mix TypeScript and ReScript in a single codebase 👌

Are there trade-offs?

Yes. To maximize DX, performance, and bundle size while keeping the library fully runtime, I've decided to use eval under the hood. You needn't worry about the code's dangerous execution, but some environments, like Cloudflare Workers, won't work. In 99% of cases, you don't need to be concerned about this. I just think it's my duty as a creator to let you know about the 1% beforehand.

What's the plan?

I'm going to provide an overview of the basic ReScript Schema API and mental model. Then, we'll discuss what makes it stand out from millions of similar libraries (and this is not only performance). I'll also look at some more advanced use cases and discuss the ecosystem, performance, and where it stands with other libraries.

I hope you'll enjoy it. 😊

Follow me on X to learn more about programming stuff I'm cooking.

Parsing / Validating

Let's start with the most basic use case of ReScript Schema. By the way, if you don't know the difference between parsing (sometimes called decoding) and validating, here's a good article from Zod's docs. If you're curious about when and why you need to parse data in your application, let me know in the comments. I can write a big article about it, but for now, I assume you are already familiar with the concept.

Let's finally take a look at the code. I'll go with the TypeScript example first, so it's more familiar for most readers. Everything starts with defining a schema of the data you expect:

import * as S from "rescript-schema";

const filmSchema = S.schema({
  id: S.number,
  title: S.string,
  tags: S.array(S.string),
  rating: S.union(["G", "PG", "PG13", "R"])
})

The schema here is like a type definition that exists in runtime. If you hover over the filmSchema, you'll see the following type:

S.Schema<{
 id: number;
 title: string;
 tags: string[];
 rating: "G" | "PG" | "PG13" | "R";
}>

This is a Schema type that inferred the film object definition. I recommend extracting its value into its own type. This way, you'll have the schema as the source of truth and the Film type always matching the schema:

type Film = S.Output<typeof filmSchema>

After we've defined our Film type using the schema, we can parse unknown data entering our application to guarantee that it matches what we expect:

S.parseOrThrow(
  {
    id: 1,
    title: "My first film",
    tags: ["Loved"],
    rating: "S",
  },
  filmSchema,
);
//? Throws RescriptSchemaError with message `Failed parsing at ["rating"]. Reason: Expected "G" | "PG" | "PG13" | "R", received "S"`

S.parseOrThrow(validDataWithUnknownType, filmSchema)
//? Returns value of the Film type


// If you don't want to throw, you can wrap the operations in S.safe and get S.Result as a return value
S.safe(() => S.parseOrThrow(data, filmSchema))

Done! We have valid data here 🙌

Some experienced users may have noticed that the API is similar to Valibot, but with a unique flavor.

You can use S.schema for objects, tuples, and literals. For any kind of union, there's S.union; even if it's a discriminated one, the parser will perform in the most optimized way. I personally have seen this kind of DX only in ArkType so far.

Also, there are no annoying parentheses; the parse function explicitly says it can throw, and thanks to the modular design, the library tree-shaking is very good.

Package size

Since I mentioned tree-shaking, I'd like to quickly note about the package size. The bundle size is an essential metric for a web application, and I'd like to share how ReScript Schema is doing here in comparison with other libraries:

	rescript-schema@9.2.2	Zod@3.24.1	Valibot@1.0.0-beta.14	ArkType@2.0.4
Total size (minified + gzipped)	12.7 kB	15.2 kB	12.3 kB	40.8 kB
Example size (minified + gzipped)	5.14 kB	14.5 kB	1.39 kB	40.7 kB
Playground	Link	Link	Link	Link

It's not as amazing as Valibot, but ReScript Schema is definitely doing good here. If we compare ReScript Schema to libraries that have similar performance, they all use the code generation approach (besides ArkType). This means it'll start small, but for every new type, more and more code will be added to your bundle, rapidly increasing the application size.

Parsing using ReScript

Even though I want to make ReScript Schema popular for TS developers, ReScript is still the library's main user base, so I'll also include examples of it.

Compared to TypeScript, the type system in ReScript is much simpler; you literally can't do any type gymnastics in it. Together with nominal typing, it's getting impossible to extract the film type from the schema (even though it can infer it). But there's a built-in way to prevent boilerplate code in ReScript. You can use ReScript Schema PPX to generate schemas for your types automatically. Just annotate them with @schema attribute.

@schema
type rating =
 | @as("G") GeneralAudiences
 | @as("PG") ParentalGuidanceSuggested
 | @as("PG13") ParentalStronglyCautioned
 | @as("R") Restricted
@schema
type film = {
 id: float,
 title: string,
 tags: array<string>,
 rating: rating,
}

Does the rating type look scary to you? Don't worry, this is a ReScript Variant, which is such a nice way to describe any kind of union. Also, you can use @as and give a better name to the ratings while preserving the original short values in runtime.

Although PPX is nice, you can always code without it:

type rating =
 | @as("G") GeneralAudiences
 | @as("PG") ParentalGuidanceSuggested
 | @as("PG13") ParentalStronglyCautioned
 | @as("R") Restricted
type film = {
 id: float,
 title: string,
 tags: array<string>,
 rating: rating,
}

let filmSchema = S.schema(s => {
  id: s.matches(S.number),
  title: s.matches(S.string),
  tags: s.matches(S.array(S.string)),
  rating: s.matches(S.union([
    GeneralAudiences,
    ParentalGuidanceSuggested,
    ParentalStronglyCautioned,
    Restricted
  ]))
})

The TS API admittedly wins here since we don't need to call s.matches to make type system happy, but when it comes to parsing ReScript takes it back with the Pipe Operator and Pattern Matching on exceptions:

{
  "id": 1,
  "title": "My first film",
  "tags": ["Loved"],
  "rating": "S",
}->S.parseOrThrow(filmSchema)
//? Throws RescriptSchemaError with message `Failed parsing at ["rating"]. Reason: Expected "G" | "PG" | "PG13" | "R", received "S"`

validDataWithUnknownType->S.parseOrThrow(filmSchema)
//? Returns value of the film type

// If you don't want to throw, you can match on the S.Raised exception and return the result type. There's no S.safe API like in TypeScript, since you can do better with the language itself!
switch data->S.parseOrThrow(filmSchema) {
| film => Ok(film)
| exception S.Raised(error) => Error(error)
}

Unique Features

After we covered the most basic use case, let's move on to the things that make ReScript Schema special 🔥

Changing shape and field names

Let's imagine working with a weird REST API with poorly named fields in PascalCase, where data is randomly nested in objects or tuples. But we can't change the backend, so at least we want to transform data to a more convenient format for our application. In ReScript Schema you can make it in a declarative way, which will result in the most possibly performant operation:

const filmSchema = S.object((s) => ({
  id: s.field("Id", S.number),
  title: s.nested("Meta").field("Title", S.string),
  tags: s.field("Tags_v2", S.array(S.string)),
  rating: s.field("Rating", S.schema([S.union(["G", "PG", "PG13", "R"])]))[0],
}));

S.parseOrThrow(
  {
    Id: 1,
    Meta: {
      Title: "My first film",
    },
    Tags_v2: ["Loved"],
    Rating: ["G"],
  },
  filmSchema
);
//? { id: 1, title: "My first film", tags: ["Loved"], rating: "G" }

Looks scary? Let's dive in. First of all, every schema has Input and Output. Quite often, they are equal, and during parsing, the library only validates that Input has the correct type and returns it immediately. Although there are ways to change the expected Output type like we do in the example above. For comparison, let's take a look at how you'd usually achieve the same with other schema libraries:

const filmSchema = S.transform(
  S.schema({
    Id: S.number,
    Meta: {
      Title: S.string,
    },
    Tags_v2: S.array(S.string),
    Rating: S.schema([S.union(["G", "PG", "PG13", "R"])]),
 }),
 (input) => ({
    id: input.Id,
    title: input.Meta.Title,
    tags: input.Tags_v2,
    rating: input.Rating[0],
 })
);

This is still ReScript Schema, but we use S.transform to manually transform the Input type. You can find this kind of API in many other schema libraries. What's good about the example is that you can clearly see that we use our schema to declaratively describe what the data incoming to our system looks like, and then we transform it to what's convenient for us to work with. In a way, the schema here is similar to a contract between the client and the server that returns the object in response.

In the advanced S.object example, which I showed first, we combine a declarative description of the Input type with a transformation to the Output type. And this enables one more thing besides shorter code and a performance boost.

Reverse Parsing (aka serializing/decoding)

Decoding is present in many libraries from other languages, but it's not very common in the JS ecosystem. This is a big loss because the ability to perform operations in the reverse direction is the most powerful feature I personally find.

If it's unclear what I mean, in other popular JavaScript schema libraries, you can only parse Input to Output types. While in ReScript Schema you can easily parse Output to Input using the same schema. Or only perform the conversion logic since the Output type usually doesn't require validation.

Do you remember our filmSchema using S.object to rename fields? Let's say we want to send a POST request with the film entity, and the server also expects the weirdly cased data structure it initially sent to us. Here is how we deal with it:

// The same schema from above
const filmSchema = S.object((s) => ({
 id: s.field("Id", S.number),
 title: s.nested("Meta").field("Title", S.string),
 tags: s.field("Tags_v2", S.array(S.string)),
 rating: s.field("Rating", S.schema([S.union(["G", "PG", "PG13", "R"])]))[0],
}));

S.reverseConvertOrThrow({ id: 1, title: "My first film", tags: ["Loved"], rating: "G" }, filmSchema)
//? { Id: 1, Meta: { Title: "My first film" }, Tags_v2: ["Loved"], Rating: ["G"] }

Sweet! Isn't it? And even though I want to talk more about performance a little bit later, I can't stop myself from sharing the code it evaluates under the hood:

(i) => {
  let v0 = i["tags"];
  return {
    Id: i["id"],
    Meta: { Title: i["title"] },
    Tags_v2: v0,
    Rating: [i["rating"]],
 };
};

I think most people would write slower code by hand 😅

Reverse

The S.reverseConvertOrThrow is one of the reverse cases I use daily in my work, but this is actually just a shorthand of S.convertOrThrow and S.reverse you can use separately.

S.reverse - this is what allows you to take your Schema<Input, Output> and turn it into Schema<Output, Input>.

It may sound quite dull, but compared to the commonly used parser/serializer or encoder/decoder approach, here you get an actual schema you can use the same way as the original one without any limitations.

If you want, you can parse output with/without data validation, generate JSON Schema, perform optimized comparison and hashing, or use the data representation in runtime for any custom logic.

As a fruit of the ability to know Input and Output data types in runtime, ReScript Schema has a very powerful coercion API.

const schema = S.coerce(S.string, S.bigint)
S.parseOrThrow("123", schema) //? 123n
S.reverseConvertOrThrow(123n, schema) //? "123"

Pass any schemas to S.coerce that you want to coerce from and to, and ReScript Schema will figure out the rest.

And this has not been implemented yet, but with the API, it'll also be possible to achieve 2x faster JSON.stringify(). Like fast-json-stringify does and maybe even faster 😎

100 Operations

If you want the best possible performance or the built-in operations don't cover your specific use case, you can use S.compile to create fine-tuned operation functions.

const operation = S.compile(S.string, "Any", "Assert", "Async");
//? (input: unknown) => Promise<void>

await operation("Hello world!");

In the example above, we've created an async assert operation, which is not available by default.

With the API, you can get 100 different operation combinations, each of which might make sense for your specific use case. This is like parser in Valibot, but multiplied by 💯.

Performance Comparison

As I mentioned in the beginning, ReScript Schema is the fastest. Now I'll explain why 🔥

Also, you can use the big community benchmark to confirm yourself. If you see Typia overperforming ReScript Schema, I have a take on it too 😁

First of all, the biggest advantage of ReScript Schema is its very clever library core, which builds the most possibly optimized operations using eval. I have already shown before how the operation code looks for reverse conversion; here's the filmSchema parse operation code:

(i) => {
  if (typeof i !== "object" || !i) {
    e[7](i);
  }
  let v0 = i["Id"],
    v1 = i["Meta"],
    v3 = i["Tags_v2"],
    v7 = i["Rating"];
  if (typeof v0 !== "number" || Number.isNaN(v0)) {
    e[0](v0);
  }
  if (typeof v1 !== "object" || !v1) {
    e[1](v1);
  }
  let v2 = v1["Title"];
  if (typeof v2 !== "string") {
    e[2](v2);
  }
  if (!Array.isArray(v3)) {
    e[3](v3);
  }
  for (let v4 = 0; v4 < v3.length; ++v4) {
    let v6 = v3[v4];
    try {
      if (typeof v6 !== "string") {
        e[4](v6);
      }
    } catch (v5) {
      if (v5 && v5.s === s) {
        v5.path = '["Tags_v2"]' + '["' + v4 + '"]' + v5.path;
      }
      throw v5;
    }
  }
  if (!Array.isArray(v7) || v7.length !== 1) {
    e[5](v7);
  }
  let v8 = v7["0"];
  if (v8 !== "G") {
    if (v8 !== "PG") {
      if (v8 !== "PG13") {
        if (v8 !== "R") {
          e[6](v8);
        }
      }
    }
  }
  return { id: v0, title: v2, tags: v3, rating: v8 };
};

Thanks to eval, we can eliminate function calls and inline all type validations using if statements. Also, knowing about the Output type at runtime allows us to perform transformations with zero wasteful object allocations, optimizing the operation for JavaScript engines.

Interestingly, you probably think that calling eval itself is slow, and I thought this myself. However, it was actually not as slow as I expected. For example, creating a simple nested object schema and calling the parser once happened to be 1.8 times faster with ReScript Schema using eval than Zod. I really put a lot of effort into making it as fast as possible, and I have to thank the ReScript language and the people behind it for allowing me to write very performant and safe code.

Talking about ArkType, they use the same approach with eval and have similar potential to ReScript Schema, but their evaluated code is not there yet. Currently, their operations are a little bit slower, and the schema creation is significantly slower. But I can see that it can somewhat catch up in the future.

What other libraries will never be able to catch up on is the ability to reshape schema declaratively. And this is why I say that ReScript Schema is faster than Typia. Also, Typia doesn't always generate the most optimized code, e.g., for optional fields. And it doesn't come with many built-in operations specifically optimized for the desired use case. Still, this is an excellent library with Fast JSON Serialization and Protocol Buffer Encoding features, which I'm still yet to implement.

Ecosystem

When choosing a schema library for your project, where performance is not a concern, the ecosystem is the most important factor to consider. With a schema, you can do millions of things by knowing the type of representation in runtime. Such as JSON Schema generation, describing database schemas, optimized comparison and hashing, encoding to proto buff, building forms, mocking data, communicating with AI, and much more.

Zod is definitely a winner here. I counted 78 libraries integrating with Zod at the moment of writing the article. There are even some where you provide a Zod schema, and it renders a Vue page with a form prompting for the data. This is just too convenient for not using it for prototyping.

But if you don't need something super specific, ReScript Schema has a decent ecosystem itself, which is comparable to Valibot and ArkType. Actually, it has an even higher potential thanks to the ability to adjust Shape and automatically Reverse the schema. A good example of this is ReScript Rest, which combines the DX of tRPC while staying unopinionated like ts-rest. I also built many powerful tools around ReScript Schema, but I have to admit that I haven't added TS support yet. Let me know if you find something interesting to use, and I'll do this asap 😁

Also, ReScript Schema supports Standard Schema, a common interface for TypeScript validation libraries. It was recently designed by the creators of Zod, Valibot, and ArkType and has already been integrated into many popular libraries. This means that you can use ReScript Schema with tRPC, TanStack Form, TanStack Router, Hono, and 19+ more at the time of writing the article.

Conclusion

As the title says, I wholeheartedly believe that ReScript Schema is the future of schema libraries. It offers both DX, performance, bundle size, and many innovative features. I tried to cover all of them at a high level, and I hope I managed to make you at least a little bit interested 👌

I don't persuade you to choose ReScript Schema for your next project, and I actually still recommend Zod when somebody asks me. But I'll definitely appreciate a star and X follow 🙏

Let's see how the future of schema libraries will turn out. Maybe I'll rename ReScript Schema to something dope and become more popular than Zod? Cheers 😁

ReScript Schema V9 - Zod-like library to the next level 🚀

Dmitry Zakharov — Thu, 09 Jan 2025 17:37:00 +0000

The article is an overview of changes introduced in the recently released version 9. After more than 2 years of development, the ReScript Schema library became a project I'm genuinely proud of, so I plan to start creating more content and let more people know about it. A changelog is probably not a good piece of content to start with since it requires context for it to make sense, but I hope it'll still make some of you interested. If you've never heard about ReScript Schema, here is a short highlight:

This is the fastest parsing and validation library in the entire JavaScript ecosystem
Works with plain JavaScript, TypeScript, and ReScript. You don't need to use any compiler
People actually use it, and there's a decent ecosystem around it

If I made you slightly interested, you can find more on the GitHub page. Don't forget to subscribe to get notifications about more content about tools I create.

In the meantime, let's start the V9 changes overview 🔥

What's new in ReScript Schema V9?

ReScript Schema V9 is a big step for the library. Even though there are not many changes in the ReScript API, the version comes with a completely new mental model, an internal redesign for enhanced operations flexibility, and a drastic improvement for the JS/TS API.

New mental model 🧬

The main idea of ReScript Schema-like libraries is to create a schema with code that describes a desired data structure. Then, you can use the schema to parse data incoming to your application, derive types, create JSON-Schema, and many more. This is how other libraries, like Zod, Valibot, Superstruct, yup, etc, work.

Even though ReScript Schema is now a mature and powerful library for JS users, I originally created it specifically to parse data in ReScript applications, with the core functionality to automatically transform data to the ReScript representation and back to the original format. This is how the advanced object API was born - the primary tool of ReScript Schema up till V9.

let filmSchema = S.object(s => {
  id: s.field("Id", S.float),
  title: s.field("Title", S.string),
  tags: s.fieldOr("Tags", S.array(S.string), []),
  rating: s.field(
    "Rating",
    S.union([
      S.literal(GeneralAudiences),
      S.literal(ParentalGuidanceSuggested),
      S.literal(ParentalStronglyCautioned),
      S.literal(Restricted),
    ]),
  ),
  deprecatedAgeRestriction: s.field("Age", S.option(S.int)->S.deprecate("Use rating instead")),
})

Here, you can see features like declarative validation, fields renaming, and automatic transformation/mapping in a single schema definition. And the schema will produce the most optimized function to parse or convert your value back to the original format using eval.

What's changed and why?

As I said before, initially, the library covered two prominent use cases: parsing & serializing. But with time, when ReScript Schema got used more extensively, it wasn't enough anymore. For example, you'd want only to apply transformations without validation, validate the data before serializing, assert with the most performance without allocations for output value, or parse JSON data, transform it, and convert the result to JSON again. And V9 introduces the S.compile function to create custom operations with 100 different combinations 💪

To make things even more flexible, all operations became one-directional. This might be slightly confusing because it means there's no serializing anymore. But V9 comes with a new, powerful concept of reversing your schema. Since we have 50 different one-directional operations, we now have 50 more for the opposite direction. So I hope it's a good explanation of why serializeOrRaiseWith was removed.

To keep the DX on the same level, besides S.compile + S.reverse functions, there are some built-in operations like reverseConvertOrThrow, which is equivalent to the removed serializeOrRaiseWith.

Another hidden power of the reverse feature is that now it's possible to get the type information of the schema output, allowing one to compile even more optimized schemas and build even more advanced tools.

TS to the moon 🚀

For me, the custom compilation and reverse mental model are the biggest changes, but if you're a TypeScript user, you'll find another one to be more exciting in the v9 release. And yes, I know there are pretty many breaking changes, but creating a schema was never as smooth.

Before:

const shapeSchema = S.union([
  S.object({
    kind: S.literal("circle"),
    radius: S.number,
  }),
  S.object({
    kind: S.literal("triangle"),
    x: S.number,
    y: S.number,
  }),
]);

After:

const shapeSchema = S.union([
  {
    kind: "circle" as const,
    radius: S.number,
  },
  {
    kind: "triangle" as const, // Or you can have S.schema("triangle")
    x: S.number,
    y: S.number,
  },
]);

In V9 you don't need to care whether you work with an object, tuple, or a literal - simply use S.schema for all cases. If you have an enum, discriminated union, or some variadic union - simply use S.union. There's a single API, and ReScript Schema will automatically compile the most optimized operation for you.

Clean up built-in operations 🧹

If you're familiar with ReScript Schema's older versions, the built-in operations look somehow different. For example, serializeOrRaiseWith became reverseConvertOrThrow. So there are changes you should know about:

All operations are now throwing; there's no result-based API. As an alternative for ReScript I recommend using try/catch with the S.Raised exception. For TS users, there's a new S.safe API for convenient error handling.
TS and ReScript API are now the same, which is easier to maintain, interop between languages and work in mixed codebases.
The Raise suffix is renamed to Throw since this makes more sense in Js ecosystems, and there are plans to rename the raise function to throw in the next ReScript versions.
The With suffix is removed to save some space. Note that the operation is still data-first, and the schema should be a second argument.

Other changes you should know about 👀

In the release, S.schema got a noticeable boost. Besides becoming TS users' main API now, I recommend using it in ReScript by default when you don't need transformations. Previously, it was simply a wrapper over advanced S.object and S.tuple, but it got its own implementation, which allows creating schemas faster, as well as including optimizations for compiled operations:

If you use S.schema for strict objects without transformed fields, the incoming object won't be recreated.
If you use S.schema for tuples without transformed items, the incoming array won't be recreated.

Also, you can pass the object schema created with S.schema to the new Advanced Object API for nested fields coming in as a replacement for s.nestedField:

let entityDataSchema = S.schema(s => {
 name: s.matches(S.string),
 age: s.matches(S.int),
})
let entitySchema = S.object(s => {
  // Schema created with S.object wouldn't work here 👌
  let {name, age} = s.nested("data").flatten(entityDataSchema)
 {
 id: s.nested("data").field("id", S.string),
 name,
 age,
 }
})

Besides the runtime improvements for operations of S.schema, there are a few more, which were possible thanks to the ability to know the output type information:

The union of objects will use literal fields to choose which schema it should use for parsing. Previously, it used to run operations for every schema of the union and return the result of the first non-failing one. The approach was slow, provided worse error messages, and didn't work for reversed operations. In V9 all the problems are solved.
Improved optional operations by doing the Caml_option.valFromOption call only when it's truly needed.

As a cherry on top of the cake, schema names became more readable, making error messages even better:

-Failed parsing at root. Reason: Expected Object({"foo":Option(String)}), received 123
+Failed parsing at root. Reason: Expected { foo: string | undefined; }, received 123

Thanks for reading the high-level overview of the release. Contact me on GitHub or X if you have any questions 😁 And enjoy using ReScript Schema 🚀

The ultimate answer to Belt vs Js in ReScript

Dmitry Zakharov — Sun, 29 Jan 2023 21:50:18 +0000

Probably every developer that comes to ReScript stumbles upon a dilemma about which module from the standard library they should use to work with JavaScript API.

Should I take the Js module with a familiar design for JavaScript developers and runtime-free bindings? 🧐
Or should I take the more powerful Belt? 🤔
Wait, I heard something about rescript-js! Maybe that’s what I need? 😅

Those are pretty familiar thoughts, right? I’ve seen a lot of discussions about which one you should use, but there were never solid answers, and the result was either “it depends” or “I personally like one over another because of X”.

My lovely Carla colleague Daggala has written a very detailed article about the problem, so I won’t repeat her and continue.

Problem 2: Multiple sources of truth

No matter what we choose, sometimes we still need to use another module. It’s because some functions which exist in Js don’t exist in Belt and vise-versa.

But it might happen that a function doesn’t exist in both of the modules, eg infamous padStart. At Carla, we used to solve the problem by creating a lot of StringExtra, OptionExtra, and WhateverExtra modules to add missing helper functions.

This leads to another problem when developers don’t know where they can find the desired helper:

Will it be in Belt that we agreed to use as default, or the helper doesn’t exist there, and I should use Js instead, or maybe StringExtra?

A few times, we even end up using Pervasives by mistake.

Problem 3: Creating guidelines

Depending on the project, we may have rules for the team to follow. For example, Belt.Option.getExn raises a ReScript exception which is very difficult to trace, so at Carla we decided to use our own OptionExtra.getExnWithMessage instead. Although there's an agreement, it's very easy to forget about and continue using Belt.Option.getExn. We want a way to prevent the usage of Belt.Option.getExn whatsoever.

Solution

I will not create intrigue and say that the solution I suggest is to create your own vendored standard library and enforce its usage across the codebase. You can reuse existing modules like Js, Belt, or RescriptJs, and adjust them for our needs.

The enforcing is the most crucial part here because if we don't automate it with CI, our colleagues and even ourselves will continue using all different modules instead of the single vendored one.

And to solve the problem, I've created rescript-stdlib-vendorer, an easy-to-use linter to support the usage of a vendored standard library.

Linter

The linter does a straightforward thing - It checks all project files and detects the usage of Js, Belt, and ReScriptJs modules. So you can easily find and replace them with your Stdlib.

To start using the linter in your project, install it as a dev dependency:

npm install -D rescript-stdlib-vendorer

Let's also add an npm run script for convenience and immediately use it:

npm pkg set scripts.lint:stdlib="rescript-stdlib-vendorer lint"
npm run lint:stdlib

So if we have a project created from the official template repository, which has a single ReScript file with Js.log("Hello, World!"), we’ll get the following error:

~/rescript-project-template/src/Demo.res:1
  Found "Js" module usage.

Use the vendored standard library instead. Read more at: https://github.com/DZakh/rescript-stdlib-vendorer

To fix it, let’s create a directory stdlib and add the first vendored module:

cd src
mkdir stdlib
cd stdlib
echo 'include Js.Console' >> Console.res

We can now update the Demo.res by replacing Js.log with Console.log.

Let’s run the linter again and see that there’s no error:

npm run lint:stdlib

In the following way, you can create reexports for other modules and adjust them to make them better suit you.

For example, for the Array module, you can redefine some functions with Belt’s implementation to make the code safer:

// src/stdlib/Array.res
include Js.Array
let get = Belt.Array.get

This way, the usage of square brackets to get an array item will return option, which’s more correct:

let array = [1, 2, 3]
let item = array[3]
// The item will have the option<int> type instead of the default int one
Console.log(item)

Returning to the Belt.Option.getExn, mentioned in the third problem, instead of reexporting all functions from Js/Belt, we can explicitly reexport only the functions we need and replace the ones we consider harmful:

// src/stdlib/Option.res
let forEach = Belt.Option.forEach
let mapWithDefault = Belt.Option.mapWithDefault
let map = Belt.Option.map
let flatMap = Belt.Option.flatMap
let isSome = Belt.Option.isSome
let isNone = Belt.Option.isNone

let getExnWithMessage = (x, message) =>
  switch x {
  | Some(x) => x
  | None => Js.Exn.raiseError(message)
  }

Reusing the vendored stdlib

I’ve shown how to start vendoring stdlib in a short way. But having multiple projects following the same guidelines, you’d soon want to start reusing the vendored stdlib. It’s very easy to do by moving the code from the stdlib directory featured above to a separate package.

For my personal projects, I copied Gabriel's repository with a proposal for a new ReScript stdlib, which did not work out. Afterward, I modified it to suit my taste better and published it to npm, making it easy to use.

I recommend taking a look at it as a reference @dzakh/rescript-stdlib, but I don’t bring it to your own projects. You'll lose a very good part of vendoring - full control over the code.

At Carla, we had a different situation. Having a huge codebase with Js, Belt, and WhateverExtra all over the place, it would be too much work to take some existing customized stdlibs like rescript-js or @dzakh/rescript-stdlib and update old code with them.

First of all, since at Carla we have different guidelines compared to my personal projects, it would be a bad idea to use @dzakh/rescript-stdlib from the get-go. As I said before, it'd lose the whole point of vendoring.

So, to migrate the whole codebase, we’ve started with creating a small stdlib package in our pnpm mono repository that simply reexported functions from Belt or Js. And started updating file by file, replacing open Belt with open Stdlib and Js.Array2 with Array, etc.

Also, you can use a tool like Comby to transform the whole codebase in one go.

Before you start the migration to the vendored stdlib, I highly recommend replacing Js.String and Pervasives.String with Js.String2. Since some of the functions have the same API, but different logic, there’s a chance of missing one of them and getting a runtime error.

But we didn’t rush with the migration, and to avoid regressions of the process, we ran the linter script in CI with the --ignore-without-stdlib-open flag to skip files not containing open Stdlib.

After every file was updated, we removed open Stdlib from the beginning of the files and opened it globally via bsconfig.json. When it was done, we could finally start gradually adjusting the Stdlib to make the process of writing ReScript code more convenient and reliable.

If you have any questions feel free to write them in the comment section or ping me on Twitter.

Testing in ReScript

Dmitry Zakharov — Mon, 02 Jan 2023 11:25:02 +0000

Hello, I’m Dmitry Zakharov, a Frontend-engineer at Carla and author of rescript-struct. After using ReScript for two years, of which 9 months are in production, I’ve gotten some insights about testing I wanted to share. I use ReScript not only for FE but for different areas, so if you’re a BE engineer or create a CLI tool, this article will also be useful for you.

Testing in ReScript is not much different from testing JavaScript. That’s because we don’t test ReScript directly, but the code it generates. But the difference is that thanks to the great type-safety that ReScript provides, it’s almost unnecessary to test the connection between modules inside of your system. My experience with ReScript has shown that having unit tests for domain/business logic and a few end-to-end (e2e) tests to check that the whole system works correctly when modules are combined - is more than enough.

Unit tests

Regarding unit testing, the library you use doesn't really matter. Choose any that works for you. My personal preference is to use bindings for AVA.

Another popular option is to use bindings for Jest. However, in my opinion, Jest is a monstrous combine that is slow, has a hacky mock system, bad ESM support, and purely tries to mimic DOM API with JSDOM. AVA literally doesn't have any of these. Also, the available Jest bindings don't allow doing multiple assertions per test, which is often useful to me.

Besides bindings for JavaScript libraries, there is rescript-test - a lightweight test framework written in ReScript for ReScript. I have heard that some people like it, but for me, it lacks coverage output and Wallaby support.

E2E

Even though I claim that integration tests are unnecessary, we still need to ensure that the application works correctly when all the modules are combined. For this purpose, I like having a few E2E tests that imitate an end user of my application and ensure that it works as intended.

For FE, it’s usually Cypress or Playwright; for BE, it’s to run a server and start sending requests; for CLI, I like the tool called execa.

The idea is to imitate a real user. And using ReScript for this kind of test is good but not mandatory. You can have Cypress tests in Js, Selenium, Postman, or other external tools.

Tip 1: Wallaby

Up till now, I have mostly shown my worldview. But now, I would like to share with you some tips. And the first one is Wallaby.

It is a JavaScript test runner that provides real-time code quality feedback. Even though in ReScript we don't get all the benefits, I still find it useful when it comes to diving into JavaScript to debug some failing tests. The stories feature is particularly helpful, where you can visually see how the generated code is executed.

It helps to have tests always running and brings enjoyment to the process of working with them.

Tip 2: Interfaces and opaque types

Opaque types in ReScript are types whose implementation is hidden from other parts of the program, allowing for information hiding, modularity, type safety, and improved performance. They provide a clear interface for interacting with the type and can help ensure that the internal state of the type is consistent and well-formed. Shortly speaking, they are wonderful!

Although when we write tests, we want to be able to assert that an opaque entity has an exact value. But it’s impossible to create the exact value for assertion since the implementation is hidden behind an interface.

To workaround the problem, I’ve started creating TestData modules with functions to create a value of the opaque type directly. And have a convention that it’s only allowed for use inside of the test files. Here’s an example:

// ModuleName.res
type t = string


let fromBscFlag = bscFlag => {
  // Some logic
}

module TestData = {
  let make = moduleName => moduleName
}

// ModuleName.resi
type t

let fromBscFlag: string => option<t>

module TestData: {
  let make: string => t
}

// ModuleName_test.res
test("fromBscFlag works with Belt", t => {
  t->Assert.deepEqual(
    ModuleName.fromBscFlag("-open Belt"),
    Some(ModuleName.TestData.make("Belt")),
    (),
  )
})

I’m very satisfied with the approach. Although if you develop a library and don’t control the end user of your code, it’s not a good idea to expose innards like this.

Tip 3: Place tests close to the tested code

Another tip that won’t work for libraries while definitely worthy for applications. And it’s to place test files close to the code they are testing. Which can improve organization, maintainability, and convenience.

That’s pretty common for Js, but in ReScript, the most common approach is to connect a testing library via the bs-dev-dependencies and put tests in the __tests__ directory, marking it as dev in the bsconfig.json.

I think that the value of placing tests close to the code is much higher than using bs-dev-dependencies, so I moved a testing library to the bs-dependencies and removed the __tests__ directory.

If you are afraid of test code leaking into the application. You can use eslint to prevent this:

export default [
  {
    rules: {
      "no-restricted-imports": [
        "error",
        {
          patterns: [
            {
              group: ["*_test.bs.mjs"],
              message: "It's not allowed to import test modules.",
            },
          ],
        },
      ],
    },
  },
];

Tip 4: Mocking

Especially when talking about unit testing, we often have external dependencies that should be replaced during a test. And me saying that Jest’s mocking is a bad thing (the same goes for Vitest) might sound a bit controversial.
One reason is that mocking in Jest heavily relies on JavaScript’s module system, which differs from ReScript’s. Also, the insanely hacky implementation and terrible DX make it even worse. And the main reason is that DI (Dependency Injection) solves the problem much better.

Implementation depends on your architecture and will vary from project to project. I’ll share some examples of how I do it myself.

I find that in most cases, DI can be done by simply passing dependencies as function arguments without any abstractions. And then return an implementation which is usually a single function:

// Lint.res
let make = (
  // Dependencies
  ~loadBsConfig,
  ~loadSourceDirs
) => {
  // Implementation of the lint logic
  (. ~config) => {
    // Some code
  }
}

The example is taken from my rescript-stdlib-vendorer project, which uses the approach as the core of the architecture. I recommend you take a look at the source code if you want to see a bigger picture.

But sometimes, implementation needs to be a whole module. And for this, we can use ReScript functors (functions that create modules).

The idea is the following: when you are working on module A, instead of calling B.doSomething directly, you have an AFactory.Make functor that accepts doSomething as an argument and returns the A module. This way, you can create the A module with different dependencies for testing.

// AFactory.res
module Make = (T: {
    let doSomething: () => ()
  },
) => {
  let call = () => {
    T.doSomething()
    true
  }
}

// A.res
include AFactory.Make({
  let doSomething = B.doSomething
})

// A_test.res
test("Calls doSomething once", t => {
  let doSomethingCallsCountRef = ref(0)
  module A = AFactory.Make({
    let doSomething = () => {
      doSomethingCallsCountRef := doSomethingCallsCountRef.contents + 1
      ()
    }
  })
  A.call()

  t->Assert.is(doSomethingCallsCountRef.contents, 1, ())
})

The approach with functor has a few problems, usually not critical ones, though.

One problem is that it suggests creating A.res, which is publicly available from other application parts. It’s usually fine for FE apps, but for developing BE and CLIs, I prefer to follow the hexagonal architecture by creating the implementation inside the Main.res and passing it to other modules via function arguments. Once again, an example from rescript-stdlib-vendorer:

// Main.res
let runCli = RunCli.make(
  ~runLintCommand=RunLintCommand.make(
    ~lint=Lint.make(
      ~loadBsConfig=LoadBsConfig.make(),
      ~loadSourceDirs=LoadSourceDirs.make()
    ),
  ),
  ~runHelpCommand=RunHelpCommand.make(),
  ~runHelpLintCommand=RunHelpLintCommand.make(),
)

runCli(.)

Another problem with ReScript functors is that the created module is not tree-shakable. But if it’s really a problem, you probably already know how to work around it.

Tip 5: Test bindings

Bindings with JavaScript is the most dangerous part of any application - the bridge with an unsafe and unpredictable world. And it’s definitely a bad idea to trust yourself that you’ve done it correctly. Especially considering the fact that it might become outdated during the next release.

Honestly, I’m guilty myself of neglecting binding tests. So I can’t give you any advice on how to handle it in a good way. But at least I want you to be more careful and consider writing tests for bindings when you see that it might become a problem.

Tip 6: Coverage

Lastly, I want to share a small personal thing. I really like numbers and as well as seeing the result of my work in numbers. One of the ways to achieve this is to configure a test coverage analytics tool like Codecov in your CI. And although being over-concentrated on coverage is not a healthy and useful thing, I really noticed that it makes writing tests more exciting. It probably won’t work for everyone, but at least I recommend trying it out.

Project examples

You can see how I follow the described ideas in my open-source projects. If you're interested, I recommend checking out the most model ones:

rescript-struct - a good example of testing a library
rescript-stdlib-vendorer - a good example of testing an application

Discussion is encouraged

I realize that I’ve mentioned quite a few contradictory things without going into detail. If you have any questions, suggestions or want to argue, feel free to speak up in the comment section or ping me on Twitter.

DEV Community: Dmitry Zakharov

I Ditched My Keyboard for Voice Coding 🎙️

Why I wanted to ditch the keyboard

WhisperFlow: The first try

Switching to Aqua Voice

WhisperFlow vs Aqua Voice: The verdict (so far)

The results

What about Claude's built-in voice input?

Zod v4 got 17x Slower than v3 🚦

Zod v4: 17x Slower? Not Quite, But...

Schema from the benchmark

What Changed in Zod v4?

Is Eval/JIT Bad? Not Really.

What Should Zod Users Do?

Enter Sury: The Fastest Schema Library

Final Thoughts

Welcome Sury - The fastest schema with next-gen DX 🚀

What is Sury?

Ecosystem

Standard Schema

JSON Schema

Offtopic: Serialization

Internal Representation

Sury Ecosystem Future

New API Features

S.with

S.min

S.meta

S.to

What's next?

Q&A

What about ReScript support?

What about new Function?

What about Zod?

What about TypeBox?

What about X?

What about me?

JavaScript schema library from the Future 🧬

What's a parser?

Is ReScript Schema faster than all of them?

What's ReScript? Isn't the library for JavaScript/TypeScript?

Are there trade-offs?

What's the plan?

Parsing / Validating

Package size

Parsing using ReScript

Unique Features

Changing shape and field names

Reverse Parsing (aka serializing/decoding)

Reverse

100 Operations

Performance Comparison

Ecosystem

Conclusion

ReScript Schema V9 - Zod-like library to the next level 🚀

What's new in ReScript Schema V9?

New mental model 🧬

What's changed and why?

TS to the moon 🚀

Clean up built-in operations 🧹

Other changes you should know about 👀

The ultimate answer to Belt vs Js in ReScript

Problem 2: Multiple sources of truth

Problem 3: Creating guidelines

Solution

Linter

Reusing the vendored stdlib

Testing in ReScript

Unit tests

E2E

Tip 1: Wallaby

Tip 2: Interfaces and opaque types

Tip 3: Place tests close to the tested code

Tip 4: Mocking

Tip 5: Test bindings

Tip 6: Coverage

Project examples

Discussion is encouraged

What about `new Function`?