I don't think that's it. I write pretty much exclusively typed code, except in places where I've not managed to get everything set up properly (mainly old Vue2 code). And even then, imports are unidirectional: JS can import TS, but TS can only import other TS files.

As to the "world of uncertainty", this lasts surely less than 100ms for me, certainly little enough time that it feels instantaneous. Usually I get feedback as I'm typing, sometimes if I'm doing things in new files I need to save the file first, but either way, my IDE is consistently fast enough that I know immediately if my code type checks or not. There is no downtime here at all.

As for seeing the code change, I usually have the page open on a second monitor, so I press "save", and glance over to my second monitor, and with live reload and a good configuration (that's harder to achieve on some projects, I grant you), I'm usually already looking at the results of my changes.

In practice, I very rarely have any uncertainty about what typescript thinks my types are - this information is always immediately at my fingertips. Where I do have uncertainty sometimes is whether the javascript types match the expected typescript ones - this often happens when I'm dealing with third-party libraries, particularly when `any` types start popping up. In that case, it's occasionally useful to ignore the type checker altogether, play around with some different cases, and then come back to ensuring that the types match later. That's just not really possible if you're treating the type checker and the compiler as an all-in-one unit.

right but livereload has the same problem as you: The build is already done so it reloads but lets say the typecheck will error out because surely you save a file more often than you want to recompile. So your page just reloaded which you didn't intend, in fact, it might actively have destroyed a debugging session which you didnt want to reload yet. How do you configure that away to make it work sensibly? And here is the kicker: I know you can configure your livereload build so it only reloads after the build and the typecheck are done. But this is precisely how we ended up discussing this.. now you always depend on both the typecheck and the build to end before you can test your change anyway.

I suspect we're just used to building code in very different ways. If you've not tried approaching typescript as a linter rather than "just" a compiler, I really recommend giving it a proper go - it feels very freeing, and I think is one of the biggest advantages of typescript as a tool/concept. (It obviously has its own disadvantages compared to how, say, a traditional AOT compiler would work, namely that tsc can never really take advantage of types at all during the compilation, but it gives you a lot of flexibility during development - essentially the best of both worlds for dynamic and static type systems.)

That said, if you've already tried it and know it's not for you, then fair enough - ultimately all of these tools are just ways for us to write code, so if you write code best in this way, then I don't want to try and force you to do it some other way!

You're right in saying that having a clean and understandable development environment has a lot of complicated moving parts! Dropping the ball on any one of them means having a bad developer experience.

Since I've said this on other comments, I'm not going to dwell on the fact that this behavior isn't something Webpack itself solves. However, if you make a change in a .ts file, two things typically happen in a dev server:

1. Your code is retranspiled and rebundled, usually using partial recompilation. 2. Your IDE sends these updates to the TS language server that powers your IDE's TypeScript support. That server uses the same typechecking logic as the TypeScript compiler, so it's a good source of truth for surfacing type errors in the files open in your IDE.

Depending on your dev environment, one of a few things might happen next: 1. Your dev server might hot reload the changes in your browser once the build is finished. 2. Your dev server might also block reloading if a type error is found. 3. Your dev server might even show you that error in your browser so that you know what's going on.

Next.js currently does all three of those things, which makes for a really nice developer experience. You don't really have to keep an eye on another terminal — everything shows up in your browser. They even render a little loading icon to let you know when a rebuild is taking place.

Next.js uses Webpack internally, but Webpack isn't the reason for this nice developer experience; it's just a core part of it, and is only responsible for bundling and rebuilding.

I love talking about this stuff, for what it's worth, so feel free to ask more questions. I helped Etsy adopt both Webpack and TypeScript when I worked there, so I have a good chunk of experience in the area.