I don't know about Flow, but in Typescript you can still fire up a REPL and play around. The difference is that the typechecker validates every command you run. This is enough for small experiences, e.g., when you want to validate an algorithm. But yes, in the case you want to rerun your application to test your changes, the feedback cycle is a bit longer. But I find acceptable considering that static-typing makes refactoring significantly easier and less risky, which is important when working on large projects.

How do Sherpas get around without canoes? How do Amazonians stay warm without an Igloo?

I can't speak for Flow and Typescript, but I've been teaching myself Elm after a decade of JavaScript development. Elm has a very strict static type system, compiles to JavaScript, does have a REPL, and isn't readily debuggable like normal JavaScript.

Like any comparison of programming languages, you come to rely on features F, G, and G because your usual features X, Y, and Z don't make as much sense in the new language.

Elm famously promises that if a program will compile then it will run without runtime errors, and delivers on that promise. As a consequence, more time is spent in conversation with the compiler in exchange for never having to step through a program and see where things went wrong. A working program just "snaps together" and lets you safely refactor or move on the next feature. The feedback loop in Elm is very fast because you don't have to run your program and play with it in order to see it fail.

As far as I can tell the Elm REPL can't analyze types in the way that the compiler can, so it's not really useful except to experiment with basic functions and values.

Most JavaScript projects I work on these days have some kind of build step, whether that's limiting or minifying or transpiling ES6. So no difference there, except that the Elm tooling is nicely integrated and doesn't require as much futzing around.

All this to say that a step through debugger might only seem essential if your program can be run in ways that require debugging.

Typescript is written in itself and compiled to JS. You can use Typescript directly in the browser if you have the inclination. There's still speed tradeoffs, but you can even play with a Typescript REPL (http://www.typescriptlang.org/play/index.html).

There's a growing set of tools in the build tooling space called "Hot Module Reloading" (HMR). Webpack and JSPM/SystemJS both have picked up HMR tooling of different capabilities. HMR is very similar, from what I can tell, to the skewer-mode example you have posted: HMR tools watch for file changes, rebuild the bare necessary for those file changes, and via websockets between development server and browser communicate "live" reloading of modules as you work.

The work in HMR space is pretty impressive; I've started to rely on it in some webpack-built projects lately.

That said, "build step after every change like you're a C++ programmer" is a workflow that has survived a long time. There are some developers that prefer the comfortable routine of that workflow.

As a professional web developer who uses TypeScript (disclaimer: MS employee, not on the TypeScript team), I don't find that it impacts in-browser debugging. TypeScript has the ability to generate map files, but we don't use it because issues with our tooling. I don't miss it though, because the generated JavaScript is pretty close to the TypeScript (we target ES5, if you can target ES6 the mangling is even less). Once you learn the common patterns (methods get mapped onto the prototype, fat arrow functions get compiled to regular functions with a _this variable) it's pretty straightforward to debug in the browser.

The dev inner loop is maybe a little slower with the compile step for us, but it is possible to use TypeScript's automatic compilation with webpack and Node and all the latest hotness and get automatic build/deploy/refresh (see Office Fabric: https://github.com/OfficeDev/office-ui-fabric-react)

It hurts the REPL experience a lot. You can still open the Console and execute JS in the context of your application, but you'll end up working in the transpiled JS, which might look very little or nothing like the source code you've been working on. It's annoying to the point that I don't bother doing it often any more. I think ClojureScript might be an exception to this, though, so if you're a lisper that's probably something you'd want to look at.

I don't find it makes much difference. If I get any runtime errors, you can add breakpoints into your code and the compiled TypeScript looks very similar to the JavaScript most of the time, plus you can use sourcemaps. The test code you type into the console doesn't need to be written in TypeScript either. The build step going from editing in an IDE to the code running is only a couple of seconds maximum as well.

Getting more errors to appear in your IDE at compile time compared to in the console speeds you up way more than any slowdown you'd get too e.g. being told a variable could be undefined at compile time is much faster to fix than having to wait for a runtime crash, you having to track down the cause then hoping you've fixed it.

I use WebStorm and debug TS inline all the time. There's definitely a lag from doing straight JS in dev tools, but I'll happily take the extra hit for the benefits of a transpiled language. Raw JS can be a pain in the neck to debug if the code you're working through is poorly written. You can still write bad TS, but it's less likely.