Recently Mike Driscoll took a shot across the bow of the LAMP stack in an article called Node.js and the JavaScript Age. Arguing that the LAMP age (2000 to 2009) was about shuttling data back and forth from the database, he asserts that in the JavaScript age

The principal role of the server is to ship an application to the client (Javascript), along with data (JSON), and let the client weave those into a DOM.

Mr. Driscoll envisions a world where the server becomes “dumb” and the client increasingly becomes the brains of the operation. This comes after his team migrated a dashboard application from Django (Python) into node.js (JavaScript). Mr. Driscoll points are compelling. Imagine that after more than a decade of technology specialization we may finally be on the cusp of a fully unified web stack – mongodb as your data store, node.js as your server environment, and JQuery in the browser – based entirely on JavaScript. We could be witnessing the dawn of the JavaScript stack.

The benefits of the JavaScript stack are clear – code libraries shared across a homogenous team of JavaScript developers leading to reduced development and maintenance costs. All of your unit tests in one language! How can it fail?

In reality it’s probably not going to be that simple.

One big hole (pun intended) in Mr. Driscoll’s design is security. Yes, in some applications only 10% of your server-side templates are HTML. But that 10% is the core of your business, the bits of data you can’t expose directly to the client for them to tinker with – things like account numbers and product prices. This might not be critical for internal-facing reporting apps like Mr. Driscoll’s dashboard app but for public-facing dynamic apps like EBay it’s the difference between success or crash and burn.

Furthermore, current web development teams are specialized for a reason. Front end programming has different demands and patterns than does server-side programming, and these are both very different than database design and programming. Startups and smaller teams might have rockstars who operate seamlessly across tiers, but these developers can be hard to find. So even though JavaScript might be a common language across application tiers, the reality is that as your team grows you’ll still need specialized developers to be effective across all three.

Lastly, even though node.js promises performant asynchronous application design, the truth is that many developers face a steep learning curve before they can be effective programming (and debugging) in asynchronous environments. Like Java threading before it, asynchronous programming will likely find its niche solving certain problems but never become mainstream. Or it will be hidden behind so many layers of framework programming as to be nearly unrecognizable and totally unusable.

So LAMP is far from dead. It will persist exactly because it’s a perfectly tuned commodity solution in a market that values commodity solutions (e.g. Google’s famed server farms). It’s the UNIX of the web layer, encouraging extensible designs by nature of its simplicity and interoperability.

Every age has its upstart, and this age is no different. But to win the upstart has to bring more to the table than the established solution, and it remains to be seen whether the JavaScript stack has what it takes to displace the LAMP juggernaut.

In an article I had published in infoTech Spotlight discussing security and the Gawker database hack, I argued that it’s relatively easy to protect your user’s personal data against a database breach. The idea isn’t new – as a matter of fact this particular implementation dates back to 2005, and you can be sure it was known well before then.

Faced with a similar breach, Mt. Gox appears to have performed a little better. Although they originally depended on md5() hashing to secure their passwords (warning: do not do that), they came to their senses and started salting individual passwords much the same way as this article recommends.

Good for them. This is a great case study on how an organization who borked it was able to retrofit their code to protect their users. I applaud them for that effort. It may not have been perfect, but it was likely good enough for users who were smart enough to protect an account on a financial exchange with a half-way decent password.

As an aside, it’s a little disturbing how many of the nerds on the Hacker News don’t understand that not only is it ok to store the salt alongside the encrypted passwords in your database, it’s actually a good idea. Ugh. Another reason why developers should never be trusted to roll their own authentication schemes.

Unfortunately, Mt. Gox’s security lapse has come at a crucial point for Bitcoin. Bitcoin is an interesting economic experiment. I encourage you to read up about it as the official docs can explain it much better than I can here.

While it’s strictly true that Mt. Gox != Bitcoin, at this point in the evolution of the movement few people have the sophistication to understand the difference. So it might not be fair, but it’s still entirely possible that this incident could torpedo the movement. That’s unfortunate for many reasons, but it’s a reality of the world we live in. An upstart economy can’t prevail without trust.

It seems that 8 lines of code may not be enough.