Well, what I really want in 2016 is a Java powered flying car
-Dustin

Yes, these are exactly the kind of things I have in mind…

I think that you could also use the same kind of principles than Pylons in Python and route HTTP requests to object methods. Being a XSLT fan, I would suggest to use XSLT as a templating language and get a nice and competitive framework!

Eric

The JavaScript on Rails framework that I am dreaming of wouldn’t be especially targeted to rookie developers!

That being said, you are raising a very valid point and many developers badly need to be trained on Web technologies and especially on HTTP. In fact, this feeling has been my initial motivation for publishing “Professional Web 2.0 Programming“.

I’ll also add that there are probably more benefits in using the same language client and server side than copy/pasting documents! On the contrary, I’d even say that the main benefit is to avoid copy/pasting like we do with algorithms if we don’t have the same language…

Eric

For instance, a typical contemporary server side JavaScript might look something like:

Servelet.getInstance({
paint:function(){
var authState = (new Authenticator()).authenticate(
Request.params.name,Request.params.password);
if (authState){
Response.write(<div>
	<h1>You're in!</h1>
	<p>Hello, World!</p>
</div>);
else {
Response.write(<div>
	<h1>Fat Chance</h1>
	<p>Go away!!</p>
</div>);
}

});

This assumes that you’ve passed your functionality as an object instance (so you could conceivably use JSON here, though it’d be an incredible security hole) and that you have Request, Response, and Authenticate objects available (not to mention a little E4X, though that’s not a strict requirement.

JavaScript is used as a binding and glue language, and is quite good in both of those roles. I don’t necessarily see this being any worse than PHP, and the syntax is closer to the C++/Java model than Ruby, Python, or PHP.

The thing I really don’t like about applets is that they break the web architecture still more than bad Ajax applications do!

Anyway, we’ll see in 2016 if one of us was right…

Eric

10 years ago everyone complained about how slow Java was on the client side, and they were right, but these days nobody complains about it (read: Moore’s Law). I use Eclipse every day, and I think it’s a great app. Azureus is another client side Java app that works great. In fact their latest version, Zudeo (http://www.zudeo.com/az-web/app), installs via Java Web Start, one of the first real apps I’ve encountered to use JWS, and it is incredibly slick. I think we’ll likely see more apps like this. Just looking at my dock, I’ve got JEdit, AquaData Studio, Oxygen XML Editor, and Oracle SQL Developer. That’s (with Eclipse and Zudeo) 7 java apps that I use every day! I realize these are mostly developer apps, but I think as Linux UIs get better and better, more people will substitute Linux for Windows and it will make sense for companies to make consumer apps in Java, like the new Azureus, since it can run anywhere. JWS is great because all of the installation/updates/distribution framework is already there, and easy to use.

As for JavaScript on the server side. Sounds alright with me if someone builds a nice framework around it like Rails or Grails (as you said), but I don’t see any real need for it to happen. In fact, if XForms ever becomes a reality, it will pretty much do away with JavaScript on the client side (except in special cases). I admit a bias though - JavaScript just seems like a mess to me, and doing a large scale project with it sounds awful.

Just my 2 cents,
-Dustin