There’s a continuous revolution taking place in web development as platforms and tools evolved first to handle dynamic pages and now cloud services. But sometimes what goes around comes around so I’m predicting a resurgence of Java and Java-like languages as rotating storage goes into decline.  Here’s why.

In the beginning of the web we wrote web apps with Perl and C++ because that’s all we had.  This sucked.

C++ is awesome for anything requiring intense performance but because it operates at a comparatively low level (closer to the silicon) C++ is very hard for dopes like me to use. And in a way it’s an insult to the language, which gets bored waiting for databases and network requests.

To avoid the complexities of C++ we turned to Perl which was fast to write in but wasn’t ready to be a web server. And Perl had no frameworks to help write web apps so we wrote a lot of boiler plate crap every time just to get started. Sure CPAN eventually brought libraries to help but it was still fragmented.

When Java arrived it wasn’t so interesting that we had Java, it was interesting that we had the Java Virtual Machine. JVM’s took care of cleaning up memory and automatically profiling and optimizing our programs — tasks that had to be done by hand back in C++.

Java also had threading really well integrated from the start so we could handle many requests at once which was starting to become a problem by 2005 or so. Multicore’s introduction hit just at the right time for Java, too. Compiled Java is a very high-level machine code but is a standard that JVM engineers have had more than a decade to tune so it works very well.

.NET was really just another Java for Windows. Nothing is fundamentally awesome about it over Java except that the engineers got to learn from Java’s mistakes.

Java’s performance was no C++ but it was way better than perl’s and again, we didn’t need all that much. What we needed was faster development and we got it.

Yet in the last few years since, say, 2007 we’ve been moving away from Java and .NET for web development and back to interpreted dynamic languages like Ruby. These are slow as molasses (though now our CPUs are much faster) but easy to program for a broader, younger, and maybe less experienced crowd of developers. Prototyping new websites and apps has become very easy, which is why there are so many bad ones out there.

The difference between the old days of Perl and today is that we’ve made the real web server in C++. So performance in Ruby is helped by a lot of work done in C++. Since every app needs to do that work, we can write it once and lay Ruby on top to make connections, talk HTTP, etc.

Under Ruby, we put C++. On top of Ruby we put the Rails web framework.  It’s not very common to actually code anything in Ruby.  You pretty much only see people coding Ruby while using the Rails framework which governs the whole thing.

You can replace Ruby here with Python, Django or Groovy and it is still correct.

Notice the transition? We started with Perl, went to Java, then came back to Perl!  The reason we didn’t literally do that (actually go back to writing in Perl) is because the kids who wrote Rails were too cool for Perl, which they saw as old school. But Ruby has nothing on Perl. What’s brilliant is the Rails web framework, which came about because of what people learned writing web apps in Java. There are lots of web frameworks in Java, but that was part of the problem — knowing which of the many Java web frameworks were any good.

Ruby is easier than Java. It runs something like seven times slower but who cares? We’re still waiting for the database. And if you are a new developer you can learn Rails and be one of the cool kids.

Java has all the fantastic data structures you learn about in school while Ruby has only hashtables and arrays. But if you don’t give a rat’s ass about performance you can shoehorn anything into hashtables and arrays. That’s why prototyping is so fast in Ruby.

Yeah, but there’s a problem looming for Ruby and Rails (Python, Groovy, etc.) and it is that web frameworks based on interpreted, dynamic languages only exist at all because disks are just so damned slow.  What happens to these frameworks when disks get faster or disappear entirely?

A modern disk seek is around five milliseconds. That means we can get only about 200 disk seeks per second.  Every non-cached database access will do several seeks (BTree datastructure, Mr. Smartypants) and every web page usually requires several database accesses to construct the page. In other words, its not uncommon to take half a second in just doing disk seeks for your local database!  And of course it gets worse, much worse, if seeks across the network are involved.

But if you replace spinning disks and moving read/write heads with Solid State Disks (SSDs) and no heads at all, local seek times drop to zero. That’s why Ruby and its surrogate languages will eventually disappear.

When SSDs gain enough capacity there will be a shift from the Ruby world back to the Java world. Not for prototyping, because, well, it’s prototyping. But simply because the statement “Ruby is incredibly slow but I don’t care because my database is slower” will no longer be true. At that point Ruby (Python, Groovy, you name it) becomes the bottleneck.

The big story here (since from the comments below it apparently wasn’t obvious) is the JVM.  Ruby is already migrating to that JRuby as will all similar tools. So far, it just hasn’t mattered that much — but it will.