Text in the screenshots is barely readable. It should be comparable to default text size.

That's great feedback, thank you!

We'll go through screenshots, check their readability and crop or re-create them before going to print.

Can you point to particular screenshots that feel the worst?

I think I saw this template before. What software did you use to create the book?

Pragmatic has an inhouse book compiler. Most authors write in markdown and there's some special XML features you can use as well for it. Of course code linking is a first class feature.

It's a pretty nice system, actually.

Exactly. I wrote in (flavored) Markdown with occasional XML inserts.

How did you enjoy the process?

I did, thank you! It was hard and long, though. Much harder and longer than I expected it to be. The book ended up being very different from what I initially conceived (for the better, I hope.) I have too much to say to fit it all in one comment, to be honest :)

Great that you finished :)

Do you have a next book project lined up?

Thank you!

Not really. I am almost sure that eventually I'll do it, but what I have at this point is more like "dreams" or "ideas", very far from being materialized.

Also, I know that I want to write about something less practical and more fun. Maybe, making music. Writing about fun parts is so much easier

> What You Need: A computer with a Chromium-based browser such as Chrome, Vivaldi, or Brave [...]

I believe the book focuses on client-side TS apps?

I build a "wrapper" for this (not public, quick&dirty code). Transfer everything that could be logged via websocket to console and output and colorize it like I do it with a node app. Reduces the time that I need to spend in browser for debugging (click, scroll, open trees, etc.), has same format and it saves much time.

I am sure somebody created a good lib for that on github.

Node.js uses the same JavaScript engine as chrome and chrome dev tools can be connected to node to debug and profile.

node --inspect

chrome://inspector

Mostly yes. It touches upon debugging unit tests and server-side code, as well as methodologies applicable to debugging in general, but the practical parts are almost exclusively client-side.

Nice to see someone tackling debugging in TypeScript head on... the discussion about templates and in‑house compilers is interesting... I always appreciate when authors share their process...

ALSO when it comes to debugging TypeScript I lean heavily on a mix of tools and best practices... Visual Studio Code’s built‑in debugger and Jest integration make stepping through code a breeze... I combine that with custom type guards and strategic logging to catch errors early and make the stack traces meaningful...

I’m curious if you dive into production debugging and error tracking... things like source maps and disciplined logging can save hours when chasing bugs in the wild... thanks for sharing your experience and good luck polishing the final version...

I totally agree.

At first, I started writing a book about very practical, hands-on debugging practices, but quickly realized that the "mix of tools and best practices" you're talking about is a much more valuable skill, as well as bug prioritization, and even bug reporting.

So, as a result, catching errors early, type guarding, logging to debug asynchronous operations, and error tracking are all major parts of the book.

vibe coded?

no

let me read it to verify