I would reformulate the question.
Usually (in my experience), the goal is not exactly to get a prototype asap, but to be sure of what you'd get. So in the lines below I'm answering the question « What's the best way to prototype...»
And the stack itself could only be defined depending of the goals of your product. (And the tips from @JanVladimirMostert are really thoughtful) But ultimately, the difference between your prototype and your MVP is related to scale, reliability, ...
I mean:
for both, you should set the priorities of your features and your prototype will highlight the main features of your product, which are likely to be the ones you plan to build your MVP for (unless the prototype does make you realize that the killer features are not the one you thought)
you don't need to build your prototype to scale, whereas this is something important to think about it to set the foundations in your MVP
you don't need to care about technology debt in your prototype, so if you can use a stack that you know that might cause you issues for the real product (like some IE8/9 incompatibilities, or some legacy stuff you can use to build something quick, even if it's not something you want to use, like building an iOS app with a 32 bits middleware a few months ago, when you knew that 64 bits support was becoming mandatory, ...)
If I wanted to try to summarize it, for the prototype, you'd better choose any technology stack your team is comfortable to build something correct in a reasonable timeframe. But then for your real product (starting with the MVP), some other considerations (risk, perennity, scalability, security,...) might lead you to other choices.