Introduction
Javascript is everywhere and will not be going away anytime soon. I love Javascript, it's the first language I learned, and I use it every day, having done so for the past 7 years. But I think we can all agree that the language has many flaws, especially with error handling, callback hell, type coercion and many more. Alot of improvments have been made over time tho.
Typecript was introduced as a superset of Javascript, aimed at addressing many of Javascript's flaws through the introduction of static typing. These days, pure Javascript applications are becoming increasingly rare. The vast majority of new projects opt for Typescript for its robust typing system that improves code reliability and maintainability.
Popular frameworks like Next.js strongly advocate for Typescript, further solidifying its position as the preferred choice for modern web development. This shift towards Typescript is a positive move towards a future where code is more understandable, easier to refactor, and less prone to runtime errors.
Why is typescript not enough?
We often like to think that Typescript solves all the problems inherent to Javascript, but unfortunately, that's not entirely true.
How many times do we not write an API call like this? I've done it thousands of times, and it seems to work, right?
async function getTodo(id: number): Promise<{ todo: Todo}> {
const response = await fetch(`/todos/${id}`)
const todo = await response.json()
return { todo }
}
So, what's the problem here? At first glance, it looks straightforward and effective. However, several things could go wrong and as developers we need to take care of that. For error handling we can use try-catch.
async function getTodo(
id: number
): Promise<
| { ok: true; todo: any }
| { ok: false; error: "InvalidJson" | "RequestFailed" }
> {
try {
const response = await fetch(`/todos/${id}`)
if (!response.ok) throw new Error("Not OK!")
try {
const todo = await response.json()
return { ok: true, todo }
} catch (jsonError) {
return { ok: false, error: "InvalidJson" }
}
} catch (error) {
return { ok: false, error: "RequestFailed" }
}
}
This is better but we had to add more then 10 lines of code for it and the nested try-catches can be hard to read.
But for a production-grade app, we might still need more features, like retries in case something fails. That would look something like this:
function getTodo(
id: number
{
retries = 3,
retryBaseDelay = 1000,
}: { retries?: number; retryBaseDelay?: number },
): Promise<
| { ok: true; todo: any }
| { ok: false; error: "InvalidJson" | "RequestFailed" }
> {
async function execute(
attempt: number
): Promise<
| { ok: true; todo: any }
| { ok: false; error: "InvalidJson" | "RequestFailed" }
> {
try {
const response = await fetch(`/todos/${id}`)
if (!response.ok) throw new Error("Not OK!")
try {
const todo = await response.json()
return { ok: true, todo }
} catch (jsonError) {
if (attempt < retries) {
throw jsonError // jump to retry
}
return { ok: false, error: "InvalidJson" }
}
} catch (error) {
if (attempt < retries) {
const delayMs = retryBaseDelay * 2 ** attempt
return new Promise((resolve) =>
setTimeout(
() => resolve(execute(attempt + 1)),
delayMs,
),
)
}
return { ok: false, error: "RequestFailed" }
}
}
return execute(0)
}
The code is getting out of hand but we are still not done. Often we must introduce a mechanism for interruption to manage and clean up resources effectively. We can use the AbortSignal API for that
function getTodo(
id: number
{
retries = 3,
retryBaseDelay = 1000,
signal,
}: {
retries?: number
retryBaseDelay?: number
signal?: AbortSignal
},
): Promise<
| { ok: true; todo: any }
| {
ok: false
error: "InvalidJson" | "RequestFailed" | "Timeout"
}
> {
async function execute(attempt: number): Promise<
| { ok: true; todo: any }
| {
ok: false
error: "InvalidJson" | "RequestFailed" | "Timeout"
}
> {
try {
const controller = new AbortController()
setTimeout(() => controller.abort(), 1000)
signal?.addEventListener("abort", () =>
controller.abort(),
)
const response = await fetch(`/todos/${id}`, {
signal: controller.signal,
})
if (!response.ok) throw new Error("Not OK!")
try {
const todo = await response.json()
return { ok: true, todo }
} catch (jsonError) {
if (attempt < retries) {
throw jsonError // jump to retry
}
return { ok: false, error: "InvalidJson" }
}
} catch (error) {
if ((error as Error).name === "AbortError") {
return { ok: false, error: "Timeout" }
} else if (attempt < retries) {
const delayMs = retryBaseDelay * 2 ** attempt
return new Promise((resolve) =>
setTimeout(
() => resolve(execute(attempt + 1)),
delayMs,
),
)
}
return { ok: false, error: "RequestFailed" }
}
}
return execute(0)
}
Now our API is robustly designed, having addressed nearly all the typical issues. However, we find ourselves dealing with over 60 lines of code and the solution lacks modularity. This means we'd need to replicate this for each of our API routes, which is hardly efficient or scalable.
Additionally, another aspect worth considering is the incorporation of a tracer.
const tracer = Otel.trace.getTracer("todos")
function getTodo(
id: number
{
retries = 3,
retryBaseDelay = 1000,
signal,
}: {
retries?: number
retryBaseDelay?: number
signal?: AbortSignal
},
): Promise<
| { ok: true; todo: any }
| {
ok: false
error: "InvalidJson" | "RequestFailed" | "Timeout"
}
> {
return tracer.startActiveSpan(
"getTodo",
{ attributes: { id } },
async (span) => {
try {
const result = await execute(0)
if (result.ok) {
span.setStatus({ code: Otel.SpanStatusCode.OK })
} else {
span.setStatus({
code: Otel.SpanStatusCode.ERROR,
message: result.error,
})
}
return result
} finally {
span.end()
}
},
)
async function execute(attempt: number): Promise<
| { ok: true; todo: any }
| {
ok: false
error: "InvalidJson" | "RequestFailed" | "Timeout"
}
> {
try {
const controller = new AbortController()
setTimeout(() => controller.abort(), 1000)
signal?.addEventListener("abort", () =>
controller.abort(),
)
const response = await fetch(`/todos/${id}`, {
signal: controller.signal,
})
if (!response.ok) throw new Error("Not OK!")
try {
const todo = await response.json()
return { ok: true, todo }
} catch (jsonError) {
if (attempt < retries) {
throw jsonError // jump to retry
}
return { ok: false, error: "InvalidJson" }
}
} catch (error) {
if ((error as Error).name === "AbortError") {
return { ok: false, error: "Timeout" }
} else if (attempt < retries) {
const delayMs = retryBaseDelay * 2 ** attempt
return new Promise((resolve) =>
setTimeout(
() => resolve(execute(attempt + 1)),
delayMs,
),
)
}
return { ok: false, error: "RequestFailed" }
}
}
}
Now all of a sudden we have gone from from 6 lines of code to about 80 lines...
To be honest, I rarely go to these lengths when creating an API endpoint and that's largely due to how cumbersome it is.
Producing production-grade TypeScript is hard.
Challenges include:
- No type-safety beyond the happy path
- Error handling
- Retrying on error
- Interruptions
- Observability
- Schema validation
The last point, schema validation, isn't even covered in our code example, but we'd often turn to tools like Zod for this purpose.
What TypeScript lacks, that other languages offer, is a comprehensive standard library. Instead, we have NPM, which is great because we can find almost everything, but that comes with its own set of problems as well.
So, what should we do then?
Effect
Effect is designed to address the issues inherent in Typescript and to solve the challenges developers face when using it.
It does so using:
- Powerful building blocks: Each component of the Effect ecosystem is crafted to be composable.
- No more one-off deps:: With Effect, we have all we need, eliminating the necessity to depend on numerous npm packages. It provides tools for data validation and HTTP frameworks, among others.
- No more try-catch:: Effect takes a comprehensive approach to error handling, ensuring all errors are type-safe and not just the happy path.
The 2022 State of JS survey highlighted a strong desire among developers for a standard library.
Effect can be utilized wherever Typescript is applicable, positioning itself as the missing standard library for Typescript. However, there's a catch:
- Learning curve: Effect heavily relies on functional programming concepts, which can be intimidating for many developers.
- Different programming style: The programming style of Effect is quite distinct from traditional Typescript, potentially making it challenging to adapt to.
- Extensivve API: Aiming to be a standard library for Typescript, Effect boasts an API for nearly every situation, which can be overwhelming. Yet, mastering just a few of the most common ones can go a long way.
So, how would our production-grade code example look like in Effect?
const getTodo = (id: number): Effect.Effect<
unknown,
HttpClientError | TimeoutException
> =>
Http.request.get(`/todos/${id}`).pipe(
Http.client.fetchOk(),
Http.response.json,
Effect.timeout("1 seconds"),
Effect.retry(
Schedule.exponential(1000).pipe(
Schedule.compose(Schedule.recurs(3)),
),
),
Effect.withSpan("getTodo", { attributes: { id } }),
)
This code is significantly shorter and more modular. Admittedly, it might be challenging to grasp what's happening if you're not familiar with the syntax, but it illustrates the power and potential of adopting Effect for Typescript development.
Conclusion
In this post we did not go into how to use or what effect really is. We talked about the problem it solves.
What does the future of Typescript look like, in your opinion?
Resources
This post is heavily inspired by the insightful talk from Johannes Schickling the founder of Primsa. You can watch his talk here
The effect website. Be sure to read the docs
Join the Discord: https://discord.gg/effect-ts
Learning resources:
Top comments (1)
Effect is a wonderful solution. I wouldn't have believed that it fixes TypeScript if you would have told me that before I tried it myself.
But, to be honest, it's still not elegant enough.
If you have tried other languages that compile to JavaScript or TypeScript (e.g. when you want to share types), you will understand what I mean.
I think languages like ReScript, ReasonML, PureScript, Elm are much better, but they fragment the ecosystem and interop is a chore (no-one likes to write external bindings).
This is also why I am unsure that WASM will be able to fix this issue either, even though it is very obvious that the middleman (JavaScript) must be removed (compile directly to bytecode the browser can run, instead of JavaScript).
The issue remains in the ability of the platform and the stakeholders to re-standardize on a different language.
JavaScript happened by mistake. My hope is that standardizing on a language like ReasonML or ReScript will also happen largely by chance. I think these two languages are probably the best candidates to replace JavaScript and TypeScript, because they require very little manual typing (ML seems to me to be the best paradigm for the web, the language needs to remain terse and fast to write, to feel "scripty").
Ultimately, I think the power is in the hands of those developers with a lot of experience that can dictate the direction of their next projects and aren't afraid to gamble a bit.
Here's me wishing us all the luck!