Paris Typescript Conference Report - Afternoon

The TypeScript community gathered in Paris for the first time for a day of conferences dedicated to the language. Covering best practices, emerging tools, and valuable insights, this edition offered an opportunity to explore a wide range of topics.

We already covered the morning talks in a previous blog post. Let’s dive into the afternoon.

TypeScript meets IoT: safe programming for embedded devices

Soumaya Erradi - Senior Software Developer, Atlantis

Soumaya started her talk with a quick look at Arduino, an open-source electronics platform designed for building digital devices and interactive objects. Launched in 2005 in Italy and quickly became a favorite among amateurs, educators, and engineers.

Its key features:

• Microcontroller-based: Ideal for controlling sensors, motors, and circuits.
• C++ based development: Uses the Arduino IDE.
• Beginner-friendly: Lots of tutorials and an active global community.
• Applications: Robotics, home automation, education, and prototyping.

Then Soumaya talked about Firmata, the protocol that allows the communication with microcontrollers from interface software on a computer, letting developers write JavaScript/TypeScript code to control the hardware in real-time.

She talked also about Johnny-Five, the JavaScript/TypeScript framework for robotics and IoT. It allows developers to control hardware via Node.js.

She explained how Johnny-Five offers TypeScript support and makes it easier to build structured and type-safe IoT applications.

During her talk, Soumaya demonstrated a simple IoT project using TypeScript and Arduino.

She explained how the developers can profit from the strengths of TypeScript - type safety, scalability and maintainability to bring structure and reliability to IoT projects.

Whether you’re working with a Raspberry Pi, an Arduino, or an ESP32, integrating TypeScript with Node.js and libraries like Johnny-Five or Espruino opens up new possibilities for writing robust code that interacts with hardware in a clean and organized way.

Did you catch my expression

Orta Therox - ex-TypeScript Complier Team

Orta started his talk from the idea of who has the control in a system, he talked about his games website Puzzmo as an example of the need to give the people and the admins of the site the ability to write small snippets of code using embeddable expressions with clear constraints.

He talked about one solution using eval, although it is a powerful solution but there is a grand risk because it could result in the execution of malicious code on the user's machine.

He compared another solution of parser javascript expression as jsep , espression and angular-expressions as shown in the table below

He explained the possibility of adding dev tools such as AST explorer, TypeScript AST viewer and angular-expressions and the power of these tools to help non-dev users.

You can find more examples in his github account.

How to infer a dynamic list of type arguments... kind of

Mateusz Burzyński

This talk was by far the more technical of the day. It aims to make the audience familiar with the concept of reverse mapped types in TypeScript.

It refers to a pattern where you invert or reverse the keys and values of a mapped type: you take a type where keys map to values and create a new type where those values become the keys and the keys become the values.

This is useful when you want to look up values in both directions using TypeScript’s type system. For example:

type ColorHexMap = {
  red: '#FF0000',
  green: '#00FF00',
  blue: '#0000FF'
};

type ReverseMapping<T extends Record<string, string>> = {
  [K in keyof T as T[K]]: K
};

type HexToColor = ReverseMapping<ColorHexMap>;

// gives
type HexToColor = {
  '#FF0000': 'red',
  '#00FF00': 'green',
  '#0000FF': 'blue'
};

To learn more about it, take a look at this blog post what the heck are reverse mapped types?

undefined

Pragmatic AI with TypeChat

David Rousset

LLM answers are good for humans, not so much for applications and code. Because they are texts.

We can ask the LLM to answer in a JSON format. But the format differs from one LLM to another. It is difficult to map the user intent to a schema. We cannot be sure that the LLM will correctly understand the schema. David wants to reduce the risk of errors and hallucinations.

It appears that LLMs can understand Typescript types and use them to format the answer as a valid JSON following those Typescript types.

Models are very good at parsing and writing valid JSON: the format is simple and ubiquitous. This is the same thing for Typescript types. By using this method, we can improve the quality of the LLM answer. “We switch from prompt engineering to schema engineering.”

David introduces TypeChat, a way to make LLM answers follow a defined Typescript type.

By giving the types to the LLM and the request made by the user, TypeChat allows to “integrate natural language into an application and work through well-typed structured data.”

TypeChat will abstract this method by:

• Creating the prompt for the LLM using the given types
• Validate that the LLM answer is following the given schema. If this validation fails, it will ask the LLM to fix its answer

You can find some code examples on the TypeChat Github repository.

TypeChat supports Typescript, Python and C#/.NET.

undefined

Debugging apps with Deno and OpenTelemetry

Luca Casonato

Luca came to present Deno, which now supports OpenTelemetry and how this integration works. OpenTelemetry is a standard for traces, metrics and logs. TODO to have better Observability on production environments.

Deno will automatically associate a traceId to the console logs that are made. This traceId is not displayed to the console, but can be found on the metadata of the log in any log viewer, such as Graphana. This means you can filter by this traceId and find all the logs associated with the request.

It will also automatically create a span for each incoming request. This is used to display a trace of the request. Outgoing requests have also their own span created, as a child of the incoming request span. We can also define our own span.

It handles async context propagation. This is useful in microservices environments where debugging can be difficult due to the distributed nature of services, making it harder to trace requests and identify the root cause of issues. Traces can have spans across multiple services.

To do that, we need propagation: we pass the tracecontext from one service to another when making a request. Deno will automatically pass the trace information for us between services : it injects the trace information into the outbound requests, and reads it from incoming requests.

Another OpenTelemetry standard support is metrics. We can send to our observability stack different types of metrics: Counter, UpDownCounter, Gauge and Histogram.

Under the hood, Deno is using AsyncContext. You can learn more on the Context Propagation Deno documentation.

Luca also made a blog post about all of this that you can find on the Deno blog and a live stream.

Conclusion

The conference was rich with a variety of talks, for all levels - from beginners to advanced - and covered both technical and practical topics. The breaks were great opportunities for exchanges with the participants, and overall a truly impressive organization.