That must be a big number

Alan over at http://www.akbkhome.com/blog.php in a recent post claimed to have an idea for the perfect way to take the P out of LAMP. He proposes the idea of an Apache module that will talk directly to MySQL and return JSON for a JavaScript applet on the requester's computer. I can see a somewhat limited place for such a change, but I don't see it as the PHP killer Alan would like.

The biggest issue will be getting the web content spidered by search engines. Spiders have zero understanding of JavaScript and completely ignore that content. Thus if you want decent ranking in the search engines, you will need some sort of standard HTML delivered to those, as well as being able to deliver the dynamic content to your regular users. PHP fills this need very well.

Using this, you would also need to work with users, such as myself, that browse with JavaScript turned off unless needed. Firefox's NoScript extension is great. It keeps malicious sites (or insecure sites with malicious content added...) from being able to do anything to my computer. Until these security holes are fixed (and I don't expect that to ever be finished), I will continue to browse without JavaScript and ignore sites that require it just to move past the home page.

There is are also the problems of performance and portability. Many things are often quicker for PHP to do after requesting data from MySQL than to run using stored procedures in MySQL alone. As for portability, it can be more complicated to move your applications from one MySQL server instance to the next. There is also the possible problem that such an extension would be a effectively a direct connection to the database server. We all know the issue of SQL injection when user input isn't properly filtered and validated before being sent to the database. Now we would either have to add a new application layer inside Apache to handle this or have the database open to such issues.

If it can overcome the portability, performance, and SQL injection problems, I do see one space where it can be useful. Web services are becoming more and more common. This is a great idea to make the services more accessible. But even there, PHP is already very capable as a web service provider. It will take more than just being the "cool new thing" to draw me away from a language that I am very comfortable using.

JavaScript incompatibilites

It was just brought to my attention that Mozilla is beginning work on a new version of JavaScript (aka ECMAScript). Microsoft, however, would rather web technologies move forward their way, with an entirely new language. As a web developer, I have to side with Mozilla on this one.

We currently have a glut of web programming and scripting languages: from server side languages like PHP and ASP, to client side languages like JavaScript and Flash. Adding more ways to do things to your users' computers, without fixing the issues currently present is not the right way to go. The original ECMAScript was designed by Netscape to be simple and allow an improved user experience on a given page. This originally was mostly sandboxed to only affect the current page or guide users to new pages. With the addition of the DOM and XMLHTTPRequest this has greatly increased the scope of what a page can do, even to the point of allowing some malicious scripts to turn your browser into a zombie bot like regular malware would do to your computer.

Every new web technology has added its own issues and vulnerabilities. From PDF cross site scripting holes, to Quicktime and Flash user input vulnerabilities. Creating an entirely new language will just create more surface area for browser vendors to need to protect (or more likely not protect). However, in upgrading a current technology, Mozilla is only adding a little more surface area (only the new features) and possibly closing up old holes through bug fixes. After glancing over the white paper, many of the new features in JavaScript may lead to better, easier to manage code, with fewer user space bugs.

Microsoft's main argument is that by upgrading the language, rather than creating a new one, old scripts could break and backwards compatibility will be lost. While this could be true, one of the main goals of the ES4 Working Group is to maintain backwards compatibility. This means that, barring a few edge cases, and if all goes as planned, the barrier to entry for ES4 will be minimal, potentially only requiring a browser update (only for previously unsupported features) and, if the developer feels the need for it, training on the new features. However, uptake of a new language will be slow, both on the consumer end where users will have to upgrade their browser or download new plug-ins (anyone want another active-x situation?) and on the developer end where they will need to learn a new language, potentially buy new development tools, and still need to support the users who don't have this new software.

There is also the question of how open Microsoft wants to make it's new language. If history is any indicator, they may try to use it as a wedge to push people back to their browser. Mozilla, however, is an open source company; ECMAScript is an open standard.