As an older die-hard DRY coder I was a little flummoxed to have to accept a pretty substantial copy/paste-coding approach in a non-production prototyping scenario. JavaScript developers tend to lean on copy/paste more than other languages in my experience, but I fought a losing battle on that front.
The situation was a pretty complicated one:
If this had been a production context I would have more strongly argued for a fully DRY, fully tested approach. It's actually a great case for integration tests being able to provide added security. But since the requirements were driven by visuals and constantly-changing specs, it just turned out that it was too heavy-handed of an approach, and in fact the more we tried to share any part of the app that differed the messier things became.
We ended up continuing to share a large portion of logic, structure and components between the 2 app prototypes, but moved to a fully non-DRY approach for anything with significant differences. Of course that led to sloppy cases where similar logic was not maintained across both apps, and all the expected problems that can arise from non-DRY code duplication, but since it was a prototyping context it didn't matter as much.
Again, in production I would suggest that everyone (especially JavaScript coders!) try and adhere to DRY strictly. But I also learned that there are certain cases where strict coding standards can end up adding drag to a fast-moving process.