No it isn't. NaCl is a great proof of concept. It shows that you can sandbox x86 apps using some static analysis of the binaries and a few other constraints (it also showed that segmentation support on modern x86 chips is pretty poor and terrible on Atom). The problem is that it only works on x86 binaries. What proportion of Web use these days is (ARM-based) phones and tablets? 20%? If you make something that only works for 80% (and falling) of your customers, then that's a problem.
PNaCl is promising, but it's currently in early draft stage. It hard-codes some things into the ABI too early and misses other important things (e.g. no mechanism for exceptions, and they're very difficult to implement correctly in a PNaCl model). And, unlike NaCl, PNaCl relies on a complex compiler being bug free for security, and we all know how well that worked out for Java...
Single-bit errors in DRAM are caused by the capacitor that stores the data being discharged. This means that the transitions happen in one direction: from charged to discharged. With parity RAM, you can tell that an error has occurred, but you can't tell what the error is. The parity and ECC checks happen in the the digital circuitry and so have no knowledge of the analogue state. Since ECC uses Hamming codes, it can detect more than single-bit errors, but it can only fix one bit flip (the bias isn't actually required, but it does make the code shorter).
A list is only as strong as its weakest link. -- Don Knuth