Hacker News Reader

Comment by lacampbell | Hacker News Reader

How does the development cycle work? With plain JS I load up my html page in browser (chrome) and head to the console to check for errors in the JS. Then I do user testing.

Can type-script be debugged by a browser on a source code level - ie not on a transpiled level? If not, I am not sure if it's worth it. And I say that as someone who is a huge fan of explicit optional typing.

View on HN

There is typically a quick transpile process in the IDE/toolchain of your choice. Most browser dev tools now support sourcemaps quite well which means that debugging shows the TS source and breakpoints are set directly there and typically show error stacktraces with your TS files.

Another option is to load Typescript in your browser and let it transpile directly in the browser. Sourcemaps in this case are a bit more iffy in their browser support, but it can be an option for a quick debug cycle if you wanted to try something like that. Not particularly the fastest idea for a production app, though.

The development cycle is basicaly this: write Typescript code in a .ts file, transpile to a .js file, load .js into html. Transpiling can be handled by the IDE or by a build tool like gulp. For example, IntelliJ Webstorm has a built-in file watcher that tracks changes to .ts files and transpiles accordingly.

Typescript can be debugged on a source code level, using source-maps. Webstorm and VS Code have built-in or plugin solutions. I heard some people complaining about issues, but i had a pretty smooth experience so far.

In theory source maps is the answer but personally this has only worked some of the time. When it does work though it is magical and exactly answers your question of debugging in the browser at the source level.

Reply on news.ycombinator.com