json-schema-to-typescript VS assemblyscript

Compile JSONSchema to TypeScript type declarations

Nice! Lots of tricky edge cases to do this right: there’s ambiguity in the JSON Schema spec, version-to-version changes, many popular community conventions that don’t adhere to the spec, etc. Feel free to check out the tests to understand some of these: https://github.com/bcherny/json-schema-to-typescript (shameless plug — I have maintained this library for a number of years).

jsonnet is my go-to language for anything related to configuration, after having tried json, yaml, TS, edn, and tasting dhall and toml. It addresses all problems in the article and more.

the composition strikes a good balance between extensiveness and ease of use.

the generated json leads to easy and portable data, and if you write jsonschemas from jsonnet, tools like json-schema-to-typescript [1] make it easy to import a consistent interface, and almost every language has a reasonably up-to-date validation library.

[1] https://github.com/bcherny/json-schema-to-typescript

Take a look at https://github.com/bcherny/json-schema-to-typescript, too. I used it successfully at a previous job. IIRC, I had to write some code to convert OpenAPI to JSON Schema but it wasn’t onerous

If you're using OpenAPI, you could use this to generate TypeScript interfaces:

https://github.com/bcherny/json-schema-to-typescript

It works really well

I'm messing around with a process to convert JSON schemas to TypeScript interfaces using json-schema-to-typescript. I have a little under 900 JSON files each containing a schema, totaling about 3.5 MB.

json-schema-to-typescript

I like your take but JavaScript was literally the assembly language of the web until WASM came along. There was no other language that TypeScript could compile to.

This train of thought lead me to discover AssemblyScript! https://www.assemblyscript.org/

Incidentally, it’s also what AssemblyScript uses: https://github.com/AssemblyScript/assemblyscript/blob/main/s...

Use it as a Front-End for other low-level languages.

> MHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript?

Check out AssemblyScript which is exactly that:

https://www.assemblyscript.org/

If you're curious, check out AssemblyScript, that might describe better what needs to be cut from TypeScript to make it possible to be compiled to WASM.

This is kinda the idea behind AssemblyScript, but IIRC it's more of a low-level typescript-ish syntax for WebAssembly.

https://www.assemblyscript.org/ maybe, but I'm not sure exactly what you need.

Exactly, WASM was designed to be very very lightweight... you can put a lot of logic into a very small amount of WASM, but you need a good compiler to do that, or write WASM by hand to really feel the benefit. If you just compile Go to WASM, with its GC, runtime and stdlib included in the binary, yeah it's going to be pretty heavy... Rust doesn't have a runtime but as you said, for some reason, produces relatively large binaries (not the case only in WASM by the way). Probably, the best ways to create small WASM binaries is to compile from C or from a WASM-native language like AssemblySCript (https://www.assemblyscript.org).

Well we have all the new ECMA standards that will be introduced in 5 years now. It's looking more like Java actually. its accessor and typing patterns match it the most. TypeScript has had quite the profound influence over future ECMA design. There is a not so well known project called AssemblyScript which I think has a promising future. Since future ecma standards closely resembles it and TypeScripts popularity has exploded I have a feeling it may become a real standard as well.