I think Toyota is planning to debut hydrogen cars in Japan, not in america.

With the recent news that they'll be renewing nuclear generation there. Producing hydrogen should be much easily done at the plants.most of the energy to split water can come from thermal, making it much more feasible. Also I don't think Japan has such great oil reserves so switching to a non foreign dependent energy source is smart for the country.

if you have any projects that can be publicly shown, they sometimes speak louder than experience in a resume. (especially if they deal with the technology/skills companies are looking for)

Math is sometimes useful for specific jobs like finance, 3d graphics, and you may find yourself in trouble if trying to grok details of those projects. However strong Logic sense should serve you well on most other projects. overall I think a strong background in algorithms, data structures trumps that of math. You can always look it up or ask someone for those rare cases where you deal with a tricky math problem.

Seems many technologies already do this like VNC.. services like onlive does streaming video as well.

Not necessarily. If the salt or part of the salt was a "Proof of work" package, it could be offloaded to the client side.
i.e.
my password is stored in regular hash/salt format, the salt being a challenge string.

The proof of work would be to vary the challenge string on a pre-agreed upon mutation, and produce a hash of the mutated string so that the value starts with 0000. That hash added to a secondary salt based on the challenge string constitutes the actual salt. Naturally the proof of work can vary with hardware improvements.

Now I can off load most of that work to the client to calculate the salt for me.

From a language side, much of the problems you mentioned can be solved via the provided sdk. Like the old CS saying, all computer programming problems can be fixed with adding another layer of indirection. e.g. Memory leaks can be controlled through malloc by just discarding the block after the user leaves the page.

Difference between this and javascript would be that there's little waste features like a GC that runs in the background. Overall getting C/C++ to compile has much more research and accumulated experience then Javascript. This would close the 10x gap between current native JS vs C app.

>compiling C is not necessarily all that fast. Compile time does matter for the web. I would welcome data about relative compile speeds of C and JS, though; I don't have hard data on this.

JS is now both interpreted and compiled. It is first run in interpreted mode, when the optimizer figures out which code/function should be optimized, it would compile that block, and point the execution pointer of that call to the new native code instead of running the interpreted branch. Thus compilation runs on a backend thread and time is somewhat irrelevant. Same could be done for C.

This actually brings an interesting point, why compile from source each time, huge amount of processing power is wasted from analyzing the syntax and performing the first few passes on the code. This would suck the power from a mobile device quicky. A better solution is to include an intermediary bytecode directly into the page. It would require very little translation/linking to convert into final native code.

Here's an idea, why don't browsers allow developers to embed direct C code. each browser includes some standard static libraries for the calls the code can make, which would provide the sandboxed environment. When the page loads, the browser can fire up gcc to do the compiling prior to running. Everything would then be native, No more effort spent on trying to optimize a language what wasn't meant to be fast in the first place. it would be much more power efficient to run on mobile devices too as you don't have to have the overhead these dynamic languages impose like garbage collection, and tracing/optimzation.