rescript VS TypeScript

When I see this it makes me want to run for ReasonML/ReScript/Elm/PureScript.

Sum types (without payloads on the instances they are effectively enums) should not require a evening filling ceremonial dance event to define.

https://reasonml.github.io/

https://rescript-lang.org/

https://elm-lang.org/

https://www.purescript.org/

(any I forgot?)

It's nice that TS is a strict super set of JS... But that's about the only reason TS is nice. Apart from that the "being a strict super set" hampers TS is a million and one ways.

To my JS is too broken to fix with a strict super set.

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.

Fortunately, the OCaml compiler is very modular, and there have been efforts to make things more... reasonable.

- Reason, a different syntactic frontend for regular OCaml: https://reasonml.github.io/

- ReScript, a language with OCaml semantics that compiles into: JS https://rescript-lang.org/ (I suppose it's a reincarnation of js-of-ocaml).

Elm, ReScript, F#, Ocaml, Scala… it’s just normal to name your types, then use them places. In fact, you’ll often create the types _before_ the code, even if you’re not really practicing DDD (Domain Driven Design). Yes, you’ll do many after the fact when doing functions, or you start testing things and decide to change your design, and make new types. Either way, it’s just “the norm”. You then do the other norms like “name your function” and “name your variables”. I’m a bit confused why it’s only 2 out of 3 (variables and functions, not types) in this TypeScript Angular project. I’ll have to look at other internal Angular projects and see if it’s common there as well.

A web application makes use of these same ingredients, i.e. HTML, CSS, and JavaScript, but it uses significantly more JavaScript. As the JavaScript powering your web application grows in size it can bring with it a variety of problems that a few languages, like TypeScript, ReScript, PureScript, and Elm, have attempted to solve. Each of the aforementioned compile to JavaScript languages have their pros and cons but it is beyond the scope of this article to get into those details. Suffice it to say, my preference is Elm. It is also not the goal of this article to convince you to use Elm but only to show you how Elm fits into the flow of creating a web application and hosting it on GitHub Pages. So let's continue by adding Elm to our project.

Since JavaScript doesn't have a pattern-matching like Rust, it could be hard to replicate the same logic. I used the ReScript compiler to maintain the original logic as much as possible. It made me able to port it confidently. Specifically check_pair function can be converted into this.

This requires the whole `.proto` declaration inline in source a string constant. I'm not holding my breath on "Import non-js content"[1] getting approved, so that means you still have to use another build dependency, or manually keep the .proto files synchronized across multiple sources truth. In that light, it's not clear when this would be a benefit over straight-forward code gen. Cool POC hack though.

[1]: https://github.com/microsoft/TypeScript/issues/42219

I think what you're looking for is an `internal` modifier. This allows class members to be public within a library, but private outside it.

It's been proposed since 2015: https://github.com/microsoft/TypeScript/issues/5228

Currently, you can use `@internal` in jsdoc, which with the `stripInternal` option in tsconfig will cause it to be omitted from the type declarations for a similar effect.

https://www.typescriptlang.org/tsconfig/#stripInternal

So, without TypeScript, JavaScript is dynamic and vulnerable to runtime errors. And with TypeScript, type-checking dawns on compile time, which further ensures minimal production bugs.

This article compares three JWT packages designed for Node.js and TypeScript.

> Enums Are Meant To Be Symbolic

And yet you can’t use symbols [1].

Author gives a valiant effort, but is defending the indefensible.

[1] https://github.com/microsoft/TypeScript/issues/18408

This tutorial assumes you are familiar with TypeScript and MCP.

For the frontend we're going a bit against the grain of current webdev trends and bet on Nuxt (of course with Typescript and Tailwind) as our framework of choice. This is mostly because Lukas (the co-founder) is a long-term Nuxt.js fan and sponsor! Of course, the frontend is completely hosted on sliplane for proper dogfooding, with Cloudflare as a CDN in front because script kiddies like to test their DDOS scripts on us :).

📌 Get started with TypeScript here: https://www.typescriptlang.org/

Typescript's type system is technically undecidable because you can interpret Turing machines with it:

https://github.com/microsoft/TypeScript/issues/14833

The flip side is that such systems can still be practically useful. You just have to manage your type complexity, much like you already manage your runtime complexity.