Hacker News Reader

Comment by alttab | Hacker News Reader

What's been your experience with browser-side debugging? The one thing that scares me about typescript is you end up debugging something you didn't write.

View on HN

Yes, good question.

I use VS Code (with the Chrome debugger plugin) and that works like a charm. I don't debug javascript in the browser anymore.

TS provides source mappings to map the compiled javascript back to the source (similar to a .dll's .pdb maybe?).

It took me some time to set up the config file which proved to be a headache (because webpack was screwing with the source maps), but again once that was set up it has been a breeze to debug right in my IDE whenever I want.

That's been my experience too. Also once angular-cli seems more stable, I will probably switch to it and delete webpack (I know angular-cli uses webpack behind-the-scene, but at least I don't have to deal with it directly)

Odd, I'm new to vscode, but I tried to set up this plugin and it was completely unusable to me.

Perhaps you can describe the steps you followed? I tried installing the plugin and launching chrome with the debug flag, then setting a breakpoint in vscode. Is there something I am missing there?

You can tell the Typescript compiler to generate source maps that allow you to debug your Typescript code in the browser with a single configuration item in tsconfig.json. Chrome (and maybe Firefox?) will download them by default when you open up the debugger.

By default angular-cli produces source maps in dev mode. These work transparently when viewing source and using breakpoints in Chrome, Firefox, Safari, Opera. Just install @angular/cli create a project and a few components and check it out: https://github.com/angular/angular-cli

That's why I'd personally prefer Flow for that. It has a more elaborate type system anyway. [1]

Moreover, Flow is pure annotation, which can be removed by Babel. And Flow is also backed by a large company (Facebook instead of Microsoft).

However, if you do want to generate JS, use a language that elminiates runtime errors almost completely, such as Elm or OCaml (through bucklescript or js-of-ocaml).

[1] The following presentation contains some scary examples of incorrect code not rejected by Typescript. I'd rather prefer Flow which errs on beeing too strict: https://djcordhose.github.io/flow-vs-typescript/elm-flow-typ...

Your comment neglects to mention that Typescript debugging is generally easy because one of the design goals of typescript is to produce javascript that matches what a developer would write.

Debugging javascript produced by Babel is generally hell in comparison. The transforms done by Babel are not designed to be human readable and they generally aren't.

Whoops, you are right. Removed the misleading part of my comment.

>And Flow is also backed by a large company (Facebook instead of Microsoft).

Only Facebook doesn't care much to back or promote Flow, besides the occasional blog post, whereas Microsoft has created a whole IDE / VS Code support for it, great tooling, documentation, etc.

At least in Chrome it'll pick up the mappings and let you directly debug the typescript you wrote. Worst case the javascript isn't nearly as gnarly as you'd think.

But then you need to be good at Typescript, React, AND Javascript to build a feature. And that's not even considering databases, server middle ware, etc.

Great question. This is a cause for concern for me as well.

Reply on news.ycombinator.com