I have tried both ways, and I agree with what you've said. It's not faster than hot-reloading, and it's not faster than TDD either given the tests run super fas

I have tried both ways, and I agree with what you've said. It's not faster than hot-reloading, and it's not faster than TDD either given the tests run super fast. Both are not too hard to achieve in the JavaScript world. However, I found where REPL-driven development shines and more productive, is when there's no specific requirement and the programmer is exploring things. Traditionally there are product owners, designers, and programmers in the team, and they work in the pipelines. Both the functionality and the design are settled, the programmer just needs to implement the functionality and the UI. Now just imagine in a small team there's no split between roles. One obvious way to work is to pretend there are roles: 1) design the core functionalities on paper 2) design the UI on Figma 3) write the code. Although this approach brings clarity, it's rigid and not pretty productive. A reasonable alternative is to do all the things altogether: design when programming. REPL-driven development is a perfect fit for this methodology. TDD, in this case, is not working well because tests need rigid boundaries to test on, if I write tests I have to erase them repeatedly because I don't have specific ideas of what I'm going to build in the first place. What about hot-reloading? Say if we are developing a game, and the player can jump, with hot-reloading, I still have to implement a button to jump, while with REPL I can send a piece of code to let the player jump without writing UIs for it at all. REPL-driven development provides a perfect playground that can be leveraged as a tool for both thinking and programming. In hindsight, TDD resonates functionality designs from product people - if it's settled we can write test cases and just implemented it. And hot-reloading helps a lot in implementing settled graphic design - because there's no better way to test graphic than just seeing it in real-time. If there is neither functionality design nor graphic design in the first place, we need new things to help us to do the all designs with our code, where REPL-driven programming is a perfect it. Rather I would call it REPL-driven design. To maximize gains from a tool, the way we work and think must be adjusted. As another example, many programmers who favor statically typed languages program in dynamically typed languages, usually don't write in the same way as those who favor dynamically typed languages, thus for them, dynamically typed languages are just net loss. IMO the REPL-driven design resonates with Paul Graham: A programming language is for thinking about programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. . This approach also reminds me of the 'Sketch HTML' approach in Getting Real from 37 Signals.