> But how exactly do you go about doing unit tests of the front end of a web application?

Unit testing in PHP isn't different than in other languages. You split code into testable chunks and hammer them with PHPUnit.

> due to all the javascript stuff that lives on the browser these days.

How is that related to C++/PHP? And would you just run Facebook without unit tests? (good luck!)

Anyway, for JS there's Selenium and it can integrate with PHPUnit. UI testing is difficult, and browser-hosted tests are especially fragile and finicky, but that's not PHP's fault and C++ won't fix it.

> If there is so much PHP out there, why wouldn't/couldn't there be an efficient compiler

There is PHC and Roadsend.

However there are PHP-specific problems that make it harder than it should be.

PHP's "standard library" is heavily dependent on the interpreter, so you either lug it around and maintain its state, or rewrite 5000 methods.

And there's of course eval(), extract(), dynamic include/autoload and other magic that makes static analysis pretty hard or impossible.

Developers that are diligent enough to make only 1 memory-related bug/year can certainly spell variable names correctly.

If you have statically typed language, you rely on types. If you have dynamic, you rely on unit tests. Both are probably equally slow :)

This is not a problem in PHP.

If you have editor with auto-completion, misspellings are uncommon. Other kinds of errors are caught (and logged) as soon as faulty code is executed. With short edit-run cycle it's pretty quick.

It's not perfect, but OTOH C++ compiler won't tell you about all memory leaks, dangling pointers and buffer overflows at compile time.

C++ has runtime errors too, and you won't easily get logs with line numbers where your memory corruption happened.

They have 20 million Opera Mini users, 40 million desktop users, and very few desktop users will use Turbo.

That argument never stopped RIAA and MPAA before.

It has been discussed recently on HTML5 WG.

Browsers' UI for HTTP authentication so far is absolutely awful, and there's no standard mechanism for logging out.

Although HTTP Digest authentication does offer slighly better security than cookies, HTTP authentication is helpless against any MITM attacks.

There have been proposals to give HTML forms front-end for HTTP authentication, but they haven't gone anywhere, since there is little to gain (same UI as cookie-based auth, negligible security improvement) and backwards compatibility is poor.

That's exactly what Sblam! does.

It's PHP-based filter for web forms that detects spam based on content (bayesian filter + specific rules), behavior and uses 3rd party blacklists.

It's absolutely transparent to the user (well, 99.8% of them).